Skip to content

Tester nginx location — perché vince quel blocco

Scopri quale blocco location di nginx vince e perché gli altri perdono. Tester online gratuito per =, ^~, ~ e ~*, tutto dentro il browser.

Niente tracciamento Funziona nel browser Gratuito
La tua configurazione viene analizzata in locale nel browser e non viene mai caricata. Le configurazioni dei server contengono hostname di upstream e blocchi di autenticazione: apri il pannello Network e guardalo restare in silenzio, oppure vai del tutto offline.
Prova una configurazione sbagliata reale
Location selezionata
~* \.(gif|jpg|jpeg)$

Prima regex nell'ordine della configurazione che ha corrisposto. La lunghezza è irrilevante.

Su che cosa nginx confronta davvero
Target della richiesta
/documents/1.jpg
$uri normalizzato
/documents/1.jpg
Query string $args
—

La corrispondenza gira solo sul percorso normalizzato. La query string viene separata prima e non partecipa mai.

Perché ha vinto quel blocco
Perché ha vinto quel blocco
Riga location Fase Esito Motivo
2 = / Esatta Nessuna corrispondenza Una location = richiede che l'intero URI sia uguale, non che inizi con esso.
3 / Prefisso Corrisponde ma è più corta Corrisponde, ma un altro prefisso ha coperto più caratteri.
4 /documents/ Prefisso Corrisponde ma è più corta Corrisponde, ma un altro prefisso ha coperto più caratteri.
5 ^~ /images/ Prefisso Nessuna corrispondenza L'URI non inizia con questo prefisso.
6 ~* \.(gif|jpg|jpeg)$ Regex Selezionata Prima regex nell'ordine della configurazione che ha corrisposto. La lunghezza è irrilevante.

Modificatori delle location nginx: =, ^~, ~ e ~* a confronto

Modificatori delle location nginx: =, ^~, ~ e ~* a confronto
Modificatore Sintassi Corrisponde per Ordine Ferma le regex Uso tipico
= location = /path Uguaglianza 1 Sì Percorsi caldi come / — la corrispondenza più veloce possibile.
^~ location ^~ /path Inizia con 2 Sì Directory che non devono mai finire a una regex, come quelle di upload.
~ location ~ regex Regex PCRE 3 No Instradamento per estensione quando le maiuscole contano.
~* location ~* regex Regex PCRE 3 No Instradamento per estensione quando le maiuscole non contano.
(nessuno) location /path Inizia con 4 No Instradamento generico per percorso.
@ location @name Solo interna — No Fallback di error_page e try_files.

La colonna dell'ordine non è una classifica semplice. Una location a prefisso ferma la valutazione delle regex solo quando porta ^~ ed è essa stessa la corrispondenza più lunga — ed è esattamente per questo che a volte un blocco ^~ sembra non fare nulla.

Priorità delle location nginx: l'ordine di risoluzione

Priorità delle location nginx: l'ordine di risoluzione
# Fase Chiude la ricerca Che cosa succede
1 Normalizzazione No Decodifica delle percentuali, risoluzione di . e .., barre ripetute compresse. Qui la query string viene separata e non partecipa mai alla corrispondenza.
2 Esatta Sì location = /path, confrontata per uguaglianza. Un successo chiude subito la ricerca.
3 Redirect automatico Sì Una location di proxy il cui nome è l'URI più una barra. nginx risponde 301 e non arriva mai alle regex.
4 Prefisso No Ogni prefisso corrispondente viene confrontato e viene ricordato il più lungo. L'ordine nella configurazione è ignorato.
5 Annidata No Si scende dentro il prefisso vincente. Una regex annidata viene provata prima del livello superiore.
6 Regex Sì Le regex si provano nell'ordine della configurazione e vince la prima corrispondenza. Una regex più lunga o più specifica scritta dopo non viene mai eseguita.
7 Fallback Sì Nessuna regex ha corrisposto, quindi si usa il prefisso ricordato prima.
L'ordine di corrispondenza, il cortocircuito di ^~, la discesa nelle location annidate, il comportamento del redirect automatico e la normalizzazione dell'URI sono stati confrontati con il codice sorgente di nginx e confermati eseguendo le configurazioni su nginx 1.27.5. — Team di Ingegneria Go Tools · Jul 22, 2026

