502 Bad Gateway на сайте: как найти неисправный слой

Как разбирать 502 Bad Gateway по слоям: найти ответивший шлюз, сопоставить журналы с upstream, проверить состояние PHP и повторить запрос без дублей записывающих операций.

Зафиксируйте ошибку до любых перезапусков

502 Bad Gateway означает, что сервер, действующий как шлюз или прокси, получил некорректный ответ от следующего сервера при обработке запроса. Это описание взаимодействия, а не готовый диагноз «сломался PHP» или «виноват хостинг». В цепочке могут участвовать CDN, балансировщик, веб-сервер и обработчик приложения. Сначала сохраните адрес, метод, время с часовым поясом и видимый код.

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

Определите масштаб и границы сбоя

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

Сохраните последнее успешное наблюдение и начало отказа. Если есть идентификатор запроса от шлюза, запишите его без cookies и авторизационных заголовков. Для закрытого API фиксируйте маршрут и метод, но не публикуйте токен или полное тело с данными клиента.

Найдите звено, которое сформировало 502

В инструментах разработчика браузера посмотрите основной запрос, код, заголовки и ответ. Брендированная страница CDN и ответ origin помогают установить источник, но сами по себе не показывают первопричину. Пользовательский шаблон ошибки может скрывать сообщение следующего уровня. Сопоставляйте время и идентификатор с журналами доступных компонентов.

Проверять origin в обход CDN допустимо только в рамках разрешённой инфраструктуры и согласованного диагностического способа. Не меняйте публичный DNS и не отключайте защиту сайта целиком ради эксперимента. На shared владелец может не иметь доступа к upstream-журналу; тогда передайте хостеру точные время, URL и повторяемость, чтобы он проверил свою часть цепочки.

Время и часовой пояс: ...
URL и метод: ...
Действие: чтение / запись / импорт
HTTP: 502
Идентификатор запроса: если доступен
Последнее изменение: конкретная операция
Состояние после ошибки: сохранено / не сохранено / неизвестно

Сопоставьте журналы прокси и обработчика

Попросите администратора найти запись Nginx или другого шлюза для конкретного запроса. Отказ соединения, преждевременное закрытие upstream и некорректный заголовок — разные направления разбора. Затем сравните журнал PHP-FPM и приложения за тот же момент. Не начинайте с универсальной команды перезапуска: она может уничтожить наблюдаемое состояние, временно скрыв повторяющийся отказ.

Пути журналов и названия служб зависят от площадки. Не выполняйте sudo-команды для выдуманного имени сервиса. Администратор должен подтвердить реальную схему и область влияния: один пул PHP может обслуживать несколько проектов. Наблюдение относится к зафиксированному запросу, а не автоматически ко всем сайтам на сервере.

Проверьте ресурсы без случайного увеличения лимитов

Завершение PHP-процесса может быть связано с памятью, ограничением времени, ошибкой расширения или аварией. Высокое использование памяти в панели не определяет, какой процесс и почему прекратил работу. Сопоставьте время, журналы и реальную операцию. Для VPS администратор проверяет состояние пула, системные события и доступные ресурсы; на shared нужны данные поставщика.

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

Если сбой появился после обновления

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

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

Особая осторожность для сохранения, API и заказа

Получив 502 после записи, сначала прочитайте результат: существует ли публикация, изменился ли товар, создан ли заказ, обработан ли идентификатор события. Если результат уже появился, повтор может создать дубль. Для API нужны предусмотренные разработчиком ключи идемпотентности или уникальные идентификаторы операций; их нельзя придумывать поверх неподдерживающего сервиса.

1. Остановите автоматический повтор проблемной записывающей операции.
2. Сохраните её идентификатор и время в закрытом протоколе.
3. Прочитайте фактическое состояние штатным способом.
4. Сверьте внешний результат, если задействован другой сервис.
5. Устраните подтверждённую причину и повторяйте только по правилам обработчика.

Для платежа локальный статус страницы не является окончательным источником результата списания. Сверку выполняют по процедуре платёжного модуля и провайдера. Не создавайте реальный платёж ради диагностики общего 502: используйте разрешённую песочницу и обезличенный сценарий.

Внесите минимальное исправление и повторите исходный тест

Исправление выбирают по факту: восстановить нужный сервис, вернуть ошибочную конфигурацию, устранить несовместимость, скорректировать обработку ответа или ресурсный профиль. Каждое действие должно иметь владельца и область влияния. Если причина пока неизвестна, так и запишите; временное восстановление после перезапуска не доказывает окончательного устранения.

Повторите исходный запрос в том же контексте, затем проверьте критичные соседние операции. Проверьте новые записи журналов, а не только браузер. Для чтения сравните реальное содержимое и один H1, для записи — сохранённое состояние, для интеграции — отсутствие дублей и подтверждение получателя. Не объявляйте весь сайт исправленным по одной закэшированной главной.

Подготовьте доказательный запрос в поддержку

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

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

FAQ и критерий завершения

Завершение — это подтверждённая доступность нужного действия, сохранность данных, отсутствие непредусмотренных повторов и протокол причины либо её текущей неопределённости. Не подменяйте диагностику рекламным выводом о качестве провайдера.

Источники и дата

• RFC 9110: 502 и HTTP-семантика
• PHP-FPM: конфигурация и журналирование
• Nginx: модуль FastCGI
• HTTP 502
• Отладка WordPress

Редакционная переработка: 26.10.2026. Источники относятся к своим версиям продуктов; параметры конкретного проекта необходимо подтвердить отдельно.