Ошибка 502 Bad Gateway: что делать посетителю и владельцу сайта

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

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

Что означает ошибка 502 Bad Gateway

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

По RFC 9110 код 502 связан именно с некорректным ответом при работе сервера в роли шлюза. На практике конкретная реализация может выдавать его при разных нарушениях связи с обработчиком. Установить причину только по трём цифрам нельзя: нужен контекст ответа и запись о событии.

Не путайте соседние статусы. 500 сообщает об общем внутреннем сбое сервера, 503 — о временной невозможности обслужить запрос, а 504 — об отсутствии своевременного ответа от вышестоящего сервера. Это разные направления проверки. Разница между шлюзом и обычной внутренней ошибкой также объясняется в справке MDN о 502.

Ошибка бывает частичной. Каталог может открываться, а поиск или оформление заказа — получать 502, потому что их обслуживают разные компоненты. Поэтому вопрос «сайт работает или нет» лучше уточнить: какой адрес, метод и действие не выполняются?

Что делать посетителю сайта при ошибке 502

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

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

Если сервис работает у коллег, а у вас нет, можно сравнить результат в другом браузере или обычной доступной сети. Это диагностическое сравнение, а не доказательство неисправности компьютера. Разные пользователи могут попадать на разные серверы, использовать разные сессии и выполнять разные запросы.

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

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

Как владельцу сайта найти источник ошибки 502

Начните с карты прохождения проблемного запроса. Например: браузер, CDN, Nginx, приложение. Для PHP последним звеном может быть PHP-FPM; для другого проекта — HTTP-сервис. Не переносите настройки из чужой инструкции, пока не установили собственную схему.

Откройте Network («Сеть») в инструментах разработчика и воспроизведите один допустимый тестовый сценарий. Найдите запрос со статусом 502, проверьте адрес, метод, заголовки и тело ответа. Эти возможности описаны в руководстве Chrome DevTools. Важно отличить отказ основного документа от ошибки фонового API или стороннего виджета.

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

Надпись nginx, логотип CDN и заголовок Server помогают выбрать направление поиска. Они не доказывают, что проблема находится именно в показанном продукте. Прокси может сообщать о сбое программы за ним, а другой узел — передавать уже полученный ошибочный ответ.

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

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

Основные причины 502: что искать в журналах

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

Наблюдение	Что может происходить	Что проверить
Соединение с обработчиком отклонено	Процесс не слушает ожидаемый адрес или порт	Состояние процесса и совпадение адресов на обеих сторонах
Не найден Unix-сокет	Прокси обращается по устаревшему пути	Сокет работающего пула и настройку передачи запроса
Доступ к сокету запрещён	Рабочему процессу не хватает предусмотренных прав	Пользователя, группу, ACL и доступ к каталогам пути
Обработчик закрыл соединение раньше завершения ответа	Процесс завершился или оборвал обработку	Его журнал и системные события в тот же момент
Ответ или заголовок не принят прокси	Нарушен ожидаемый формат либо превышено конкретное ограничение	Содержимое ответа и точное сообщение об отказе
Ошибки чередуются с успехом	Различается состояние узлов или условий запроса	Адрес обслуживающего узла и различия конфигурации

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

В Nginx сведения об upstream помогают уточнить цепочку. Переменные адреса, статуса и времени ответа описаны в документации upstream-модуля. Один клиентский запрос может включать несколько попыток обращения к обработчикам, поэтому запись анализируют целиком, а не по одному выбранному значению.

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

Как исправлять 502 в Nginx и PHP-FPM

У Nginx может быть несколько способов передачи запроса. Сначала выясните, какой применяется к проблемному маршруту. HTTP-сервис за proxy_pass и PHP-FPM за fastcgi_pass требуют разных настроек; заменить одно другим по сходству названий нельзя.

Проверьте адрес и протокол upstream

Директива proxy_pass задаёт адрес HTTP- или HTTPS-сервера и может влиять на передаваемый путь. Синтаксис приведён в документации модуля проксирования. Сравните домен, порт, протокол и маршрут с тем, что фактически обслуживает приложение.

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

Если журнал указывает на проблему TLS при связи с upstream, исследуйте имя сервера, сертификат и доверие между компонентами. Отключение проверки сертификата не объясняет причину. Исправление должно восстановить предусмотренный защищённый обмен.

