HTTP 502 Bad Gateway на сайтах с Cloudflare

#Кто виноват: Cloudflare или ваш сервер

Cloudflare работает как посредник: посетитель подключается к нему, а он — к вашему серверу (источнику). Страница ошибки показывает, где проблема: если её оформила Cloudflare и есть внизу пометки «Browser — Working / Cloudflare — Working / Host — Error», то отказал именно источник. В 99% случаев причина не в Cloudflare, а в сервере. Обратите внимание на код: 502 — неверный ответ источника; 504 — таймаут; 520 — пустой или неожиданный ответ; 521 — источник отказал в соединении; 522 — таймаут соединения; 523 — источник недоступен; 524 — таймаут ответа; 525/526 — ошибки TLS между Cloudflare и сервером.

#Проверяем сервер без Cloudflare

Если прямой запрос тоже даёт 502, проблема на сервере. Если сервер отвечает 200, а через Cloudflare ошибка, проверьте файрвол и SSL-режим.

#Что проверить на сервере

1. Работают ли службыДля администратора собственного сервера: зайдите по SSH и проверьте состояние нужных служб: systemctl status nginx и, если используется, systemctl status php8.2-fpm (версию PHP замените на реально установленную); не перезапускайте их без выяснения причин. Локально выполните curl -I http://127.0.0.1/ и сравните код ответа с запросом через Cloudflare, учитывая заголовок Host и HTTPS. Если приложение не отвечает локально — ищите проблему на origin, а не у посетителя.
2. Журналы nginx и приложенияАдминистратору: найдите в журнале доступа и ошибок веб-сервера запись, соответствующую точному времени и URL сбоя. На системах с systemd можно начать с sudo journalctl -u nginx --since "15 minutes ago" (если nginx работает как служба); для файловых логов используйте путь, указанный в конфигурации access_log/error_log. Ищите сообщения подключения к upstream, тайм-ауты и отказ приложения; не меняйте лимиты без подтверждённой причины. Посетителю достаточно записать код и время и обратиться к владельцу.
3. РесурсыАдминистратору: во время возникновения 502 откройте SSH-терминал и выполните free -h, df -h, uptime, затем изучите журнал PHP-FPM/приложения. Если в журнале есть server reached pm.max_children, проверьте число одновременных PHP-процессов и использование памяти перед изменением лимита. Не увеличивайте pm.max_children произвольно: при недостатке RAM сервер может начать завершать процессы. Повторите исходный запрос и сравните состояние ресурсов.
4. ТаймаутыАдминистратору: в журналах nginx, прокси и приложения сопоставьте время начала запроса с моментом обрыва. Если подтверждён тайм-аут, сначала найдите медленный запрос/блокировку в приложении и базе данных; увеличение proxy_read_timeout/fastcgi_read_timeout без устранения причины лишь отложит сбой. Перед правкой сохраните конфигурацию, выполните nginx -t и применяйте её только после успешной проверки. Посетителю эти действия не нужны.
5. Команды для отдельных ситуацийВыберите только подходящий вариант. Это не одна последовательность: часть команд диагностирует проблему, а часть меняет настройки или данные.
   Выберите подходящий вариант — это не команды для последовательного выполнения

   Вариант 1Состояние стека

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Состояние стека

   sudo systemctl status nginx php8.3-fpm --no-pager

   sudo tail -n 50 /var/log/nginx/error.log

   free -m; df -h; uptime

   Вариант 2Слушает ли сервер порты 80 и 443

   Linux · Терминал (Bash)КомандаНужен sudoКопировать всёВыделить

   Слушает ли сервер порты 80 и 443

   sudo ss -ltnp | grep -E ":80|:443"

   Вариант 3Увеличение таймаутов для медленного бэкенда (используйте только когда это действительно нужно)

   nginx.confКопировать всёВыделить

   Увеличение таймаутов для медленного бэкенда (используйте только когда это действительно нужно)

   fastcgi_read_timeout 120s;
   proxy_read_timeout   120s;

#Файрвол и SSL

Чтобы исключить Cloudflare как причину, временно переключите запись DNS в режим «Только DNS» (серое облако) и проверьте сайт напрямую. Если ошибка исчезает, смотрите настройки SSL, файрвол и правила страницы в Cloudflare; если остаётся — проблема на сервере.