Eine kurze Diskussion über den magischen Schrägstrich im Nginx Reverse Proxy

Beim Konfigurieren des Nginx-Reverse-Proxys können die Schrägstriche in location und proxy_pass verschiedene Probleme verursachen. Manchmal führt ein Schrägstrich mehr oder weniger zu völlig anderen Ergebnissen. Daher haben wir die Situationen mit und ohne Schrägstriche nach location und proxy_pass speziell angeordnet und kombiniert und einen vollständigen Test durchgeführt, um das Prinzip herauszufinden und unsere Haltung zu verbessern~

0. Umweltinformationen

Zwei Nginx-Server

nginx A: 192.168.1.48

nginx B: 192.168.1.56

1. Testmethode

Konfigurieren Sie verschiedene Regeln in nginx A und fordern Sie dann nginx A an: http://192.168.1.48/foo/api

Beobachten Sie die von nginx B empfangene Anfrage, indem Sie das Feld $request im Protokoll betrachten

2. Testablauf und Ergebnisse

Fall 1

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/;
}

Von nginx B empfangene Anfrage: /api

Fall 2

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/;
}

Von nginx empfangene Anfrage B: //api

Fall 3

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/;
}

Von nginx B empfangene Anfrage: /foo/api

Fall 4

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/;
}

Von nginx B empfangene Anfrage: /foo/api

Fall 5

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/bar/;
}

Von nginx B empfangene Anfrage: /bar/api

Fall 6

nginx Eine Konfiguration:

Standort /foo {
  Proxy-Passwort http://192.168.1.56/bar/;
}

Von nginx B empfangene Anfrage: /bar//api

Fall 7

nginx Eine Konfiguration:

Standort /foo/ {
  Proxy-Passwort http://192.168.1.56/bar;
}

Von nginx B empfangene Anfrage: /barapi

Fall 8

nginx Eine Konfiguration:

Standort /foo {
  Proxy-Passwort http://192.168.1.56/bar;
}

Von nginx B empfangene Anfrage: /bar/api

Ist Ihnen schwindlig, wenn Sie das sehen? Tatsächlich gibt es ein Muster.

Ordnen Sie diese Fälle nun in einer Tabelle an. Das Ergebnis zeigt die von nginx B empfangene Anfrage.

Tabelle 1

Tabelle 2

3. Analyse

Ursprünglicher Anforderungspfad: Dieser Artikel verwendet denselben Namen wie „/foo/api“

Standort: Die Spalte „Standort“ in der Tabelle oben

proxy_pass: Die Spalte proxy_pass in der Tabelle oben

Neuer Anforderungspfad: die Zeichenfolge, nachdem nginx den ursprünglichen Anforderungspfad verarbeitet hat

Konzentrieren Sie sich auf die Analyse von Proxy_Pass, das in drei Formen unterteilt werden kann

Anschließend wird die Zeichenfolge in zwei Kategorien eingeteilt, je nachdem, ob auf sie IP:Port folgt. „/“ ist auch eine Zeichenfolge, daher wird 1 in eine Kategorie eingeteilt und 2 und 3 in eine Kategorie. Im Folgenden werden diese beiden Kategorien erläutert.

Wenn auf den Proxy-Pass „IP:Port“ kein String folgt, leitet Nginx den ursprünglichen Anforderungspfad unverändert an den nächsten Nginx weiter, wie in den Fällen 3 und 4.

Wenn nach der IP:Port-Adresse von Proxy_Pass eine Zeichenfolge hinzugefügt wird, entfernt Nginx den Speicherort aus dem ursprünglichen Anforderungspfad, verknüpft die verbleibende Zeichenfolge mit Proxy_Pass, um einen neuen Anforderungspfad zu generieren, und leitet den neuen Anforderungspfad dann an die nächste Nginx-Station weiter (die obige Situation ist eigentlich dieselbe wie diese, außer dass die entfernte Zeichenfolge eine leere Zeichenfolge ist~~)

Nehmen wir das verwirrendste Beispiel: Fall 7. Auf die IP:Port von proxy_pass folgt die Zeichenfolge „/bar“, sodass der Speicherort „/foo/“ aus dem ursprünglichen Anforderungspfad „/foo/api“ entfernt wird und zu „api“ wird. Anschließend wird „api“ mit proxy_pass: http://192.168.1.48/bar verknüpft, um eine neue Anforderungs-URL zu generieren: „http://192.168.1.48/barapi“, sodass die von nginx beim nächsten Stopp empfangene Anforderung „/barapi“ lautet.

Fall 6: Auf die IP:Port-Angabe von Proxy_Pass folgt die Zeichenfolge „/bar/“, sodass der Speicherort „/foo“ aus dem ursprünglichen Anforderungspfad „/foo/api“ entfernt und zu „/api“ wird. Anschließend wird „/api“ mit Proxy_Pass: http://192.168.1.48/bar/ verknüpft, um einen neuen Anforderungspfad zu generieren: „http://192.168.1.48/bar//api“, sodass die von Nginx beim nächsten Stopp empfangene Anforderung /bar//api lautet.

Das Gleiche gilt auch für andere Fälle. Jetzt verstehe ich es endlich und muss nicht mehr verwirrt sein.

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.