Сайт отдаёт ошибку 502 Bad Gateway: разбор причин

Ошибка 502 Bad Gateway означает, что веб-сервер принял запрос посетителя, передал его дальше — приложению сайта — и не дождался внятного ответа. Сеть работает, домен переводится в IP-адрес, сам веб-сервер жив и отвечает. Молчит бэкенд — программа, которая собирает страницы: PHP-FPM, Node.js или Apache за спиной nginx. Чаще всего виноват упавший или перегруженный процесс на сервере с nginx, и лечится это за 10–15 минут, если знать, куда смотреть.

Материал для владельца сайта и начинающего администратора. Разберём, чем 502 отличается от 500, 503 и 504, как за три минуты понять, лежит сайт у всех или только у вас, какие строки в логах указывают на причину и что делать с каждой из пяти типовых поломок. Отдельно — граница ответственности: когда чинит хостинг, а когда правите вы.

Что означает код 502 и кто его отдаёт

Современный сайт почти никогда не обслуживается одной программой. Снаружи стоит nginx — он принимает соединения, отдаёт картинки и статику, шифрует трафик. Всё «умное» — генерацию страниц, работу с базой — он передаёт вглубь, приложению. Такая связка называется обратным прокси, а приложение за ним — апстримом (от английского upstream). Так дальше и будем называть программу за спиной nginx.

Код 502 отдаёт именно фронтальный сервер: «я спросил у апстрима и получил обрыв, отказ или мусор вместо HTTP-ответа». Ошибку формирует nginx, а не PHP, поэтому в логах приложения может не быть ничего — там не успело выполниться ни строчки.

Апстримом бывает что угодно: пул PHP-FPM для WordPress, процесс Node.js, отдельный Apache на порту 8080, контейнер Docker. Схема поломки от этого не меняется.

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

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

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

Ошибка 503 — «сервис временно недоступен»: её отдают намеренно во время обновления или когда nginx считает нерабочими все бэкенды сразу. Ошибка 504 означает, что апстрим отвечал слишком долго и прокси разорвал ожидание сам. Разница с 502 тонкая: там соединение оборвал бэкенд, здесь — терпение фронтенда закончилось раньше.

Полный разбор трёх- и пятисотых кодов с примерами есть в отдельном материале про коды ошибок HTTP — держите его под рукой, если ошибка окажется не 502.

Первые три минуты: сайт лежит у всех или только у вас

Прежде чем лезть в конфиги, отсеките ложную тревогу. Бывает, что 502 показывает промежуточный сервис — корпоративный шлюз офиса или кеш CDN (сеть серверов, раздающая копии сайта), — а сам сервер полностью здоров. Проверка занимает пару минут.

Сначала запросите сайт с мобильного интернета, а не с офисного Wi-Fi. Затем зайдите на сервер по SSH (защищённое подключение к консоли машины) и запросите сайт оттуда. Если с самого сервера страница отдаётся нормально, поломка лежит вне вашей машины — в кеше, шлюзе или у промежуточного провайдера. Команда ниже спрашивает сайт у самого сервера, минуя весь внешний путь.

curl -I -H "Host: example.ru" http://127.0.0.1/
# -I запрашивает только заголовки, без тела страницы
# -H подставляет домен, чтобы nginx выбрал нужный сайт
# в первой строке ищем «HTTP/1.1 200 OK» или «502 Bad Gateway»

Если локальный запрос вернул 200, а из браузера приходит 502 — виновата прослойка перед сервером: CDN, внешний прокси, балансировщик. Если 502 приходит и локально, поломка внутри, и дальше по списку идут логи.

Лог ошибок nginx — главный источник правды

Гадать о причинах бессмысленно, пока вы не прочитали одну конкретную строку. Nginx пишет каждую неудачную попытку достучаться до апстрима в файл /var/log/nginx/error.log. В панелях управления лог часто лежит отдельно для каждого сайта, в каталоге вида /var/www/example/logs/.

sudo tail -n 50 /var/log/nginx/error.log
# показывает последние 50 строк файла

