Ошибка 502 Bad Gateway в WordPress: пошаговая диагностика

Коротко: ошибка 502 Bad Gateway: ошибка 502 означает, что веб-сервер (Nginx или Apache), выступая в роли шлюза, получил недопустимый ответ от вышестоящего сервера, например от PHP-FPM. Для устранения последовательно проверьте доступность сервера, логи ошибок PHP и веб-сервера, состояние PHP-обработчика, лимиты памяти, активные плагины и кеширующие слои. В большинстве случаев проблема решается перезапуском PHP-FPM или отключением конфликтующего расширения.

Ошибка 502 Bad Gateway на сайте WordPress способна парализовать работу буквально за секунду, но не стоит сразу обращаться в техподдержку — часто причина лежит на поверхности и устраняется без глубоких знаний серверной инфраструктуры. В этой диагностической схеме мы пройдём от самых вероятных источников сбоя до тонких настроек, чтобы вы могли восстановить сайт как можно быстрее.

Что понадобится

• Доступ к панели управления хостингом или серверу по SSH
• Возможность просматривать логи ошибок веб-сервера и PHP
• Права на изменение файла wp-config.php (опционально)
• Базовое понимание работы веб-сервера (Nginx/Apache) и PHP

Что такое ошибка 502 Bad Gateway и где она возникает

Ошибка 502 Bad Gateway — это HTTP-статус, который возвращает промежуточный сервер (чаще всего Nginx или Apache в роли reverse proxy), когда не может получить корректный ответ от backend-сервера. В контексте WordPress backend-сервером обычно выступает PHP-FPM (FastCGI Process Manager) или, реже, устаревший модуль mod_php. Когда PHP-процесс падает, зависает или возвращает мусорные данные, шлюз фиксирует некорректный ответ и отдаёт посетителю ошибку 502, прекращая обработку запроса.

Сценарий проявления может различаться: ошибка появляется сразу на всём сайте, только в админ-панели, на конкретных страницах или только при загрузке тяжёлых скриптов. Такая избирательность уже сама по себе сужает круг подозреваемых. Важно понимать, что 502 — это не внутренняя ошибка WordPress, а сигнал о проблемах во взаимодействии между компонентами серверного стека.

• Nginx возвращает 502, если не смог связаться с PHP-FPM через сокет или порт
• Apache с mod_proxy_fcgi выдаёт 502 при обрыве соединения с обработчиком
• Ошибка может возникнуть и при участии сторонних прокси — например, CDN или балансировщика

Быстрая проверка доступности сайта и сервера

Прежде чем углубляться в логи и конфигурации, исключите самые очевидные причины: физическую недоступность сервера, сбои в работе хостинга или проблемы с DNS. Иногда 502 маскирует ситуацию, когда сайт просто не открывается из-за превышения лимитов тарифного плана или временной перегрузки.

• Проверьте, отвечает ли сервер по IP-адресу (например, через ping или telnet на 80/443 порт)
• Зайдите в панель управления хостингом и убедитесь, что статус услуги активен, а дисковое пространство и трафик не исчерпаны
• Попробуйте открыть статический файл (example.com/readme.html) — если он загрузился, значит веб-сервер работает, и проблема именно в связке с PHP

1. Проверьте доступность сервера по IP, минуя DNS
2. Просмотрите графики загрузки ЦП и памяти в панели хостинга — аномальные скачки указывают на возможный fork bomb или утечку
3. Откройте статический ресурс: картинку или .css-файл. Успешная загрузка означает, что фронтальный веб-сервер жив

Важно: Если статика отдаётся, а динамические URL — нет, 100% проблема на стороне PHP-обработчика.

Анализ логов — главный инструмент диагностики

Логи ошибок веб-сервера и PHP — самый надёжный источник информации. В них вы увидите конкретную причину, по которой обработчик вернул некорректный ответ или упал. Без просмотра логов дальнейшие шаги будут гаданием.

• Лог ошибок Nginx обычно находится в /var/log/nginx/error.log
• Лог Apache — /var/log/apache2/error.log или /var/log/httpd/error_log
• Журнал PHP-FPM часто лежит рядом: /var/log/php*-fpm.log или в системном journalctl
• WordPress собственный журнал можно активировать в wp-config.php: define('WP_DEBUG', true); define('WP_DEBUG_LOG', true);

