Ошибка 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, и новым запросам некуда идти.

• Заголовки ответа слишком большие. Крупные cookie или объёмные заголовки безопасности переполняют proxy_buffer_size в nginx.

• Несовпадение keep-alive за балансировщиком. Приложение закрывает простаивающие соединения раньше, чем ожидает балансировщик, и тот отправляет запрос в закрывающееся соединение.

• Изменения файрвола или сети между прокси и origin-сервером. Например, CDN больше не может достучаться до origin-сервера, у которого сменился IP-адрес или правила файрвола.

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

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

• Подождите 30–60 секунд и обновите страницу (Ctrl + R, на Mac — Cmd + R). Многие ошибки 502 длятся ровно столько, сколько идёт деплой или перезапуск.

• Проверьте, не лежит ли сайт у всех. Инструмент HTTP Headers от DNS Robot запрашивает страницу с наших серверов и показывает точный код состояния. Если мы тоже получаем 502, проблема в сайте, а не у вас. Ping-тест покажет, отвечает ли серверная машина вообще.

• Сделайте жёсткую перезагрузку и очистите кеш. Ctrl + Shift + R (на Mac — Cmd + Shift + R) обходит закешированную копию на случай, если вам показывают устаревшую страницу ошибки.

• Очистите DNS-кеш, если сайт недавно сменил хостинг, — так вы попадёте на новый сервер. Вот как очистить DNS-кеш в любой системе.

• Выключите VPN и прокси. Неисправным «шлюзом» может оказаться ваш собственный прокси, особенно в рабочих сетях.

• Попробуйте другой браузер или телефон через мобильный интернет. Если там всё работает, удалите cookie этого сайта.

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

На стороне сервера 502 — одна из самых простых в исправлении ошибок, потому что прокси почти всегда точно записывает, что пошло не так. Пройдите эти четыре проверки по порядку.

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

Воспроизведите ошибку 502, затем прочитайте последние строки лога ошибок на прокси-сервере:

# 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

Эти сообщения nginx покрывают подавляющее большинство ошибок 502, и каждое указывает на решение:

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>

# Не был ли процесс убит за превышение памяти?
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 проксирует запросы?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# Что на самом деле слушает?
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). После любых изменений выполните sudo nginx -t и sudo systemctl reload nginx.

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, который проксирует запросы к приложению:

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

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

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

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

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

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

502 Bad Gateway в Cloudflare

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

• Страница с брендингом Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): Cloudflare работает, но не смог получить корректный ответ от вашего origin-сервера. Проверьте, что origin работает, слушает порты 443/80 и не блокирует диапазоны IP Cloudflare в файрволе. Проверьте origin напрямую через Port Checker.

• Простая страница 502 без брендинга: если на ней нет упоминания cloudflare (например, указан nginx или Apache), ошибку 502 сгенерировал ваш собственный origin-сервер. Используйте серверные шаги выше. Пустая страница, внизу которой написано только «cloudflare», исходит от самого Cloudflare — например, во время кратковременной перемаршрутизации трафика или когда origin отдаёт сломанный gzip-контент.

• Сменился IP origin-сервера? Если вы переехали на другой хостинг, обновите A-запись в DNS Cloudflare. DNS Lookup покажет, что сейчас видит весь мир.

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

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

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