sudo tail -f /var/log/nginx/error.log
# -f оставляет лог открытым: обновите сайт в браузере
# и смотрите, какая строка появится

Второй способ надёжнее: вы сами провоцируете ошибку и видите её отпечаток в реальном времени. Скопируйте появившуюся строку и сверьтесь с таблицей.

Проверяем бэкенд: жив ли процесс и слушает ли он порт

Дальше проверяем сам апстрим — по слоям, от простого к сложному. Команды приведены для PHP-FPM 8.2 на Ubuntu; для другой версии подставьте свой номер, для Node.js — имя сервиса.

Выполняйте их по одной и читайте вывод целиком. Слово active (running) означает, что сервис работает; failed — что он падал и не поднялся; inactive (dead) — что его никто не запускал.

1. Статус сервиса: sudo systemctl status php8.2-fpm — работает ли процесс и когда он перезапускался.
2. Порты: sudo ss -lntp | grep 9000 — пустой вывод означает, что порт 9000 никто не слушает.
3. Сокет вместо порта: ls -l /run/php/php8.2-fpm.sock — файл должен существовать, а владелец совпадать с пользователем nginx. Сокет — служебный файл для обмена данными между программами на одной машине.
4. Журнал сервиса: sudo journalctl -u php8.2-fpm -n 30 — последние 30 записей с причиной падения.
5. Синтаксис конфига: sudo nginx -t — покажет файл и номер строки с опечаткой.
6. Перезапуск: sudo systemctl restart php8.2-fpm && sudo systemctl reload nginx — сначала бэкенд, потом фронтенд.

Перезапуск почти всегда возвращает сайт к жизни. Но если через 20 минут 502 приходит снова — проблема системная, и следующие разделы объясняют, какая именно.

Причина 1: PHP-FPM убил OOM killer при нехватке памяти

Самый частый сценарий на серверах с 1–2 ГБ памяти. Когда свободная оперативная память заканчивается, ядро Linux запускает OOM killer: он выбирает самый прожорливый процесс и убивает его без предупреждения. Обычно это пул PHP-FPM или MySQL.

Сайт после этого отдаёт 502, пока сервис не поднимут вручную. В логе nginx остаётся строка про prematurely closed connection: соединение оборвалось на полуслове, потому что собеседника больше нет.

free -m
# память в мегабайтах; смотрим колонку available:
# постоянно меньше 100 МБ — красная зона

sudo dmesg -T | grep -i "killed process"
# ищем в журнале ядра следы OOM killer;
# -T переводит метки времени в читаемый вид

Лечится тремя способами. Быстрый — добавить файл подкачки: swap на 2 ГБ спасает от внезапных всплесков, хотя и замедляет работу при постоянном использовании. Средний — урезать аппетиты MySQL и число воркеров PHP. Честный — добавить памяти: переход с 1 ГБ на 2 ГБ стоит ориентировочно 150–300 ₽ в месяц. Кто именно съедает память, покажет команда top -o %MEM: она выводит процессы, отсортированные по расходу оперативной памяти.

Причина 2: закончились воркеры pm.max_children

PHP-FPM обрабатывает запросы пулом дочерних процессов — их называют воркерами. Один воркер занят одним запросом. Их предельное число задаёт параметр pm.max_children в файле /etc/php/8.2/fpm/pool.d/www.conf. Когда все воркеры заняты, новые запросы встают в очередь, а при переполнении очереди nginx получает отказ и рисует 502.

Опознать этот случай легко: в собственном логе PHP-FPM (/var/log/php8.2-fpm.log) появляется прямое предупреждение «server reached pm.max_children setting». Ошибка приходит волнами — в часы трафика сайт лежит, ночью работает идеально.

Считается лимит просто: из всей памяти сервера вычитаем запас на систему и базу данных, а остаток делим на средний вес одного процесса. Запас растёт вместе с сервером: около 400 МБ при 1 ГБ памяти и примерно 1,4 ГБ при 8 ГБ. Средний вес процесса для WordPress — 40–60 МБ, для 1С-Битрикс — 80–120 МБ.

