Ошибка 502 Bad Gateway: что сломалось и как это чинить

502 означает, что веб-сервер обратился к обработчику PHP и не получил внятного ответа. На тарифах за 300-600 рублей это почти всегда упор в лимит памяти: процесс WordPress с двумя десятками плагинов весит 80-140 МБ, и десяток одновременных посетителей выбирает весь лимит аккаунта.

Вместо главной страницы сайт отдаёт белый экран с короткой надписью 502 Bad Gateway. Реклама продолжает крутиться и лить трафик в пустоту, в админку не зайти, поддержка хостинга отвечает, что у них всё в порядке. Ошибка 502 bad gateway пугает сильнее, чем заслуживает: почти всегда это не взлом и не потеря данных, а оборванный разговор двух программ на вашем же сервере. Ниже разберу, что именно рвётся, как за десять минут найти виновника по логам, что можно сделать самому без риска добить сайт и какие цифры приложить к заявке хостеру, чтобы вам ответили по делу, а не прислали ссылку на базу знаний.

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

Что происходит на сервере в момент 502

На типовом хостинге ваш сайт обслуживают минимум две программы. Первая принимает запрос из интернета: nginx, LiteSpeed или Apache. Сама она PHP не выполняет, она умеет отдавать картинки, css и раздавать статику. Всё, что связано с CMS, она передаёт второй программе: php-fpm, lsphp, mod_php. Та выполняет код WordPress или Битрикса, ходит в базу и возвращает готовый HTML.

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

Отсюда простой вывод, который экономит кучу времени. Раз вы видите страницу с текстом 502, значит веб-сервер жив и отвечает. Домен делегирован, DNS в порядке, сертификат на месте, хостинг вас не заблокировал. Всё это можно вычеркнуть из списка подозреваемых сразу. Проблема внутри, между nginx и PHP.

Проверить это можно за десять секунд. Откройте прямую ссылку на любой статический файл темы, например https://example.ru/wp-content/themes/ваша-тема/style.css. Если css открывается, а страницы отдают 502, диагноз подтверждён: обработчик PHP лежит, а раздача статики работает.

502, 503 и 504: разница, которая экономит час

Эти три кода регулярно путают, и из-за путаницы люди чинят не то. Самый частый пример: человек ловит 502, читает совет «увеличьте таймаут» и полдня крутит max_execution_time. Таймауты к 502 отношения не имеют.

Код	Что произошло	Состояние PHP	Куда смотреть первым
502 Bad Gateway	обработчик оборвал соединение или вернул мусор	процесс умер или не запущен	error.log nginx, лог php-fpm, OOM в системном логе
503 Service Unavailable	обработчик есть, но обслуживать отказывается	занят, выключен или заблокирован	лимиты пула, режим обслуживания, фаервол хостинга
504 Gateway Timeout	обработчик жив, но не уложился в отведённое время	работает, просто долго	лог медленных запросов, внешние API, тяжёлый импорт

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

Отдельная тонкость: некоторые панели показывают 502 и в ситуации, когда php-fpm вообще не запущен после перезагрузки сервера. Симптом идентичный, причина банальная.

Первые пять минут: что проверить до логов

Пока вы не залезли в консоль, соберите факты. Они пригодятся и вам, и хостеру.

Первое: 502 везде или на отдельных страницах. Главная, любая внутренняя, /wp-admin/, /bitrix/admin/. Если падает только админка или только одна форма, виноват конкретный кусок кода, а не сервер целиком.

Второе: ошибка постоянная или плавающая. Это ключевой признак. Постоянная 502 обычно означает, что пул PHP не поднялся. Плавающая, когда через раз открывается, почти всегда упирается в лимиты: память или число одновременных процессов.

Проверяется циклом из консоли или с любой машины, где есть curl:

for i in $(seq 1 20); do
  curl -o /dev/null -s -w "%{http_code} %{time_total}n" https://example.ru/
  sleep 3
done

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

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

Четвёртое: страница статуса хостинга и его телеграм-канал. Если провайдер как раз переносит ноду или чинит дисковый массив, диагностика не нужна, нужно ждать и предупредить клиента.

Логи: где смотреть и что искать

На шаред-хостинге логи обычно лежат в домашней папке: ~/logs/example.ru.error.log и ~/logs/example.ru.access.log. На VPS с nginx это /var/log/nginx/error.log, лог php-fpm живёт в /var/log/php8.2-fpm.log или рядом. Точный путь у каждого провайдера свой, ищите раздел «Логи» в панели.

