Ошибка 502 Bad Gateway на VPS: что проверить в Nginx, PHP‑FPM, Node.js и Docker

Ошибка 502 Bad Gateway обычно означает, что reverse proxy получил неправильный ответ от upstream-сервиса или не смог до него достучаться. На VPS таким proxy чаще всего выступает Nginx, а upstream может быть PHP-FPM, Node.js-приложение, Docker-контейнер, Apache, backend на другом порту или сервис за CDN.

Первое, что нужно понять: кто именно отдаёт 502. Ошибку может показывать Nginx на сервере, CDN перед сервером, Apache в роли proxy или другой балансировщик. Пока источник не определён, легко чинить не тот слой.

Базовый troubleshooting flow выглядит так:

Для Nginx диагностику обычно начинают с логов: sudo tail -n 100 /var/log/nginx/error.log

Если сайт работает на PHP, нужно проверить PHP-FPM: systemctl status php8.2-fpm

Версия может отличаться: php8.1-fpm, php8.3-fpm или другая, в зависимости от сервера.

Если backend написан на Node.js, нужно проверить, запущен ли процесс и слушает ли приложение нужный порт: ss -tulpn | grep 3000

Если приложение работает в Docker, нужно смотреть статус контейнера и его логи:

docker ps

docker logs container_name --tail=100

502 важно не путать с 504. При 502 proxy часто получает ошибочный ответ или не может подключиться к upstream. При 504 upstream обычно не отвечает вовремя, и проблема чаще связана с timeout, долгим запросом, зависшим backend или перегрузкой.

Очистка кеша редко исправляет 502. Она может помочь, если CDN или proxy временно показывают старую страницу ошибки, но не решит падение PHP-FPM, неверный proxy_pass, закрытый порт Node.js, неправильный socket или упавший Docker-контейнер.

Самая частая ошибка — сразу перезапускать сервер без чтения логов. Restart может временно вернуть сайт в работу, но причина останется: нехватка памяти, неверный upstream port, падение процесса после deploy, проблема с правами на socket, битый контейнер или неправильный healthcheck.

Правильная логика такая: сначала определить источник 502, затем открыть error.log, проверить статус сервисов, socket или port upstream, ресурсы сервера, логи приложения и только после этого перезапускать конкретный сервис. После временного исправления нужно зафиксировать причину, иначе ошибка вернётся снова.

Как работает 502 Bad Gateway

Ошибка 502 появляется не просто потому, что “сайт упал”. Обычно она означает, что один сервер пытался получить ответ от другого сервера или приложения, но получил некорректный ответ либо не смог нормально подключиться.

На VPS такая схема часто выглядит так: браузер → Nginx → PHP-FPM / Node.js / Docker / Apache / другой upstream

Браузер обращается к сайту, Nginx принимает запрос и передаёт его дальше. Если backend не отвечает как ожидается, Nginx может вернуть пользователю 502 Bad Gateway.

Кто отдаёт 502

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

502 может отдавать:

• Nginx на VPS;
• Apache, если он работает как reverse proxy;
• CDN перед сервером;
• Внешний балансировщик;
• Панель управления;
• gateway внутри Docker-инфраструктуры;
• Другой proxy перед приложением.

Например, пользователь видит страницу с 502, но её может отдавать CDN, потому что CDN не смог подключиться к origin-серверу. В другом случае 502 отдаёт Nginx на самом VPS, потому что PHP-FPM не запущен или Node.js-приложение не слушает нужный порт.

Поэтому не стоит сразу перезапускать весь сервер. Сначала нужно посмотреть, откуда пришла ошибка: из CDN, из Nginx, из Apache или из приложения.

Практически это можно понять по странице ошибки, HTTP-заголовкам, логам CDN и логам веб-сервера. Если в /var/log/nginx/error.log одновременно появляются свежие ошибки по этому домену, диагностику стоит начинать с VPS и upstream.

Когда источник ошибки найден, следующий важный момент — не спутать 502 с похожей ошибкой 504.

502 vs 504

502 и 504 похожи тем, что обе ошибки часто связаны с proxy и upstream. Но смысл у них разный.

502 Bad Gateway обычно означает, что proxy получил некорректный ответ от upstream или не смог нормально подключиться к нему.

Типичные причины 502:

• PHP-FPM не запущен;
• Node.js-приложение упало;
• Docker-контейнер остановлен;
• Nginx смотрит не на тот порт;
• socket PHP-FPM не существует;
• Нет прав на socket;
• backend вернул неправильный ответ;
• upstream закрыл соединение.

