# Reescritor de proxy_pass do NGINX

> Uma barra final decide se seu backend vê /app/page ou /page. Cole a diretiva e veja as duas respostas lado a lado.

- Tool: https://ronutz.com/pt-BR/tools/nginx-proxy-pass-rewriter
- Family: Redes

---

## O que esta ferramenta faz

Cole um `location`, seu `proxy_pass`, e uma URI de requisição. A ferramenta calcula o que o backend de fato recebe — e mostra a **mesma configuração com a barra final invertida**, para que a diferença seja visível em vez de descrita.

## A regra

`proxy_pass http://backend;` **não tem parte de URI**, então a URI original da requisição passa inalterada, prefixo do location incluído. `proxy_pass http://backend/;` **tem** parte de URI — mesmo essa barra única conta — então a parte da requisição que casa com o prefixo do location é **substituída** por ela.

Com `location /app/` e uma requisição para `/app/page`: a primeira forma envia `/app/page`, a segunda envia `/page`, e `proxy_pass http://backend/v2/;` envia `/v2/page`.

Qual você quer depende do backend. Uma aplicação montada no mesmo caminho precisa do prefixo mantido; uma que não sabe estar atrás de um prefixo precisa dele removido. Escolher errado produz um 404 do backend para uma requisição que o proxy tratou perfeitamente.

## A barra dobrada é real

Um location sem barra final somado a uma parte de URI envia uma barra genuinamente dobrada ao upstream — `location /app` com `proxy_pass http://backend/` transforma `/app/page` em `//page`. Esta ferramenta reproduz isso em vez de arrumar, porque uma resposta mais bonita que a do NGINX esconderia justamente o defeito que você veio procurar.

## O que ela recusa

Locations de expressão regular e nomeados não podem carregar parte de URI: não há prefixo literal a substituir, então o NGINX rejeita a configuração na inicialização. A ferramenta reporta isso em vez de inventar um resultado.

## A exceção da variável

Uma variável em qualquer ponto do valor suspende a substituição de prefixo por completo, e move a resolução do upstream para o tempo de requisição — o que normalmente exige um `resolver` e transforma uma falha de nome em erro de execução, e não num que o `nginx -t` pegaria.

## Limites honestos

Sem `rewrite`, `try_files` ou redirecionamentos internos: isto responde qual caminho o backend recebe, não o que a requisição inteira faz. Blocos upstream não são resolvidos em servidores, e query strings passam sem serem modeladas.

## Standards and references

- [NGINX documentation: ngx_http_proxy_module, proxy_pass directive](https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass) - URI-part semantics: with a URI the matched location prefix is replaced; without one the original request URI is passed; the regex/named-location restriction; variable handling

## Related reading

- [A barra final do proxy_pass no NGINX: um caractere que decide o que seu backend recebe](https://ronutz.com/pt-BR/learn/nginx-proxy-pass-uri-rewriting.md): proxy_pass com uma parte de URI substitui o prefixo do location que casou. Sem ela, a URI original da requisição passa direto. Essa é a regra inteira, é um interruptor binário e não uma questão de grau, e uma única barra basta para virá-lo.
- [Cache no NGINX: o que é armazenado, o que é servido, e a brecha por onde dados de usuário vazam](https://ronutz.com/pt-BR/learn/nginx-proxy-cache-what-gets-stored.md): Se uma resposta é armazenada e se uma requisição posterior é servida a partir dela são perguntas diferentes com respostas diferentes. O NGINX protege você de cachear uma resposta com cookie, e não protege de servir uma resposta cacheada a uma requisição com cookie. Essa assimetria é por onde um usuário recebe a página de outro.