Wie lautet die exakte Prioritätsreihenfolge der Nginx-Location-Modifikatoren?

Nginx prüft Locations in fünf Schritten: 1) Exakter Match (=) stoppt bei Erfolg sofort; 2) Alle Präfix-Locations werden gescannt und das längste Präfix zwischengespeichert; 3) Besitzt dieses ^~, wird Regex übersprungen und der Block gewinnt; 4) Reguläre Ausdrücke (~, ~*) werden von oben nach unten geprüft – der erste Treffer gewinnt; 5) Trifft kein Regex zu, gewinnt das längste Präfix aus Schritt 2.

Wie normalisiert Nginx Anforderungs-URIs vor dem Abgleich der Location-Direktiven?

Vor dem Matching dekodiert Nginx Prozent-kodierte Zeichen (z. B. %20 zu Leerzeichen), löst relative Pfade (. und ..) auf und reduziert mehrere aufeinanderfolgende Schrägstriche (//) auf einen einzelnen Schrägstrich. Query-Strings nach ? werden in $query_string ausgelagert.

Warum unterstützt das Location-Matching keine Query-Parameter oder URL-Fragmente?

Gemäß RFC 3986 sind Pfad und Query getrennte Komponenten. Nginx routet Locations strikt anhand des URI-Pfads. Verwenden Sie zur Auswertung von URL-Parametern die Variablen $args oder $arg_ innerhalb von map-Direktiven oder Rewrite-Regeln.

Beeinflusst die physische Reihenfolge von Präfix-Blöcken in der nginx.conf das Routing?

Nein. Im Gegensatz zu Regex-Blöcken (~ und ~*) werden Standard-Präfix-Blöcke ("") und ^~ von Nginx intern in einem Suchbaum organisiert. Es gewinnt immer das längste passende Präfix (Longest Prefix Match), unabhängig von der Position in der Datei.

Werden eingegebene Nginx-Konfigurationen oder Testfälle an externe Server übertragen?

Nein. Die gesamte URI-Normalisierung, das Parsing von Konfigurationsblöcken, die Match-Algorithmen und die Batch-Tests laufen vollständig clientseitig in der JavaScript-Laufzeit Ihres Browsers ab.

Nginx-Location-Prioritätstester & Match-Simulator

Echtzeit-URI-Simulator(Automatisch normalisiert: Prozent-Decodierung, Schrägstriche zusammengeführt, Abfrage entfernt)

TREFFER:location ^~ /static/(0.32ms)

GET

Schnelltests:

Tier 1: Exakt

log_not_found off; ...Exact match bypasses all other rules instantly

TREFFER

Tier 2: RegEx-Stopp-Präfix

alias /var/www/spa/static/; ...Preferential prefix: Skips all regex tests for static build assets

Tier 3: RegEx (Ignoriert Groß-/Kleinschreibung)

expires 7d; ...Regex for root-level and un-prefixed media assets

Tier 2: RegEx-Stopp-Präfix

proxy_pass http://backend_upstream; ...Preferential prefix: Directs all /api/ endpoints to backend

Tier 5: Root-Standard

root /var/www/spa/dist; ...Catch-all fallback prefix for client-side HTML5 history routing

Locations: 5Exakt (=): 1Bevorzugt (^~): 2RegEx (~): 1Präfix (/): 1

Zeilen: 55 · Bytes: 1842B

ÜBEREINSTIMMUNG GEFUNDEN IN 0.32msHTTP 200 VERARBEITET

location ^~ /static/

Phase 2: Bevorzugter Präfix (^~)

Längster passender Präfix hat „^~“-Modifikator. RegEx-Prüfung wurde komplett übersprungen.

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

Ausgeführte Direktiven:

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

Schrittweise Auswertung (6 Schritte)

Auswertung in strenger RFC-Phasenreihenfolge

URI-Normalisierung & Extraktionnormalization

Prozent-Codierung aufgelöst, doppelte Schrägstriche zusammengeführt und Query-String abgetrennt.

Request URI: "/static/css/bundle.css"
Normalized:  "/static/css/bundle.css"
Query:       ""

Tier 1: Exakt (= /favicon.ico)exact

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

Standard-Präfix: ^~ /static/ [8]prefix scan

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

Standard-Präfix: ^~ /api/prefix scan

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

Standard-Präfix: (standard) / [1]prefix scan

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

Tier 2: RegEx-Stopp-Präfix (^~ /static/)preferential check

Längster passender Präfix hat „^~“-Modifikator. RegEx-Prüfung wurde komplett übersprungen.

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

Ergebnis: ^~ /static/|Latenz: 0.32ms

RegEx geprüft: 0Präfixe geprüft: 3

RFC- und Nginx-Kern-Algorithmus-Treue

Simuliert exakt die Matching-Mechanik des Nginx C-Kerns: = exakte Übereinstimmung, ^~ bevorzugter Präfix, Reihenfolge regulärer Ausdrücke und längster Standard-Präfix als Fallback.

Null Server-Upload & Null Latenz

Sämtliche URI-Normalisierungen, RegEx-Analysen und Prioritätsprüfungen erfolgen vollständig im Browser-Arbeitsspeicher ohne jeglichen Netzwerk-Overhead.

Produktionsreife Konfigurationsgenerierung

Exportiert sofort saubere, validierte Nginx-Konfigurationsblöcke inklusive erklärender Kommentare und diagnostischer cURL-Prüfbefehle.

Nginx-Location-Prioritätstester & Match-Simulator

Schrittweise Auswertung (6 Schritte)

RFC- und Nginx-Kern-Algorithmus-Treue

Null Server-Upload & Null Latenz

Produktionsreife Konfigurationsgenerierung

Nginx-Location-Prioritätstester & Match-Simulator — Referenz-Leitfaden

Wichtige Parameter & Steuerelemente

Profi-Tipps & Best Practices

^~ für statische Assets nutzen

Regex nach Traffic sortieren

Exakter Match für Root-Pfade

Normalisierte URIs prüfen

Häufige Fallstricke & Fehlerbehebung

Ein Regex-Location-Block überschreibt unerwartet einen längeren Präfix-Block

Query-String-Parameter in der Test-URI werden vom Location-Pfad nicht gematcht

Case-Sensitive-Regex ~ schlägt bei gemischter Groß-/Kleinschreibung fehl

Häufig gestellte Fragen (FAQ)

Verwandte Werkzeuge & Dienstprogramme