504 Gateway Timeout означает, что proxy ждал ответ слишком долго и не дождался его за отведённое время.

Типичные причины 504:

• backend завис на долгом запросе;
• PHP-скрипт выполняется слишком долго;
• Node.js не успевает ответить;
• База данных перегружена;
• Внешний API тормозит;
• timeout в Nginx слишком короткий для конкретной операции;
• Серверу не хватает ресурсов.

То есть при 502 чаще проверяют доступность upstream: работает ли сервис, открыт ли порт, существует ли socket, совпадает ли конфиг. При 504 чаще смотрят время выполнения, зависшие запросы, нагрузку, медленные SQL-запросы и timeout-настройки.

Путаница между 502 и 504 приводит к неправильному ремонту. Например, можно увеличивать timeout, хотя Node.js-приложение вообще не запущено. Или перезапускать PHP-FPM, хотя проблема в долгом запросе к базе.

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

Почему проблема почти всегда в связке proxy → upstream

На VPS Nginx часто работает как входная точка. Он принимает HTTP/HTTPS-запрос, обрабатывает SSL, статические файлы, редиректы и затем передаёт динамический запрос дальше.

Для PHP-сайта upstream обычно PHP-FPM: Nginx → PHP-FPM socket или TCP-port

Для Node.js-приложения: Nginx → localhost:3000

Для Docker: Nginx → container port / published port / Docker network

Если эта связка нарушается, появляется 502. Nginx жив, домен открывается, SSL может быть в порядке, но backend не принимает запрос или отвечает неправильно.

Примеры:

• В proxy_pass указан порт 3000, а приложение слушает 3001;
• PHP-FPM перезапущен с другим socket, а Nginx смотрит на старый путь;
• Docker-контейнер работает внутри сети, но порт не опубликован наружу;
• Node.js упал после deploy;
• PHP-FPM pool исчерпал лимит процессов;
• У Nginx нет прав на socket PHP-FPM;
• backend завершает соединение из-за нехватки памяти.

Поэтому при 502 полезно мыслить не страницей в браузере, а маршрутом запроса. Нужно пройти цепочку: кто принял запрос, куда он передал его дальше, существует ли этот upstream, слушает ли он нужный socket или port и что написано в логах.

Очистка кеша, смена браузера или полный reboot сервера могут случайно скрыть симптом, но не объяснят причину. Для нормального исправления нужно разбирать именно связку proxy → upstream: Nginx, PHP-FPM, Node.js, Docker, порт, socket, права, timeout, память и логи.

Диагностика по шагам

При 502 важно не начинать с хаотичных действий. Полный reboot сервера, очистка кеша и случайный restart всех сервисов могут временно скрыть симптом, но не покажут причину.

Правильнее идти по цепочке запроса: кто отдал ошибку, какие сервисы должны были обработать запрос, что написано в логах, куда proxy передаёт трафик и хватает ли серверу ресурсов.

Определить источник ошибки

Сначала нужно понять, кто именно показывает 502. Это может быть Nginx на VPS, Apache, CDN, внешний reverse proxy, балансировщик или gateway внутри Docker-инфраструктуры.

Если перед сайтом стоит CDN, пользователь может видеть 502 от CDN, хотя проблема находится на origin-сервере. CDN не смог подключиться к VPS, получил ошибочный ответ или не дождался корректного ответа от backend.

Проверку можно начать с простых вопросов:

• Используется ли CDN или внешний proxy;
• Появляется ли ошибка при обращении напрямую к IP сервера;
• Есть ли свежие записи в логах Nginx или Apache;
• Совпадает ли время ошибки в браузере и в логах сервера;
• Показывает ли страницу ошибки сам Nginx, CDN или приложение.

Если в логах Nginx есть свежие ошибки по этому домену, диагностику стоит продолжать на VPS. Если на сервере тишина, а ошибку показывает CDN, нужно отдельно проверить доступность origin, DNS, firewall и настройки CDN.

Когда источник определён, следующий шаг — убедиться, что нужные сервисы вообще запущены.

Проверить сервисы

502 часто появляется из-за того, что upstream-сервис не работает. Nginx жив, принимает запросы, но PHP-FPM, Node.js, Apache или Docker-контейнер, которому нужно передать запрос, остановлен или упал.

Для начала проверьте Nginx: systemctl status nginx

Если сайт работает на PHP, проверьте PHP-FPM. Версия может отличаться: systemctl status php8.2-fpm

