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

Что такое ошибка 502 Bad Gateway?

502 Bad Gateway — это код состояния HTTP, который означает, что отвечающий вам сервер работает как шлюз или прокси и получил неверный ответ от сервера за ним. Стандарт HTTP (RFC 9110, раздел 15.6.3) определяет его именно так: сервер, «действуя как шлюз или прокси, получил неверный ответ от входящего сервера, к которому обратился, пытаясь выполнить запрос».

У большинства современных сайтов минимум два уровня. Фронтовой сервер — nginx, Apache, Cloudflare или облачный балансировщик нагрузки — принимает ваше соединение и передаёт запрос вышестоящему (upstream) приложению: PHP-FPM, приложению на Node.js, Gunicorn на Python или контейнеру. Когда этот upstream не работает, падает или отвечает чем-то, что прокси не может использовать, прокси нечего вам отдать, и он возвращает 502.

Главное: сам шлюз работает. Он получил ваш запрос и ответил. Неисправность находится на шаг дальше.

Как может выглядеть ошибка 502

Код состояния везде одинаковый, но страница, которую вы видите, зависит от того, какой прокси её сгенерировал:

Какой бы вариант вы ни видели, название прокси внизу страницы — полезная подсказка: оно говорит владельцу сайта, какой уровень нужно проверять.

Ошибки 502, 500, 503 и 504: в чём разница?

Все коды 5xx означают «проблема на сервере», но каждый указывает на свой уровень:

Простое правило: 502 = upstream отказал в соединении, повесил трубку или дал плохой ответ, 504 = upstream не ответил вовремя. Соседние ошибки подробно разобраны в наших руководствах: 500 Internal Server Error, 503 Service Unavailable и 504 Gateway Timeout.

Причины ошибки 502 Bad Gateway

• Upstream-приложение не запущено. PHP-FPM, Node, Gunicorn или контейнер упали, не запустились после деплоя или перезапускаются.
• Прокси указывает не туда. В proxy_pass или fastcgi_pass указан не тот порт, старый путь к сокету PHP после обновления или localhost внутри Docker-контейнера.
• Приложение падает на некоторых запросах. Одна страница вызывает завершение процесса из-за нехватки памяти или необработанное исключение, и соединение закрывается до ответа.
• Все воркеры заняты. PHP-FPM упёрся в pm.max_children, и новые запросы ждут в очереди сокета. Большинство из них заканчивается ошибкой 504 по таймауту; когда очередь заполняется, nginx пишет в лог (11: Resource temporarily unavailable) и возвращает 502.
• Заголовки ответа слишком большие. Крупные cookie или объёмные заголовки безопасности переполняют proxy_buffer_size в nginx.
• Несовпадение keep-alive за балансировщиком. Приложение закрывает простаивающие соединения раньше, чем ожидает балансировщик, и тот отправляет запрос в закрывающееся соединение.
• Прокси не может достучаться до upstream после изменений в сети. Файрвол, который отклоняет прокси, или upstream, переехавший на другой IP, дают 502 (Connection refused, No route to host). Файрвол, молча отбрасывающий пакеты, даёт 504, а за Cloudflare это выглядит как 521 или 522.

Как исправить ошибку 502, если вы посетитель

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

• Подождите 30–60 секунд и обновите страницу (Ctrl + R, на Mac — Cmd + R). Многие ошибки 502 длятся ровно столько, сколько идёт деплой или перезапуск.
• Проверьте, не лежит ли сайт у всех. Проверка доступности сайта от DNS Robot открывает страницу из 11 точек, а Проверка HTTP-заголовков показывает точный код состояния, который получает наш сервер. Если они тоже видят 502, проблема в сайте, а не у вас.
• Сделайте жёсткую перезагрузку — Ctrl + Shift + R (на Mac — Cmd + Shift + R) — на случай, если вам показывают закешированную страницу ошибки.
• Очистите DNS-кеш, если сайт недавно сменил хостинг, — так вы попадёте на новый сервер. Вот как очистить DNS-кеш в любой системе.
• Выключите VPN и прокси. Неисправным «шлюзом» может оказаться ваш собственный прокси, особенно в рабочих сетях.
• Попробуйте другой браузер или телефон через мобильный интернет. Если там всё работает, удалите cookie этого сайта.

Как исправить 502 Bad Gateway на своём сервере

На стороне сервера 502 — одна из самых простых в исправлении ошибок, потому что прокси обычно записывает, что пошло не так (исключения — гонка keep-alive у балансировщика и собственные ошибки 502 у Cloudflare). Пройдите эти три проверки по порядку; четвёртая часть — реальный пример.

1. Прочитайте лог ошибок прокси

Воспроизведите ошибку 502 и прочитайте последние 50 строк лога ошибок прокси (команды — под таблицей). Каждое из этих сообщений nginx указывает на своё решение:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Убедитесь, что upstream-приложение запущено

# PHP-FPM (подставьте свою версию)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js под PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # ищите контейнеры, которые постоянно перезапускаются
docker logs --tail 50 <container>

# Не был ли процесс убит за превышение памяти?
sudo dmesg -T | grep -i "killed process"

