nginx-Location-Tester

Wie nginx eine location wählt

1. Die URI wird zuerst normalisiert: Prozent-Dekodierung, mehrfache Schrägstriche zusammengeführt, . und .. aufgelöst. Der Query-String ist nie Teil des Location-Matchings.
2. Alle Präfix-locations (ohne Modifikator, =, ^~) werden verglichen. Ein exakter =-Treffer gewinnt sofort. Sonst wird der längste passende Präfix gemerkt.
3. Hat dieser längste Präfix ^~, gewinnt er, und Regexe werden übersprungen.
4. Regex-locations (~ schreibungsabhängig, ~* schreibungsunabhängig) werden in der Reihenfolge der Datei getestet. Der erste Treffer gewinnt, selbst wenn vorher ein längerer Präfix passte.
5. Passt kein Regex, wird der gemerkte längste Präfix verwendet.
6. Innerhalb der gewinnenden location läuft dasselbe Verfahren erneut für verschachtelte locations.

Zwei Folgen überraschen am meisten: Ein schlichtes location /images/ verliert gegen location ~ \.png$ für /images/a.png, weil Regexe nach Präfixen geprüft werden; und location /api passt auch auf /apiary, weil Präfixe String-Präfixe sind, keine Pfadsegmente. Nutzen Sie /api/ oder ^~, wenn Sie es so meinen.

proxy_pass und der abschließende Schrägstrich

Hat proxy_pass einen URI-Teil (irgendetwas nach dem Host, auch nur /), ersetzt nginx den Teil der Request-URI, der auf den Location-Präfix passte, durch ihn. location /api/ { proxy_pass http://app/; } macht aus /api/users /users. Ohne URI-Teil geht die Request-URI unverändert durch. Nicht zusammenpassende Schrägstriche (/api gegen /api/, oder http://app gegen http://app/) erzeugen //users oder users — der Tester gibt die exakte Upstream-URI aus, damit Sie es sehen. In einer Regex-location ist ein URI-Teil nicht erlaubt, es sei denn, ein rewrite hat die URI zuerst geändert.

root gegen alias

root hängt die ganze URI an das Verzeichnis an: root /srv; location /static/ liefert /srv/static/x.css. alias ersetzt den Location-Präfix: alias /srv/assets/; location /static/ liefert /srv/assets/x.css. Bei alias müssen die abschließenden Schrägstriche von location und alias übereinstimmen, und in einer Regex-location muss alias Captures verwenden.

rewrite-Flags

try_files

Jedes Argument wird als Datei (oder Verzeichnis, mit abschließendem Schrägstrich) relativ zu root/alias geprüft; das erste existierende wird ausgeliefert. Das letzte Argument ist der Fallback und wird nicht geprüft: Es ist eine interne Umleitung auf eine URI (die erneut durch das Location-Matching geht), eine benannte location @name oder ein Statuscode im Stil =404. Der Tester sieht Ihr Dateisystem nicht, also listet er die Pfade, die geprüft würden.

add_header-Vererbung

add_header wird von der server-Ebene nur geerbt, wenn die location kein eigenes add_header hat. Ein einziges add_header Cache-Control in einer location lässt die auf server-Ebene gesetzten Security-Header stillschweigend wegfallen. Die Spur weist darauf hin.

Fragen