Le regole di selezione di questa pagina sono state verificate su un nginx 1.27.5 in esecuzione, invece che riprese da articoli di seconda mano, e il motore è coperto da test unitari derivati da quelle esecuzioni.

Corrispondenza delle location nginx: risposte rapide

nginx elabora le location a regex prima di quelle a prefisso?

No — i prefissi si controllano per primi, ma una regex che corrisponde vince comunque. nginx controlla prima tutte le location a prefisso e ricorda la corrispondenza più lunga, poi valuta le location a espressione regolare nell'ordine in cui compaiono nel file. Vince la prima regex che corrisponde. Se nessuna corrisponde, si usa il prefisso ricordato. L'unica eccezione è ^~: se il prefisso corrispondente più lungo lo porta, la fase delle regex viene saltata del tutto.

L'ordine dei blocchi location conta in nginx?

Solo per le location a espressione regolare. Le location a prefisso — comprese = e ^~ — si selezionano per corrispondenza più lunga, quindi il loro ordine nel file è irrilevante. Le location a regex si provano dall'alto in basso e vince la prima corrispondenza, quindi spostare un blocco regex cambia quale viene eseguito. Una regex più specifica messa sotto a una più ampia non viene mai eseguita.

Che cosa fa davvero il modificatore ^~?

Ferma nginx dopo la corrispondenza di prefisso, invece di alzare la priorità. Se la location a prefisso corrispondente più lunga porta ^~, nginx salta la fase delle regex e usa quel blocco. Non rende il prefisso più lungo né lo mette sopra agli altri prefissi — sopprime soltanto la valutazione delle espressioni regolari. Ecco perché un blocco ^~ sembra non fare nulla quando corrisponde anche un prefisso semplice più lungo: viene ricordato quello più lungo, e quello non sopprime niente.

location /static è la stessa cosa di location /static/?

No — /static corrisponde anche a /staticfoo. La corrispondenza per prefisso è un semplice confronto di stringhe, non un confine tra segmenti di percorso, quindi location /static serve anche /staticfiles e /static-backup. A parte questo, quando /static/ è usato con proxy_pass, una richiesta a /static senza barra finale riceve un redirect 301 verso /static/ prima che venga considerata qualsiasi regex.

nginx decodifica %2F e comprime le doppie barre prima della corrispondenza?

Sì — la corrispondenza gira sull'URI normalizzato, non sulla richiesta grezza. nginx decodifica %XX, risolve . e .. e comprime le barre ripetute prima di selezionare una location. Un %2F decodificato diventa un separatore vero e partecipa a quella risoluzione, quindi /a/b%2F..%2Fzz viene confrontato come /a/zz. La query string viene separata per prima e non partecipa mai alla corrispondenza.

Che cos'è un blocco location di nginx?

Un blocco location dice a nginx che cosa fare con una richiesta il cui URI corrisponde a un pattern. Un blocco server ne contiene di solito parecchi, e la parte interessante non è che cosa fa ciascuno ma quale sceglie nginx — perché le regole di selezione non sono quelle che quasi tutti danno per scontate.

Le forme sono cinque. location = /path corrisponde solo quando l'intero URI è uguale. location /path corrisponde a qualsiasi URI che inizi con quei caratteri. location ^~ /path è lo stesso confronto di prefisso con un effetto in più. location ~ regex e location ~* regex applicano un pattern PCRE, distinguendo e non distinguendo maiuscole e minuscole. location @name non partecipa affatto alla corrispondenza dell'URI ed esiste solo come destinazione di try_files ed error_page.

La selezione procede per fasi. Prima l'URI viene normalizzato: percentuali decodificate, . e .. risolti, barre ripetute compresse, query string separata. Poi una location = uguale all'URI chiude subito la ricerca. Poi tutti i prefissi corrispondenti vengono confrontati e viene ricordato il più lungo — qui l'ordine nella configurazione non ha alcun ruolo. Se il prefisso ricordato porta ^~, nginx si ferma e usa quello. Altrimenti le location a espressione regolare vengono provate nell'ordine in cui compaiono nel file, e vince la prima corrispondenza, per quanto specifica possa essere una successiva. Se nessuna corrisponde, si usa il prefisso ricordato.

