Nginx перед приложением: проверяем reverse proxy по шагам

Приложение отвечает на localhost:3000, а через домен возвращается 502. Между браузером и приложением появился ещё один участник — Nginx. Проверим оба соединения по отдельности: сначала само приложение, затем прокси. Это обычно полезнее, чем сразу увеличивать все таймауты.

Пример локального прокси

server {
    listen 80;
    server_name app.example.org;
    location / {
        proxy_pass http://127.0.0.1:3000;
        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;
    }
}

Это пример локального HTTP-прокси, а не готовая публичная конфигурация с TLS. Порт 3000 должен обслуживаться вашим приложением. Доверие к forwarded-заголовкам на стороне приложения настраивается только для известных прокси, иначе клиент сможет повлиять на интерпретацию своего адреса.

Сначала проверка, затем применение

curl -i http://127.0.0.1:3000/
sudo nginx -t
sudo systemctl reload nginx

Если первый запрос не проходит, изменение таймаутов Nginx не исправит отсутствие процесса или неверный порт. Если проверка конфигурации неуспешна, не применяйте её. После reload проверьте запрос через Nginx и сопоставьте время с access_log и error_log.

Обращаем внимание на URI

Наличие URI в proxy_pass меняет правила передачи пути. Для location /api/ варианты с завершающим слешем и без него могут отправлять приложению разные адреса. Выпишите ожидаемый путь для одного конкретного запроса и сравните его с журналом приложения.

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

Источники и дальнейшее чтение

• Nginx: модуль HTTP proxy
• Nginx: руководство для начинающих