Testador de prioridade e simulador de correspondência do Nginx Location

Testador de prioridade e simulador de correspondência do Nginx Location

Simulador interativo do núcleo C

Guia técnico para teste de correspondência de blocos location no Nginx e avaliação de precedência de modificadores.

Predefinições:
Simulador de URI de requisição em tempo real
CORRESPONDÊNCIA:location ^~ /static/(0.38ms)
GET
Testes rápidos:
#1
log_not_found off; ...Exact match bypasses all other rules instantly
#2
VENCEDOR
alias /var/www/spa/static/; ...Preferential prefix: Skips all regex tests for static build assets
#3
expires 7d; ...Regex for root-level and un-prefixed media assets
#4
proxy_pass http://backend_upstream; ...Preferential prefix: Directs all /api/ endpoints to backend
#5
root /var/www/spa/dist; ...Catch-all fallback prefix for client-side HTML5 history routing
CORRESPONDÊNCIA RESOLVIDA EM 0.38msHTTP 200 PROCESSADO
location ^~ /static/
Fase 2: Prefixo preferencial (^~)

O prefixo correspondente mais longo possui o modificador "^~". A avaliação de regex foi completamente ignorada.

Finalidade: Preferential prefix: Skips all regex tests for static build assets

Diretivas ativas executadas:
alias /var/www/spa/static/;
expires 365d;
add_header Cache-Control "public, immutable";

Rastreamento passo a passo da avaliação (6 passos)

Avaliado em fases estritamente ordenadas conforme a RFC
Normalização e extração de URInormalization

Codificação percentual decodificada, barras redundantes mescladas e query string separada.

Request URI: "/static/css/bundle.css"
Normalized:  "/static/css/bundle.css"
Query:       ""
Tier 1: Exata (= /favicon.ico)exact

URI "/static/css/bundle.css" != "/favicon.ico".

Prefixo padrão: ^~ /static/ [8]prefix scan

URI begins with prefix "/static/" (length 8).

Prefixo padrão: ^~ /api/prefix scan

URI "/static/css/bundle.css" does not start with "/api/".

Prefixo padrão: (standard) / [1]prefix scan

URI begins with prefix "/" (length 1).

Tier 2: Prefixo sem RegEx (^~ /static/)preferential check

O prefixo correspondente mais longo possui o modificador "^~". A avaliação de regex foi completamente ignorada.

location ^~ /static/ {
  alias /var/www/spa/static/;
  expires 365d;
  add_header Cache-Control "public, immutable";
}

Fidelidade ao algoritmo do núcleo do Nginx e RFC

Simula com exatidão a mecânica do núcleo C do Nginx: = correspondência exata, ^~ prefixo preferencial, ordem de aparição de regex e fallback para o prefixo padrão mais longo.

Zero envio para servidor e latência zero

Toda a normalização de URI, processamento de expressões regulares e ordenação de prioridade ocorrem 100% na memória do navegador sem sobrecarga de rede.

Geração de configuração para produção

Exporte instantaneamente blocos de configuração do Nginx limpos e validados com comentários explicativos e comandos cURL de diagnóstico.

Referência técnica e guia de arquitetura

Referência de Desenvolvedor para Nginx Location Match Tester — Guia de referência

Guia técnico para teste de correspondência de blocos location no Nginx e avaliação de precedência de modificadores.

Parâmetros principais e controles

uristring

Caminho URI da requisição (excluindo protocolo e domínio) avaliado contra os blocos location configurados.

Padrão: "/"
modifier'=' | '^~' | '~' | '~*' | ''

Modificador de prefixo de location do Nginx que controla a prioridade de avaliação, bypass de regex e encerramento antecipado.

Padrão: ""
pathstring

Padrão de prefixo de URI ou expressão regular compatível com PCRE testada contra a URI normalizada.

Padrão: "/"
outputTab'trace' | 'batch' | 'ladder' | 'conf'