Для Node.js-приложения нужно понять, как оно запущено: через systemd, PM2, Docker или вручную. Например, для PM2: pm2 status

Если используется Docker, проверьте контейнеры: docker ps

И отдельно все контейнеры, включая остановленные: docker ps -a

На этом этапе важно не просто увидеть “active” или “running”, а понять, соответствует ли это реальной схеме сайта. Например, Nginx может быть активен, но Node.js-приложение упало. Или контейнер запущен, но внутри приложение не прошло healthcheck.

Если сервис остановлен, его можно перезапустить, но перед этим лучше открыть логи. Именно они покажут, почему процесс упал.

Открыть error.log

Логи — главный источник информации при 502. Без них легко начать чинить не то: менять timeout, хотя порт закрыт; чистить кеш, хотя PHP-FPM не запущен; перезапускать Docker, хотя Nginx смотрит не на тот upstream.

Для Nginx основной файл — error.log: sudo tail -n 100 /var/log/nginx/error.log

Если на сервере несколько сайтов, полезно смотреть лог конкретного virtual host, если он настроен отдельно: sudo tail -n 100 /var/log/nginx/example.com.error.log

В логах часто встречаются подсказки: connect() failed (111: Connection refused) while connecting to upstream

Это значит, что Nginx попытался подключиться к upstream, но тот не принял соединение. Обычно причина в неверном порту, остановленном backend или закрытом socket.

Другой пример: upstream timed out while reading response header from upstream

Здесь upstream принял соединение, но не ответил вовремя. Это уже ближе к timeout, долгому запросу, зависшему PHP/Node.js или перегрузке.

Ещё один частый вариант: connect() to unix:/run/php/php8.2-fpm.sock failed (13: Permission denied)

Такой лог указывает на проблему с правами доступа к socket PHP-FPM.

После логов обычно становится понятно, куда смотреть дальше: socket, port, upstream-конфиг или ресурсы сервера.

Проверить socket, port и upstream

502 часто возникает из-за несовпадения между конфигом Nginx и реальным backend. Nginx передаёт запрос в одно место, а приложение слушает другое.

Для PHP-FPM нужно проверить fastcgi_pass в конфиге Nginx:

location ~ \.php$ {

    fastcgi_pass unix:/run/php/php8.2-fpm.sock;

}

Затем нужно убедиться, что socket действительно существует: ls -la /run/php/

Если Nginx смотрит на php8.2-fpm.sock, а на сервере есть только php8.3-fpm.sock, будет 502. Такая ситуация часто появляется после обновления PHP.

Для Node.js нужно проверить proxy_pass:

location / {

    proxy_pass http://127.0.0.1:3000;

}

И убедиться, что приложение слушает этот порт: ss -tulpn | grep 3000

Если порт не слушается, проблема не в Nginx, а в Node.js-приложении, PM2, systemd-сервисе, переменных окружения или ошибке после deploy.

Для Docker нужно проверить, как опубликованы порты: docker ps

Например, если Nginx на хосте обращается к 127.0.0.1:3000, контейнер должен публиковать этот порт наружу. Если Nginx работает внутри Docker-сети, нужно проверять имя сервиса, сеть и внутренний порт контейнера.

Когда socket и port совпадают, но 502 остаётся, стоит проверить ресурсы. Backend может быть запущен, но падать под нагрузкой или не успевать отвечать.

Проверить память и лимиты

Нехватка памяти, процессов или файловых дескрипторов тоже может приводить к 502. В этом случае сервис вроде бы работает, но периодически падает, не принимает соединения или не успевает обработать запросы.

Начать можно с общей нагрузки:

free -h

df -h

top

Если серверу не хватает памяти, Linux может убить процесс через OOM killer. Проверить это можно так: dmesg -T | grep -i "killed process"

Или через journal: journalctl -k | grep -i oom

Для PHP-FPM стоит проверить лимиты pool. Если процессов слишком мало, а запросов много, сайт может отвечать нестабильно:

grep -E "pm.max_children|pm.start_servers|pm.min_spare_servers|pm.max_spare_servers" /etc/php/8.2/fpm/pool.d/www.conf

Версия PHP и имя pool могут отличаться.

Для Node.js нужно смотреть, не падает ли процесс из-за ошибки, нехватки памяти или неправильных переменных окружения. Если используется PM2: pm2 logs

Для Docker — логи и состояние контейнера:

docker logs container_name --tail=100

docker inspect container_name --format='{{.State.Health.Status}}'

