Skip to content

Testador de nginx location — por que esse bloco vence

Qual bloco location do nginx vence — e por que os outros perderam. Testador gratuito para =, ^~, ~ e ~*, tudo no seu navegador.

Sem rastreamento Roda no navegador Grátis
Sua configuração é interpretada localmente no navegador e nunca é enviada. Configurações de servidor carregam hostnames de upstream e blocos de autenticação, então abra o painel Network e veja-o permanecer em silêncio — ou fique offline de vez.
Teste uma configuração errada real
Location selecionado
~* \.(gif|jpg|jpeg)$

Primeiro regex, na ordem da configuração, que casou. O comprimento é irrelevante.

Contra o que o nginx realmente compara
Alvo da requisição
/documents/1.jpg
$uri normalizado
/documents/1.jpg
Query string $args
—

A correspondência roda apenas contra o caminho normalizado. A query string é separada antes e não participa de nada.

Por que esse bloco venceu
Por que esse bloco venceu
Linha location Etapa Resultado Motivo
2 = / Exato Não casou Um location = exige que a URI inteira seja igual, não que comece com ela.
3 / Prefixo Casou, mas é mais curto Ele casa, mas outro prefixo casou mais caracteres.
4 /documents/ Prefixo Casou, mas é mais curto Ele casa, mas outro prefixo casou mais caracteres.
5 ^~ /images/ Prefixo Não casou A URI não começa com este prefixo.
6 ~* \.(gif|jpg|jpeg)$ Regex Selecionado Primeiro regex, na ordem da configuração, que casou. O comprimento é irrelevante.

Modificadores de location no nginx: =, ^~, ~ e ~* comparados

Modificadores de location no nginx: =, ^~, ~ e ~* comparados
Modificador Sintaxe Casa por Ordem Interrompe regex Uso típico
= location = /path Igualdade 1 Sim Caminhos quentes como / — a correspondência mais rápida possível.
^~ location ^~ /path Começa com 2 Sim Diretórios que nunca podem ser entregues a um regex, como os de upload.
~ location ~ regex Regex PCRE 3 Não Roteamento por extensão quando maiúsculas importam.
~* location ~* regex Regex PCRE 3 Não Roteamento por extensão quando maiúsculas não importam.
(nenhum) location /path Começa com 4 Não Roteamento geral por caminho.
@ location @name Só interno — Não Fallbacks de error_page e try_files.

A coluna de ordem não é um ranking simples. Um location de prefixo só interrompe a avaliação dos regex quando carrega ^~ e é ele próprio o casamento mais longo — que é exatamente por que um bloco ^~ às vezes parece não fazer nada.

Prioridade de location no nginx: a ordem de resolução

Prioridade de location no nginx: a ordem de resolução
# Etapa Encerra a busca O que acontece
1 Normalizar Não Decodificação de percentuais, resolução de . e .., barras repetidas colapsadas. A query string é separada aqui e nunca participa da correspondência.
2 Exato Sim location = /path, comparado por igualdade. Um acerto encerra a busca na hora.
3 Redirect automático Sim Um location de proxy cujo nome é a URI mais uma barra. O nginx responde 301 e nunca chega aos regex.
4 Prefixo Não Todo prefixo que casa é comparado e o mais longo é memorizado. A ordem na configuração é ignorada.
5 Aninhado Não O parser desce para dentro do prefixo vencedor. Um regex aninhado é testado antes do nível pai.
6 Regex Sim Os regex são testados na ordem da configuração e o primeiro que casar vence. Um regex mais longo ou mais específico escrito depois nunca roda.
7 Fallback Sim Nenhum regex casou, então é usado o prefixo memorizado antes.
A ordem de correspondência, o curto-circuito do ^~, a descida em locations aninhados, o comportamento de redirecionamento automático e a normalização de URI foram conferidos contra o próprio código-fonte do nginx e confirmados rodando as configurações no nginx 1.27.5. — Equipe de Engenharia da Go Tools · Jul 22, 2026

As regras de seleção desta página foram verificadas contra um nginx 1.27.5 em execução, em vez de tiradas de textos secundários, e o motor é coberto por testes unitários derivados dessas execuções.

Correspondência de location no nginx: respostas rápidas

O nginx processa locations de regex antes das de prefixo?