Due di queste regole tirano in direzioni opposte, ed è lì che vive la confusione: i prefissi si scelgono per lunghezza a prescindere dall'ordine, le regex per ordine a prescindere dalla lunghezza. Una configurazione che si legge correttamente dall'alto in basso può comunque instradare una richiesta dove non volevi, e nessuna rilettura lo rivela. Questa pagina ripercorre l'intera sequenza sulla tua configurazione e mostra dove ogni blocco è uscito di scena.

# 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 ^~.

Caratteristiche principali

Ogni blocco perdente, con la fase in cui è stato eliminato

Ogni location che hai scritto ottiene una riga: ha corrisposto ma è più corta, saltata perché ha vinto un prefisso ^~, irraggiungibile perché una regex precedente ha corrisposto, oppure semplicemente nessuna corrispondenza. Sapere perché hanno perso gli altri è di solito ciò che risolve davvero la questione.

La catena decisionale in quattro fasi, ripercorsa

Normalizzazione, corrispondenza esatta, memoria del prefisso più lungo, il cortocircuito di ^~, le regex nell'ordine del file e il fallback compaiono come passi distinti sulla tua configurazione, invece che descritti in astratto.

Il cortocircuito di ^~ reso visibile

Quando un prefisso ^~ sopprime la fase delle regex, ogni regex saltata viene etichettata come saltata invece di sparire in silenzio — e quando il ^~ non si applica perché ha vinto un prefisso semplice più lungo, viene mostrato anche quello.

Location annidate risolte, non appiattite

nginx scende dentro il prefisso vincente e cerca tra i suoi figli, quindi una regex annidata viene eseguita prima di quelle del livello superiore. I blocchi annidati mantengono la loro indentazione nella tabella, così la struttura resta leggibile.

Sintassi esclusiva di PCRE rilevata subito

I browser eseguono regex ECMAScript, non PCRE. Gruppi atomici, quantificatori possessivi, classi POSIX ed escape come \A e \K vengono segnalati invece che valutati male in silenzio, così una risposta sbagliata e sicura di sé non viene mai presentata come un dato di fatto.

Niente viene caricato — gira nel tuo browser

Le configurazioni dei server contengono hostname di upstream, porte interne e regole di autenticazione. Il parsing è semplice lavoro su stringhe, senza dipendenze e senza chiamate di rete, verificato da un test di contratto automatico a ogni build.

Altri modi per rispondere a questa domanda

nginx -T

Riga di comando

Stampa la configurazione completamente risolta, il che è prezioso per capire che cosa è davvero caricato. Non dice quale location viene selezionata da un dato URI — è la lacuna che questa pagina colma.

error_log ... debug

Server in esecuzione

La risposta più autorevole disponibile: la riga "using configuration" nomina il blocco che nginx ha davvero scelto. Richiede root, un reload e un server raggiungibile — quindi risponde dopo il rilascio, non prima.

Verificatori di sintassi della configurazione

Servizio ospitato

Ottimi per il lint dell'intero file e per le regole di sicurezza. In genere girano lato server, il che significa caricare una configurazione che contiene hostname interni e percorsi dei certificati.

Leggere la documentazione

Riferimento

La documentazione di nginx enuncia l'algoritmo con precisione e vale la pena leggerla una volta. Applicarlo a mano a otto blocchi e a un URI è dove si insinuano gli errori, perché due delle regole puntano in direzioni opposte.

Esempi di corrispondenza delle location nginx

Un'espressione regolare batte un prefisso più lungo

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

Il prefisso /documents/ corrisponde ed è il prefisso più lungo del file, quindi nginx se lo ricorda — poi valuta comunque le espressioni regolari e consegna la richiesta alla prima che corrisponde. La lunghezza perde contro la fase delle regex. Se quel prefisso fosse stato scritto ^~ /documents/, nessuna regex sarebbe stata eseguita. Questo è l'esempio della documentazione di nginx, ed è il singolo caso più utile da interiorizzare.

La directory di upload che esegue PHP

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

Il prefisso /uploads/ corrisponde, ma un prefisso semplice non ferma la fase delle regex, quindi un file caricato da qualcuno finisce dritto in PHP-FPM. Scrivere location ^~ /uploads/ cortocircuita la fase delle regex e chiude la porta. Non è un caso teorico: è la forma dietro una lunga serie di segnalazioni upload-to-RCE, e la differenza tra vulnerabile e sicuro sono due caratteri.

Un ^~ che in silenzio non fa nulla

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