tail -n 100 ~/logs/example.ru.error.log
grep -i "upstream" ~/logs/example.ru.error.log | tail -n 30
tail -n 200 /var/log/php8.2-fpm.log
dmesg -T | grep -i "killed process"

Дальше читаем не глазами по диагонали, а по конкретным строкам. Вот что означают самые частые:

• connect() to unix:/var/run/php-fpm.sock failed (111: Connection refused) — пул PHP не запущен вообще. Лечится перезапуском, дальше выясняем, почему он упал.
• recv() failed (104: Connection reset by peer) while reading response header from upstream — процесс умер посреди выполнения. Кандидаты: нехватка памяти, segfault в расширении PHP.
• upstream sent too big header while reading response header from upstream — ответ не влез в буфер заголовков. Никакой памяти не хватает, потому что дело в размере cookie или редиректе с огромным набором заголовков.
• server reached pm.max_children setting, consider raising it в логе php-fpm — упёрлись в число одновременных процессов. Это ваша плавающая 502.
• Out of memory: Killed process 12345 (php-fpm) в dmesg — системный OOM-killer застрелил обработчик, потому что кончилась оперативка на аккаунте.

Отдельно посмотрите, кто вообще к вам ходил в момент аварии:

awk '{print $1}' ~/logs/example.ru.access.log | sort | uniq -c | sort -rn | head -20

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

Шесть причин, которые дают 502 у малого бизнеса

Кончилась память

Самая частая история на тарифах за 300-600 рублей в месяц. У аккаунта лимит, скажем, 1 ГБ, каждый процесс WordPress с двадцатью плагинами весит 80-140 МБ, при десяти одновременных посетителях сумма выходит за потолок. Ядро выбирает самый жирный процесс и убивает его. Пользователь получает 502.

Признак: Killed process в системном логе, ошибка приходит волнами в часы трафика, ночью сайт идеален. Лечится в двух направлениях: убрать лишний вес (тяжёлые плагины, конструкторы страниц, разросшаяся автозагрузка в базе) или переехать на тариф с нормальной памятью. Подробный разбор лимитов есть в статье про ограничения shared-хостинга по процессору и памяти.

Упёрлись в число процессов PHP

Второе место. У пула php-fpm есть параметр pm.max_children: сколько запросов он готов обрабатывать одновременно. Когда все воркеры заняты, новые запросы встают в очередь, очередь переполняется, nginx получает отказ и отдаёт 502.

pm = dynamic
pm.max_children = 10
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 5
pm.max_requests = 500

Считается так: доступная память делится на средний вес процесса. Полтора гигабайта при весе 120 МБ дают потолок в 12 воркеров, ставить 40 бессмысленно, ядро всё равно начнёт убивать. Параметр pm.max_requests тоже полезен: он перезапускает воркер каждые 500 запросов и лечит медленные утечки памяти в кривых плагинах.

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

Плагин или правка в теме положили обработчик

Классика после обновлений. Бесконечная рекурсия, обращение к несуществующей функции в старой версии PHP, конфликт двух плагинов кэширования. Иногда вместо белого экрана PHP просто падает с segfault, и вы получаете 502.

Проверяется отключением. Если админка недоступна, папку плагина переименовывают прямо в файловой системе:

mv wp-content/plugins/podozritelnyy-plugin wp-content/plugins/podozritelnyy-plugin.off

Если плагинов много и виновник неизвестен, отключаем все разом через WP-CLI и включаем обратно по одному:

wp plugin deactivate --all --skip-plugins --skip-themes
wp plugin activate akismet

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

Боты, парсеры и мелкая атака

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

Признак: в access.log за час больше запросов, чем у вас посетителей за неделю, и все с двух-трёх адресов или с одинаковым user-agent. Что с этим делать без дорогих сервисов, описано в статье про защиту маленького сайта от ботов и наплыва запросов.

Слишком большие заголовки ответа

Редкая, но крайне обидная причина: сайт работает у всех, кроме конкретного человека, и только на конкретной странице. Обычно виноват разросшийся набор cookie или плагин, который лепит гигантский заголовок редиректа. Буфер nginx по умолчанию небольшой, ответ в него не влезает, соединение рвётся.

Лечится на стороне сервера:

fastcgi_buffers 16 32k;
fastcgi_buffer_size 64k;
fastcgi_busy_buffers_size 64k;

На шареде это делает поддержка по запросу, если предъявить строку too big header из лога.

Хостинг чинит себя сам