Если проблема в ресурсах, простой restart поможет только временно. Через некоторое время процессы снова упрутся в память, лимиты PHP-FPM, долгие запросы, тяжёлые SQL-операции или ошибки приложения.

Поэтому диагностика 502 должна завершаться не командой “перезапустить всё”, а понятным выводом: какой upstream не отвечал, почему он не отвечал и что нужно изменить, чтобы ошибка не вернулась.

Проверки для Nginx, PHP-FPM, Node.js и Docker

После общей диагностики нужно перейти к конкретной связке. Ошибка 502 может выглядеть одинаково в браузере, но причины у PHP-сайта, Node.js-приложения и Docker-контейнера будут разными.

Удобнее идти от входной точки к backend: сначала Nginx или внешний proxy, затем upstream-сервис, который должен обработать запрос.

Nginx

Nginx часто отдаёт 502, когда не может передать запрос дальше: в PHP-FPM, Node.js, Apache, Docker-контейнер или другой upstream.

Начать стоит с проверки конфига: sudo nginx -t

Если в конфигурации есть синтаксическая ошибка, Nginx может не применить новые настройки или работать со старой конфигурацией.

Затем нужно посмотреть логи: sudo tail -n 100 /var/log/nginx/error.log

И, если для сайта настроен отдельный лог: sudo tail -n 100 /var/log/nginx/example.com.error.log

В Nginx чаще всего нужно проверить:

• proxy_pass для Node.js или другого backend;
• fastcgi_pass для PHP-FPM;
• Путь к PHP-FPM socket;
• upstream port;
• Права доступа к socket;
• timeout-настройки;
• Не указывает ли конфиг на старую версию PHP;
• Не изменился ли порт после deploy.

Для PHP-сайта ошибка может быть в таком фрагменте: fastcgi_pass unix:/run/php/php8.2-fpm.sock;

Если PHP-FPM после обновления работает через другой socket, Nginx продолжит смотреть в старый путь и будет отдавать 502.

Для Node.js нужно проверить proxy_pass: proxy_pass http://127.0.0.1:3000;

Если приложение слушает другой порт, Nginx не сможет подключиться к upstream.

Nginx показывает место поломки, но часто не является первопричиной. После его логов обычно нужно переходить к PHP-FPM, Node.js или контейнеру, на который он проксирует запрос.

PHP-FPM

PHP-FPM отвечает за выполнение PHP-кода. Если WordPress, Laravel или другой PHP-сайт работает через Nginx, то при падении PHP-FPM пользователь может увидеть 502.

Сначала проверьте статус сервиса: systemctl status php8.2-fpm

Версия может отличаться:

systemctl status php8.1-fpm

systemctl status php8.3-fpm

Если сервис не запущен, нужно смотреть его логи:

journalctl -u php8.2-fpm -n 100 --no-pager

Дальше проверьте pool-конфигурацию. Обычно она находится здесь: /etc/php/8.2/fpm/pool.d/www.conf

Важные параметры:

listen = /run/php/php8.2-fpm.sock

user = www-data

group = www-data

listen.owner = www-data

listen.group = www-data

pm.max_children = 20

Параметр listen должен совпадать с fastcgi_pass в конфиге Nginx. Если PHP-FPM слушает socket, Nginx должен смотреть на этот socket. Если PHP-FPM слушает TCP-порт, Nginx должен обращаться к этому порту.

Проверить socket можно так: ls -la /run/php/

Если в логах Nginx есть Permission denied, проверьте владельца socket и параметры listen.owner, listen.group, listen.mode.

Также PHP-FPM может давать 502 из-за нехватки процессов. Если pm.max_children слишком мал, а запросов много, часть запросов может зависать или обрываться. В таком случае нужно смотреть логи PHP-FPM, нагрузку, память и slow log.

PHP-FPM обычно связан с PHP-сайтами. Если же backend написан на Node.js, диагностика смещается к процессу приложения и его порту.

Node.js

Для Node.js 502 чаще всего означает, что Nginx пытается проксировать запрос на порт, где приложение не отвечает.

Сначала нужно понять, как запущено приложение: через PM2, systemd, Docker, screen, supervisor или вручную. Если используется PM2, проверьте статус: pm2 status

И логи: pm2 logs

Если приложение запущено через systemd:

systemctl status app-name

journalctl -u app-name -n 100 --no-pager

Дальше проверьте, слушает ли Node.js нужный порт: ss -tulpn | grep 3000

Если Nginx настроен на: proxy_pass http://127.0.0.1:3000;

то приложение действительно должно слушать 127.0.0.1:3000 или 0.0.0.0:3000.