Não — os prefixos são verificados primeiro, mas um regex que casar ainda vence. O nginx verifica todos os locations de prefixo primeiro e memoriza o mais longo que casou, depois avalia os locations de regex na ordem em que aparecem no arquivo. Vence o primeiro regex que casar. Se nenhum regex casar, é usado o prefixo memorizado. A única exceção é ^~: quando o prefixo mais longo que casou o carrega, a fase de regex é pulada por inteiro.

A ordem dos blocos location importa no nginx?

Só para os locations de regex. Locations de prefixo — incluindo = e ^~ — são escolhidos pelo casamento mais longo, então a ordem deles no arquivo é irrelevante. Locations de regex são testados de cima para baixo e o primeiro que casar vence, então mover um bloco de regex muda qual deles roda. Um regex mais específico colocado abaixo de um mais amplo nunca é executado.

O que o modificador ^~ realmente faz?

Ele faz o nginx parar após o casamento de prefixo, em vez de aumentar a prioridade. Se o location de prefixo mais longo que casou carrega ^~, o nginx pula a fase de regex e usa aquele bloco. Ele não torna o prefixo mais longo nem o coloca acima de outros prefixos — apenas suprime a avaliação dos regex. É por isso que um bloco ^~ parece não fazer nada quando um prefixo simples mais longo também casa: é o mais longo que fica memorizado, e ele não suprime coisa alguma.

location /static é o mesmo que location /static/?

Não — /static também casa com /staticfoo. A correspondência por prefixo é uma comparação simples de string, não um limite de segmento de caminho, então location /static também serve /staticfiles e /static-backup. Em separado, quando /static/ é usado com proxy_pass, uma requisição para /static sem a barra final recebe um redirect 301 para /static/ antes de qualquer regex ser considerado.

O nginx decodifica %2F e colapsa barras duplas antes da correspondência?

Sim — a correspondência roda contra a URI normalizada, não contra a requisição bruta. O nginx decodifica %XX, resolve . e .. e comprime barras repetidas antes de escolher um location. Um %2F decodificado vira um separador de verdade e participa dessa resolução, então /a/b%2F..%2Fzz é comparado como /a/zz. A query string é separada antes de tudo e não participa da correspondência em momento algum.

O que é um bloco location do nginx?

Um bloco location diz ao nginx o que fazer com uma requisição cuja URI casa com um padrão. Um bloco server normalmente contém vários, e a parte interessante não é o que cada um faz, e sim qual deles o nginx escolhe — porque as regras de seleção não são as que a maioria das pessoas supõe.

Existem cinco formas. location = /path casa apenas quando a URI inteira é igual. location /path casa com qualquer URI que comece com aqueles caracteres. location ^~ /path é a mesma comparação de prefixo com um efeito extra. location ~ regex e location ~* regex aplicam um padrão PCRE, diferenciando e não diferenciando maiúsculas. location @name não participa da correspondência de URI de forma alguma e existe apenas como alvo de try_files e error_page.

A seleção roda em etapas. Primeiro a URI é normalizada: percentuais decodificados, . e .. resolvidos, barras repetidas colapsadas, query string separada. Depois, um location = igual à URI encerra a busca imediatamente. Em seguida todos os prefixos que casaram são comparados e o mais longo é memorizado — a ordem na configuração não tem papel nenhum aqui. Se o prefixo memorizado carrega ^~, o nginx para e usa esse bloco. Caso contrário, os locations de regex são testados na ordem em que aparecem no arquivo, e vence o primeiro que casar, por mais específico que um posterior possa ser. Se nenhum casar, é usado o prefixo memorizado.

Duas dessas regras puxam em direções opostas, e é aí que mora a confusão: prefixos são escolhidos por comprimento, independentemente da ordem; regex, por ordem, independentemente do comprimento. Uma configuração que se lê corretamente de cima para baixo ainda pode rotear uma requisição para onde você não pretendia, e nenhuma releitura revela isso. Esta página reproduz a sequência inteira contra a sua própria configuração e mostra onde cada bloco caiu fora.

# From the nginx documentation. Which block serves each request?
server {
    location = /                   { }   # A
    location /                     { }   # B
    location /documents/           { }   # C
    location ^~ /images/           { }   # D
    location ~* \.(gif|jpg|jpeg)$  { }   # E
}

#   /                        -> A   exact match, search ends here
#   /index.html              -> B   no regex matched, longest prefix used
#   /documents/document.html -> C   longer prefix than B
#   /images/1.gif            -> D   ^~ won the prefix stage, regex skipped
#   /documents/1.jpg         -> E   regex beats the longer prefix C

