Os padrões de reverse proxy do Nginx que de fato rodamos em produção

A maioria das configs de reverse proxy do Nginx em produção é um copy-paste do blog de alguém em 2017. Funciona, mais ou menos. O keep-alive para o backend está desligado, então cada requisição abre uma nova conexão. A cadeia X-Forwarded-For está errada, então a aplicação loga o IP cliente errado. proxy_buffering está ligado por padrão, o que adiciona latência em respostas streamadas. Nenhuma é uma falha dramática — são impostos lentos e constantes que você só nota quando senta para ler o que implantou.

Esta é a config de reverse proxy que copiamos no edge de cada cliente.

O bloco upstream minimamente viável

upstream app {
    server 10.0.1.10:8080 max_fails=3 fail_timeout=15s;
    server 10.0.1.11:8080 max_fails=3 fail_timeout=15s;
    keepalive 32;
    keepalive_requests 1000;
    keepalive_timeout 60s;
}
 
location / {
    proxy_pass http://app;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    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_read_timeout 60s;
}

O keepalive 32 + Connection "" é inegociável. Sem isso, você refaz o handshake TCP para o backend a cada requisição — e para tráfego interno de alto RPS isso dobra a latência sem motivo.

O artigo completo cobre:

• A cadeia X-Forwarded-For — e o bloco real_ip_header que faz a app ver o IP correto
• proxy_buffering vs respostas streamadas (Server-Sent Events, downloads grandes)
• Health checks: passivos (max_fails/fail_timeout) vs ativos (Nginx Plus comercial ou ngx_http_upstream_check_module)
• proxy_next_upstream — quando retries ajudam e quando causam writes duplicados
• Limites de tamanho de body (client_max_body_size) e onde mordem uploads
• O padrão TLS-to-backend quando você de fato quer

Entregamos essa config em cada instalação Nginx gerenciada.