Nginx как reverse proxy: понятная схема для VPS

Reverse proxy позволяет держать снаружи один nginx, а внутренние приложения запускать на локальных портах. Это удобная схема для Node.js, Python, Docker, панелей и API.

Зачем нужен reverse proxy

Обычно приложение слушает локальный порт, например 127.0.0.1:3000. Nginx принимает внешний запрос на 80 или 443 порту и передаёт его приложению. Пользователь не видит внутреннюю схему.

• удобно подключать HTTPS;
• можно держать несколько приложений на одном IP;
• проще вести логи;
• можно ограничивать запросы и отдавать статику через nginx.

Базовый proxy_pass

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;
}

Почему важны заголовки

Без правильных заголовков backend может не знать реальный IP клиента, исходный Host и схему запроса. Из-за этого ломаются ссылки, авторизация, редиректы и логи.

WebSocket

Для WebSocket нужны Upgrade-заголовки. Если их не передать, обычные страницы могут работать, но чат, realtime-панель или уведомления — нет.

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;

502 Bad Gateway

502 означает, что nginx не смог получить нормальный ответ от backend. Причина чаще всего простая: приложение не запущено, слушает другой порт или упало.

ss -tulpn
systemctl status app --no-pager
journalctl -u app --no-pager -n 50

Таймауты

Для долгих запросов можно увеличить timeout, но не стоит делать их огромными без причины. Длинные соединения занимают ресурсы.

proxy_connect_timeout 30s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;

Практический вывод

Reverse proxy лучше строить по шагам: сначала backend на localhost, затем nginx, потом заголовки, WebSocket, HTTPS, лимиты и мониторинг.