# The last two lines are the whole lesson: identical-looking prefixes
# behave differently because only one of them carries ^~.

Recursos principais

Cada bloco perdedor, com a etapa em que foi eliminado

Cada location que você escreveu ganha uma linha: casou mas é mais curto, pulado porque um prefixo ^~ venceu, inalcançável porque um regex anterior casou, ou simplesmente não casou. Saber por que os outros perderam costuma ser o que de fato resolve a questão.

A cadeia de decisão de quatro etapas, reproduzida

Normalização, casamento exato, memória do prefixo mais longo, o curto-circuito do ^~, os regex na ordem do arquivo e o fallback aparecem como passos distintos contra a sua própria configuração, em vez de descritos no abstrato.

O curto-circuito do ^~ tornado visível

Quando um prefixo ^~ suprime a fase de regex, cada regex pulado é rotulado como pulado em vez de sumir sem aviso — e quando o ^~ deixa de valer porque um prefixo simples mais longo venceu, isso também é mostrado.

Locations aninhados resolvidos, não achatados

O nginx desce para dentro do prefixo vencedor e pesquisa os filhos dele, então um regex aninhado roda antes dos do nível pai. Blocos aninhados mantêm a indentação na tabela, para a estrutura continuar legível.

Sintaxe exclusiva do PCRE detectada de saída

Navegadores rodam regex ECMAScript, não PCRE. Grupos atômicos, quantificadores possessivos, classes POSIX e escapes como \A e \K são sinalizados em vez de avaliados errado em silêncio, para que uma resposta errada e confiante nunca seja apresentada como fato.

Nada é enviado — roda no seu navegador

Configurações de servidor carregam hostnames de upstream, portas internas e regras de autenticação. O parsing é trabalho simples de string, sem dependências e sem chamadas de rede, verificado por um teste de contrato automatizado a cada build.

Outras formas de responder a essa pergunta

nginx -T

Linha de comando

Despeja a configuração totalmente resolvida, o que é valiosíssimo para descobrir o que está de fato carregado. Não diz qual location uma dada URI seleciona — essa é a lacuna que esta página preenche.

error_log ... debug

Servidor em execução

A resposta mais autoritativa disponível: a linha "using configuration" nomeia o bloco que o nginx realmente escolheu. Exige root, um reload e um servidor acessível — então responde depois da implantação, não antes.

Verificadores de sintaxe de configuração

Serviço hospedado

Fortes em lint de arquivo inteiro e em regras de segurança. Em geral rodam no servidor, o que significa enviar uma configuração que contém hostnames internos e caminhos de certificado.

Ler a documentação

Referência

A documentação do nginx enuncia o algoritmo com precisão e vale ser lida uma vez. Aplicá-lo à mão a oito blocos e uma URI é onde os erros se infiltram, porque duas das regras apontam em direções opostas.

Exemplos de correspondência de location no nginx

Um regex vence um prefixo mais longo

location /documents/  ·  location ~* \.(gif|jpg|jpeg)$  ·  GET /documents/1.jpg
~* \.(gif|jpg|jpeg)$ wins

O prefixo /documents/ casa e é o prefixo mais longo do arquivo, então o nginx o memoriza — e mesmo assim avalia os regex, entregando a requisição ao primeiro que casar. O comprimento perde para a fase de regex. Se aquele prefixo tivesse sido escrito como ^~ /documents/, nenhum regex teria rodado. Este é o exemplo da documentação do nginx, e é o mais útil de internalizar.

O diretório de upload que executa PHP

location /uploads/  ·  location ~ \.php$ { fastcgi_pass ... }  ·  GET /uploads/evil.php
~ \.php$ wins — the upload lands in the interpreter

O prefixo /uploads/ casa, mas um prefixo simples não interrompe a fase de regex, então um arquivo enviado por alguém vai direto para o PHP-FPM. Escrever location ^~ /uploads/ curto-circuita a fase de regex e fecha a porta. Isso não é hipotético: é o formato por trás de uma longa série de relatos de upload-para-RCE, e a diferença entre vulnerável e seguro são dois caracteres.

^~ que silenciosamente não faz nada

location ^~ /a/  ·  location /a/b/  ·  location ~ \.php$  ·  GET /a/b/x.php
~ \.php$ wins — the ^~ never applied

