Ошибка 502 Bad Gateway означает, что сервер, работающий как шлюз или прокси, получил некорректный ответ от вышестоящего сервера. Обычно проблема находится между Nginx, CDN или балансировщиком и приложением. Посетитель может исключить локальный сбой, но исправлять устойчивую 502 должен владелец сайта или администратор инфраструктуры.
Если нужна системная работа с поисковым спросом, технической базой и контентом, изучите услугу комплексного SEO-продвижения.
Что означает 502 и где возникает ошибка
Смежная задача разобрана отдельно: Ошибка 502 Bad Gateway: что означает и как исправить.
Что происходит при ошибке 502
Браузер обращается к публичному серверу. Тот передает запрос приложению, PHP-FPM, API или другому вышестоящему компоненту (upstream). Если ответ отсутствует, поврежден или соединение завершается неправильно, промежуточный сервер возвращает 502.
Не путайте 502 с 504: при 504 шлюз не дождался ответа вовремя, а 502 указывает на недопустимый ответ. На практике причины могут пересекаться, поэтому решают проблему по журналам и трассировке запроса.
Действия посетителя и владельца сайта
Смежная задача разобрана отдельно: Ошибка 404: что это значит и как исправить на сайте.
Что делать посетителю
Обновите страницу один раз, затем проверьте другой раздел сайта. Исключите локальную сеть: попробуйте другое подключение или устройство. Если не работает только один сайт, вероятнее всего, проблема на его стороне.
Не очищайте без необходимости все данные браузера и не устанавливайте сомнительные программы. Для платежа сначала проверьте историю операций: повторная отправка формы после сбоя может создать дубль.
Причины 502 по компонентам инфраструктуры
Причины на стороне сайта
Частые причины: остановленное приложение, перегрузка, неверный адрес вышестоящего сервера, ошибка DNS внутри инфраструктуры, закрытый порт, несовместимые настройки TLS, авария контейнера, лимиты соединений, перезапуск во время релиза или некорректный ответ внешнего API.
Сообщение с подписью Nginx указывает, кто сформировал ответ, но не доказывает, что виноват сам Nginx. Первопричина часто находится в приложении или сети за ним.
Диагностика и безопасное исправление
Диагностика для администратора
Зафиксируйте время, URL, метод, заголовок трассировки и узел, который вернул ошибку. Сверьте access/error logs прокси с журналами приложения и метриками CPU, памяти, соединений и времени ответа.
Проверьте доступность вышестоящего сервера с того же узла и в том же сетевом контексте. Сопоставьте всплеск ошибок с релизом, изменением конфигурации, сертификата, DNS, автоскейлинга или внешнего сервиса.
Как исправлять безопасно
Восстановите приложение или маршрут, исправьте адрес и порт, настройте проверки готовности, лимиты и таймауты по реальному профилю нагрузки. Простое увеличение таймаута маскирует медленную обработку, если причина — блокировка базы или исчерпание пула.
После исправления выполните контрольные запросы, проверьте долю 5xx и время ответа. Добавьте мониторинг на уровне пользователя и оповещения по проценту ошибок, а не только по факту работы процесса.
Влияние на SEO
Единичная краткая 502 не требует паники. Массовые или длительные ответы 5xx мешают пользователям и поисковым роботам получать страницы, могут замедлить обход и обновление индекса.
Не перенаправляйте все ошибки на главную и не отдавайте страницу ошибки с кодом 200. Сервер должен возвращать корректный статус, а мониторинг — быстро обнаруживать инцидент.
Сценарии для Nginx, CDN и контейнеров
В связке Nginx и приложения проверьте, существует ли сокет или порт, слушает ли его процесс и разрешено ли соединение. После релиза приложение может еще запускаться, тогда прокси уже принимает трафик, но вышестоящий сервер еще не готов. Решение — корректная проверка готовности и переключение трафика только после успешного ответа.
В инфраструктуре с CDN выясните, кто вернул 502: пограничный узел, балансировщик или origin. Сравните заголовки и журналы на каждом уровне. В контейнерной среде проверьте перезапуски, нехватку памяти, сервисное имя, сетевые политики и актуальность списка endpoints.
Что искать в журналах
Сообщения connection refused обычно указывают, что по адресу никто не принимает соединение либо доступ блокируется. Connection reset означает разрыв установленного соединения. Ошибки разбора заголовков могут появиться из-за некорректного ответа приложения или слишком больших заголовков. Формулировка в журнале важнее текста стандартной страницы 502.
Связывайте записи по идентификатору запроса (request ID). Без единого идентификатора запрос трудно провести через CDN, прокси, приложение и базу. Синхронизируйте время узлов и сохраняйте достаточно контекста, но не записывайте секреты, пароли и полные платежные данные.
Реагирование, профилактика и мониторинг
План реагирования на инцидент
Сначала ограничьте влияние: откатите проблемный релиз, выведите неисправный узел из балансировки или включите проверенный резервный маршрут. Затем подтвердите восстановление снаружи, а не только на сервере. После стабилизации соберите временную линию и первопричину.
Постинцидентный разбор должен закончиться изменением системы: тестом конфигурации, проверкой работоспособности, лимитом, автоматическим откатом, мониторингом зависимости или инструкцией дежурному. Цель — не найти виновного, а уменьшить вероятность и длительность повторения.
Профилактика и мониторинг
Используйте внешние проверки ключевых пользовательских сценариев, метрики доли ответов 5xx и распределение времени ответа. Оповещение по одной ошибке создает шум; порог выбирают с учетом трафика и критичности операции. Для редких, но важных действий полезны синтетические транзакции.
Проводите нагрузочные испытания до пиковых периодов, задавайте разумные лимиты очередей и соединений, контролируйте пулы базы и внешние API. Таймауты на соседних уровнях должны быть согласованы, чтобы внутренний компонент завершал работу раньше внешнего шлюза и возвращал диагностируемый ответ.
Диагностическая таблица решений
Если 502 видят все пользователи и на всех URL, начинайте с доступности origin, балансировщика и общих зависимостей. Если ошибка ограничена одним разделом, ищите конкретный сервис, маршрут или тяжелую операцию. Если сбой возникает только под нагрузкой, анализируйте исчерпание пулов, очереди, лимиты памяти и масштабирование.
Если прямой запрос к приложению успешен, а через прокси — нет, сравните протокол, адрес, Host/SNI, размер заголовков и настройки TLS. Успешный curl с ноутбука не доказывает доступность из контейнера прокси: тест выполняют из того же сетевого пространства и с максимально близкими параметрами.
Если ошибка появилась сразу после релиза, самым быстрым безопасным действием часто будет откат, но сначала сохраните логи и идентификаторы запросов. Если изменений не было, проверьте автоматические события: ротацию сертификата, DNS, перезапуск, очистку кэша, окончание квоты и аварию поставщика.
Документируйте ответственность по слоям: CDN, DNS, балансировщик, прокси, приложение, база и внешние API. Для каждого слоя задайте метрику здоровья и контакт. При следующем инциденте команда быстрее определит, где заканчивается успешный запрос и начинается отказ.
Что не следует делать
Не перезапускайте все компоненты одновременно до сбора доказательств: проблема может исчезнуть вместе с причиной. Не увеличивайте без разбора все таймауты и лимиты. Не скрывайте сбой ответом 200 с текстом ошибки и не повторяйте автоматически небезопасные операции пользователя.
Не ограничивайтесь проверкой главной страницы. Тестируйте чтение, поиск, авторизацию и критичные операции отдельно. Сервис может отвечать 200 на легкий служебный адрес проверки работоспособности и возвращать 502 на запросе, которому нужна база данных.
Контроль перед публикацией и внедрением
Для бизнеса заранее определите допустимый уровень ошибок и время восстановления для разных операций. Недоступность статьи, корзины и подтверждения платежа имеет разную цену. Критичные операции проектируют идемпотентными, чтобы безопасный повтор не создавал второй заказ или списание. Пользовательская страница сбоя должна дать понятное сообщение и способ продолжить позже, но сохранять честный код 5xx.
После инцидента проверьте поисковые последствия: длительность, долю затронутых URL, активность роботов и восстановление обхода. Не предпринимайте массовые SEO-изменения, если страницы снова стабильно отвечают. Главная профилактика для поиска — доступная инфраструктура, корректные статусы и отсутствие повторяющихся длительных отказов.
Ошибка 502 на хостинге и в WordPress
На виртуальном хостинге владелец не всегда видит инфраструктуру. Зафиксируйте время, URL, частоту и действия перед сбоем, проверьте статус площадки и обратитесь в поддержку. Приложите идентификатор запроса и журналы, если панель их предоставляет. Не меняйте DNS или тариф наугад до подтверждения причины.
На WordPress 502 часто проявляется при сбое PHP-FPM, тяжелом плагине, исчерпании памяти, проблеме базы или конфликте после обновления. В безопасной среде проверьте журналы, ресурсы и последние изменения. Отключение плагинов выполняйте контролируемо и с резервной копией; на рабочем магазине необдуманный эксперимент может повредить данные.
Nginx и PHP-FPM: последовательность проверки
Проверьте состояние PHP-FPM, путь к Unix-сокету или порт, права доступа, число занятых воркеров и журнал медленных запросов. Конфигурация Nginx должна ссылаться на реально работающий upstream. После изменения выполните проверку синтаксиса до перезагрузки.
Если пул исчерпан, увеличение числа процессов может лишь перенести перегрузку на память или базу. Сначала измерьте длительность запросов, очередь и потребление ресурсов, затем устраняйте медленный код или узкую зависимость.
Пошаговый алгоритм и чек-лист устранения
Диагностика 502 за 15 минут
- Зафиксируйте точный URL, время, регион, метод запроса и request ID из заголовков, если он есть. Проверьте несколько страниц: это отделяет общий сбой от одного маршрута.
- Проверьте мониторинг и логи внешнего прокси или CDN. Определите, кто сформировал 502: CDN, балансировщик, Nginx или другой шлюз.
- На прокси найдите запись по времени, URL и request ID. Сообщения `connection refused`, `upstream prematurely closed connection`, ошибки DNS и TLS ведут к разным веткам.
- Обратитесь к upstream напрямую из той же сети: проверьте порт, DNS-имя, сертификат, ответ health-check и время обработки.
- Сопоставьте сбой с релизом, ростом нагрузки, исчерпанием процессов, памяти, соединений с БД и изменением конфигурации.
- После исправления повторите исходный запрос, проверьте разные экземпляры приложения и убедитесь, что доля 5xx вернулась к нормальному уровню.
Сообщение прокси и направление проверки
| Сигнал | Вероятная зона | Первая проверка |
|---|---|---|
| Connection refused | Процесс или порт upstream | Слушающий сокет, сервис, контейнер |
| Host not found | DNS или имя сервиса | Разрешение имени из среды прокси |
| Prematurely closed connection | Приложение завершило ответ | Логи исключений и рестарты |
| TLS handshake failed | Сертификат или протокол между узлами | Имя, цепочка, версии TLS |
Что проверять в Nginx и приложении
Начните с `nginx -t`: конфигурация должна пройти проверку до перезагрузки. Затем проверьте error log, адрес `proxy_pass` или `fastcgi_pass`, доступность порта и разрешение DNS из среды Nginx. Не увеличивайте таймаут, пока не установлено, что приложение работает корректно, но объективно не успевает.
В приложении проверьте запуск процесса, логи исключений, очередь запросов, пул БД, память и рестарты контейнеров. `connection refused` обычно означает, что на адресе никто не слушает; преждевременно закрытое соединение — что upstream принял запрос, но завершил его некорректно.
Чек-лист устранения 502
- Определен компонент, который вернул 502.
- Есть точное время и идентификатор проблемного запроса.
- Проверены DNS, маршрут, порт и TLS между прокси и upstream.
- Логи прокси сопоставлены с логами приложения.
- Проверены лимиты процессов, соединений, памяти и диска.
- Исправление протестировано на нескольких экземплярах.
- Настроен алерт по доле 5xx, а не только по полной недоступности.
- Для повторного инцидента подготовлен runbook и безопасный откат.
Диагностика распределенной инфраструктуры
Карта компонентов между браузером и приложением
Типовой маршрут выглядит так: браузер → CDN или WAF → load balancer → reverse proxy → upstream-приложение → база данных или внешний API. Код 502 формирует один из промежуточных узлов, когда получает недопустимый ответ дальше по цепочке. Сначала найдите этот узел, затем проверяйте следующий hop.
В контейнерной среде upstream может задаваться DNS-именем сервиса, IP или Unix socket. После деплоя проверьте, что endpoint зарегистрирован в service discovery, health-check проходит, порт слушается, а прокси не хранит устаревший адрес.
502 у CDN и балансировщика
Если 502 показывает Cloudflare или другой CDN, временный обход CDN допустим только как диагностический тест и при сохранении защиты origin. Проверьте доступность origin с разрешенных адресов, сертификат между CDN и сервером, DNS-запись, таймаут и firewall.
У балансировщика изучите состояние backend pool и результаты health-check. Один неисправный экземпляр создает плавающую ошибку: повторный запрос иногда успешен. Сопоставьте request ID и адрес backend, выведите экземпляр из ротации и только потом исследуйте его логи.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.