Ошибка 502 Bad Gateway в nginx: причины и способы исправления

Автор: Редакция Торох Опубликовано: 14 ноября 2026 7 минут чтения

502 Bad Gateway означает, что nginx принял запрос браузера, но не получил корректного ответа от бэкенда: PHP-FPM, Apache, Node.js или другого приложения. Ошибка почти всегда указывает на проблему за nginx — упавший процесс, неверный сокет или порт, таймаут либо исчерпанные лимиты. Посетителю остаётся обновить страницу и подождать, владельцу — смотреть error.log nginx и состояние бэкенда.

Что означает 502 Bad Gateway

Код 502 относится к серверным ошибкам и расшифровывается как «неверный шлюз». Его отдаёт не приложение, а сервер-посредник, который принял запрос от браузера и должен был передать его дальше. В связке с nginx это выглядит так: nginx принимает соединение на 80 или 443 порту, перенаправляет запрос бэкенду — PHP-FPM по сокету, Apache, Node.js или другому приложению на локальном порту — и ждёт корректный HTTP-ответ. Если ответа нет, он пустой или не соответствует протоколу, посетитель получает 502.

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

Как ошибка выглядит в браузере

Стандартная заглушка nginx содержит крупную надпись «502 Bad Gateway», ниже — строку вида «nginx/1.24.0 (Ubuntu)». Именно эти версии часто попадают в поисковые запросы: 1.18.0, 1.22.1, 1.26.3, 1.28.3, 1.30.4 и другие. Номер означает лишь сборку nginx на сервере и ничего не говорит о причине сбоя; на Ubuntu к нему добавляется название дистрибутива.

Если у сайта настроена собственная страница ошибки (у хостинга, у CMS, у CDN), вместо заглушки откроется оформленная страница с другим текстом. Код ответа при этом остаётся прежним — его видно в инструментах разработчика на вкладке «Сеть» (Network) в строке запроса документа.

Чем 502 отличается от похожих кодов

Разница принципиальна при диагностике: 500 ищут в коде и логах приложения, 502 — в связке nginx с бэкендом, 503 — в лимитах и доступности, 504 — в таймаутах. Подробнее о соседних кодах — в материалах про ошибку 500, 503 Service Unavailable и 504 Gateway Timeout.

Причины

Что наблюдает посетитель

• Сайт открывается частично: статика грузится, а страницы с данными нет — значит nginx работает, а приложение недоступно.
• Ошибка появляется на всех страницах сразу — обычно упал бэкенд или сервер перезагружается.
• Ошибка возникает на отдельных разделах и формах — вероятно, тяжёлый запрос не укладывается в таймаут или падает конкретный сценарий в коде.
• Сбой совпал с обновлением сайта, массовой рассылкой или наплывом посетителей — типичные признаки перегрузки.

Локальные факторы (VPN, прокси, антивирус с проверкой HTTPS, расширения-блокировщики) чаще дают другие коды, но исключить их стоит, прежде чем делать выводы.

Что проверяет владелец сайта

• Бэкенд не запущен или перезапускается после падения.
• В конфигурации указан неверный путь к сокету PHP-FPM или неверный порт приложения.
• Исчерпан лимит одновременных процессов (pm.max_children в PHP-FPM, MaxRequestWorkers в Apache).
• Не хватает оперативной памяти: OOM-killer убивает процессы, и nginx получает оборванное соединение.
• Приложение падает на старте из-за синтаксической ошибки, отсутствующего расширения или недоступной базы данных.
• Истёк таймаут fastcgi_read_timeout или proxy_read_timeout.
• Закончилось место на диске — PHP-FPM и сессии в этом случае не стартуют.
• Сокет создан с правами, недоступными пользователю nginx (актуально после смены версии PHP).
• Ошибка появилась после деплоя, обновления CMS или смены версии интерпретатора.

Что делать посетителю

1. Обновите страницу обычной кнопкой и через Ctrl+F5, подождите минуту и повторите.
2. Проверьте соседние страницы и разделы: если часть сайта работает, сбой временный.
3. Откройте сайт в другом браузере, в режиме инкогнито и с мобильного интернета вместо Wi-Fi.
4. Отключите VPN, прокси и расширения, фильтрующие трафик.
5. Если ошибка повторяется у всех и долго, напишите в поддержку сервиса; при оплате на сайте дождитесь восстановления, чтобы не создавать дубли заказов.
6. На чужом сайте (маркетплейс, игровая площадка, банк) повлиять на причину нельзя — остаётся ждать восстановления.

Диагностика для владельца сайта

1. Проверить состояние служб и портов

systemctl status nginx --no-pager
systemctl status php8.2-fpm --no-pager
ss -ltnp | grep -E ':(80|443|9000|8080)'
ls -l /run/php/