O ^~ só suprime a fase de regex quando ele próprio é o prefixo mais longo entre os que casaram. Aqui /a/b/ é mais longo, então é ele que o nginx memoriza, e seu modificador simples deixa a fase de regex rodar. O bloco ^~ continua no arquivo, continua parecendo protetor e não tem efeito nenhum nesta requisição. Ler a configuração de cima para baixo não revela isso; comparar comprimentos de prefixo revela.

/static também captura /staticfoo

location /static  ·  location /static/  ·  GET /staticfoo
/static wins

A correspondência por prefixo compara caracteres, não segmentos de caminho. /staticfoo começa com /static, então casa, e /static/ não casa de jeito nenhum porque a URI não tem barra naquela posição. Qualquer coisa acessível sob um caminho que apenas comece com as mesmas letras é servida por aquele bloco — é assim que uma regra /static acaba servindo /static-backup.

Vence o primeiro regex, não o melhor

location ~ ^/a  ·  location ~ ^/a/b/c$  ·  GET /a/b/c
~ ^/a wins; ~ ^/a/b/c$ is unreachable

Os regex são avaliados na ordem em que aparecem no arquivo e o primeiro que casar encerra a busca. O segundo bloco é mais específico e casa exatamente com esta URI, e nunca vai rodar — para requisição nenhuma. Locations de prefixo são escolhidos por comprimento, independentemente da ordem; locations de regex são escolhidos por ordem, independentemente da especificidade. Confundir essas duas regras é o motivo habitual de uma regra "parar de funcionar" depois que alguém arrumou o arquivo.

A travessia codificada é resolvida antes da correspondência

location /a/  ·  location /b/  ·  GET /a/b%2F..%2Fzz
$uri becomes /a/zz, so /a/ wins

O nginx decodifica os percentuais, resolve . e .. e colapsa barras repetidas antes de consultar qualquer location. %2F decodifica para um separador de verdade e então participa dessa resolução, de modo que este alvo não fica dentro de /a/b/ — ele cai em /a/zz. Comparar contra o alvo que você digitou em vez do $uri normalizado dá a resposta errada aqui.

Como usar o testador de nginx location

  1. 1

    Cole o bloco server

    Jogue ali um bloco server inteiro, ou só os blocos location sobre os quais você está raciocinando. Locations aninhados são entendidos, e os números de linha originais são preservados para que a tabela bata com o seu arquivo.

  2. 2

    Informe a URI da requisição

    Digite o caminho como ele chega pela rede, incluindo qualquer codificação por percentual e a query string. As três linhas acima da tabela mostram como ele é normalizado antes da correspondência.

  3. 3

    Leia o vencedor e depois os perdedores

    O cartão de veredito nomeia o bloco selecionado e o motivo em uma linha. A tabela de decisão logo abaixo explica cada um dos outros blocos: em que etapa foi eliminado e por quê.

  4. 4

    Confira os diagnósticos

    Regex sem âncora, prefixos sem barra final, um ^~ carregando um padrão de regex, duplicatas inalcançáveis e diretórios de upload alcançáveis por um regex de PHP são todos reportados.

  5. 5

    Compartilhe o estado exato

    Copiar link codifica a configuração e a URI no fragmento da URL, para que um colega abra exatamente o que você está vendo. Fragmentos nunca são transmitidos a um servidor.

Erros comuns com location no nginx

Esperar que ^~ supere um prefixo mais longo

O ^~ só é consultado no prefixo que já venceu por comprimento. Um prefixo simples mais longo vence primeiro, e a fase de regex então roda como se o ^~ não existisse.

✗ Incorreto 
location ^~ /a/ { }
location /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ~ \.php$
✓ Correto 
location ^~ /a/ { }
location ^~ /a/b/ { }
location ~ \.php$ { }
# /a/b/x.php -> ^~ /a/b/

Um prefixo sem barra final pegando os irmãos

A correspondência por prefixo compara caracteres, e não segmentos de caminho, então o bloco também serve todo caminho irmão que comece com as mesmas letras.

✗ Incorreto 
location /static { root /var/www; }
# also serves /staticfoo and /static-backup
✓ Correto 
location /static/ { root /var/www; }
location = /static { return 301 /static/; }

Colocar o regex específico abaixo do amplo

Os regex são testados na ordem do arquivo e o primeiro que casar encerra a busca, então o bloco mais preciso nunca é executado, para requisição nenhuma.

