502 Bad Gateway означает, что сервер-посредник — например, Nginx, CDN или балансировщик — не получил корректный ответ от вышестоящего сервиса. Посетитель может обновить страницу и проверить другой канал связи, но владелец сайта должен диагностировать цепочку запроса: прокси → приложение → база или другой upstream.
Что обновлено 24.08.2026: добавлена таблица технической приёмки и условия отката.
Таблица технической приёмки: Ошибка 502
Проверка ошибка 502 Bad Gateway выполняется на нескольких состояниях шаблона, а не на одном удачном URL. Сначала сохраняют исходный код и HTTP-заголовки, затем сравнивают их с отрисованным DOM и ожидаемым поведением.
| Сценарий | Что проверить | Нормальный результат | Исправление |
|---|---|---|---|
| Один URL отдаёт 502 | Повторить запрос из разных точек | Ошибка воспроизводится и имеет время | Сохранить request ID и перейти к логам |
| Прокси не получает ответ | Логи reverse proxy и upstream | Причина локализована | Проверить порт, DNS, сокет и доступ |
| Upstream отвечает слишком долго | Тайминги и профилирование | Найдена медленная операция | Исправить запрос или обоснованно настроить таймаут |
| Ошибка после релиза | Сравнить конфигурацию и версию | Есть связь с конкретным изменением | Откатить релиз и проверить восстановление |
| Сервис восстановлен | Коды, логи и мониторинг | 502 не повторяется на критических маршрутах | Оставить наблюдение и разобрать первопричину |
До и после релиза
До выпуска владелец шаблона проверяет тестовую выборку и фиксирует условие блокировки. После выпуска SEO-специалист повторяет запросы к production, а разработчик просматривает логи и массовые отклонения. Откат нужен, если полезные страницы получают ошибочную директиву, теряют основной контент или массово меняют код ответа. Закрывать задачу можно только после повторной проверки тем же способом.
Что делать пользователю
Обновите страницу один раз через минуту: сбой мог быть кратковременным.
Проверьте, открывается ли сайт с другого устройства или мобильного интернета.
Откройте страницу в приватном режиме, чтобы исключить локальный кеш и расширения.
Если не работает только один сайт, не меняйте системные настройки: проблема, вероятнее всего, на его стороне.
При повторении сообщите поддержке URL, время, регион, устройство и снимок экрана.
Как владельцу локализовать 502 за 15 минут
1. Подтвердите масштаб
Проверьте главную, статический файл, динамическую страницу и служебный endpoint с нескольких точек. Зафиксируйте начало сбоя, долю ответов 502 и изменения перед инцидентом: релиз, обновление CMS, конфигурация, сертификат, DNS или рост нагрузки. Если ошибка только у части пользователей, проверьте CDN, конкретный узел и регион.
2. Найдите узел, который вернул статус
Посмотрите заголовки через curl -I и журналы доступа. Ответ мог сформировать CDN, балансировщик, reverse proxy или веб-сервер. Затем сопоставьте timestamp и request ID в логах прокси и приложения. Диагностика без единого времени и идентификатора запроса быстро превращается в перебор причин.
3. Проверьте upstream
Процесс приложения или PHP-FPM запущен и слушает ожидаемый сокет/порт.
В конфигурации proxy_pass или upstream указан правильный хост и порт.
Нет ошибок соединения, permission denied, connection refused или premature close.
Память, CPU, место на диске и число процессов не исчерпаны.
База данных, кеш, очередь и внешние API отвечают без критических задержек.
TLS между прокси и upstream согласован, сертификат и имя хоста корректны.
Firewall, security group и DNS не блокируют связь между узлами.
4. Сопоставьте ошибку с последним изменением
Если 502 появился сразу после релиза, сначала остановите расширение инцидента: откатите изменение или переключите трафик на стабильную версию. Не повышайте тайм-ауты вслепую. Большой тайм-аут может лишь дольше удерживать соединения и скрыть медленный запрос, нехватку воркеров или блокировку базы.
| Симптом в логах | Вероятная зона | Следующая проверка |
|---|---|---|
| Connection refused | Процесс/порт upstream | Статус сервиса, сокет, порт и права |
| Upstream timed out | Медленное приложение или зависимость | Трейс запроса, БД, внешние API, воркеры |
| No live upstreams | Пул backend-узлов | Health check и доступность всех узлов |
| SSL handshake failed | TLS между сервисами | SNI, цепочка сертификата и протоколы |
| 502 только через CDN | Связь CDN с origin | Origin firewall, DNS, сертификат, правила кеша |
Что проверить после восстановления
Повторите запросы к критичным URL и API из внешней и внутренней сети.
Убедитесь, что доля 5xx вернулась к нормальному уровню, а задержка не выросла.
Проверьте поисковых роботов по логам: они снова получают 200.
Настройте алерт не только на доступность, но и на долю 5xx, latency и ресурсы upstream.
Оформите короткий разбор: причина, временное решение, постоянное исправление и владелец задачи.
Как 502 влияет на SEO
Краткий единичный сбой обычно не требует специальных SEO-действий. Массовые или продолжительные 5xx заставляют поисковых роботов снижать интенсивность обхода; долго недоступные URL со временем могут выпасть из индекса. После восстановления важнее стабильный код 200, внутренние ссылки и нормальная скорость ответа, а не массовая ручная отправка всех страниц.
Ошибки диагностики
Считать очистку кеша браузера исправлением серверной причины.
Перезапускать все сервисы до сохранения логов и метрик.
Увеличивать memory_limit и тайм-ауты без измерения узкого места.
Проверять только главную страницу, когда сбоит один шаблон или API.
Не различать 502, 504 и ошибку самого приложения.
Не связывать инцидент с релизом и не добавлять контроль повторения.
Частые вопросы
502 — это проблема Nginx?
Nginx часто показывает этот код, потому что работает прокси, но первопричина может быть в приложении, PHP-FPM, базе, сети, DNS, TLS или внешнем сервисе. Имя сервера на экране указывает точку ответа, а не обязательно виновника.
Нужно ли ставить 503 вместо 502?
Код должен описывать фактическую ситуацию. 502 возникает при некорректном ответе upstream, 503 — когда сервис сознательно недоступен или перегружен. Не подменяйте статус ради SEO; исправьте архитектурную причину и корректно настройте обслуживание.
Приёмка обновлённой версии
проверены исходный HTML, HTTP-заголовки и итоговый DOM;
контрольная выборка включает нормальные и ошибочные состояния;
критическая ошибка блокирует масштабирование;
условие отката и владелец известны до релиза;
задача закрыта после повторной проверки production.
Итог
Причина локализована между прокси и upstream, сервис восстановлен и наблюдается после исправления. Масштабировать решение можно только после проверки на реальных URL и фактических данных проекта; если критерии не выполняются, сначала исправляют причину, а не увеличивают объём страниц, публикаций или автоматизации.
Получите бесплатный аудит и стратегию роста
Изучим сайт, покажем точки роста и подготовим прогноз до квалифицированных лидов и оборота из SEO/GEO.