Если сервис остановлен, запустите его и выясните, почему он остановился: неудачный деплой, синтаксическая ошибка в новом релизе или OOM killer (завершение процессов при нехватке памяти). Строка server reached pm.max_children setting в логе PHP-FPM означает, что все воркеры были заняты. Увеличивайте pm.max_children только если серверу хватает RAM, иначе найдите медленные запросы, которые держат воркеры.

3. Проверьте, что proxy_pass указывает на правильный порт или сокет

Сравните, с чем nginx должен общаться, с тем, что на самом деле слушает:

# Куда nginx проксирует запросы?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# Что на самом деле слушает?
sudo ss -tlnp            # TCP-порты и их процессы
ls -l /run/php/          # файлы сокетов PHP-FPM

Два классических несоответствия: после обновления PHP сокет становится php8.3-fpm.sock, а nginx всё ещё указывает на php8.1-fpm.sock; а внутри Docker proxy_pass http://localhost:3000 указывает на сам контейнер nginx, а не на приложение, — используйте имя сервиса из Compose (http://app:3000).

4. Реальный пример: как dnsrobot.net отдавал ошибку 502

Это случилось у нас 30 сентября 2026 года. После публикации пачки новых статей в блоге ровно одна из них возвращала 502 Bad Gateway через nginx 1.24, а все остальные страницы работали. Приложение Next.js за nginx отдавало ту же страницу с кодом 200 OK, когда мы запрашивали её напрямую на порту 3000. Значит, приложение было в порядке, а сбоил шлюз.

Ответ нашёлся в одной строке лога ошибок nginx: upstream sent too big header while reading response header from upstream. Заголовки ответа этой страницы занимали 4 087 байт — в основном длинный заголовок Content-Security-Policy и заголовки Link для preload. nginx читает первую часть ответа, включая все заголовки, в буфер, размер которого задаёт proxy_buffer_size, а по умолчанию он равен одной странице памяти: 4 КБ на нашем сервере. Свободного места оставалось всего 9 байт, и полный блок заголовков вместе со строкой статуса его переполнил.

Исправление — три строки в блоке location, который проксирует запросы к приложению; после nginx -t и перезагрузки конфигурации страница вернула 200:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # место для больших заголовков (было 4k по умолчанию)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

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

Node.js за балансировщиком нагрузки: случайные ошибки 502

Если Node.js работает за AWS Application Load Balancer или похожим балансировщиком и вы видите редкие ошибки 502 без каких-либо ошибок в логах приложения, проверьте таймауты keep-alive. HTTP-сервер Node по умолчанию закрывает простаивающие keep-alive-соединения через 5 секунд в Node 26 и более ранних (server.keepAliveTimeout; в Node 24.6 и 22.19 добавили поверх этого keepAliveTimeoutBuffer в 1 секунду, а в следующей мажорной версии значение по умолчанию вырастет до 65 секунд), а AWS ALB держит простаивающие соединения открытыми 60 секунд. Иногда балансировщик повторно использует соединение ровно в тот момент, когда Node его закрывает, и этот запрос возвращается как 502.

Решение — сделать таймаут приложения длиннее, чем у балансировщика:

const server = app.listen(3000)
// Должен быть больше таймаута простоя балансировщика (ALB по умолчанию: 60 с)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // нужно только до Node 18; позже не мешает

502 Bad Gateway в Cloudflare

Если сайт работает через Cloudflare, сначала посмотрите, кто сгенерировал страницу ошибки (руководство Cloudflare по 502/504):

• Страница с брендингом Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): ваш origin-сервер сам вернул Cloudflare ошибку 502 или 504. Исправляйте на origin по серверным шагам выше. Если Cloudflare вообще не может подключиться к origin, вы получите 521 или 522, а не 502.
• Простая страница «502 Bad Gateway», под которой написано «cloudflare»: такую ошибку создаёт сам Cloudflare. В его документации названы две причины: origin отдаёт сломанный gzip-контент или gzip-контент без обновлённого Content-Length (для проверки отключите сжатие на origin) и внезапный всплеск трафика в одном дата-центре Cloudflare, который проходит сам.
• Страница с упоминанием nginx или Apache: обычно запрос дошёл до вашего сервера мимо Cloudflare — DNS-запись без проксирования (серое облако, «DNS only») или вы открываете origin напрямую (если только Cache Rule не включает «Origin error page pass-through»).
• Переехали на другой хостинг? Обновите A-запись origin в DNS Cloudflare (неверный IP origin обычно проявляется как 521, 522 или 523). DNS Lookup показывает origin только для записей с серым облаком (DNS only); проксируемые записи отвечают IP-адресами самого Cloudflare.

Вредит ли ошибка 502 SEO?

Короткий сбой — нет. В документации Google сказано, что серверные ошибки 5xx заставляют краулеры временно замедлить сканирование. Уже проиндексированные страницы поначалу остаются в индексе, но если ошибки не прекращаются, Google в итоге удаляет эти URL.

Поэтому ошибка 502, которая длится несколько минут во время деплоя, безвредна. А 502 на важных страницах, которая держится днями или неделями появляется время от времени, может сократить сканирование и стоить позиций. Следите за ключевыми URL и после любого сбоя проверяйте отчёт «Статистика сканирования» в Search Console.