✗ Incorreto 
location ~ ^/api { }
location ~ ^/api/v2/users$ { }
# the second is unreachable
✓ Correto 
location ~ ^/api/v2/users$ { }
location ~ ^/api { }

Escrever um regex depois de ^~

O ^~ recebe um prefixo literal. O nginx carrega o arquivo sem reclamar e o bloco simplesmente nunca casa com nada, o que torna o problema difícil de notar na revisão.

✗ Incorreto 
location ^~ "\.php$" { deny all; }
✓ Correto 
location ~ \.php$ { deny all; }

Supor que a query string participa da correspondência

A query string é separada durante a normalização, então um location nunca consegue casar por ela. Leia $arg_name dentro do bloco.

✗ Incorreto 
location /search?q= { }
# never matches anything
✓ Correto 
location /search {
    if ($arg_q = "") { return 400; }
}

O que dá para fazer com o testador de nginx location

Conferir uma configuração antes de ela chegar à produção
Raciocine sobre o roteamento de um bloco server que você editou mas ainda não implantou. A falha que isso pega é aquela que só aparece com um formato específico de URI, justamente o tipo que um smoke test após o reload costuma deixar passar.
Descobrir por que uma regra parou de funcionar
Um regex que rodava e agora não roda é quase sempre vítima da ordem: algo casou antes, ou um ^~ apareceu acima dele. A tabela marca o bloco como inalcançável e nomeia o bloco que ficou com a requisição.
Auditar um diretório de upload ou de mídia
Carregue o preset que reproduz o formato de upload-com-execução e depois cole os seus próprios caminhos. Se um regex de PHP estiver pegando requisições dentro de um diretório que aceita escrita, o diagnóstico diz isso e nomeia os dois blocos.
Encerrar um comentário de revisão com evidência
Copiar link captura a configuração e a URI exatas no fragmento da URL. Jogar isso num pull request substitui uma discussão sobre precedência por uma tabela de decisão que qualquer um pode reexecutar.
Ensinar o algoritmo de seleção
As duas tabelas de referência são material estático e rastreável para o qual você pode apontar, e os chips de preset demonstram cada armadilha sem precisar quebrar um servidor. O exemplo do ^~, em particular, costuma encerrar o debate rápido.

Como funciona a seleção de location no nginx

A normalização acontece antes de qualquer location ser consultado
A URI é decodificada dos percentuais, os segmentos . e .. são resolvidos e as barras repetidas são colapsadas, e só então um location é escolhido. Um %2F decodificado vira um separador de verdade e participa dessa resolução, então /a/b%2F..%2Fzz é comparado como /a/zz. Três caracteres decodificados são exceção e permanecem literais: %25, %23 e %3F — é por isso que /a%3Fx=1 tem uma interrogação no caminho e a query string vazia. Um + não é espaço aqui; só %20 é. Travessia acima da raiz e escape inválido são ambos rejeitados com 400 antes de a correspondência começar.
O comprimento do prefixo decide; a ordem na configuração, não
Todo location de prefixo que casa é comparado e o mais longo vence, apareça ele primeiro ou por último no arquivo. A comparação é por caracteres, não por segmentos de caminho, então /static casa com /staticfoo. O vencedor é memorizado em vez de usado na hora, porque a fase de regex ainda pode sobrepujá-lo.
^~ suprime os regex; ele não aumenta a prioridade
O modificador só é consultado no prefixo que já venceu por comprimento. Se um prefixo simples mais longo também casa, é ele que fica memorizado e a fase de regex roda normalmente — o bloco ^~ não tem efeito nenhum sobre a requisição. Colocar ^~ num location aninhado não protege contra um regex declarado no nível externo, e ele nunca suprime os regex aninhados dentro do próprio bloco.
Os regex rodam na ordem do arquivo e o primeiro que casar encerra a busca
O nginx mantém os locations de regex na ordem em que foram escritos e não os ordena. Especificidade, comprimento e ancoragem não influenciam qual é testado primeiro, então um padrão preciso colocado abaixo de um amplo é configuração morta. Um location de regex que casou também é percorrido por dentro, então os locations aninhados nele são pesquisados em seguida.
PCRE e ECMAScript não são a mesma linguagem
O nginx compila os regex de location com PCRE, sem modo UTF nem multilinha, então os padrões operam sobre bytes e ^ ancora apenas no início da URI. Uma diferença tem peso de segurança: o $ do PCRE também casa logo antes de uma quebra de linha final, então uma URI terminada em %0A ainda satisfaz \.php$ mesmo que um motor JavaScript recusasse. Esse comportamento é emulado aqui e reportado, porque é uma forma conhecida de escapar de regras baseadas na extensão do arquivo.

