Node.js LinuxWindowsNode.js

Node.js: После изменения порта обратный прокси отвечает 502

  • Обновлено
  • Чтение ≈ 3 минуты
  • Нужны права администратора

Краткий ответ

После смены порта приложения Node.js обратный прокси Nginx может отвечать 502 Bad Gateway, потому что продолжает подключаться к прежнему порту, процесс не запущен или слушает другой интерфейс.

В этой статье
  1. Как проявляется неисправность
  2. Причины и отличительные признаки
  3. Пошаговая диагностика и исправление
  4. Проверка результата

#Как проявляется неисправность

После смены порта приложения Node.js обратный прокси Nginx может отвечать 502 Bad Gateway, потому что продолжает подключаться к прежнему порту, процесс не запущен или слушает другой интерфейс.

#Причины и отличительные признаки

Возможная причинаКак узнатьЧто делать
proxy_pass остался на старом портуNginx подключается к неправильному upstream.В error.log connect() failed (111: Connection refused) к прежнему портуСверить активный порт приложения и конфигурацию прокси.
Node не запущен или слушает другую семью адресовПроцесс не слушает ожидаемый IPv4/IPv6 интерфейс.curl на старый и новый порт даёт connection refusedПроверить service и адрес слушателя.
Nginx не может соединиться с сокетомНет доступа к файлу сокета либо неверный путь.В журнале Permission denied на unix socketПроверить владельца и доступ адресно.

#Пошаговая диагностика и исправление

  1. Сохраните симптомы без изменения проксиОткройте сайт, запишите время 502 и посмотрите журнал ошибок Nginx. Найдите upstream адрес и причину: connection refused, timeout или Permission denied. Сравните с реальным адресом, на котором Node сообщил о запуске.
  1. Проверьте приложение напрямую из сервераЧерез SSH выполните ss -ltn и найдите новый порт. Потом отправьте запрос curl напрямую на проверенный локальный адрес и существующий маршрут, например /, если он поддерживается. Если приложение возвращает 404 на запрос, соединение всё же установлено; это уже другой случай, чем connection refused.
  2. Linux, порт 3001 — пример
    Linux · Терминал (Bash)Команда
    Linux, порт 3001 — пример. Используйте фактический порт и разрешённый путь приложения.
    ss -ltn
    curl -i http://127.0.0.1:3001/
  1. Откройте действующую конфигурацию NginxДля чтения конфигурации используйте nginx -T при достаточных правах; вывод может содержать конфиденциальные пути. Найдите server/location нужного домена и proxy_pass. Если прокси указан как http://localhost:3000, учтите, что localhost может резолвиться также в IPv6; при необходимости зафиксируйте согласованный адрес.
  1. Сверьте адрес и порт в обеих настройкахВ коде Node ищите server.listen(port, host) или app.listen; в Nginx — proxy_pass. Для локального проксирования часто безопасно сохранять Node на 127.0.0.1 и изменить только порт в proxy_pass. Не открывайте внутренний порт Node напрямую в интернет, если он не рассчитан на публичный доступ.
  1. Проверьте исправленную конфигурацию без примененияПопросите администратора сначала сделать копию файла сайта и внести точечную правку proxy_pass http://127.0.0.1:3001; для соответствующего location. Затем выполните nginx -t. Должно быть syntax is ok и test is successful. При ошибке не выполняйте reload.
    Linux · Терминал (Bash)КомандаНужен sudo
    Linux; проверка требует достаточных прав для чтения конфигурации. Не вносит изменение в запущенный Nginx.
    sudo nginx -t
  1. Примените после проверки и в согласованное времяПосле успешного nginx -t администратор выполняет systemctl reload nginx (или предусмотренный панелью способ). Перезагрузка конфигурации затрагивает и другие сайты на этом Nginx: согласуйте изменение и сохраните возможность вернуть исходный файл.
    Linux · Терминал (Bash)С осторожностьюНужен sudo
    Linux с systemd, требует администратора; запускайте только после успешного nginx -t.
    sudo systemctl reload nginx

    Команда может изменить состояние системы или её настройки. Проверьте параметры и последствия перед запуском.

  1. Проверьте весь маршрут запросаВыполните локальный curl на upstream и отдельный HTTPS-запрос по публичному домену. Оба должны возвращать ожидаемый результат; просмотрите error.log за время теста. Если 502 осталась, проверьте другой upstream, SELinux/ACL, системные журналы и фактическую конфигурацию загруженного сайта.

#Проверка результата

Nginx принимает запрос по домену и перенаправляет на новый подтверждённый порт Node.js без новых 502. Внутренний сервис остаётся доступен только по разрешённым адресам.

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

Так эту ошибку тоже называют

Источники и обновления

Последнее обновление статьи: 2 ноября 2026. Версии программ и интерфейсы меняются — если шаги не совпадают с вашей версией, сверяйтесь с документацией производителя.