Частые причины 502 в Node.js:

• Приложение упало после deploy;
• Не установлены зависимости;
• Не задана переменная окружения;
• Занят нужный порт;
• Приложение слушает другой порт;
• PM2 не сохранил процесс после reboot;
• backend падает на первом запросе;
• Nginx проксирует не туда;
• Запрос выполняется слишком долго и упирается в timeout.

После исправления важно сохранить процесс, если используется PM2: pm2 save

И проверить автозапуск, чтобы после reboot приложение не исчезло.

Если Node.js работает внутри контейнера, обычной проверки порта на хосте может быть недостаточно. Тогда нужно отдельно смотреть Docker.

Docker

В Docker 502 часто появляется из-за того, что контейнер остановлен, приложение внутри контейнера упало, порт не опубликован наружу или Nginx обращается не к тому имени сервиса.

Сначала проверьте контейнеры: docker ps

И остановленные контейнеры: docker ps -a

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

Логи контейнера: docker logs container_name --tail=100

Если используется Docker Compose:

docker compose ps

docker compose logs app --tail=100

Дальше нужно проверить проброс портов. Например, если Nginx на хосте обращается к 127.0.0.1:3000, контейнер должен публиковать порт на хост: 0.0.0.0:3000->3000/tcp

Если Nginx тоже работает в Docker, он может обращаться не к 127.0.0.1, а к имени сервиса внутри Docker-сети: proxy_pass http://app:3000;

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

Также стоит проверить healthcheck, если он настроен: docker inspect container_name --format='{{.State.Health.Status}}'

Контейнер может быть “running”, но приложение внутри него фактически не готово принимать запросы. Healthcheck помогает отличить живой контейнер от рабочего приложения.

Docker добавляет ещё один слой между proxy и backend. Но иногда 502 вообще приходит не с VPS, а от CDN или внешнего proxy перед сервером.

CDN или внешний proxy

Если перед сайтом стоит CDN, внешний reverse proxy или балансировщик, 502 может появляться ещё до обращения к Nginx на VPS.

В таком случае нужно проверить, доходит ли запрос до origin-сервера. Если в логах Nginx нет свежих запросов в момент ошибки, возможно, проблема между CDN и VPS.

Проверьте:

• Правильно ли CDN указывает на origin;
• Не изменился ли IP VPS;
• Открыт ли 80/443 порт на сервере;
• Не блокирует ли firewall IP-адреса CDN;
• Совпадает ли SSL-режим CDN и origin;
• Нет ли ошибок в панели CDN;
• Доступен ли сайт напрямую без CDN;
• Не включены ли слишком жёсткие WAF-правила.

Если CDN показывает 502, а сайт напрямую по origin работает, проблема может быть в настройках CDN, SSL, firewall или маршрутизации. Если сайт напрямую тоже отдаёт 502, диагностику нужно возвращать на VPS: Nginx, upstream, PHP-FPM, Node.js или Docker.

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

Типовые ошибки 

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

Но быстрые действия без диагностики часто только скрывают проблему. Сайт может заработать после restart, но через час снова упасть по той же причине: backend не держит нагрузку, PHP-FPM упирается в лимиты, Node.js падает после запроса, контейнер не проходит healthcheck или Nginx смотрит не на тот порт.

Restart без чтения логов

Самая частая ошибка — сразу перезапустить Nginx, PHP-FPM, Node.js, Docker или весь VPS, не посмотрев логи. Иногда это действительно временно помогает: процесс стартует заново, socket появляется, порт снова слушается, контейнер поднимается.

Проблема в том, что причина остаётся неизвестной.

До restart стоит хотя бы быстро сохранить состояние:

systemctl status nginx

systemctl status php8.2-fpm

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

Для Node.js:

pm2 status

pm2 logs --lines 100

Для Docker:

docker ps -a

docker logs container_name --tail=100

Если сразу всё перезапустить, можно потерять важный контекст: какой сервис был остановлен, какая ошибка была в логах, был ли OOM, какой контейнер перезапускался и на каком запросе падало приложение.

Restart лучше использовать как временное восстановление, но не как замену расследованию. После него всё равно нужно понять, почему upstream перестал отвечать.

Следующая частая ошибка — лечить 502 как любой другой “gateway timeout”, хотя это не всегда timeout.

Путаница 502 и 504

502 и 504 похожи внешне, но указывают на разные типы проблем.