1. Откройте лог веб-сервера и найдите строки, соответствующие времени появления ошибки
2. Обратите внимание на сообщения вида 'connect() to unix:/var/run/php/php8.1-fpm.sock failed' или 'upstream sent too big header'
3. Просмотрите лог PHP-FPM: 'WARNING: [pool www] seems busy', 'max_children reached' или 'exited on signal 11 (SIGSEGV)'
4. Если ошибки неочевидны, включите WP_DEBUG и повторите запрос — запись в /wp-content/debug.log укажет на конкретный плагин или скрипт

Важно: Никогда не оставляйте WP_DEBUG включённым на боевом сайте дольше, чем нужно для диагностики.

Диагностика PHP-обработчика (PHP-FPM)

Самая частая причина 502 — проблемы с PHP-FPM. Процессы могут быть убиты из-за нехватки памяти, аварийно завершены из-за ошибок в коде или просто перестать отвечать из-за неправильно настроенного пула. Проверьте, жив ли сервис и достаточно ли дочерних процессов.

• Проверка статуса: systemctl status php*-fpm (подставьте вашу версию)
• Проверка сокета: ls -la /var/run/php/php*-fpm.sock — должен существовать и иметь корректные права
• Параметр listen.mode = 0660 или 0666 в конфигурации пула влияет на доступность сокета для веб-сервера
• Ограничение pm.max_children — если все дочерние процессы заняты, новые запросы будут висеть и вызывать 502

1. Выполните перезапуск PHP-FPM: sudo systemctl restart php8.1-fpm (версия зависит от окружения)
2. Проверьте файл конфигурации пула (например, /etc/php/8.1/fpm/pool.d/www.conf) на предмет корректности listen = /run/php/php8.1-fpm.sock
3. Временно увеличьте pm.max_children, pm.start_servers и pm.max_requests, если логи указывают на исчерпание процессов
4. Убедитесь, что пользователь и группа, от которых работает PHP-FPM, совпадают с владельцем директории сайта

Важно: Перезапуск PHP-FPM — быстрое временное решение, но если ошибка повторяется регулярно, ищите корневую причину.

Ресурсные ограничения: память и время выполнения

WordPress с тяжёлыми темами и множеством плагинов легко выходит за пределы памяти, выделенной PHP-процессу. Когда memory_limit исчерпан, PHP-FPM убивает воркера, и Nginx получает неожиданный обрыв соединения — ту самую 502. Аналогично, слишком маленький max_execution_time может обрывать долгие скрипты.

• memory_limit в php.ini обычно составляет 128M или 256M — для некоторых сборок WordPress этого мало
• Значение можно временно увеличить в wp-config.php: define('WP_MEMORY_LIMIT', '256M');
• Если после повышения лимита ошибка пропадает, причина точно в нехватке памяти — далее оптимизируйте код, а не бесконечно поднимайте лимит
• max_execution_time ниже 30 секунд часто приводит к 502 при импорте данных или работе тяжёлых плагинов

1. Проверьте текущие лимиты через phpinfo() или файл с
2. Добавьте в wp-config.php строку define('WP_MEMORY_LIMIT', '256M'); перед /* That's all, stop editing! */
3. При использовании собственного сервера отредактируйте php.ini: memory_limit = 256M, max_execution_time = 300
4. После правок обязательно перезапустите PHP-FPM и проверьте сайт

Важно: Не устанавливайте memory_limit безграничным — это маскирует утечки памяти и может привести к падению всего сервера из-за OOM Killer.

Конфликты плагинов и темы оформления

Некорректно написанный плагин или тема способны вызывать фатальную ошибку PHP (Fatal error), которая обрывает выполнение скрипта до того, как он вернёт HTTP-ответ. Веб-сервер расценивает это как плохой ответ и показывает 502. Особенно часто такое случается после обновлений WordPress, плагинов или самого PHP.

• Массовое отключение всех плагинов — самый быстрый способ проверить эту гипотезу
• Переименование папки плагинов

Также может быть интересно

Ошибка 403 в WordPress: причины появления и практические способы исправленияОткрыть инструкциюЧто делать, если Elementor перестал открыватьсяОткрыть инструкциюПочему WordPress не загружает изображения: основные причины и способы исправленияОткрыть инструкцию