Detaillierte Erklärung des durch einen Schrägstrich / verursachten Mordes in Nginx proxy_pass

Hintergrund

Ein Nginx-Servermodul muss als Proxy für zwei Server fungieren, daher werden zur Unterscheidung und Weiterleitung an die verschiedenen Server unterschiedliche Standortpfade verwendet.

Das steht am Anfang geschrieben

Standort / {
   Proxy-Passwort http://server1/;
}

Standort /Index {
   Proxy-Passwort http://server2/;
}

Ich habe jedoch vergessen, dass es auf Server1 einen Dienstpfad /indexNew gibt, sodass dieser auf Server1 weitergeleitet wurde, was zu einem 404-Problem führte. Dann habe ich die Konfiguration dringend wie folgt geändert:

Standort /indexNeu {
   Proxy-Passwort http://server1/;
}

Standort / {
   Proxy-Passwort http://server1/;
}

Standort /Index {
   Proxy-Passwort http://server2/;
}

Problemphänomen

Als Ergebnis erreicht die Anforderung Server1, aber die Fehlermeldung lautet „POST wird nicht unterstützt“.

{
	"Status": 500,
	"Nachricht": "http://172.28.72.117/-Anforderungsmethode 'POST' nicht unterstützt",
	"Ergebnis": {}
}

Dies war der Fehler, der zu diesem Zeitpunkt von der Anwendung zurückgegeben wurde. Ich habe nginx überprüft und es gab auch keinen Fehler. Es war sehr seltsam. Ich habe im Code gesehen, dass /indexNew tatsächlich die POST-Methode war. Warum wurde also ein Fehler gemeldet, der besagte, dass es nicht unterstützt wird?

Hier ist zunächst die Reihenfolge der Übereinstimmung der verschiedenen Methoden zum Schreiben von Standorten in nginx:

analysieren

Es gibt keinen Fehler im Nginx-Protokoll. Versuchen Sie daher, das Paket von Nginx zur Anwendung zu erfassen

Erfassen von Paketen mit dem Befehl tcpdump

tcpdump -w dataAll_normal.pcap -i eth0 -s0 Port 8888

Ähnlich wie beim obigen Befehl zum Erfassen des Pakets wird durch Wireshark festgestellt, dass überhaupt keine mit /indexNew in Zusammenhang stehenden HTTP-Verkehrspakete gefunden werden.

Versuchen Sie, den Standort wie folgt zu ändern

Standort /indexNeu {
   Proxy-Passwort http://server1;
}

Standort / {
   Proxy-Passwort http://server1/;
}

Standort /Index {
   Proxy-Passwort http://server2/;
}

Der einzige Unterschied besteht darin, dass der letzte Schrägstrich / in proxy_pass von /indexNew entfernt wird. Erfassen Sie weiterhin Pakete und stellen Sie fest, dass das /indexNew-Paket durchsucht werden kann

Dies zeigt an, dass die Änderung korrekt ist.

Ändern Sie den Fehler weiter zurück und versuchen Sie, das Paket zu erfassen, aber Sie können immer noch nicht nach dem /indexNew-Paket suchen. Führen Sie dann ein Remote-Debugging der Anwendung über die IDE durch

Ich habe festgestellt, dass in der URL der Anwendung kein /indexNew vorhanden war, daher konnte ich es natürlich nicht im Wireshark-Paket finden. . .

Dies liegt daran, dass der Zugriffspfad nur / ist, wenn nginx die Anwendung weiterleitet.

Die Schnittstelle mit dem Anforderungspfad / im Projekt ist in der Tat die GET-Methode

Schauen Sie sich die Syntax von proxy_pass im Standort genauer an. Sie ist tatsächlich so. Am Ende von proxy_pass steht ein /, das den Pfad am entsprechenden Standort entfernt und den nachfolgenden URL-Pfad zum Weiterleiten abfängt.

Daher müssen wir auf die Bedeutung des letzten / in proxy_pass achten und es mit Vorsicht verwenden. Es ändert die Pfadanforderungsinformationen, anstatt 100 % der Informationen weiterzuleiten.

Dies ist das Ende dieses Artikels über den blutigen Fall, der durch einen Schrägstrich / in Nginx proxy_pass verursacht wurde. Weitere verwandte Inhalte zum Schrägstrich von Nginx proxy_pass finden Sie in den vorherigen Artikeln von 123WORDPRESS.COM oder stöbern Sie weiter in den folgenden verwandten Artikeln. Ich hoffe, dass jeder 123WORDPRESS.COM in Zukunft unterstützen wird!