Boas práticas de location no nginx

Proteja diretórios com escrita usando ^~, não um prefixo simples
Todo diretório que aceita uploads precisa de location ^~ /uploads/ para que a fase de regex não consiga entregar um arquivo armazenado a um interpretador. Um prefixo simples parece equivalente e não é.
Dê barra final aos prefixos de diretório
Escreva location /static/ em vez de location /static, a menos que você queira deliberadamente que /staticfoo e /static-backup sejam servidos pelo mesmo bloco. Adicione um location = /static separado quando o caminho puro também precisar ser tratado.
Ordene os regex do mais específico ao menos específico
Vence o primeiro que casar, então um padrão amplo acima de um preciso torna o preciso inalcançável. Manter poucos regex e ordenados de propósito é mais fácil de manter do que raciocinar sobre sobreposição depois do fato.
Ancore os regex que devem casar um prefixo de caminho
location ~ /admin procura em qualquer ponto da URI e casa com /public/admin/x. Escreva ~ ^/admin quando você quer dizer o início. Ancorar só no final é normal e correto para roteamento por extensão.
Reconfira o roteamento depois de qualquer reordenação
Mover blocos é seguro para prefixos e muda o comportamento dos regex. Como um diff que só reordena linhas parece inofensivo na revisão, reexecutar as URIs afetadas é a forma mais barata de pegar isso.

Perguntas frequentes sobre o testador de nginx location

Como eu descubro qual location o nginx selecionou?
Cole a configuração e a URI da requisição neste testador para ver o bloco vencedor e por que cada um dos outros foi eliminado. Num servidor em execução, adicione error_log /var/log/nginx/debug.log debug; e procure a linha "using configuration", que nomeia o location selecionado. As duas abordagens respondem perguntas diferentes: o log conta o que um servidor ativo fez, e esta página conta o que uma configuração que você ainda não implantou faria.
Por que meu regex de location no nginx não funciona?
Normalmente por um de três motivos, e a tabela de decisão diz qual. Um regex anterior já casou, então o seu nunca rodou — os regex são testados na ordem do arquivo e o primeiro que casar vence. Ou o prefixo mais longo que casou carrega ^~, que pula a fase de regex por completo. Ou o regex está certo mas a URI não é o que você pensa: a correspondência roda contra o caminho normalizado, depois da decodificação de percentuais e da resolução de .., e com a query string removida.
Por que meu casamento exato não dispara?
Um location = exige que a URI inteira seja igual, não que ela comece com o padrão. location = /a/ não casa com /a, e location = /a não casa com /a/b. Barras finais são caracteres comuns aqui, então as duas formas são strings diferentes. Quando um location exato casa, a busca para na hora e nada mais chega a ser comparado.
O nginx compara a query string num bloco location?
Não. A query string é separada durante a normalização e a seleção de location roda só contra o caminho. É por isso que location = /a casa com uma requisição para /a?x=/b. Se você precisa ramificar por um parâmetro, tem que ler $arg_name ou $args dentro do bloco. Uma sutileza que vale conhecer: %3F decodifica para uma interrogação literal que permanece no caminho, então /a%3Fx=1 tem query string vazia e um caminho contendo ?.
Posso usar sintaxe de regex do JavaScript num location do nginx?
Não — o nginx usa PCRE, e as diferenças importam. Esta página roda no seu navegador, onde só existem expressões regulares ECMAScript, então construções exclusivas do PCRE são detectadas e sinalizadas em vez de avaliadas errado em silêncio: grupos atômicos, quantificadores possessivos, modificadores inline como (?i), classes POSIX como [[:alpha:]] e escapes como \A e \K, que o JavaScript lê discretamente como letras comuns. Quando um location é sinalizado, os candidatos restantes continuam sendo avaliados na ordem do nginx, mas o veredito daquele bloco precisa ser conferido num servidor real. Se você está escrevendo o próprio padrão, o testador de regex cobre a sintaxe ECMAScript a fundo.
Os casamentos de prefixo de location no nginx diferenciam maiúsculas de minúsculas?
No Linux, sim — location /Static/ não casa com /static/x. Em sistemas de arquivos que não diferenciam maiúsculas, como macOS e Cygwin, o nginx compara prefixos sem diferenciar e ainda força todo location de regex a se comportar como ~*. Esta página modela o comportamento do Linux, que é o que servidores de produção quase sempre rodam. Se você desenvolve no Mac e implanta no Linux, essa diferença pode esconder uma regra quebrada até ela subir.
O try_files muda qual bloco location foi selecionado?
Não. A seleção de location termina primeiro; o try_files roda depois, dentro do bloco que já venceu. Se uma requisição nunca chega ao bloco que contém o seu try_files, a diretiva é irrelevante — a causa habitual é um regex ~ \.php$ pegando a requisição antes que o bloco de prefixo com o fallback tenha chance de agir. Um redirecionamento interno emitido depois reinicia a correspondência, então uma URI reescrita é resolvida contra a lista de locations de novo, do começo.
Por que o nginx retorna 301 quando peço um diretório sem barra?
Dois mecanismos diferentes produzem isso. Se um location cujo nome termina em / carrega proxy_pass ou outra diretiva *_pass, uma requisição para o mesmo caminho sem a barra é respondida com 301 durante a seleção de location — antes de qualquer regex ser avaliado. Em separado, o módulo de arquivos estáticos emite um 301 quando o caminho resolve para um diretório real em disco. O primeiro é visível aqui; o segundo depende do seu sistema de arquivos. Adicionar location = /path suprime o primeiro.
Blocos location aninhados mudam o resultado?
Mudam, e de um jeito fácil de deixar passar. O nginx desce para dentro do location de prefixo vencedor e pesquisa os filhos dele, então um regex aninhado é testado antes dos regex do nível pai. Um ^~ no bloco externo não o protege dos regex aninhados dentro dele mesmo, e o aninhamento pode tornar inalcançável um prefixo globalmente mais longo quando um irmão do nível externo vence antes. Blocos aninhados são modelados aqui com a mesma indentação com que você os escreveu.
Minha configuração do nginx é enviada para algum lugar?
Não. O parsing e a correspondência acontecem localmente no seu navegador, com operações simples de string — não há chamada a servidor e nada é retido. Isso importa mais aqui do que na maioria das ferramentas, porque um bloco server real contém hostnames de upstream, portas internas, caminhos de certificado e regras de autenticação. Você não precisa acreditar na nossa palavra: abra as ferramentas de desenvolvedor do navegador e veja o painel Network permanecer em silêncio enquanto você digita, ou desconecte-se da rede e continue testando. A ausência de qualquer requisição externa também é garantida por um teste de contrato automatizado a cada build, então não dá para regredir sem alarde.