Aba ativa para inspeção de rastreamento passo a passo, asserções em lote, escada de prioridades ou configuração nginx.conf.

Padrão: "trace"
inputMode'visual' | 'raw'

Modo de entrada alternando entre edição visual por cartões interativos e análise textual direta de sintaxe nginx.conf.

Padrão: "visual"

Dicas profissionais e melhores práticas

Usar ^~ para assets estáticos

O modificador location ^~ /static/ impede varreduras caras de regex ao servir arquivos estáticos, contornando diretivas subsequentes como ~* \.(jpg|png|css)$.

Ordenar regex por frequência

Como o Nginx encerra a checagem de regex no primeiro bloco ~ ou ~* correspondente na ordem do arquivo, posicione as regras de maior tráfego no topo.

Match exato na rota raiz

Definir location = / otimiza o ciclo de processamento da página inicial em proxies reversos de alta carga, eliminando buscas completas na árvore de prefixos.

Testar URIs normalizadas

O Nginx decodifica percent-encoding como %20 e consolida barras consecutivas // antes do match. Valide sempre formatos originais e codificados.

Problemas comuns e solução de problemas

Bloco de regex location sobrescreve inesperadamente um bloco de prefixo mais longo

Prefixos sem ^~ funcionam apenas como fallback caso nenhuma regex coincida. Adicione o modificador ^~ ao bloco de prefixo ou reordene as regras de regex.

Parâmetros de query string na URI de teste não correspondem ao caminho da location

O Nginx avalia locations estritamente contra $uri, descartando a query string ($args). Utilize map ou if ($arg_name) para avaliar parâmetros em vez de locations.

Regex sensível a maiúsculas ~ falha em arquivos com extensões em maiúsculas

Substitua o modificador ~ por ~* para habilitar correspondência case-insensitive, permitindo tratar arquivos como .JPG e .jpg uniformemente.

Perguntas frequentes (FAQ)

Qual é a ordem exata de prioridade entre os modificadores de location do Nginx?▼

O Nginx avalia as locations em 5 fases: 1) Match exato (=) encerra imediatamente se correspondido; 2) Busca pelo prefixo mais longo em blocos convencionais; 3) Se o prefixo mais longo contiver ^~, a avaliação de regex é ignorada e ele vence; 4) Expressões regulares (~ e ~*) são avaliadas de cima para baixo na ordem do arquivo (a primeira vence); 5) Se nenhuma regex coincidir, vence o prefixo mais longo da fase 2.

Como o Nginx normaliza as URIs de requisição antes de testar os blocos location?▼

Antes da comparação, o Nginx decodifica caracteres codificados em porcentagem (%20 para espaço, %2F para /), resolve referências relativas . e .., e comprime barras múltiplas consecutivas (//) em uma única barra. Parâmetros após ? são isolados em $query_string.

Por que a diretiva location não aceita parâmetros de query string ou identificadores de fragmento?▼

Conforme a RFC 3986, caminho e query são componentes distintos. O Nginx restringe a diretiva location estritamente ao caminho do recurso. Para rotear requisições com base em parâmetros de query, utilize as variáveis $args ou $arg_<nome> com map ou regras de reescrita.

A ordem física dos blocos location de prefixo no nginx.conf altera o roteamento?▼

Não. Ao contrário dos blocos de expressão regular (~ e ~*), os blocos de prefixo padrão ("") e ^~ são organizados internamente pelo Nginx em uma árvore e sempre selecionam a correspondência de prefixo mais longa, independentemente de sua ordem no arquivo.

As configurações inseridas ou os casos de teste são enviados para servidores externos?▼

Não. Todo o processo de normalização de URI, verificação de correspondência de locations, execução de testes em lote e exportação de configuração ocorre 100% no cliente via motor JavaScript do navegador.

Ferramentas e utilitários relacionados

Todas as ferramentas →