502 Bad Gateway чаще означает, что proxy получил некорректный ответ от upstream или не смог нормально подключиться к нему. Например, PHP-FPM не запущен, Node.js упал, Docker-контейнер остановлен, socket не существует или Nginx проксирует на неправильный порт.

504 Gateway Timeout означает, что proxy ждал ответ слишком долго и не дождался. Здесь чаще виноваты долгие запросы, зависший backend, перегруженная база, внешний API или слишком короткие timeout-настройки.

Если перепутать эти ошибки, можно пойти не туда. Например, увеличивать timeout, хотя backend вообще не слушает порт. Или перезапускать PHP-FPM, когда на самом деле запрос зависает на медленном SQL-запросе.

При 502 полезно сначала проверить:

• Запущен ли upstream;
• Существует ли socket;
• Слушается ли нужный port;
• Совпадает ли proxy_pass или fastcgi_pass;
• Нет ли connection refused или permission denied в логах.

При 504 важнее смотреть длительность запросов, slow log, базу данных, внешние API и timeout.

Когда тип ошибки определён, не стоит пытаться исправить её очисткой кеша. Для 502 это почти всегда не основной слой проблемы.

Очистка кеша вместо диагностики

Очистка кеша может помочь, если браузер, CDN или proxy временно показывают старую страницу ошибки. Но если Nginx не может подключиться к PHP-FPM, Node.js или Docker-контейнеру, кеш не исправит upstream.

502 возникает в момент обработки запроса между proxy и backend. Поэтому реальную причину нужно искать в сервисах и логах, а не только в кеше сайта.

Очистка кеша не решит:

• Остановленный PHP-FPM;
• Неверный путь к socket;
• Закрытый port Node.js;
• Упавший контейнер;
• Ошибку connection refused;
• Проблему с правами на socket;
• Нехватку памяти;
• Неправильный proxy_pass;
• Падение приложения после deploy.

Для WordPress очистка кеша плагина тоже не заменяет проверку PHP-FPM и Nginx. Для Node.js-приложения очистка CDN не поднимет процесс, который упал после ошибки в коде. Для Docker очистка кеша не исправит контейнер, который постоянно перезапускается.

Кеш можно проверять после базовой диагностики, но начинать нужно с маршрута запроса: proxy → upstream. Особенно важно убедиться, что Nginx обращается на правильный port.

Непроверенный upstream port

Неправильный upstream port — одна из самых простых и неприятных причин 502. Конфиг выглядит почти правильно, сервис вроде бы запущен, но Nginx отправляет запрос не туда.

Пример для Node.js: proxy_pass http://127.0.0.1:3000;

Если приложение после deploy стало слушать 3001, Nginx продолжит обращаться к 3000 и получит ошибку.

Проверить порт можно так: ss -tulpn | grep 3000

Или посмотреть все слушающие порты: ss -tulpn

Для PHP-FPM похожая проблема возникает не с TCP-портом, а с socket: fastcgi_pass unix:/run/php/php8.2-fpm.sock;

Если после обновления PHP появился php8.3-fpm.sock, а Nginx смотрит на старый socket, сайт может отдавать 502.

Проверка: ls -la /run/php/

В Docker порт может быть опубликован не так, как ожидает Nginx. Например, приложение внутри контейнера слушает 3000, но наружу опубликован другой порт или не опубликован вообще.

Поэтому при 502 нужно всегда сверять три вещи: куда смотрит Nginx, где реально слушает backend и есть ли между ними доступ.

Даже если после исправления порта или restart сайт заработал, работу нельзя считать законченной. Нужно зафиксировать причину, иначе эта же ошибка вернётся позже.

Нет фиксации причины после restart

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

После восстановления нужно записать:

• Какой сервис не отвечал;
• Какая ошибка была в логах;
• Какой upstream использовался;
• Какой port или socket был указан в конфиге;
• Был ли OOM или нехватка памяти;
• Какой контейнер падал;
• Что именно исправили;
• Какие команды помогли;
• Что нужно изменить, чтобы ошибка не повторилась.

Например, если PHP-FPM упал из-за нехватки pm.max_children, простой restart вернёт сайт в работу, но под нагрузкой ошибка появится снова. Нужно пересмотреть лимиты, память сервера, нагрузку и slow log.

Если Node.js упал после deploy, restart тоже не решает причину. Нужно смотреть ошибку приложения, зависимости, переменные окружения и автозапуск.

Если Docker-контейнер постоянно перезапускается, важно не только выполнить docker restart, а понять, почему он падает: ошибка в entrypoint, переменных окружения, базе, сети или healthcheck.

