#Как проявляется неисправность
Сервер Node.js отвечает по адресу 127.0.0.1 на самом компьютере, но недоступен с другого устройства. Нужно отличить привязку сокета к loopback от сетевых ограничений, обратного прокси и правил брандмауэра.
#Причины и отличительные признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Приложение слушает только 127.0.0.1Loopback доступен лишь с самого компьютера. | ss показывает 127.0.0.1:порт | При необходимости выбрать нужный внешний интерфейс и защитить его. |
| Брандмауэр или сеть блокирует портПравило ОС или сети запрещает входящее соединение. | На сервере доступно по LAN IP, с другого ПК нет | Точно настроить разрешённый порт/источник. |
| Порт опубликован через обратный проксиNginx/балансировщик обращается не к тому адресу или порту. | Сервис отвечает локально, публичный домен нет | Сверить upstream и журналы. |
#Пошаговая диагностика и исправление
- Проверьте фактическую точку входаЗапишите порт и адрес, указанный в логах приложения. На сервере откройте браузер или curl и проверьте локальный URL, например
http://127.0.0.1:3000/health, только если приложение действительно содержит маршрут /health. При 404 сервер может работать — проверьте существующий URL.
- Посмотрите, какой адрес слушает процессНа Linux выполните
ss -ltnpи найдите требуемый порт.127.0.0.1:3000означает только локальный IPv4;0.0.0.0:3000— все IPv4-интерфейсы. Для просмотра владельца процесса иногда нужны права администратора, но наличие слушающего адреса видно и без них. - Linux; порт 3000 примерLinux · Терминал (Bash)КомандаLinux; порт 3000 пример. Windows:
Get-NetTCPConnection -LocalPort 3000 -State Listenв PowerShell.ss -ltn | grep :3000
- Проверьте код запуска Node.jsВ исходном коде найдите
server.listen(port, host)илиapp.listen(port, host)для Express. Указанный127.0.0.1намеренно ограничивает доступ; если нужен внешний доступ из разрешённой сети, допустим0.0.0.0, но он открывает службу на всех IPv4-интерфейсах. Убедитесь, что приложение имеет авторизацию и защищённый сетевой контур.
- Сначала проверьте адрес самого сервераУзнайте IP сетевого интерфейса через настройки ОС или
ip -4 addr. С самого сервера попробуйте запрос по этому IP и текущему порту. Если он не проходит, проблема скорее в привязке слушателя или локальном файрволе, а не в маршруте между двумя машинами. - Linux, только чтениеLinux · Терминал (Bash)КомандаLinux, только чтение. Не используйте случайный внешний IP; выбирайте адрес той сети, где ожидаются подключения.
ip -4 addr
- Проверьте с другого устройстваС компьютера в той же разрешённой сети попробуйте
curl -v http://IP_СЕРВЕРА:3000/, заменив IP и путь. Если есть таймаут, проверьте маршрутизацию и правила брандмауэра на конкретный порт. Если соединение отвергнуто, проверьте слушатель и активность процесса.Linux · Терминал (Bash)КомандаIP 192.0.2.10 — документальный пример, замените реальным адресом; без прав администратора.curl -v http://192.0.2.10:3000/
- Для публичного сайта предпочтите обратный проксиЕсли Node работает на одном сервере с Nginx, допустимо оставить Node привязанным к
127.0.0.1и принимать публичные HTTPS-запросы через Nginx. Проверьтеproxy_passи сертификат прокси, вместо открытия прямого порта Node в интернет.
- Сделайте проверку безопасности после исправленияПодтвердите доступ лишь с согласованных адресов, работу HTTPS через прокси и отсутствие случайного публичного доступа к административным маршрутам. Если открыли слишком широкий интерфейс, откатите настройку и ограничьте доступ на уровне прокси/брандмауэра.
#Проверка результата
Запрос с разрешённого клиента проходит, с неразрешённого — блокируется; локальный слушатель и сетевой маршрут соответствуют архитектуре.
При повторной ошибке сравните фактическую команду запуска, журнал приложения и параметры окружения. Если изменения затронули службу, верните предыдущую конфигурацию из сохранённой копии и разберите исходное сообщение об ошибке.