Артём Савельев 
502 Bad Gateway: что означает ошибка и как её исправить
502 Bad Gateway — самая частая из «серверных» ошибок, и при этом самая обманчивая: слово gateway намекает на что-то сетевое, хотя в девяти случаях из десяти дело в упавшем приложении за прокси-сервером. Разбираем, как устроена ошибка, что делать посетителю за две минуты и где искать причину владельцу сайта.
Что на самом деле означает 502
Современный сайт почти никогда не отвечает вам напрямую. Запрос проходит цепочку: браузер → CDN или балансировщик → веб-сервер (обычно nginx) → приложение (PHP, Python, Node.js). Ошибка 502 — это честный доклад промежуточного звена: «я работаю, но тот, кто за мной, ответил ерундой или не ответил вовсе». То есть прокси жив, а бэкенд — нет: он упал, перезапускается или отвечает не по протоколу. Этим 502 отличается от соседей по пятисотой серии, с которыми её постоянно путают:
| Код | Что говорит прокси | Типовая причина |
|---|---|---|
| 502 Bad Gateway | «Бэкенд ответил невалидно или отказал в соединении» | Приложение упало или перезапускается |
| 503 Service Unavailable | «Сервис намеренно недоступен или перегружен» | Техработы, перегрузка |
| 504 Gateway Timeout | «Бэкенд жив, но не ответил за отведённое время» | Слишком долгий запрос, зависшая база |
| 500 Internal Server Error | «Ошибка в самом приложении» | Баг в коде, ошибка конфигурации |
Полный разбор всех кодов ответа — в нашей статье про коды HTTP; здесь сосредоточимся на конкретной механике 502.
Если вы посетитель: две минуты диагностики
Сразу важное: 502 — ошибка на стороне сайта, а не вашего компьютера. Починить её вы не можете, но можете быстро понять масштаб. Обновите страницу через 20–30 секунд: если 502 вылетела в момент перезапуска приложения (частый случай при деплое), она проживёт секунды. Проверьте сайт с телефона через мобильный интернет и любым онлайн-чекером доступности: если 502 видна отовсюду — инцидент общий, остаётся ждать. Кэш и куки чистить бессмысленно — к этой ошибке они отношения не имеют, что бы ни советовали инструкции из 2012 года.
Если вы владелец: где искать причину
Логика поиска — от приложения к прокси, потому что статистически виновник почти всегда в конце цепочки:
| Причина | Как выглядит | Что делать |
|---|---|---|
| Упал процесс приложения (php-fpm, gunicorn, node) | В логе nginx — connect() failed / Connection refused to upstream | Перезапустить сервис, смотреть его лог на причину падения |
| Кончилась память — сработал OOM-killer | В системном логе — Out of memory: Killed process | Больше памяти или меньше воркеров; найти утечку |
| Деплой или перезапуск | Короткие всплески 502 ровно в моменты выкладки | Настроить graceful reload вместо жёсткого рестарта |
| Переполнена очередь воркеров | 502/504 в часы пик, в остальное время всё чисто | Увеличить пул воркеров, кэшировать тяжёлое |
| Прокси не достучался до origin (при CDN) | CDN отдаёт свою страницу 502, сервер в логах чист | Проверить, отвечает ли origin напрямую; файрвол и IP-списки CDN |
Ключевой инструмент — лог ошибок прокси (для nginx — error.log): он прямым текстом пишет, что именно не так с бэкендом: connection refused (процесс не слушает), upstream prematurely closed connection (упал в момент ответа) или no live upstreams (балансировщику некому отдать запрос). По этой строке причина находится быстрее, чем по любой инструкции.
Постоянный 502 находят быстро — сайт лежит, все видят. Опаснее 502 эпизодический: раз в час на несколько секунд, при всплесках трафика или ночных бэкапах. Посетители попадают на ошибку, а вы при ручной проверке — нет. Такие всплески видны только в истории регулярных проверок: если каждая N-я проверка ловит 502 — проблема системная, хоть и прячется.
Как измерить масштаб: доля 502 в логе
Прежде чем чинить, полезно понять, сколько запросов реально страдает. Одна команда по access-логу nginx даёт распределение кодов ответа за сегодня:
awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -rn
# Когда именно сыпались 502 (по часам):
grep ' 502 ' /var/log/nginx/access.log | awk -F: '{print $2":00"}' | sort | uniq -c
Вторая команда особенно показательна: если 502 кучкуются в конкретные часы — ищите, что происходит в это время (бэкапы, крон-задачи, пики трафика, ночной импорт каталога). Если размазаны равномерно — дело в нестабильности самого приложения. Это десятиминутное упражнение сужает круг подозреваемых лучше любых догадок.
Частные случаи: WordPress, Битрикс, Docker
На WordPress и любом PHP-сайте 502 — это почти всегда php-fpm: упал, перезапустился, кончились воркеры пула (параметр pm.max_children). Смотрите лог php-fpm рядом с логом nginx — там будет либо падение, либо строка «server reached pm.max_children», означающая, что пул надо расширять или искать, кто его занял. На shared-хостинге (включая типичные площадки под Битрикс) прямых логов может не быть — тогда единственный аргумент в диалоге с поддержкой это внешняя статистика: когда и как часто сайт отдавал 502. В Docker-окружении 502 от прокси-контейнера обычно значит, что контейнер приложения перезапускается (смотрите docker ps на счётчик рестартов) либо после пересоздания сменил внутренний адрес, а прокси держит старый — лечится перезагрузкой прокси или нормальным service discovery.
Сколько стоит невидимый 502
Простой пример арифметики. Если сайт ловит 502 суммарно 15 минут в день на всплесках — это 0,7 терпимого на вид аптайма недобора (99,3% вместо 100%). Но 15 минут в день — это 7,6 часа в месяц; при тысяче посетителей в сутки, равномерно размазанных по времени, на ошибку за месяц наткнутся сотни людей — и заметная их часть больше не вернётся. Деньги, которые теряются на нестабильности, мы считали подробно в статье о цене нестабильного сайта.
Пруфен выполняет HTTP-проверки с интервалом от 2 минут из 13 точек и присылает уведомление, как только сайт начал отдавать 5xx, — в Email, Telegram, Макс или звонком. Для «мигающих» ошибок есть задержка уведомлений: секундный всплеск при деплое не разбудит вас ночью, а настоящий инцидент — дойдёт.
Частые вопросы
502 — это вирус или взлом? Нет. Это штатный код ответа: прокси не смог получить корректный ответ от приложения. К безопасности вашего устройства ошибка отношения не имеет.
Ошибка 502 у всех или только у меня? Почти всегда у всех: она рождается на сервере. Быстрая проверка — открыть сайт с мобильного интернета или через онлайн-чекер; как проверить доступность из разных мест, мы разбирали отдельно.
Вредит ли 502 позициям в поиске? Короткие эпизоды поисковики прощают. Систематические 502 — уже поведенческий и технический сигнал: роботы получают ошибки при обходе, посетители уходят. Стабильно доступный сайт — базовое условие, на котором строится всё остальное SEO.
Как сделать, чтобы 502 не появлялся при каждом деплое? Использовать мягкую перезагрузку вместо жёсткого рестарта: у php-fpm и nginx есть reload, поднимающий новые процессы до убийства старых, у приложений — схемы вида «поднять новую версию рядом, переключить трафик, погасить старую». Если балансировщик умеет health-check'и — он сам выведет перезапускаемый бэкенд из ротации на время рестарта.
Чем 502 отличается от 504? При 502 бэкенд ответил «не то» или отказал сразу; при 504 — не ответил вовремя. Причины и лечение разные, поэтому у нас про 504 отдельный разбор.