^~ sopprime la fase delle regex solo quando è esso stesso il prefisso corrispondente più lungo. Qui /a/b/ è più lungo, quindi è quello che nginx ricorda, e il suo modificatore semplice lascia girare la fase delle regex. Il blocco ^~ è ancora nel file, sembra ancora protettivo e non ha alcun effetto su questa richiesta. Leggere una configurazione dall'alto in basso non lo rivela; confrontare le lunghezze dei prefissi sì.

/static cattura anche /staticfoo

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

La corrispondenza per prefisso confronta caratteri, non segmenti di percorso. /staticfoo inizia con /static, quindi corrisponde, e /static/ non corrisponde affatto perché l'URI non ha una barra in quella posizione. Tutto ciò che è raggiungibile sotto un percorso che semplicemente inizia con le stesse lettere viene servito da quel blocco — ed è così che una regola /static finisce per servire /static-backup.

Vince la prima espressione regolare, non la migliore

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

Le espressioni regolari sono valutate nell'ordine in cui compaiono nel file e la prima corrispondenza chiude la ricerca. Il secondo blocco è più specifico e corrisponde esattamente a questo URI, e non verrà mai eseguito — per nessuna richiesta. Le location a prefisso si scelgono per lunghezza a prescindere dall'ordine; quelle a regex si scelgono per ordine a prescindere dalla specificità. Confondere queste due regole è il motivo abituale per cui una regola "smette di funzionare" dopo che qualcuno ha riordinato il file.

Il traversal codificato si risolve prima della corrispondenza

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

nginx decodifica le percentuali, risolve . e .. e comprime le barre ripetute prima di consultare qualsiasi location. %2F si decodifica in un separatore vero e proprio e poi partecipa a quella risoluzione, quindi questo target non resta dentro /a/b/ — finisce su /a/zz. Confrontare il target che hai digitato invece del $uri normalizzato qui dà la risposta sbagliata.

Come usare il tester delle location nginx

  1. 1

    Incolla il blocco server

    Butta dentro un blocco server intero, o solo i blocchi location su cui stai ragionando. Le location annidate vengono comprese e i numeri di riga originali sono mantenuti, così la tabella combacia con il tuo file.

  2. 2

    Inserisci l'URI della richiesta

    Scrivi il percorso così come arriva sul filo, comprese le codifiche percentuali e la query string. Le tre righe sopra la tabella mostrano come viene normalizzato prima della corrispondenza.

  3. 3

    Leggi il vincitore, poi i perdenti

    La scheda del verdetto nomina il blocco selezionato e il motivo in una riga. La tabella delle decisioni sotto spiega ogni altro blocco: in quale fase è stato eliminato e perché.

  4. 4

    Controlla la diagnostica

    Regex senza ancoraggio, prefissi senza barra finale, un ^~ che porta un pattern regex, duplicati irraggiungibili e directory di upload raggiungibili da una regex PHP vengono tutti segnalati.

  5. 5

    Condividi lo stato esatto

    Copia link codifica la configurazione e l'URI nel frammento dell'URL, così un collega apre esattamente quello che stai guardando. I frammenti non vengono mai trasmessi a un server.

Errori comuni con le location nginx

Aspettarsi che ^~ superi un prefisso più lungo

^~ viene consultato solo sul prefisso che ha già vinto sulla lunghezza. Un prefisso semplice più lungo vince per primo, e la fase delle regex parte come se il ^~ non ci fosse.

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

Un prefisso senza barra finale che cattura i fratelli

La corrispondenza per prefisso confronta caratteri e non segmenti di percorso, quindi il blocco serve anche ogni percorso fratello che inizia con le stesse lettere.

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

Mettere la regex specifica sotto a quella ampia

Le regex si provano nell'ordine del file e la prima corrispondenza chiude la ricerca, quindi il blocco più preciso non viene mai eseguito, per nessuna richiesta.

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

Scrivere una regex dopo ^~

^~ prende un prefisso letterale. nginx carica il file senza protestare e il blocco semplicemente non corrisponde mai a nulla, il che lo rende difficile da notare in review.

✗ Errato 
location ^~ "\.php$" { deny all; }
✓ Corretto 
location ~ \.php$ { deny all; }

Dare per scontato che la query string partecipi alla corrispondenza

La query string viene separata durante la normalizzazione, quindi una location non può mai corrispondere su di essa. Leggi $arg_name dentro il blocco.

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