Imена службы и пути зависят от версии PHP и дистрибутива: на Ubuntu это /run/php/php8.2-fpm.sock, на других сборках путь и имя юнита отличаются. Если сокета нет, а служба «active», проверьте журнал: journalctl -u php8.2-fpm -n 50 --no-pager.

2. Прочитать журнал ошибок nginx

tail -n 100 /var/log/nginx/error.log
tail -f /var/log/nginx/error.log | grep -i upstream

Что означают типовые строки:

• connect() failed (111: Connection refused) while connecting to upstream — на указанном порту или сокете никто не слушает.
• upstream timed out (110: Connection timed out) — бэкенд не успел ответить, нужны таймауты или оптимизация кода.
• recv() failed (104: Connection reset by peer) — процесс умер во время обработки: fatal error, нехватка памяти, падение воркера.
• no live upstreams while connecting to upstream — все серверы в блоке upstream помечены как нерабочие.
• Permission denied while connecting to upstream — у пользователя nginx нет доступа к сокету.

3. Сверить конфигурацию с реальностью

Для PHP-FPM:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_read_timeout 60s;
}

Для приложения на порту:

upstream backend {
    server 127.0.0.1:8080;
    keepalive 16;
}

server {
    location / {
        proxy_pass http://backend;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_read_timeout 60s;
        proxy_next_upstream error timeout http_502;
    }
}

После правок обязательно nginx -t, затем systemctl reload nginx. Частая причина — приложение слушает только 127.0.0.1, а nginx резолвит localhost в ::1 и получает отказ; используйте явный IP.

4. Проверить лимиты PHP-FPM и память

grep -E '^(listen|pm|pm.max_children|pm.max_requests|request_terminate_timeout)' /etc/php/8.2/fpm/pool.d/www.conf
free -m
df -h
journalctl -k | grep -i 'killed process'

Запись server reached pm.max_children setting (5), consider raising it означает, что все воркеры заняты. Значение подбирают по памяти: один процесс PHP в среднем занимает десятки мегабайт, и запас обязателен, иначе сервер начнёт уходить в swap или терять процессы. Полезны request_slowlog_timeout и slowlog — они показывают конкретные медленные запросы.

5. Apache за nginx

ProxyPass "/" "http://127.0.0.1:8080/"
ProxyPassReverse "/" "http://127.0.0.1:8080/"

Проверьте apachectl configtest, systemctl status apache2 и /var/log/apache2/error.log. Если Apache упирается в MaxRequestWorkers, он перестаёт принимать соединения — nginx в этот момент отдаёт 502.

6. Node.js и другие приложения

pm2 list
pm2 logs --lines 100
ss -ltnp | grep 3000

Ищите EADDRINUSE (порт занят), падение на старте из-за переменных окружения, отсутствующих зависимостей или недоступной базы. Если процесс запускается вручную и работает, а через systemd падает — сравните пользователя, рабочий каталог и переменные окружения в юните.

7. WordPress и другие CMS

• Включите отладку в wp-config.php: define('WP_DEBUG', true); и define('WP_DEBUG_LOG', true); — ошибки попадут в wp-content/debug.log.
• Проверьте лимит памяти: define('WP_MEMORY_LIMIT', '256M'); и значение memory_limit в PHP.
• Отключите подозрительный плагин или тему переименованием каталога, чтобы убедиться, что причина в них.
• Ошибки только в админке обычно указывают на тяжёлый запрос или конфликт плагинов, а не на сеть.

Как предотвратить повторение

• Включите внешний мониторинг доступности с интервалом 1–5 минут и проверкой не только кода ответа, но и ожидаемого фрагмента страницы: заглушка с кодом 502 иногда маскируется под рабочий сайт.
• Настройте ротацию журналов через logrotate и держите уровень error_log достаточным для диагностики, но без избыточного объёма.
• Рассчитайте лимиты процессов от реальной памяти сервера, добавьте pm.max_requests, чтобы воркеры периодически перезапускались.
• Держите таймауты nginx (fastcgi_read_timeout, proxy_read_timeout) больше максимального времени обработки в приложении, иначе 504 и 502 будут появляться на медленных, но рабочих запросах.
• Следите за свободным местом на диске и размером логов: переполненный раздел ломает запуск PHP-FPM.
• Выкатывайте обновления через reload, а не полный перезапуск, проверяйте конфигурацию в тестовой среде и держите резервную страницу ошибки: error_page 502 /502.html;.
• В open-source nginx активных проверок апстрима нет, работают пассивные (max_fails, fail_timeout) — учитывайте это при балансировке между несколькими бэкендами.

Если сайт активно собирают парсеры или боты, нагрузка на бэкенд растёт незаметно; о том, как это отслеживать, читайте в статье про парсинг сайтов.

Материал подготовлен редакцией справочника Торох и носит справочный характер: интерфейсы программ и настройки серверов зависят от версии. Нашли неточность? Напишите нам.