Сверьте fastcgi_pass и настройки PHP-FPM

Для FastCGI адрес обработчика задаёт fastcgi_pass: это может быть адрес с портом либо путь Unix-сокета. Допустимые формы описаны в документации Nginx. Проверьте значение в реально выбранном обработчике, а не в соседнем конфигурационном файле.

Со стороны PHP-FPM проверьте запущенный пул и его listen. Для Unix-сокета существенны настройки владельца, группы и режима доступа; при использовании ACL учитывайте их отдельно. Значение параметров описывает руководство PHP-FPM. После смены версии PHP имя сокета или пула могло измениться, а прокси — сохранить прежний путь.

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

Исследуйте состояние приложения и доступные ресурсы

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

Если рабочие процессы заняты, оцените длительность операций и очередь. Например, pm.max_children ограничивает количество одновременно обслуживаемых запросов PHP-FPM. Увеличивать его без оценки памяти и нагрузки нельзя: дополнительные процессы тоже потребляют ресурсы. Сначала подтвердите, что ограничение действительно участвует в сбое.

Сравните узлы и готовность новой версии

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

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

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

Меняйте только подтверждённую настройку

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

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

Что проверить, если ошибка связана с CDN

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

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

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

Пример: 502 появился после обновления PHP

Рассмотрим условную ситуацию. После смены версии PHP статические изображения загружаются, а динамические страницы возвращают 502. В журнале прокси указан несуществующий Unix-сокет. Новый пул PHP-FPM запущен и принимает обращения по другому пути.

Здесь уже есть проверяемая гипотеза: передача запроса осталась привязана к старому обработчику. Администратор сверяет выбранный конфигурационный блок Nginx, параметр listen нового пула и назначение этого пула для нужного сайта. Затем проверяет предусмотренные права доступа. Простого наличия любого PHP-процесса недостаточно.

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

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

Как проверить, что ошибка 502 устранена

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

• Исходный маршрут возвращает ожидаемый статус и содержимое.
• В нужном обработчике появляется соответствующая запись.
• Действие завершается в приложении: данные сохранены, результат доступен пользователю.
• В журнале больше нет подтверждённой причины отказа для этого сценария.
• При нескольких узлах проверены конфигурация и работа каждого участвующего экземпляра.
• Изменение и способ возврата к прежнему состоянию зафиксированы.

Код 200 сам по себе не подтверждает исправление: вместо страницы сервер может вернуть пустой ответ или сообщение об ошибке. Не маскируйте 502 заменой статуса без восстановления функции. Оценивайте содержание и конечный результат действия.

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

Как замечать повторные сбои и учитывать влияние на SEO

Регулярные проверки важных адресов помогают заметить повторный 502 и сопоставить его с релизом или работами на хостинге. Для расследования полезны история ответов и понятный порядок уведомления ответственного. Перейдите на SiteGuard, если хотите обсудить задачу: укажите проблемный маршрут, время отказа и известную схему обработки запроса.

Внешний контроль адреса не заменяет журнал приложения и проверку всех пользовательских действий. Если 502 возникает только при отправке формы или у отдельной сессии, исследуйте этот сценарий дополнительно. Для команды полезно заранее определить, кто получает уведомление и где ищет сведения о последнем изменении.

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

Что передать хостингу или разработчику

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

Условный шаблон: «После обновления среды динамические страницы возвращают 502, изображения открываются. В журнале прокси указан отсутствующий сокет. Просим проверить соответствие адреса FastCGI работающему пулу». Используйте только собственные факты и замените детали. Так специалист получает проверяемую задачу, а не просьбу перезапустить всё подряд.

Частые вопросы об ошибке 502 Bad Gateway

Ошибка 502 находится на моём компьютере или на сайте?

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

Почему 502 появляется и исчезает?

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

Поможет ли увеличение тайм-аута Nginx?

Только если измерения подтвердили связанную с ожиданием причину и изменение соответствует архитектуре. При отсутствии обработчика, неправильном сокете или протоколе дополнительное ожидание не восстановит обмен. Отличайте 502 от отдельного статуса 504.

Почему перезапуск помог только ненадолго?

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

Когда можно закрывать задачу об исправлении?

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