Ставить значение «с запасом» вредно: 100 воркеров на сервере с 1 ГБ не ускорят сайт, а приведут к сценарию из предыдущего раздела. После правки выполните sudo systemctl reload php8.2-fpm — конфигурация применится без разрыва текущих соединений.

Причина 3: nginx стучится не в тот порт или сокет

Эта поломка появляется после ручной правки конфигов, обновления PHP или переноса сайта. Nginx и PHP-FPM должны договориться об одном адресе связи. Вариантов ровно два: TCP-порт (обычно 9000) или файл-сокет в каталоге /run/php/. Если в одном конфиге записан порт, а в другом сокет, связи не будет.

Сверяются две строки. В конфиге сайта, в секции обработки PHP, стоит директива fastcgi_pass. В конфиге пула FPM — директива listen. Их значения обязаны совпадать символ в символ.

grep -r "fastcgi_pass" /etc/nginx/
# что nginx считает адресом бэкенда

grep -E "^listen" /etc/php/8.2/fpm/pool.d/www.conf
# что PHP-FPM реально открывает на приём

Типичная ловушка: система поставила PHP 8.3, сокет теперь называется php8.3-fpm.sock, а в конфиге сайта осталась прежняя версия. Отсюда и «Connection refused» — файла по старому пути нет. Вторая ловушка — права: nginx работает от пользователя www-data, а сокет создан от другого пользователя, и в логе появляется «13: Permission denied». Разбор базовой конфигурации собран в гайде по настройке nginx.

Причина 4: долгий скрипт и таймауты

У nginx есть предел ожидания ответа от апстрима. По умолчанию proxy_read_timeout и fastcgi_read_timeout равны 60 секундам. Импорт каталога, генерация выгрузки, отправка тысячи писем — любая операция длиннее минуты обрывается на полуслове.

Тонкость в том, что пользователь при этом чаще видит 502, а не 504. Причина: у самого PHP есть свой лимит max_execution_time, по умолчанию 30 секунд. Если он срабатывает первым, процесс просто закрывает соединение. Для nginx это выглядит как обрыв со стороны апстрима — то есть ровно 502.

location ~ .php$ {
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_read_timeout 300;
    # ждём ответа до 300 секунд вместо 60
}

Поднимать таймаут до 300 секунд разумно только для админки и страниц выгрузки: с большим лимитом медленные запросы копятся и съедают воркеры. Долгие задачи правильнее выносить в cron — планировщик, который запускает скрипт по расписанию в фоне, без участия посетителя.

Параллельно проверьте max_execution_time в файле /etc/php/8.2/fpm/php.ini и параметр request_terminate_timeout в конфиге пула. Все три лимита должны быть согласованы: если PHP обрывает работу на 30-й секунде, значение 300 в nginx ничего не изменит.

Когда виноват хостинг, а когда ваш код

Граница проходит по типу услуги. На виртуальном хостинге вы не управляете ни nginx, ни лимитами PHP-FPM. Там 502 почти всегда на стороне провайдера, и правильное действие одно — обращение в поддержку с указанием времени ошибки и адреса страницы. На своём сервере ответственность обратная: провайдер отвечает за железо, сеть и питание, всё остальное — ваше.

Признаки поломки у хостинга: сервер не пингуется, SSH не пускает, панель недоступна, на статус-странице висит сообщение об аварии. Признаки вашей вины: сервер отвечает по SSH, нагрузка видна в top, ошибка приходит только на части страниц.

Отдельный частый случай — 502 сразу после выкладки. Свежее расширение PHP роняет процесс с ошибкой segfault (аварийное завершение из-за обращения в чужую область памяти), обновлённый плагин исчерпывает память, отладочный вызов подвешивает запрос. Проверяется откатом на предыдущую версию кода: если ошибка ушла, ищите причину в изменениях.

Формулируйте обращение в поддержку конкретно. Укажите домен, время ошибки с точностью до минуты, адрес страницы и строку из error.log. С такими данными ответ приходит в разы быстрее, чем на сообщение «у меня не работает сайт».

