Ошибка 502 Bad Gateway: причины и исправление

Ошибка 502 Bad Gateway означает, что сервер-посредник получил некорректный ответ от следующего сервера в цепочке. Посетителю стоит проверить другие страницы и повторить запрос позже. Владельцу сайта нужно зафиксировать время и URL, затем сопоставить журналы прокси, веб-сервера и приложения до перезапуска служб.

Что означает код 502

По стандарту HTTP код 502 возвращает шлюз или прокси, когда получает некорректный ответ от сервера, к которому обратился дальше. Браузер видит последнюю точку цепочки, но надпись NGINX или Cloudflare не доказывает, где возник сбой.

Типичная цепочка выглядит так: посетитель обращается к CDN или обратному прокси, тот — к веб-серверу, а веб-сервер — к приложению. Любое звено может быть доступно само по себе, но не получать ожидаемый ответ от следующего.

Не путайте соседние коды:

Если вы посетитель сайта

Посетитель не может исправить приложение или прокси. Сначала откройте другую страницу того же сайта и проверьте, повторяется ли ошибка. Затем подождите и обновите страницу один раз.

Не отправляйте повторно форму оплаты, заказ или загрузку файла без проверки результата. Сервер мог принять действие, а ответ потерялся по пути. Повторный POST-запрос способен создать дубль, даже если браузер показал ошибку.

Если сбой продолжается, передайте владельцу:

• точный адрес страницы;
• время с часовым поясом;
• снимок страницы ошибки;
• действие перед ошибкой;
• работает ли сайт через другую сеть.

Очистка кэша браузера редко устраняет серверный 502. VPN, смена DNS и переустановка браузера тоже не должны быть первым шагом, если ошибка воспроизводится у других пользователей.

Если вы владелец: сначала зафиксируйте факт

Не начинайте с перезапуска всех служб. Он стирает часть оперативных признаков, обрывает запросы и иногда временно маскирует причину. Сначала ограничение, потом наблюдение, затем изменение.

Зафиксируйте время на сервере и ответ проблемного URL:

date -Is
curl -sS -D - -o /dev/null https://example.com/problem-path

Сохраните заголовки ответа, идентификатор запроса CDN, если он есть, и несколько строк журналов вокруг события. Не публикуйте токены, cookie, IP клиентов и полные строки с персональными данными в обращении.

Определите масштаб: одна страница, один домен, один сервер или весь проект. Если статические файлы открываются, а динамические страницы дают 502, проверяйте связь с приложением раньше DNS.

Локализуйте сбой по цепочке

Двигайтесь от видимого прокси к следующему звену. Не меняйте сразу тайм-ауты, сокеты и пул процессов: при нескольких одновременных правках результат нельзя связать с причиной.

Если используется CDN, сравните публичный ответ с ответом origin только из разрешённой диагностической точки. Не открывайте origin всему интернету ради теста и не отключайте защиту без окна и способа вернуть настройки.

Проверка NGINX

В error log NGINX ищите сообщения рядом с временем запроса: отказ соединения, тайм-аут, некорректный заголовок или отсутствие доступного upstream. Затем сверьте адрес и порт из сообщения с фактическим процессом приложения.

Проверка конфигурации безопаснее перезапуска:

nginx -t

Эта команда проверяет синтаксис и доступность файлов, упомянутых в конфигурации. Она не доказывает, что приложение на upstream отвечает правильно, поэтому после неё нужен отдельный запрос к приложению из той же сетевой среды.

Перед применением изменения сохраните diff и команду возврата к предыдущему файлу. Только после успешной проверки конфигурации используйте штатную плавную перезагрузку, принятую в вашей системе. Не завершайте worker-процессы вручную и не запускайте kill по совпадению имени.

Проверка Apache и приложения

Apache с mod_proxy тоже может быть шлюзом и вернуть 502 после проблемного ответа backend. Проверьте error log Apache, настройки ProxyPass и реальный адрес приложения. Пользовательская страница ошибки через ProxyErrorOverride меняет оформление, но не устраняет причину.

Для проверки синтаксиса используйте штатный интерфейс:

apachectl configtest

Если исправление действительно требует перечитать конфигурацию, сначала подтвердите Syntax OK и подготовьте откат. Apache поддерживает graceful-перезапуск, который сохраняет текущие соединения лучше немедленного restart, но и он не заменяет проверку приложения.

У приложения проверьте состояние процесса, последние ошибки, очередь запросов, соединения с базой и доступность нужного сокета. Не удаляйте сокет и не увеличивайте лимиты вслепую: это может добавить второй сбой.

Когда причина в ресурсах

502 часто появляется рядом с исчерпанием памяти, аварийным завершением процесса, нехваткой workers или соединений. Но один высокий график CPU ещё не доказывает причинность. Сопоставьте метрики с точным временем и журналом приложения.

Проверьте:

• был ли процесс приложения жив;
• слушал ли ожидаемый порт или сокет;
• хватало ли памяти без аварийного завершения;
• не заполнился ли диск с журналами или временными файлами;
• не исчерпан ли пул соединений к базе;
• завершались ли запросы до тайм-аута прокси.

Увеличение тайм-аута полезно только для ожидаемо долгой операции. Если приложение зависло или делает неограниченный запрос, больший тайм-аут просто заставит посетителя ждать дольше.

CDN и внешний прокси

Cloudflare рекомендует различать ошибку, созданную исходным сервером, и ошибку собственной пограничной сети. Для обращения в поддержку полезны URL, точное время с часовым поясом и диагностическая трассировка. Оформление страницы может подсказать направление, но журналы надёжнее внешнего вида.

При инфраструктуре через Cloudflare, Yandex Cloud, Selectel, Beget или Timeweb проверьте статус площадки и панель проекта. Ссылки ведут на страницы провайдеров HostScout и не означают одинаковую архитектуру у всех услуг.

В обращение передавайте минимальный воспроизводимый набор: URL, время, идентификатор запроса, регион, ответ исходного сервера и факт недавних изменений. Это быстрее, чем сообщение сайт не работает без временной привязки.

Вопросы и ответы

Что считать исправлением

Ошибка устранена не тогда, когда страница открылась после перезапуска, а когда найдено проблемное звено, подтверждена причина и проверен откат. Повторите исходный запрос, просмотрите журналы и убедитесь, что метрики вернулись к норме. Self-hosting требует календаря наблюдения, а не ритуала перезапуска.