Ошибка 502 Bad Gateway: что это значит и как исправить

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

502 Bad Gateway означает, что сервер-посредник (обычно nginx или балансировщик) получил запрос от браузера, но не смог получить корректный ответ от внутреннего обработчика — PHP-FPM, Apache, Node.js или другого приложения. Посетителю достаточно подождать и обновить страницу, а владельцу сайта нужно проверить логи прокси и состояние upstream-сервиса.

Что означает ошибка 502 Bad Gateway

Код 502 входит в класс 5xx — ошибки на стороне сервера. Дословно Bad Gateway переводится как «неверный шлюз». Смысл такой: сервер, принявший запрос от браузера, сам страницу не формирует. Он работает посредником — обратным прокси — и передаёт запрос следующему звену: PHP-FPM, Apache, Node.js, контейнеру приложения или другому серверу. Это звено должно вернуть корректный HTTP-ответ, но вместо него приходит пустота, обрыв соединения или данные не по протоколу. Собрать страницу прокси не может и отдаёт 502.

Ключевой момент: 502 говорит не «сайт упал», а «одно из внутренних звеньев не отвечает как положено». Внешний сервер при этом работает — иначе браузер показал бы ошибку соединения, а не HTTP-код.

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

• Chrome и Edge показывают страницу «502 Bad Gateway» с подписью сервера, например nginx или cloudflare.
• Firefox выводит заголовок «502 Bad Gateway» и короткое пояснение, что сервер получил недопустимый ответ.
• Safari ограничивается фразой «Bad Gateway».
• В мобильных браузерах и встроенных webview текст часто сокращён до «Ошибка сервера» или «Что-то пошло не так».

Иногда страницы ошибки нет вообще: приходит пустой белый экран, JSON от API или битая вёрстка. В инструментах разработчика на вкладке Network видно, что документ отдан с кодом 502. Скрипты и боты видят то же самое: Python-библиотека requests возвращает <Response [502]>, JavaScript-библиотека axios выдаёт сообщение «Request failed with status code 502». Если вы собираете данные автоматически, стоит предусмотреть повторные попытки — об этом есть материал о парсинге сайтов.

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

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

Причины ошибки

Со стороны посетителя

Локальных причин немного, и почти все они связаны не с самим сайтом, а с путём до него: корпоративный прокси, VPN, антивирус с проверкой HTTPS, устаревший кэш браузера, расширение-блокировщик. Бывает и так, что 502 отдаёт CDN или балансировщик из-за краткого перезапуска сервиса на стороне сайта.

Со стороны владельца сайта

• процесс PHP-FPM или приложения не запущен, упал или перезапускается;
• в конфиге прокси указан неверный путь к сокету или порт, либо у пользователя нет прав на сокет;
• закончились свободные воркеры: pm.max_children меньше, чем одновременных запросов;
• обработка запроса дольше таймаута fastcgi_read_timeout или proxy_read_timeout;
• приложение слушает 127.0.0.1, а прокси обращается к внешнему интерфейсу, или наоборот;
• заголовки ответа слишком велики для буферов прокси;
• нехватка оперативной памяти: процесс убивает OOM-killer;
• ошибка при деплое — конфиг обновлён, а сервис не перечитал его;
• сбой на уровне CDN или хостинг-панели, который виден только снаружи.

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

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

Что делать владельцу: пошаговая диагностика

Шаг 1. Определите, где обрыв

curl -I https://example.com/
curl -sS -o /dev/null -w "%{http_code}\n" http://127.0.0.1/

Если на самом сервере локальный запрос отдаёт 200, а внешний — 502, ищите причину выше приложения: CDN, балансировщик, внешний прокси. Если 502 и локально — проблема внутри связки «прокси плюс приложение».

Шаг 2. Прочитайте логи

tail -n 100 /var/log/nginx/error.log
grep -iE "upstream|no live upstreams|timed out" /var/log/nginx/error.log | tail -20
journalctl -u php8.2-fpm -n 100 --no-pager

Типичные записи и их смысл:

• connect() failed (111: Connection refused) while connecting to upstream — процесс не слушает порт или сокет;
• upstream timed out (110: Connection timed out) — обработчик не уложился в таймаут;
• no live upstreams — все серверы в группе признаны неработоспособными;
• upstream sent too big header — не хватает буферов под заголовки.

