Nginx как reverse proxy — баги, которые вылезают только после деплоя

Nginx выглядит простым, пока не выкатишь в прод. Конфиг валидный, стейджинг зелёный, а потом начинается "почему вдруг 413", "почему SSE не стримит", "почему бэкенд видит не тот путь".

Самая простая грабля — слеш в proxy_pass. Один символ меняет всё:

location /api/ {
    proxy_pass http://app/;   # бэкенд видит /users
}

location /api/ {
    proxy_pass http://app;    # бэкенд видит /api/users
}

Оба конфига валидны. Только один совпадает с тем, что ждёт твоё приложение.

Остальные, на которые стоит смотреть первым делом:

- X-Forwarded-For и X-Forwarded-Proto — доверяй только тем, что проставил сам. То, что прислал клиент, — это пользовательский ввод, и на нём нельзя строить ни rate limiting, ни аудит.
- client_max_body_size против лимитов приложения — выигрывает меньший, а 413 прилетает от того, кто первый отказал.
- proxy_buffering on по умолчанию тихо ломает SSE и стриминг. Выключать надо точечно, на нужных location.
- Таймауты: proxy_read_timeout, proxy_send_timeout, keepalive_timeout, send_timeout — каждый рубит запрос на своей стадии. Половина дебага — понять, кто именно выстрелил.

Проблема не в том, что nginx сложный. Проблема в том, что дефолты разумные для статики и не всегда разумные для API.