Che cosa puoi fare con il tester delle location nginx

Controllare una configurazione prima che arrivi in produzione
Ragiona sull'instradamento di un blocco server che hai modificato ma non ancora rilasciato. Il guasto che intercetta è quello che si manifesta solo con una certa forma di URI, esattamente il tipo che uno smoke test dopo il reload tende a mancare.
Scoprire perché una regola ha smesso di funzionare
Una regex che prima girava e ora no è quasi sempre vittima dell'ordine: qualcosa ha corrisposto prima, oppure sopra è comparso un ^~. La tabella marca il blocco come irraggiungibile e nomina il blocco che si è preso la richiesta.
Verificare una directory di upload o di media
Carica il preset che riproduce lo schema upload-esecuzione, poi incolla i tuoi percorsi. Se una regex PHP sta prendendo le richieste dentro una directory che accetta scritture, la diagnostica lo dice e nomina entrambi i blocchi.
Chiudere un commento di review con una prova
Copia link cattura la configurazione e l'URI esatti nel frammento dell'URL. Metterlo in una pull request sostituisce una discussione sulla precedenza con una tabella decisionale che chiunque può rieseguire.
Insegnare l'algoritmo di selezione
Le due tabelle di riferimento sono materiale statico e indicizzabile a cui puoi rimandare, e i chip preimpostati mostrano ogni trappola senza bisogno di rompere un server. L'esempio del ^~ in particolare tende a chiudere il dibattito in fretta.

Come funziona la selezione delle location in nginx

La normalizzazione avviene prima di consultare qualsiasi location
L'URI viene decodificato dalle percentuali, i segmenti . e .. vengono risolti e le barre ripetute vengono compresse, e solo allora si sceglie una location. Un %2F decodificato diventa un separatore vero e partecipa a quella risoluzione, quindi /a/b%2F..%2Fzz viene confrontato come /a/zz. Tre caratteri decodificati fanno eccezione e restano letterali: %25, %23 e %3F — ecco perché /a%3Fx=1 ha un punto interrogativo nel percorso e la query string vuota. Qui un + non è uno spazio; solo %20 lo è. Il traversal sopra la radice e un escape non valido vengono entrambi respinti con 400 prima che la corrispondenza inizi.
Decide la lunghezza del prefisso, non l'ordine nella configurazione
Ogni location a prefisso che corrisponde viene confrontata e vince la più lunga, che compaia per prima o per ultima nel file. Il confronto è per caratteri, non per segmenti di percorso, quindi /static corrisponde a /staticfoo. Il vincitore viene ricordato invece che usato subito, perché la fase delle regex può ancora scavalcarlo.
^~ sopprime le regex; non alza la priorità
Il modificatore viene controllato solo sul prefisso che ha già vinto sulla lunghezza. Se corrisponde anche un prefisso semplice più lungo, viene ricordato quello e la fase delle regex parte come sempre — il blocco ^~ non ha alcun effetto sulla richiesta. Mettere ^~ su una location annidata non protegge da una regex dichiarata al livello esterno, e non sopprime mai le regex annidate dentro il blocco stesso.
Le regex girano nell'ordine del file e la prima corrispondenza chiude la ricerca
nginx tiene le location a regex nell'ordine in cui sono state scritte e non le riordina. Specificità, lunghezza e ancoraggio non influiscono su quale viene provata per prima, quindi un pattern preciso messo sotto a uno ampio è configurazione morta. In una location a regex che ha corrisposto si scende comunque, quindi le sue location annidate vengono cercate subito dopo.
PCRE ed ECMAScript non sono lo stesso linguaggio
nginx compila le regex delle location con PCRE, senza modalità UTF né multiriga, quindi i pattern lavorano sui byte e ^ si ancora solo all'inizio dell'URI. Una differenza ha peso di sicurezza: il $ di PCRE corrisponde anche subito prima di un a capo finale, quindi un URI che termina con %0A soddisfa comunque \.php$ anche se un motore JavaScript lo rifiuterebbe. Questo comportamento è emulato qui e segnalato, perché è un modo noto per scivolare oltre regole basate sull'estensione del file.

Buone pratiche per le location nginx