Ferramentas relacionadas

Ver todas as ferramentas →

Gerador e Construtor de Comandos cURL

Web & API

Monte comandos curl no navegador — defina método, cabeçalhos, autenticação e corpo, obtenha um comando pronto para copiar instantaneamente. Presets para Bearer, POST JSON e upload. Grátis, privado, sem cadastro.

Gerador htpasswd — bcrypt, Apache MD5 (apr1) e Basic Auth

Web & API

Gere entradas htpasswd com bcrypt, Apache MD5 (apr1), SHA-1 e mais. Obtenha configuracoes prontas para Apache, nginx e Docker. 100% no seu navegador — sem upload.

Gerador de Meta Tags e Open Graph

Web & API

Gere meta tags de Open Graph, Twitter Card e SEO com prévia ao vivo do Google, Facebook e X. 100% grátis, no navegador, sem cadastro — copie e cole o código.

Decodificador traceparent — W3C Trace Context

Web & API

Pare de contar dígitos hex. Decodificador traceparent grátis e online — roda no seu navegador, sem envio. Trace ID, span ID, 8 bits trace-flags, tracestate, Datadog/X-Ray/B3.

Ferramenta de Descriptografia AES — OpenSSL e CryptoJS

Ferramentas de Segurança

Descriptografe AES online — GCM/CBC/CTR, frase-senha ou chave bruta, detecta automaticamente o formato "U2FsdGVkX1" do OpenSSL e CryptoJS. 100% no navegador, as chaves nunca saem da página.

Ferramenta de Criptografia AES — GCM, CBC e CTR

Ferramentas de Segurança

Criptografia AES online e gratuita — AES-128/192/256, GCM/CBC/CTR, frase-senha (PBKDF2) ou chave bruta. Roda 100% no navegador; nada é enviado a um servidor.