nginx отдаёт 502 bad gateway при проксировании на Node.js приложение

[hogan20]

Настраиваю reverse proxy: nginx слушает 443, проксирует на Node.js который крутится на 3000. Сертификат Let's Encrypt, всё выглядит правильно. Но получаю 502 Bad Gateway. В error.log nginx вижу: 'connect() failed (111: Connection refused) while connecting to upstream'. Node.js при этом запущен, curl localhost:3000 отдаёт нормальный ответ. Что не так?

[lxxyl]

Connection refused на 3000 при том что curl работает — почти всегда означает что Node слушает только на 127.0.0.1, а nginx пытается подключиться на другой адрес. Проверь: ss -tlnp | grep 3000 — увидишь на каком адресе реально висит процесс. В конфиге nginx убедись что написано proxy_pass http://127.0.0.1:3000 а не http://localhost:3000 — иногда localhost резолвится в ::1 (IPv6) а нода слушает только IPv4.

[omnicrom]

Был у меня точно такой же случай. Оказалось что после обновления системы /etc/hosts поменялся и localhost стал резолвиться в IPv6. Лечится либо явным 127.0.0.1 в proxy_pass, либо в настройках Node указать host: '0.0.0.0'. Второй вариант не рекомендую на проде без firewall.

[lost300z]

Вот минимальный рабочий конфиг nginx для такого случая:

server {
listen 443 ssl;
server_name example.com;

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_bypass $http_upgrade;
proxy_read_timeout 90;
}
}

Proxy_http_version 1.1 и заголовки Upgrade/Connection нужны если используешь WebSocket. X-Forwarded-Proto важен чтобы приложение знало что запрос пришёл по HTTPS.

[rbacker]

Проверь ещё SELinux или AppArmor если на CentOS/RHEL или Ubuntu соответственно. nginx может быть запрещено коннектиться к локальным портам. На RHEL: setsebool -P httpd_can_network_connect 1 решает проблему.

[luckysms]

После правки конфига не забудь nginx -t для проверки синтаксиса перед reload. Потом systemctl reload nginx — это graceful reload без даунтайма, не restart.

[magic123]

Добавлю кейс, которого тут не было: если Node живёт в Docker и в коде app.listen(3000, '127.0.0.1') — порт будет недоступен снаружи контейнера даже с правильным -p маппингом, внутри контейнера надо слушать 0.0.0.0. И вторая частая история — приложение периодически падает и pm2/systemd его перезапускает: в эти секунды nginx ловит connection refused. Гляньте pm2 status или systemctl status — если счётчик restarts растёт, то 502 плавающие и проблема вообще не в конфиге nginx.

[puto]

@lxxyl, дополню про localhost: nginx резолвит его на этапе чтения конфига, и если в /etc/hosts есть и 127.0.0.1, и ::1, он берёт ОБА адреса как апстримы и раскидывает запросы по ним по очереди. Отсюда классический симптом «через раз»: половина запросов уходит на ::1, получает refused — и в логе вперемешку 502 и нормальные ответы. Так что явный 127.0.0.1 в proxy_pass — это не перестраховка, а единственно предсказуемый вариант.

[envoylover]

@rbacker, только перед тем как крутить setsebool, стоит убедиться, что это вообще SELinux: ausearch -m avc -ts recent или просто grep denied /var/log/audit/audit.log. Иначе можно открыть httpd_can_network_connect (а это разрешает nginx ходить на ЛЮБЫЕ порты наружу, не только на 3000) и не решить исходную проблему. На Ubuntu дефолтный профиль AppArmor для nginx такие коннекты не режет, так что там копать почти бессмысленно.