Хорошая практика — после каждого инцидента оставить короткую заметку (Postmortem): симптом, причина, исправление и action plan как предотвратить подобные инциденты в дальнейшем. Это помогает быстрее чинить повторные ошибки и постепенно превращает хаотичный troubleshooting в нормальную эксплуатацию VPS.

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

Если 502 исчезла и сайт снова открывается, диагностику всё равно не стоит сразу закрывать. Часто restart возвращает сервис в работу временно, но не устраняет причину: нехватку памяти, неверный upstream, падение приложения, перегруженный PHP-FPM pool или нестабильный контейнер.

Сначала нужно проверить, что все нужные сервисы действительно работают:

systemctl status nginx

systemctl status php8.2-fpm

Для Node.js через PM2:

pm2 status

pm2 logs --lines 50

Для Docker:

docker ps

docker logs container_name --tail=50

Затем стоит повторно открыть логи Nginx и приложения. Важно убедиться, что новые ошибки не продолжают появляться после восстановления:

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

Если в логах всё ещё появляются connection refused, upstream timed out, permission denied или ошибки приложения, значит проблема не решена полностью.

Дальше нужно проверить сам маршрут запроса. Nginx должен обращаться к актуальному socket, port или container. Если после исправления меняли конфиг, обязательно проверьте синтаксис и примените настройки:

sudo nginx -t

sudo systemctl reload nginx

Для PHP-FPM проверьте, совпадает ли fastcgi_pass с реальным socket или TCP-портом. Для Node.js — что приложение слушает тот порт, который указан в proxy_pass. Для Docker — что контейнер запущен, порт опубликован или сервис доступен внутри Docker-сети.

После этого полезно проверить ресурсы сервера:

free -h

df -h

top

Если память почти закончилась, диск заполнен или CPU постоянно загружен, 502 может вернуться. В таком случае нужно искать причину нагрузки: тяжёлые запросы, медленную базу, утечки памяти, слишком маленькие лимиты PHP-FPM, ошибку в Node.js или контейнер, который постоянно перезапускается.

Для сайта после восстановления нужно проверить не только главную страницу. Откройте несколько внутренних страниц, админку, форму заявки, авторизацию, корзину, API-эндпоинты и другие динамические разделы. Иногда главная открывается, а ошибка остаётся на тяжёлых маршрутах.

Если проблема была связана с deploy, обновлением PHP, Docker Compose, переменными окружения или сменой порта, зафиксируйте, что именно изменилось. Иначе при следующем обновлении ошибка может повториться.

Минимальная заметка после инцидента может выглядеть так:

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

Заключение

Ошибка 502 Bad Gateway на VPS почти всегда связана с разрывом между proxy и upstream. Пользователь видит одну страницу ошибки, но внутри цепочки могут участвовать Nginx, Apache, PHP-FPM, Node.js, Docker-контейнер, CDN, внешний proxy или backend на отдельном порту.

Правильная диагностика начинается не с полного reboot сервера, а с вопроса: кто отдал 502 и куда он пытался передать запрос. После этого нужно проверить статус сервисов, открыть error.log, сверить socket или port upstream, посмотреть логи приложения и оценить ресурсы сервера.

Для PHP-сайта особенно важны PHP-FPM, pool-конфигурация, fastcgi_pass, socket и права доступа. Для Node.js — процесс приложения, порт, PM2 или systemd, переменные окружения и ошибки после deploy. Для Docker — статус контейнера, проброс портов, Docker network, logs и healthcheck. Если перед сайтом стоит CDN, нужно отдельно понять, доходит ли запрос до origin-сервера.

502 не стоит путать с 504. При 502 proxy часто не может подключиться к upstream или получает некорректный ответ. При 504 upstream обычно отвечает слишком долго. Из-за этой разницы отличаются и проверки: для 502 важнее socket, port, процесс и логи подключения, а для 504 — timeout, долгие запросы, база и нагрузка.

Restart может временно вернуть сайт в работу, но сам по себе он не является исправлением. Если не прочитать логи и не зафиксировать причину, ошибка может вернуться после следующей нагрузки, deploy, перезапуска сервера или обновления PHP.

Надёжный подход — идти по цепочке запроса, проверять конкретный upstream, исправлять причину и после восстановления смотреть, не продолжают ли появляться ошибки. Тогда 502 превращается не в хаотичную аварию, а в понятную задачу диагностики VPS.

FAQ

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

