Ошибка 502 Bad Gateway: что значит, кто виноват и как исправить

Коротко. 502 Bad Gateway означает, что сервер, который работает как шлюз или прокси, не получил корректный ответ от вышестоящего сервера. Пользователь видит ошибку шлюза, а причина может быть в бэкенде, PHP-FPM, конфиге nginx, CDN, DNS или на хостинге.

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

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

Шлюзом может быть nginx, Apache, CDN, балансировщик или прокси хостинга. Поэтому «502 Bad Gateway» на странице ещё не значит, что сломан сайт. Сначала нужно понять, кто именно вернул ответ.

502, 500, 503 и 504: в чём разница

502 и 504 легко перепутать. 504 означает, что ответа не дождались. 502 означает, что ответ пришёл, но был некорректным, оборвался или бэкенд вообще отказал в соединении. В логах это видно по разным строкам.

curl -I https://example.com/
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/

Сайт отдаёт 502 на всех страницах. Перед сайтом стоит Cloudflare, на сервере nginx и PHP-FPM.
Помоги составить план: кто мог вернуть 502 и какие логи проверить первыми.
Не предлагай удалять конфиги и отключать всё сразу.

Кто вернул 502

Цепочка обычно выглядит так:

браузер → CDN или прокси → nginx → PHP-FPM / приложение → база

Ошибка может возникнуть на любом участке:

• CDN не достучался до origin;
• nginx не получил ответ от PHP-FPM;
• PHP-FPM упал или исчерпал пул процессов;
• приложение зависло или закрыло соединение;
• база не отвечает, и бэкенд падает;
• DNS или SSL на origin настроены неверно.

Если 502 на всех сайтах одного сервера, начинайте с хостинга и прокси. Если только на одном сайте, смотрите его nginx и бэкенд. Если только у вас, проверьте сеть, VPN и расширения браузера.

Как найти причину

1. Зафиксируйте масштаб

Проверьте:

• 502 на одной странице или на всём сайте;
• у всех пользователей или только у вас;
• постоянно или периодически;
• что было до ошибки: деплой, обновление, смена DNS, настройки CDN.

Сохраните URL, время и код ответа. Это понадобится хостингу и разработчику.

2. Определите, кто отдал ответ

Посмотрите заголовки:

curl -I https://example.com/

Обратите внимание на:

• server: cloudflare, server: nginx, server: Apache;
• cf-ray и другие заголовки CDN;
• страницу ошибки: у CDN и nginx она выглядит по-разному.

Если есть доступ к origin, можно проверить его в обход CDN:

curl --resolve example.com:443:ORIGIN_IP https://example.com/

Это диагностический приём. Не меняйте DNS и не отключайте CDN на живом сайте без плана.

3. Найдите логи

Типичные места:

• nginx: /var/log/nginx/error.log;
• Apache: /var/log/apache2/error.log или /var/log/httpd/error_log;
• PHP-FPM: /var/log/php-fpm/www-error.log или настройка error_log;
• панель хостинга: раздел с ошибками и логами;
• CDN: аналитика и логи origin.

Ищите строки:

• connect() failed (111: Connection refused);
• upstream prematurely closed connection;
• no live upstreams;
• recv() failed;
• upstream timed out;
• server reached pm.max_children setting;
• pool www seems busy.

Первая причинная ошибка важнее последней. Последняя часто лишь следствие.

tail -n 100 /var/log/nginx/error.log
grep -i "upstream\|502\|connect() failed" /var/log/nginx/error.log | tail -n 50

Вот фрагмент лога с ошибкой 502. Сгруппируй строки по причинам, выдели первую
причинную ошибку и предложи три проверки. Не придумывай строки, которых нет.
Я удалил IP, токены и пути к пользовательским файлам.

4. Проверьте бэкенд и PHP-FPM

• Работает ли процесс: systemctl status php-fpm или аналог.
• Не исчерпан ли пул: pm.max_children, pm.max_requests.
• Нет ли зависших процессов: ps aux | grep php-fpm.
• Хватает ли памяти: free -m.
• Не убила ли процессы система: dmesg | grep -i oom.
• Не переполнен ли диск: df -h.