Бывает и такое: у провайдера миграция, перезагрузка ноды, обновление PHP по расписанию. Ваша диагностика тут ничего не найдёт, потому что ломается не у вас. Поэтому статус-страница провайдера идёт вторым пунктом после сбора фактов, а не последним, когда вы уже перебрали все плагины.

Что делать прямо сейчас

Порядок действий на аварии отличается от порядка действий на расследовании. Сначала поднимаем сайт, потом ищем причину.

1. Сохраните последние двести строк error.log и access.log в отдельный файл. Логи ротируются, а через час доказательств уже не будет.
2. Перезапустите обработчик PHP. В панели большинства хостингов это кнопка вроде «Перезапустить PHP» или смена версии PHP туда и обратно. На VPS: systemctl restart php8.2-fpm. В половине случаев сайт поднимается сразу.
3. Откатите последнее изменение. Обновляли плагины полчаса назад, значит откатываем плагины, а не крутим настройки сервера.
4. Не обновляйте ничего «заодно». Аварийный режим не время для профилактики: вы потеряете возможность понять, что помогло.
5. Если сайт поднять быстро не выходит, поставьте заглушку с кодом 503 вместо 502. Поисковикам 503 понятен как временная недоступность, а череда 502 на все страницы может стоить позиций.

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203.0.113.10$
RewriteCond %{REQUEST_URI} !^/maintenance.html$
RewriteRule ^(.*)$ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "3600"

Свой IP в первой строке замените на реальный, иначе сами не попадёте на сайт для проверки.

Как писать в поддержку хостинга

Заявка «у меня сайт не работает, ошибка 502, помогите» уходит в общую очередь и возвращается через два часа с просьбой уточнить домен. Заявка с фактурой попадает сразу к инженеру.

Что положить в первое же сообщение:

• домен и точное время начала аварии с часовым поясом;
• постоянная ошибка или плавающая, с результатом проверки в двадцать запросов;
• три-пять строк из error.log с меткой upstream или connect() failed;
• что менялось на сайте за сутки (или честное «ничего не трогали»);
• прямой вопрос: упирается ли аккаунт в лимиты памяти и числа процессов PHP за последние сутки, и есть ли записи OOM.

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

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

Профилактика: чтобы не узнавать об аварии от клиента

Чек-лист, который я прогоняю на новых проектах в первую неделю:

• Мониторинг доступности с проверкой раз в 1-5 минут и уведомлением в мессенджер, а не на почту. Бесплатных вариантов хватает, подробности в статье про мониторинг доступности сайта.
• Мониторинг по коду ответа, а не по факту «страница открылась». Заглушка хостера отдаёт 200 и мониторинг молчит, хотя сайта нет.
• Запас по памяти минимум вдвое от пикового потребления. Если тариф впритык, 502 станет вопросом времени и удачного дня по трафику.
• Тестовая копия для обновлений. Плагины сначала накатываются туда, потом на боевой.
• Ротация и хранение логов минимум 14 дней. Разбирать аварию по пустому логу невозможно.
• Ограничение доступа к wp-login.php и xmlrpc.php, чтобы переборщики не съедали пул процессов.
• Записанный план отката: кто перезапускает PHP, где лежит последний бэкап, за сколько минут он разворачивается.

Никакой экзотики в списке нет, но именно эти пункты превращают часовую панику в пятиминутную задачу.

Если разбираться некогда

502 обычно чинится за 20-40 минут, когда у человека есть доступ к логам и понимание, где смотреть. Проблема в том, что на аварии этих двадцати минут никогда нет: сайт лежит, реклама крутится, клиенты звонят.

Если хочется, чтобы кто-то держал это под контролем постоянно, у меня есть помесячная и годовая абонентка: мониторинг, обновления на тестовой копии, разбор аварий и логов, ежемесячный отчёт по работам. Помесячно от 15 000 рублей, годовой пакет 35 000 рублей. Разработка с нуля и дизайн в обслуживание не входят, я занимаюсь именно сопровождением существующих сайтов на WordPress, Битриксе, MODX, OpenCart и Tilda, удалённо по всей России.

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

Частые вопросы

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

Веб-сервер принял запрос, передал его обработчику PHP и не дождался корректного ответа. Причина почти всегда на стороне PHP или лимитов хостинга, а не в сети и не во взломе.

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

502 это обработчик ответил мусором или умер. 503 это сервис временно недоступен, обычно упор в число процессов. 504 это никто не ответил за отведённое время. Разные причины и разное лечение.

Что проверить в первые пять минут

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

Что писать в поддержку хостинга

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