502 Bad Gateway означает, что proxy или gateway не смог получить корректный ответ от upstream-сервиса. На VPS это часто выглядит так: Nginx принимает запрос от пользователя, но не может нормально передать его дальше в PHP-FPM, Node.js, Docker-контейнер, Apache или другой backend.

Причина может быть в остановленном сервисе, неправильном порте, отсутствующем socket, ошибке прав доступа, падении приложения, проблеме в контейнере или некорректной настройке reverse proxy.

Где смотреть причину 502 на VPS?

Начинать стоит с error log веб-сервера. Для Nginx это обычно: sudo tail -n 100 /var/log/nginx/error.log

Если для сайта настроен отдельный лог, нужно смотреть его: sudo tail -n 100 /var/log/nginx/example.com.error.log

После этого проверяют upstream: PHP-FPM, Node.js, Docker-контейнер или другой backend. Для PHP-FPM смотрят systemctl status и journalctl, для Node.js — PM2 или systemd logs, для Docker — docker logs.

Почему 502 появляется после deploy?

После deploy часто меняется то, на что завязан upstream: порт приложения, переменные окружения, зависимости, путь к socket, версия PHP, Docker image или команда запуска.

Например, Nginx может продолжать проксировать запросы на 127.0.0.1:3000, а Node.js-приложение после deploy слушает 3001. Или PHP обновили с 8.2 до 8.3, но fastcgi_pass всё ещё указывает на старый socket.

После deploy нужно проверять не только статус “приложение запущено”, но и весь маршрут: Nginx → port/socket → backend → logs.

Что делать, если PHP-FPM вызывает 502?

Сначала проверьте статус PHP-FPM: systemctl status php8.2-fpm

Версия может отличаться: php8.1-fpm, php8.3-fpm или другая.

Затем проверьте, совпадает ли fastcgi_pass в Nginx с реальным socket или TCP-портом PHP-FPM. Например: fastcgi_pass unix:/run/php/php8.2-fpm.sock;

И проверьте socket: ls -la /run/php/

Если в логах есть Permission denied, нужно проверить владельца socket и параметры pool-конфигурации: listen.owner, listen.group, listen.mode. Если PHP-FPM падает под нагрузкой, смотрите память, pm.max_children, slow log и ошибки PHP.

Что делать, если 502 возникает в Node.js-приложении?

Для Node.js нужно проверить, запущен ли процесс и слушает ли он нужный порт.

Если используется PM2:

pm2 status

pm2 logs --lines 100

Проверка порта: ss -tulpn | grep 3000

Если Nginx настроен на proxy_pass http://127.0.0.1:3000;, приложение должно действительно слушать этот порт. Если процесс падает после запуска, причину нужно искать в логах: ошибка кода, отсутствующая переменная окружения, неустановленные зависимости, занятый порт или проблема с подключением к базе.

Как диагностировать 502 в Docker?

В Docker сначала проверяют статус контейнера:

docker ps

docker ps -a

Затем логи: docker logs container_name --tail=100

Если используется Docker Compose:

docker compose ps

docker compose logs app --tail=100

Частые причины: контейнер остановлен, приложение внутри контейнера упало, порт не опубликован, Nginx обращается не к тому адресу, контейнеры находятся в разных сетях или healthcheck показывает, что приложение не готово принимать запросы.

Почему очистка кеша не исправляет 502?

Очистка кеша может убрать старую страницу ошибки из браузера, CDN или proxy, но она не исправляет саму причину 502.

Если PHP-FPM не запущен, Node.js не слушает порт, Docker-контейнер падает или Nginx смотрит на неправильный upstream, кеш не поможет. В таких случаях нужно смотреть логи, статус сервисов, socket, port, upstream-конфиг и ресурсы сервера.

Когда при 502 виноват CDN?

CDN может быть источником 502, если он не может подключиться к origin-серверу или получает от него некорректный ответ.

Проверьте:

• Правильно ли CDN указывает на IP VPS;
• Доступен ли origin напрямую;
• Открыты ли 80 и 443 порты;
• Не блокирует ли firewall IP-адреса CDN;
• Совпадает ли SSL-режим CDN и origin;
• Есть ли запросы от CDN в логах Nginx.

Если в логах VPS нет свежих запросов в момент ошибки, проблема может быть между CDN и сервером. Если запросы доходят и Nginx пишет ошибки upstream, диагностику нужно продолжать на VPS.

Список источников

1. Nginx Documentation — HTTP proxy module

2. Nginx Documentation — FastCGI module

3. PHP Manual — PHP-FPM Configuration

4. Docker Documentation — View container logs