Если пул процессов занят, nginx не может получить свободный бэкенд и отдаёт 502. Увеличение pm.max_children помогает только после проверки памяти и медленных запросов.

5. Проверьте таймауты и конфиг

В nginx смотрите:

• proxy_connect_timeout;
• proxy_read_timeout;
• fastcgi_read_timeout;
• proxy_next_upstream.

Слишком короткий таймаут обрывает медленный ответ. Слишком длинный маскирует проблему и копит соединения. Сначала найдите медленный запрос, потом меняйте лимит.

Проверьте конфиг перед перезагрузкой:

nginx -t

И только потом перезагружайте. Не правьте конфиг на живом сервере без бэкапа.

6. Проверьте DNS, CDN и SSL

• DNS указывает на актуальный origin.
• SSL-сертификат на origin действителен.
• CDN не блокирует запросы к origin.
• WAF и Anti-DDoS не режут легитимный трафик.
• Origin не требует заголовок, который CDN не передаёт.

Если 502 появился после смены DNS или включения CDN, начните с этой цепочки.

7. Проверьте последние изменения

502 часто появляется после деплоя, обновления PHP, смены пула PHP-FPM, правки nginx или включения CDN. Откатывайте по одному изменению и после каждого шага проверяйте статус.

Вот изменения за последние 24 часа: деплой, обновление PHP, правка nginx, включение CDN.
502 начался после одного из них. Предложи порядок проверки и отката.
Не предлагай переустанавливать сервер и удалять базу.

Как исправить по причинам

Не меняйте несколько вещей сразу. Иначе после исправления невозможно понять, что помогло.

Что отправить хостингу

• Приложите URL и время с часовым поясом.
• Укажите код ответа и заголовки curl -I.
• Добавьте фрагмент лога nginx или PHP-FPM без паролей и токенов.
• Опишите, что уже проверили.
• Перечислите изменения за последние сутки.
• Уточните, есть ли CDN, WAF или балансировщик.
• Напишите, воспроизводится ли ошибка на всех устройствах.

Частые ошибки

• Искать 502 только в браузере и чистить кэш бесконечно.
• Путать 502 с 504.
• Поднимать таймауты, не найдя медленный запрос.
• Увеличивать pm.max_children без проверки памяти.
• Отключать все плагины на живом сайте без бэкапа.
• Менять DNS или CDN, не проверив origin.
• Возвращать 200 вместо 502.
• Верить ответу нейросети без проверки.

Когда нужен хостинг

Обратитесь в поддержку, если:

• 502 на всех сайтах сервера;
• ошибка приходит от CDN или балансировщика;
• нет доступа к логам;
• бэкенд не запускается;
• закончились память или диск;
• есть подозрение на DDoS;
• проблема на стороне сети или обслуживания.

Вопросы

502 — ошибка сайта или сервера?

Формально это ошибка шлюза. Шлюз не получил нормальный ответ от бэкенда. Причина может быть в приложении, PHP-FPM, nginx, CDN, DNS или хостинге.

Влияет ли 502 на SEO?

Кратковременная ошибка обычно не влияет: поиск повторяет запрос. Если 502 держится долго, обход замедляется, а страницы могут перестать обновляться в индексе. Ошибку нужно исправлять, а не маскировать кодом 200.

Чем 502 отличается от 504?

502 означает, что ответ от бэкенда был некорректным или соединение не состоялось. 504 означает, что шлюз не дождался ответа за отведённое время.

Почему 502 появляется только на одной странице?

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

Может ли нейросеть исправить 502?

Нет. Она помогает разобрать логи, сгруппировать ошибки и составить план проверки. Причину подтверждают инструментами и тестами.

Что делать, если нет доступа к логам?

Запросите фрагмент у хостинга. Укажите URL, время, код ответа, заголовки и что уже проверили. Без логов диагностика превращается в угадывание.

Источники