Фактический маршрут
Фиксируем CDN, балансировщик, веб-сервер, приложение, PHP-FPM, контейнеры и внешние API, участвующие в запросе.
Bad Gateway
Диагностика и исправление ошибки 502 на сайте
Проверяем всю цепочку от CDN или Nginx до приложения: доступность upstream, сокеты, процессы, контейнеры, таймауты и ответы. Исправляем подтверждённую причину, а не только страницу ошибки.
От шлюза к приложению
Где возникает
некорректный ответ
RFC 9110 определяет 502 как ситуацию, когда шлюз или прокси получил недопустимый ответ от входящего сервера. Это отличает ошибку от общего внутреннего сбоя 500 и требует проверки связи между компонентами.
Upstream
Проверяем адрес, порт или сокет, DNS внутри инфраструктуры, доступность процесса и соответствие протокола.
Журналы
Сопоставляем время 502 с error log прокси, системным журналом, журналом приложения и событиями перезапуска.
Процессы и ресурсы
Проверяем остановки, нехватку памяти, лимиты воркеров, очередь соединений и состояние диска.
Таймауты и ответы
Измеряем время ответа и корректность заголовков, не увеличивая лимиты до подтверждения причины.
Повторная проверка
Тестируем проблемные маршруты, перезапуски и ожидаемую нагрузку, контролируем отсутствие новых 502 в журналах.
Диагностика шлюза
Где возникает ошибка 502
Код 502 возвращает прокси или веб-сервер, когда не получает корректный ответ от приложения. Проверяем цепочку запроса целиком, а не перезапускаем сервисы без установления причины.
Прокси и приложение
Сверяем время ошибки в журналах Nginx, Apache и приложения. Проверяем адрес upstream, порт, сокет, DNS внутри инфраструктуры и состояние процесса, который должен обработать запрос.
Тайм-аут и нагрузка
Измеряем время ответа, очередь процессов, память, CPU и соединения с базой. Увеличение тайм-аута допустимо только после понимания, почему обработчик не успевает ответить.
Один URL или весь сайт
Сравниваем главную, административный раздел, форму и тяжёлый запрос. Ошибка одного сценария указывает на код или данные; массовый сбой чаще связан с процессом приложения или окружением.
Внешний сервис
Если страница зависит от API, отделяем его отказ от работы сайта. Добавляем ограниченный тайм-аут и понятный ответ пользователю, чтобы один недоступный сервис не блокировал весь запрос.
После восстановления
Как подтверждаем стабильность сайта
Достаточно ли перезапустить сервер?
Перезапуск может временно убрать симптом и стереть часть контекста. До действия сохраняем журналы и показатели ресурсов, после него проверяем, почему процесс остановился или перестал отвечать.
Что проверяем после исправления?
Контрольные страницы, форму, административный вход, фоновые задачи и повтор исходного тяжёлого запроса. В журналах не должно появляться новой серии 502 и аварийных перезапусков.
Когда нужен мониторинг?
Если ошибка была периодической или зависела от нагрузки, настраиваем проверку доступности и ресурсов с уведомлением. Порог выбираем по фактическому поведению приложения, а не по случайному единичному пику.
Результат
Согласованная серверная цепочка
Доступный upstream
Прокси подключается к правильному процессу, порту или сокету.
Стабильный ответ
Приложение завершает запрос в согласованных ресурсных границах.
Наблюдаемость
Разрыв можно быстро связать с конкретным компонентом и событием.
Порядок ремонта
Без случайных перезапусков
Перезапуск может временно восстановить процесс, но скрыть причину. Перед вмешательством сохраняем журналы, метрики и состояние сервисов.
Воспроизводим
Определяем URL, время, частоту и слой, который сформировал код 502.
Локализуем
Проверяем компоненты по одному, прямой ответ upstream и доступность из контекста прокси.
Исправляем
Корректируем конфигурацию, процесс, сокет, зависимость или лимит в минимальной области.
Контролируем
Повторяем критические сценарии и наблюдаем журналы после публикации.
Не путать с 504
Некорректный ответ и таймаут — разные сигналы
502 означает недопустимый ответ от upstream. 504 сообщает, что шлюз не получил своевременный ответ. На практике журналы и конфигурация нужны для точного различия.
Для диагностики подготовьте
- URL и время появления ошибки;
- схему сервера или панель хостинга;
- что менялось перед сбоем;
- используемые Nginx, PHP-FPM, Docker или приложение;
- доступ к журналам и резервной копии.
Не присылайте пароли в форме. Доступы согласуем отдельно с минимальными правами; внешние расходы не подключаем без подтверждения.
Вопросы
Перед исправлением
Что означает 502 Bad Gateway?
Шлюз или прокси получил некорректный ответ от сервера, к которому обратился для выполнения запроса. Проверяется связь и состояние всей цепочки.
Ошибка всегда связана с Nginx?
Нет. Nginx часто показывает код как прокси, но причиной может быть приложение, PHP-FPM, сокет, контейнер, неверный upstream или внешний сервис.
Поможет увеличение таймаута?
Только если подтверждено, что корректный upstream отвечает дольше лимита. Иначе это скрывает медленный код или перегрузку.
Как принимается результат?
Проверяем ответы компонентов, проблемные URL, повторные запросы, журналы и поведение под ожидаемой нагрузкой.
Первый шаг
Покажите ошибку 502
Пришлите URL, время и сведения об инфраструктуре. Определим вероятный разрыв и предложим проверяемый диагностический шаг.