Proteggi le directory scrivibili con ^~, non con un prefisso semplice
Ogni directory che accetta upload ha bisogno di location ^~ /uploads/, così la fase delle regex non può consegnare un file salvato a un interprete. Un prefisso semplice sembra equivalente e non lo è.
Dai la barra finale ai prefissi di directory
Scrivi location /static/ invece di location /static, a meno che tu non voglia deliberatamente che /staticfoo e /static-backup siano serviti dallo stesso blocco. Aggiungi una location = /static separata quando anche il percorso nudo va gestito.
Ordina le regex dalla più specifica alla meno specifica
Vince la prima corrispondenza, quindi un pattern ampio sopra a uno preciso rende quello preciso irraggiungibile. Tenere poche regex e ordinarle di proposito è più facile da mantenere che ragionare a posteriori sulle sovrapposizioni.
Ancora le regex che devono corrispondere a un prefisso di percorso
location ~ /admin cerca ovunque nell'URI e corrisponde a /public/admin/x. Scrivi ~ ^/admin quando intendi l'inizio. Ancorare solo alla fine è normale e corretto per l'instradamento per estensione.
Ricontrolla l'instradamento dopo ogni riordino
Spostare i blocchi è sicuro per i prefissi e cambia il comportamento delle regex. Dato che un diff che riordina soltanto delle righe sembra innocuo in review, rieseguire gli URI coinvolti è il modo più economico per accorgersene.

Domande frequenti sul tester delle location nginx

Come faccio a capire quale location ha selezionato nginx?
Incolla la configurazione e l'URI della richiesta in questo tester per vedere il blocco vincente e il motivo per cui ogni altro blocco è stato eliminato. Su un server in esecuzione, aggiungi error_log /var/log/nginx/debug.log debug; e cerca la riga "using configuration", che nomina la location selezionata. I due approcci rispondono a domande diverse: il log dice che cosa ha fatto un server vivo, questa pagina dice che cosa farebbe una configurazione che non hai ancora messo in produzione.
Perché la mia espressione regolare in una location nginx non funziona?
Di solito per uno di tre motivi, e la tabella delle decisioni dice quale. Una regex precedente ha già corrisposto, quindi la tua non è mai stata eseguita — le regex si provano nell'ordine del file e vince la prima corrispondenza. Oppure il prefisso corrispondente più lungo porta ^~, che salta del tutto la fase delle regex. Oppure la regex va bene ma l'URI non è quello che pensi: la corrispondenza gira sul percorso normalizzato, dopo la decodifica delle percentuali e la risoluzione di .., con la query string rimossa.
Perché la mia corrispondenza esatta non scatta?
Una location = richiede che l'intero URI sia uguale, non che inizi con il pattern. location = /a/ non corrisponde a /a, e location = /a non corrisponde a /a/b. Qui le barre finali sono caratteri ordinari, quindi le due forme sono stringhe diverse. Quando una location esatta corrisponde, la ricerca si ferma subito e nient'altro viene nemmeno confrontato.
nginx confronta la query string in un blocco location?
No. La query string viene separata durante la normalizzazione e la selezione della location gira solo sul percorso. Ecco perché location = /a corrisponde a una richiesta per /a?x=/b. Se devi ramificare su un parametro devi leggere $arg_name o $args dentro il blocco. Una sottigliezza che vale la pena conoscere: %3F si decodifica in un punto interrogativo letterale che resta nel percorso, quindi /a%3Fx=1 ha una query string vuota e un percorso che contiene ?.
Posso usare la sintassi delle regex di JavaScript in una location nginx?
No — nginx usa PCRE, e le differenze contano. Questa pagina gira nel tuo browser, dove esistono solo le espressioni regolari ECMAScript, quindi i costrutti esclusivi di PCRE vengono rilevati e segnalati invece che valutati male in silenzio: gruppi atomici, quantificatori possessivi, modificatori inline come (?i), classi POSIX come [[:alpha:]] ed escape come \A e \K che JavaScript legge tranquillamente come lettere ordinarie. Quando una location viene segnalata, i candidati restanti vengono comunque valutati nell'ordine di nginx, ma il verdetto di quel blocco va verificato su un server reale. Se stai scrivendo il pattern in sé, il tester di espressioni regolari copre a fondo la sintassi ECMAScript.
Le corrispondenze per prefisso delle location nginx distinguono maiuscole e minuscole?
Su Linux sì — location /Static/ non corrisponde a /static/x. Su filesystem che non distinguono maiuscole e minuscole, come macOS e Cygwin, nginx confronta i prefissi senza distinguerle e in più forza ogni location a regex a comportarsi come ~*. Questa pagina modella il comportamento di Linux, che è quello che i server di produzione eseguono quasi sempre. Se sviluppi su Mac e rilasci su Linux, quella differenza può nascondere una regola rotta finché non va in produzione.
try_files cambia quale blocco location è stato selezionato?
No. La selezione della location finisce per prima; try_files gira dopo, dentro il blocco che ha già vinto. Se una richiesta non raggiunge mai il blocco che contiene il tuo try_files, la direttiva è irrilevante — la causa abituale è una regex ~ \.php$ che prende la richiesta prima che il blocco a prefisso con il fallback possa agire. Un redirect interno emesso più tardi fa ripartire la corrispondenza, quindi un URI riscritto viene risolto di nuovo sulla lista delle location, dall'inizio.
Perché nginx risponde 301 quando chiedo una directory senza barra?
A produrlo sono due meccanismi diversi. Se una location il cui nome finisce con / porta proxy_pass o un'altra direttiva *_pass, una richiesta per lo stesso percorso senza barra riceve un 301 durante la selezione della location — prima che venga valutata qualsiasi regex. A parte questo, il modulo dei file statici emette un 301 quando il percorso si risolve in una directory reale su disco. Il primo caso è visibile qui; il secondo dipende dal tuo filesystem. Aggiungere location = /path sopprime il primo.
I blocchi location annidati cambiano il risultato?
Sì, e in un modo facile da farsi sfuggire. nginx scende dentro la location a prefisso vincente e cerca tra i suoi figli, quindi una regex annidata viene provata prima delle regex del livello superiore. Un ^~ sul blocco esterno non lo protegge dalle regex annidate al suo interno, e l'annidamento può rendere irraggiungibile un prefisso globalmente più lungo quando un fratello del livello esterno vince per primo. Qui i blocchi annidati sono modellati con la stessa indentazione con cui li hai scritti.
La mia configurazione nginx viene caricata da qualche parte?
No. Il parsing e la corrispondenza avvengono in locale nel tuo browser con semplici operazioni su stringhe — non c'è nessuna chiamata al server e non viene conservato niente. Qui conta più che per la maggior parte degli strumenti, perché un vero blocco server contiene hostname di upstream, porte interne, percorsi dei certificati e regole di autenticazione. Non devi crederci sulla parola: apri gli strumenti per sviluppatori del browser e guarda il pannello Network restare in silenzio mentre digiti, oppure disconnettiti del tutto e continua a provare. L'assenza di qualsiasi richiesta esterna è anche imposta da un test di contratto automatico a ogni build, quindi non può regredire di nascosto.

