1001Ferramentas
🔁 Dev

Gerador de NGINX Reverse Proxy

Monta um proxy reverso NGINX com upstream backend, proxy_set_header padrão (Host, X-Real-IP, X-Forwarded-*) e WebSocket support.

Proxy reverso para app Node atrás do nginx

Seu app escuta em 127.0.0.1:3000 e precisa aparecer em api.exemplo.com na porta 80, sem que o backend perca de vista quem é o visitante. Informe o server_name, a porta, a URL do backend e marque WebSocket se o app usar. A saída traz o proxy_pass e os quatro cabeçalhos que quase todo framework espera receber: Host, X-Real-IP, X-Forwarded-For e X-Forwarded-Proto, além do proxy_http_version 1.1.

Mandar X-Forwarded-Proto resolve metade do problema; a outra metade é o framework confiar nele. Sem app.set('trust proxy', 1) no Express, ou o equivalente no Django e no Rails, o req.ip continua sendo o do nginx e os redirects saem em http, o que costuma virar loop de redirecionamento atrás de HTTPS. Repare também que o bloco upstream sai declarado mas o proxy_pass aponta direto para a URL digitada.

Se você quiser balancear entre várias máquinas, liste os servers dentro do upstream e troque o proxy_pass por http://backend. Com WebSocket marcado, o Connection upgrade vale para todas as requisições do location, não só para as que pedem upgrade; a documentação do nginx sugere um map baseado em http_upgrade quando isso incomoda. Para SSE, acrescente proxy_buffering off. Backend em HTTPS geralmente pede proxy_ssl_server_name on.

Perguntas frequentes

Preciso mesmo do bloco upstream?
Para um backend só, não. O proxy_pass apontando direto para host e porta resolve. O upstream compensa quando há mais de uma instância ou você quer definir keepalive e política de balanceamento.
Por que meu app vê 127.0.0.1 como IP de todo mundo?
Porque o cabeçalho X-Real-IP chega, mas o framework só o usa se você habilitar a confiança no proxy. No Express é o trust proxy, no Django o SECURE_PROXY_SSL_HEADER junto com o middleware de IP.
A barra no final do proxy_pass muda alguma coisa?
Muda bastante. Com barra, o nginx remove o prefixo do location antes de repassar; sem barra, o caminho vai inteiro. Com location /, a diferença é quase nula, mas em location /api/ é exatamente o que gera 404 no backend.

Ferramentas Relacionadas