На каком сервере 502 повторяется реже

Хроническая 502 на сайте с несколькими тысячами визитов в сутки — почти всегда сигнал о нехватке памяти, а не о плохом коде. Один гигабайт для связки nginx, PHP-FPM и MySQL — это впритык: система, база и десяток воркеров съедают его в первый же час пиковой нагрузки.

В каталоге 44 площадки с виртуальными серверами. Ниже — четыре недорогих варианта; конфигурация указана по базовому тарифу, память почти везде расширяется отдельной опцией.

Данные проверены 04.09.2026.

Переезжать ради одной ошибки не нужно: сначала добейтесь, чтобы 502 перестала повторяться на текущей машине. Дальше выручает мониторинг сервера: оповещение о падении приходит раньше, чем ошибку заметят посетители. А если бюджета на апгрейд нет, сравните недорогие VPS с 2 ГБ памяти — они часто стоят как текущий тариф с одним гигабайтом.

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

Большинство потерянных часов приходится не на сложную диагностику, а на неверный первый шаг. Ниже — то, что регулярно уводит в сторону начинающих администраторов.

• Перезапускать сайт по кругу, не открыв error.log: перезапуск маскирует симптом, но причина возвращается через час.
• Чистить кеш браузера и менять DNS, когда ошибку отдаёт сервер, — со стороны клиента 502 не лечится в принципе.
• Ставить pm.max_children равным 100 на сервере с 1 ГБ памяти и получать OOM killer вместо ускорения.
• Поднимать fastcgi_read_timeout до 600 секунд для всего сайта вместо ускорения одного тяжёлого скрипта.
• Обновлять PHP до новой версии и забывать поправить путь к сокету в конфиге сайта.
• Писать в поддержку «сайт не работает» без времени ошибки, URL и строки из лога — ответ придёт в разы позже.

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

Ошибка 502 Bad Gateway — это вина посетителя или сервера? Всегда сервера. Код из пятисотого диапазона означает проблему на стороне сайта, поэтому чистка кеша браузера помогает лишь случайно — когда сервис успел подняться сам.

Что делать в первую очередь, если сайт отдаёт 502? Открыть /var/log/nginx/error.log и прочитать последнюю строку. Она делит дальнейшие действия на две ветки: «Connection refused» означает, что процесс не запущен, «prematurely closed connection» — что он падает во время работы.

Может ли 502 быть из-за вирусов или атаки? Косвенно — да. Всплеск паразитного трафика забивает воркеры PHP-FPM, очередь переполняется, и посетители видят 502. В логе доступа это видно по сотням однотипных запросов за минуту.

Почему 502 появляется только в определённые часы? Это признак упора в лимиты. Днём число одновременных запросов превышает pm.max_children или кончается память, ночью трафик падает — и сайт работает нормально.

Хватит ли 1 ГБ памяти, чтобы 502 не возвращалась? Для визитки или блога с 200–300 визитами в сутки — да, при аккуратных лимитах FPM. Для интернет-магазина или форума закладывайте от 2 ГБ, иначе OOM killer будет срабатывать регулярно.

Влияет ли 502 на позиции сайта в поиске? Разовая ошибка на несколько минут — нет. Систематическая — да: робот получает код 5xx, снижает частоту обхода, а при затяжной недоступности убирает страницы из выдачи.

Итог

Ошибка 502 Bad Gateway почти никогда не бывает загадочной. Схема одна: nginx не получил ответ от бэкенда, причина написана в error.log, а причин по существу пять — процесс не запущен, память кончилась, воркеры исчерпаны, адрес связи не совпадает, скрипт не уложился в таймаут. Пройдите слои по порядку — это 10 минут вместо часа догадок.

Если ошибка возвращается неделями и упирается в 1 ГБ памяти, лечится она не конфигом, а более просторной машиной. Подобрать подходящую конфигурацию по цене и локации можно в разделе VPS для сайтов — там собраны тарифы всех площадок каталога с фильтром по объёму памяти и типу диска.