Ошибка 502 Bad Gateway означает, что один сервер получил неверный ответ от другого сервера, к которому обратился для выполнения запроса. Браузер видит это как тупик: он правильно отправил запрос, промежуточный сервер его принял, но дальше что-то пошло не так — и вместо страницы пользователь получает белый экран с надписью Bad Gateway.
Это серверная ошибка, а не проблема на стороне пользователя. Код 5xx в HTTP означает, что запрос технически корректен, но сервер не смог его обработать. Именно поэтому перезагрузка страницы иногда помогает — если сбой был кратковременным, повторный запрос проходит успешно.
Что такое 502 Bad Gateway простыми словами
Представьте, что вы звоните в компанию, вас переключают на нужный отдел, но там никто не берёт трубку. Оператор не может соединить и говорит вам об этом. Именно так работает ошибка 502: ваш браузер — это вы, промежуточный сервер — оператор, а бэкенд-сервер — отдел, который не отвечает.
В реальной архитектуре между пользователем и приложением почти всегда стоит прокси или балансировщик нагрузки. Nginx, Apache, Cloudflare, CDN — все они принимают запрос и передают его дальше. Если дальше что-то недоступно, зависло или вернуло мусор вместо нормального ответа, пользователь видит 502.
Чем 502 отличается от других серверных ошибок
- Ошибка 500 — это общий внутренний сбой сервера, когда приложение упало или в коде произошла необработанная ошибка.
- Ошибка 503 означает, что сервер временно недоступен — перегружен или на техническом обслуживании.
- Ошибка 504 похожа на 502, но разница принципиальная: при 504 промежуточный сервер не получил ответ в отведённое время, то есть запрос ушёл, но завис. При 502 ответ пришёл, но он был некорректным или пустым.
На практике 502 и 504 часто путают, потому что внешне они выглядят одинаково. Разобраться помогают логи — в них видно, тайм-аут это или неверный ответ от апстрима.
Почему возникает ошибка 502
Причин у 502 несколько, и они лежат на разных уровнях инфраструктуры. Иногда это секундный сбой при деплое, иногда — симптом серьёзной проблемы с конфигурацией или ресурсами сервера. Понять источник быстрее всего помогают логи промежуточного сервера — там почти всегда написано, что именно вернул апстрим.
Проблемы с бэкенд-сервером
Самая частая причина — бэкенд-приложение упало, зависло или перестало принимать соединения. PHP-FPM завершил все рабочие процессы, Node.js-приложение вылетело с необработанным исключением, Python-воркер потребил всю память и был убит операционной системой. Nginx или Apache честно пытаются передать запрос, получают в ответ тишину или ошибку соединения и отдают пользователю 502.
Проверить это просто: зайти на сервер и посмотреть, запущен ли процесс приложения. Если сервис упал — поднять его и разобраться, почему он упал, чтобы это не повторялось.
Неверная конфигурация прокси
Если в конфиге Nginx или Apache указан неправильный адрес или порт бэкенда, запрос физически уходит не туда. Сервер на другом адресе отвечает отказом, и это превращается в 502. Такое часто случается после переезда приложения на другой порт или сервер, когда конфигурацию прокси забыли обновить.
Перегрузка сервера
Под высокой нагрузкой бэкенд может исчерпать пул соединений или рабочих процессов. Новые запросы некому обрабатывать — и прокси получает отказ. Это типичная картина при резком всплеске трафика: сайт работал нормально, потом пришла волна пользователей, и посыпались 502. После спада нагрузки ошибки прекращаются сами собой.
Проблемы с сетью между серверами
Если прокси и бэкенд находятся на разных машинах или в разных дата-центрах, между ними может возникнуть сетевая проблема: packet loss, недоступность IP-адреса, проблемы с DNS-резолвингом внутри инфраструктуры. Прокси не может установить соединение с апстримом — пользователь видит 502.
Истечение таймаута на стороне прокси
Иногда бэкенд отвечает, но слишком медленно — например, выполняет тяжёлый запрос к базе данных. Если прокси настроен на короткий таймаут, он не дожидается ответа и разрывает соединение. В зависимости от реализации это может отдаваться пользователю как 502 или как 504.
Ошибка 502 в Nginx
Nginx — один из самых популярных прокси-серверов, и большинство встреч с 502 происходит именно через него. Когда Nginx не может получить корректный ответ от апстрима, он записывает это в error.log и отдаёт пользователю страницу с ошибкой.
Как читать логи Nginx при 502
Первое, что нужно сделать — открыть error.log. По умолчанию он находится по пути /var/log/nginx/error.log. Там будет строка с указанием апстрима, к которому Nginx обращался, и причиной сбоя: connect() failed означает, что соединение не установилось вообще, recv() failed — что соединение было установлено, но данные не пришли, upstream sent invalid header — что бэкенд вернул что-то нечитаемое.
Зная конкретную причину, найти и устранить проблему значительно проще. Без логов придётся перебирать варианты вслепую, что занимает в разы больше времени.
Типичные настройки Nginx, влияющие на 502
Директива proxy_pass должна указывать на актуальный адрес и порт бэкенда. Директивы proxy_connect_timeout, proxy_read_timeout и proxy_send_timeout определяют, сколько Nginx ждёт ответа — слишком короткие значения приводят к ложным 502 при нормально работающем бэкенде. Параметр fastcgi_pass для PHP-FPM должен совпадать с тем, на чём слушает PHP-FPM: unix-сокет или TCP-порт.
Ошибка 502 в Apache
Apache в роли прокси встречается реже, чем Nginx, но принцип тот же. При использовании mod_proxy Apache проксирует запросы на бэкенд, и если тот недоступен или вернул некорректный ответ — Apache отдаёт 502.
Логи Apache находятся в /var/log/apache2/error.log или /var/log/httpd/error_log в зависимости от дистрибутива. В них нужно искать строки с упоминанием proxy и кодом ошибки — там будет указано, к какому хосту Apache пытался подключиться и что пошло не так. Конфигурация таймаутов в Apache управляется директивой ProxyTimeout, а адрес бэкенда задаётся в блоке ProxyPass.
Как исправить ошибку 502 Bad Gateway
Алгоритм диагностики примерно одинаковый независимо от стека. Начинают с самого очевидного и постепенно спускаются вглубь. Большинство случаев решается на первых двух-трёх шагах.
Проверить статус бэкенд-приложения
Зайти на сервер по SSH и убедиться, что процесс приложения запущен. Для PHP-FPM это systemctl status php-fpm, для Node.js — проверить процесс через pm2 status или ps aux, для Python-приложений — статус gunicorn или uwsgi. Если процесс не запущен — запустить его и изучить причину падения в системных логах.
Проверить порты и сетевую доступность
Убедиться, что бэкенд слушает на том порту, который указан в конфиге прокси. Команда ss -tlnp или netstat -tlnp покажет все открытые порты и процессы, которые их слушают. Если порты совпадают, проверить, нет ли блокировки на уровне файрвола: iptables -L или правила в ufw.
Перезапустить сервисы
Иногда достаточно перезапустить проблемный сервис — это помогает при временных зависаниях рабочих процессов. Перезапускать лучше в таком порядке: сначала бэкенд-приложение, потом прокси-сервер. Перезапускать прокси без перезапуска бэкенда смысла нет — Nginx не причина проблемы, он её только фиксирует.
Увеличить таймауты прокси
Если 502 возникает только на тяжёлых запросах — больших загрузках файлов, сложных отчётах, длинных транзакциях — проблема, скорее всего, в таймаутах. Увеличить proxy_read_timeout в Nginx до разумного значения и проверить, исчезли ли ошибки. Параллельно стоит разобраться, почему запросы выполняются так долго — это отдельная задача оптимизации.
Проверить ресурсы сервера
Если 502 появляются под нагрузкой — проверить потребление CPU, памяти и дисковый I/O в момент ошибок. Утилиты top, htop, iostat покажут, не упирается ли сервер в ресурсные ограничения. Если память на исходе, операционная система убивает процессы приложения — это прямой путь к 502.
Что делать пользователю при ошибке 502
Если вы пользователь, а не администратор сайта, возможности ограничены — проблема на стороне сервера, и починить её может только владелец ресурса. Но несколько вещей стоит попробовать, прежде чем закрыть вкладку.
Обновить страницу через несколько минут
Многие 502 кратковременны — они возникают в момент деплоя, перезапуска сервисов или кратковременного всплеска нагрузки. Подождать одну-две минуты и обновить страницу — самый простой способ, который работает в половине случаев. Нажимать F5 каждые пять секунд смысла нет — это только добавляет нагрузку на и без того перегруженный сервер.
Очистить кеш браузера и куки
В редких случаях проблема может быть связана с устаревшими кешированными данными или некорректными куки, которые заставляют сервер возвращать ошибку. Очистить кеш через настройки браузера и попробовать снова. Если сайт открывается в режиме инкогнито, а в обычном — нет, причина именно в этом.
Попробовать другой DNS-сервер
Иногда проблема не в самом сайте, а в том, что DNS-сервер провайдера кеширует устаревший IP-адрес. Попробовать сменить DNS на публичный — 8.8.8.8 или 1.1.1.1 — и проверить снова. Ещё вариант — открыть сайт с мобильного интернета: если там работает, а дома нет, проблема на уровне сети провайдера или локального DNS.
Ошибка 502 на конкретных платформах
На хостинг-панелях и популярных сервисах 502 имеет свои типичные причины, которые немного отличаются от ситуации с выделенным сервером.
VestaCP и Plesk
На серверах с VestaCP и Plesk 502 чаще всего возникает из-за того, что PHP-FPM для конкретного домена остановлен или работает не на том сокете, который указан в конфиге Nginx. Решение — зайти в панель управления, проверить статус PHP-обработчика для проблемного домена и перезапустить его. Если это не помогает, смотреть логи Nginx и PHP-FPM для этого домена отдельно.
Discord
502 в Discord — почти всегда проблема на стороне серверов Discord, не пользователя. Это происходит при деплоях, инцидентах с инфраструктурой или при аномально высокой нагрузке на конкретный регион. Проверить статус на официальной странице discordstatus.com и подождать — самостоятельно починить это невозможно.
Steam
В Steam 502 возникает при обращении к серверам Valve — во время обновлений, технических работ или при перегрузке CDN. Логика та же: проверить официальный статус Steam и подождать восстановления. Очистка кеша Steam и смена DNS иногда помогают, если проблема связана с региональным CDN-узлом.
Как предотвратить появление 502 на своём сайте
Полностью исключить 502 невозможно — любой сервер иногда ошибается. Но можно сделать так, чтобы ошибки возникали реже, длились меньше и не заставали вас врасплох.
Мониторинг доступности
Настроить внешний мониторинг, который проверяет сайт каждую минуту и отправляет уведомление при 502. Инструменты вроде UptimeRobot, Pingdom или Zabbix позволяют узнать о проблеме раньше пользователей. Без мониторинга о том, что сайт лежит, вы узнаёте из жалоб в поддержку.
Автоматический перезапуск сервисов
Настроить systemd или supervisor так, чтобы сервисы приложения автоматически перезапускались при падении. Это не решает проблему, но существенно сокращает время простоя: вместо того чтобы лежать до утра, сервис поднимается сам через несколько секунд после краша.
Запас по ресурсам и горизонтальное масштабирование
502 под нагрузкой — сигнал, что серверу не хватает ресурсов. Решение в долгосрочной перспективе — либо увеличить мощность существующего сервера, либо добавить балансировщик нагрузки с несколькими бэкенд-инстансами. Если один из них падает, балансировщик перенаправляет трафик на остальные, и пользователи ничего не замечают.
Красивая страница ошибки
Если 502 всё же случился, пользователь должен видеть понятную страницу с объяснением, а не стандартный белый экран с техническим текстом. Настроить кастомную страницу для 502 в конфиге Nginx или Apache — это не решает техническую проблему, но сильно улучшает впечатление пользователя от ситуации, которую не удалось предотвратить.
Комментарии скоро откроются. А пока — пишите нам в Telegram-канал.