Разбор типовых конфигураций nginx для этой ошибки дан в материале 502 Bad Gateway в nginx.

Шаг 3. Проверьте nginx и PHP-FPM

nginx -t
systemctl status php8.2-fpm
ls -l /run/php/
php-fpm8.2 -t

Путь к сокету в конфиге должен совпадать с реальным файлом, а версия — с установленной. Рабочий блок для сайта выглядит примерно так:

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

В пуле PHP-FPM проверьте лимит процессов и время жизни запроса:

pm = dynamic
pm.max_children = 25
pm.max_requests = 500
request_terminate_timeout = 60s
listen = /run/php/php8.2-fpm.sock

pm.max_children считают от доступной памяти: объём RAM делят на средний размер процесса PHP. Если воркеры заняты все, новые запросы встают в очередь и в итоге получают 502 или 504.

Шаг 4. Apache за прокси

apachectl configtest
systemctl status apache2
tail -f /var/log/apache2/error.log

Если PHP обрабатывается через FPM, а не модулем, нужен корректный обработчик и достаточный таймаут:

ProxyTimeout 60
<FilesMatch "\.php$">
    SetHandler "proxy:unix:/run/php/php8.2-fpm.sock|fcgi://localhost"
</FilesMatch>

Частая причина — забытый модуль proxy_fcgi или устаревший .htaccess после переезда: проверьте, включены ли proxy_module и proxy_fcgi_module.

Шаг 5. Node.js и другие приложения

pm2 status
pm2 logs --lines 100
ss -ltnp | grep -E "3000|8080"
curl -I http://127.0.0.1:3000/health

Со стороны nginx важны адрес, таймауты и keepalive до приложения:

upstream backend {
    server 127.0.0.1:3000 max_fails=3 fail_timeout=30s;
    keepalive 32;
}

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

Если приложение запущено в контейнере, проверьте, что порт опубликован и доступен из сети прокси, а health-check не возвращает ошибку.

Шаг 6. WordPress и другие CMS

• включите журнал: в wp-config.php задайте define('WP_DEBUG', true); и define('WP_DEBUG_LOG', true);, файл появится в wp-content/debug.log;
• поочерёдно отключайте плагины (достаточно переименовать папку wp-content/plugins), чтобы найти конфликтующий;
• переключитесь на стандартную тему и проверьте, сохраняется ли ошибка;
• проверьте memory_limit и max_execution_time в PHP: тяжёлые импорты и массовые операции в админке часто приводят именно к 502;
• при высокой нагрузке перенесите обработку admin-ajax.php и wp-cron на отдельные процессы или в очередь.

Шаг 7. Закрепите исправление

nginx -t && nginx -s reload
systemctl reload php8.2-fpm

Плавная перезагрузка не рвёт текущие соединения, в отличие от restart. После правок повторите curl -I и убедитесь, что в логах нет новых записей об ошибках upstream.

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

• Мониторинг доступности. Проверяйте не только главную страницу, но и ключевые сценарии: вход в аккаунт, оформление заказа, API. Настройте оповещения на всплеск ответов 5xx в логах, а не только на полную недоступность.
• Регулярный разбор логов. Ротация через logrotate и недельная выборка по коду 502 показывают, растёт ли частота сбоев и к каким часам они привязаны.
• Лимиты под реальную нагрузку. Пересматривайте pm.max_children, pm.max_requests, proxy_read_timeout при росте трафика и после добавления тяжёлых функций.
• Запас по памяти. Следите за потреблением RAM и swap: нехватка памяти — скрытая причина внезапных 502 сразу на всех страницах.
• Health-check и резерв. В группе upstream полезны проверка доступности, параметры max_fails и fail_timeout, а при возможности — резервный сервер.
• Аккуратные деплои. Обновляйте конфиги через reload, держите возможность быстрого отката, не выводите тяжёлые миграции на рабочие часы.
• Кэш и очередь. Статику и повторяющиеся запросы отдавайте из кэша, длительные операции выносите в фоновые задачи — это снижает число запросов, которые могут упереться в таймаут.

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