Strumenti correlati

Vedi tutti gli strumenti →

Generatore e costruttore di comandi cURL

Web & API

Crea comandi curl nel browser — imposta metodo, intestazioni, autenticazione e corpo, ottieni subito il comando pronto da copiare. Preset per Bearer, POST JSON, upload file. Gratuito, privato, senza registrazione.

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

Web & API

Genera voci htpasswd con bcrypt, Apache MD5 (apr1), SHA-1 e altro. Ottieni configurazioni pronte per Apache, nginx e Docker. 100% nel browser — nessun caricamento.

Generatore di Meta Tag e Open Graph

Web & API

Genera meta tag Open Graph, Twitter Card e SEO con anteprima live per Google, Facebook e X. Gratis, nel browser, senza registrazione — copia e incolla.

Decodificatore traceparent — W3C Trace Context

Web & API

Basta contare cifre hex. Decodificatore traceparent online e gratuito — gira nel browser, niente upload. Trace ID, span ID, 8 bit trace-flags, tracestate, Datadog/X-Ray/B3.

Strumento di Decifratura AES — OpenSSL e CryptoJS

Strumenti di sicurezza

Decifra AES online — GCM/CBC/CTR, passphrase o chiave grezza, rileva "U2FsdGVkX1" (OpenSSL/CryptoJS). 100% nel browser, le chiavi restano sul dispositivo.

Strumento di Crittografia AES — GCM, CBC e CTR

Strumenti di sicurezza

Crittografia AES online gratuita — AES-128/192/256, GCM/CBC/CTR, passphrase (PBKDF2) o chiave grezza. Funziona al 100% nel browser; nulla viene caricato.