Detaillierte Erklärung des "/"-Problems, wenn proxy_pass gemäß dem Pfad weiterleitet

Wenn Sie beim Konfigurieren von proxy_pass in nginx den Pfad gemäß ^~ abgleichen, achten Sie auf das letzte / in der URL nach proxy_pass. Wenn / hinzugefügt wird, entspricht dies dem absoluten Stammpfad, und nginx wird den entsprechenden Pfadteil im Speicherort nicht als Proxy verwenden. Wenn kein / vorhanden ist, wird der entsprechende Pfadteil ebenfalls als Proxy verwendet.

Beispielsweise folgende Einstellungen:

Standort ^~ /wangshibo/
{
Proxy-Cache js_cache;
Proxy_set_header Host js.test.com;
Proxy-Passwort http://js.test.com/;
}

Wie in der obigen Konfiguration gezeigt, wird die angeforderte URL, wenn sie http://servername/wangshibo/test.html lautet, an http://js.test.com/test.html weitergeleitet.

Wenn Sie es so konfigurieren

Standort ^~ /wangshibo/
{
Proxy-Cache js_cache;
Proxy_set_header Host js.test.com;
Proxy-Passwort http://js.test.com;
}

Die angeforderte URL lautet http://servername/wangshibo/test.html und wird an http://js.test.com/wangshibo/test.html weitergeleitet.

Natürlich können Sie die folgende Umschreibung verwenden, um die Funktion von / zu implementieren.

Standort ^~ /wangshibo/
{
Proxy-Cache js_cache;
Proxy_set_header Host js.test.com;
/wangshibo/(.+)$ /$1 umschreiben;
Proxy-Passwort http://js.test.com;
}

Hier ist ein Beispiel

1) Die erste Konfiguration

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
stromaufwärts bei {
  Server 192.168.1.202:8080 max_fails=3 Fail_Timeout=30s;
}
  
Server {
  hören Sie 443;
  Servername www.wangshibo.com;
  SSL aktiviert;
  
  ### SSL-Protokolldateien ###
  access_log-Protokolle/wangshibo_access.log;
  Fehlerprotokollprotokolle/wangshibo_error.log;
  
### SSL-Zertifikatsdateien ###
  SSL-Zertifikat ssl/wang.cer;  
  SSL-Zertifikatsschlüssel ssl/wang.key;
  
  Ort /Anwesenheit/ {
  proxy_pass http://at; //Kein "/" nötig          
  Proxy_next_upstream-Fehler, Timeout, ungültiger Header, http_500, http_502, http_503;
  Proxy_Set_Header Host $host;
  Proxy_Set_Header X-Real-IP $Remote_Addr;
  proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
  Proxy_set_header X-Forwarded-Proto https;
  Proxy_Redirect aus;
    }
  
}

Die Ergebnisse des Zugriffs auf https://www.wangshibo.com/attendance/ und http://192.168.1.202:8080/attendance sind konsistent.

2) Zweite Konfiguration

[root@BJLX_16_202_V vhosts]# cat ssl-wangshibo.conf
stromaufwärts bei {
  Server 192.168.1.202:8080 max_fails=3 Fail_Timeout=30s;
}
  
Server {
  hören Sie 443;
  Servername www.wangshibo.com;
  SSL aktiviert;
  
  ### SSL-Protokolldateien ###
  access_log-Protokolle/wangshibo_access.log;
  Fehlerprotokollprotokolle/wangshibo_error.log;
  
### SSL-Zertifikatsdateien ###
  SSL-Zertifikat ssl/wang.cer;  
  SSL-Zertifikatsschlüssel ssl/wang.key;
  
  Standort / {
  proxy_pass http://at/attendance/; //Denken Sie daran, "/" hinzuzufügen.            
  Proxy_next_upstream-Fehler, Timeout, ungültiger Header, http_500, http_502, http_503;
  Proxy_Set_Header Host $host;
  Proxy_Set_Header X-Real-IP $Remote_Addr;
  proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for;
  Proxy_set_header X-Forwarded-Proto https;
  Proxy_Redirect aus;
    }  
}

Die Ergebnisse des Zugriffs auf https://www.wangshibo.com und http://192.168.1.202:8080/attendance sind konsistent.

Wir möchten folgende Konfiguration erreichen:

192.168.1.27 ist der eigentliche Server im Backend und Port 8080 ist der Port des EHR-Personalsystems des Unternehmens.

Da das System über einen WeChat-Schnittstellenzugriff verfügt, nämlich http://ehr.wang.com/attendance und http://ehr.wang.com/app.

Da es sich um ein internes System handelt, sind aus Sicherheitsgründen folgende Voraussetzungen erforderlich:

1) Beim Einloggen in das EHR-Personalsystem müssen Sie den Intranet-Login verwenden, also http://192.168.1.27:8080. Sie müssen sich beim Firmen-VPN anmelden, bevor Sie darauf zugreifen können.
2) Melden Sie sich über das externe Netzwerk bei der WeChat-Oberfläche http://ehr.wang.com/attendance und http://ehr.wang.com/app an, d. h. verwenden Sie zum Anmelden den aufgelösten Domänennamen.
3) Besuchen Sie http://ehr.wang.com und erzwingen Sie eine Weiterleitung zu https://ehr.wang.com/attendance

[root@BJLX_4_21_P vhosts]# cat ehr.conf
Server {
  hören Sie 80;
  Servername ehr.wang.com;
  
  access_log Protokolle/ehr_access.log;
  Fehlerprotokollprotokolle/ehr_error.log;
 
  Rückgabewert 301 https://$server_name$request_uri;   
}
 
[root@BJLX_4_21_P vhosts]# cat ssl-ehr.conf
Upstream ehr {
  Server 192.168.1.27:8080 max_fails=3 Fail_Timeout=30s;
}
 
Server {
  hören Sie 443;
  Servername ehr.wang.com;
  SSL aktiviert;
 
  ### SSL-Protokolldateien ###
  access_log Protokolle/ehr_access.log;
  Fehlerprotokollprotokolle/ehr_error.log;
 
### SSL-Zertifikatsdateien ###
  SSL-Zertifikat ssl/wang.cer;   
  SSL-Zertifikatsschlüssel ssl/wang.key; 
  #ssl_session_timeout 5m;
 
  Standort / {
    Rückgabe 301 https://ehr.wang.com/attendance;
  }
 
  Ort /Anwesenheit/ {
  Proxy-Pass http://ehr;
  Proxy_next_upstream-Fehler, Timeout, ungültiger Header, http_500, http_502, http_503;
  Proxy_Set_Header Host $host;
  Proxy_Set_Header X-Real-IP $Remote_Addr;
  proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for; # proxy_set_header X-Weitergeleitet-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  Proxy_Redirect aus;
  }
 
  Standort /app/ {
  Proxy-Pass http://ehr;
  Proxy_next_upstream-Fehler, Timeout, ungültiger Header, http_500, http_502, http_503;
  Proxy_Set_Header Host $host;
  Proxy_Set_Header X-Real-IP $Remote_Addr;
  proxy_set_header X-Weitergeleitet-Für $proxy_add_x_forwarded_for; # proxy_set_header X-Weitergeleitet-Proto https;
  #proxy_set_header X-Forwarded-Proto https;
  Proxy_Redirect aus;
  }
 }

Beachten:

Da der Zugriff vom Browser (http) auf den realen Server der Ursprungsstation über die Nginx Reverse-Proxy-Schicht (https) erfolgen muss

Sie müssen die Zeile proxy_set_header X-Forwarded-Proto https; auskommentieren, sonst ist die obige Konfiguration ungültig.

Wenn sich in der Mitte keine Proxy-Schicht befindet und nginx direkt per Reverse-Proxy auf dem realen Server verwendet wird (d. h. das lokale nginx per Reverse-Proxy auf Port 8080 des lokalen Servers), ist dieser Parameter ungültig (das wurde überprüft).

Liste und Erklärung der HTTP-Headerfelder (proxy_set_header)

Das HTTP-Headerfeld enthält die Headerinformationen in der Anforderung und Antwort im HTTP-Protokoll. Tatsächlich handelt es sich dabei um den Betriebsparameter der HTTP-Kommunikation, der dem Webserver und dem Browser mitteilt, wie die Kommunikation zu handhaben ist.

Der HTTP-Header beginnt in der zweiten Zeile einer Anforderungs- oder Antwortnachricht (die erste Zeile ist die Anforderungszeile bzw. Antwortzeile) und endet mit zwei CR-LF-Zeichengruppen (CR: Wagenrücklauf, \r, LF: Zeilenvorschub \n).

Jeder HTTP-Header hat die Form einer Zeichenfolge, wobei Schlüssel-Wert-Paare durch Doppelpunkte getrennt sind und mehrere HTTP-Header durch CR-LF-Zeichengruppen getrennt sind.

Einige HTTP-Header können Kommentare enthalten, wie etwa „User-Agent“, „Server“ oder „Via“. Diese Kommentare werden jedoch vom Server oder Browser ignoriert. Die IETF-Organisation hat in der Spezifikation RFC2616 einige grundlegende HTTP-Header definiert.
Diese HTTP-Header müssen von jeder HTTP-basierten Software implementiert werden, und einige andere aktualisierte und erweiterte Header-Felder müssen ebenfalls von HTTP-basierter Software implementiert werden. Natürlich kann jede Software auch ein eigenes Header-Feld definieren.

Andererseits begrenzt die Spezifikation RFC2616 weder die Länge jedes HTTP-Headers noch die Anzahl der HTTP-Header. Aus Leistungs- und Sicherheitsgründen treffen die meisten Server jedoch ihre eigenen Regelungen, wie z. B. Apache 2.3.
Es legt fest, dass jeder HTTP-Header 8190 Bytes und jede Anforderung 100 HTTP-Header nicht überschreiten darf.

Werfen wir einen Blick auf die verschiedenen HTTP-Header, die beim Senden einer Anfrage enthalten sein können, und ihre Erklärungen.

Standardanforderungsheader -

Akzeptieren: Die Inhaltstypen, die der Browser (oder ein anderes HTTP-basiertes Clientprogramm) akzeptieren kann, z. B. Akzeptieren: Text/Plain

Accept-Charset: Der Zeichensatz, den der Browser erkennen kann, z. B. Accept-Charset: utf-8

Accept-Encoding: Die Kodierungsmethode, die der Browser verarbeiten kann. Beachten Sie, dass sich die Kodierungsmethode hier vom Zeichensatz unterscheidet. Die Kodierungsmethode bezieht sich hier normalerweise auf gzip, deflate usw. Zum Beispiel Accept-Encoding: gzip, deflate

Accept-Language: Die vom Browser akzeptierte Sprache, also die Sprachregion des Benutzers. Vereinfachtes Chinesisch lautet beispielsweise Accept-Language: zh-CN

Autorisierung: In HTTP kann der Server einige Ressourcen authentifizieren und schützen. Wenn Sie auf diese Ressourcen zugreifen möchten, müssen Sie einen Benutzernamen und ein Kennwort angeben. Der Benutzername und das Kennwort sind im Autorisierungsheader enthalten. Das Format ist die Base64-Kodierung der Zeichenfolge „Benutzername:Kennwort“. Beispiel: Autorisierung: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==, Basic bedeutet die Verwendung der grundlegenden Authentifizierungsmethode, QWxhZGRpbjpvcGVuIHNlc2FtZQ== dekodiert mit Base64 ist „Aladdin: Sesam öffne dich“

Cache-Control: Diese Direktive ist sowohl in der Anfrage als auch in der Antwort vorhanden und dient dazu, dem Cache-System (auf dem Server oder im Browser) Anweisungen zu geben, wie mit dem Cache umzugehen ist. Da dieses Header-Feld recht wichtig ist, insbesondere wenn man Caching zur Leistungssteigerung nutzen möchte und viel Inhalt vorhanden ist, möchte ich es im nächsten Blog-Beitrag hauptsächlich vorstellen.

Verbindung: Informiert den Server, welche Verbindungsmethode der Benutzeragent (normalerweise ein Browser) verwenden möchte. Die Werte sind Keep-Alive und Close. Die Standardeinstellung für http1.1 ist Keep-Alive. Keep-Alive bedeutet, dass die Kommunikationsverbindung zwischen Browser und Server dauerhaft gespeichert und nicht sofort geschlossen wird, während Close sofort nach der Antwort geschlossen wird. Hier ist jedoch zu beachten, dass die Aussage, dass HTTP zustandslos ist, nichts damit zu tun hat, ob Keep-Alive verwendet wird. Denken Sie nicht, dass Keep-Alive eine Verbesserung der zustandslosen Funktion von HTTP darstellt.

Cookie: Wenn ein Browser eine Anfrage an einen Server sendet oder wenn ein Server einem Browser ein Cookie anfügt, wird das Cookie hier platziert. Beispiel: Cookie:user=admin

Inhaltslänge: Die Speicherlänge des Anforderungstexts einer Anforderung in Bytes. Der Anforderungstext bezieht sich auf den Inhalt nach den beiden CR-LF-Zeichengruppen nach dem HTTP-Header. Der allgemeine Inhalt umfasst per POST übermittelte Formulardaten. Die Inhaltslänge umfasst nicht die Datenlänge der Anforderungszeile und des HTTP-Headers.

Content-MD5: Die mit Base64 codierte MD5-Prüfsumme des Anforderungstexts. Beispiel: Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ==

Inhaltstyp: Der MIME-Typ des Inhalts im Anforderungstext. Wird normalerweise nur in POST- und PUT-Methodenanforderungen verwendet. Beispiel: Content-Type: application/x-www-form-urlencoded

Datum: Die GMT-Zeit, zu der die Anfrage gesendet wurde. Beispiel: Datum: Di, 15. Nov. 1994 08:12:31 GMT

Erwarten: Zeigt an, dass einige spezielle Funktionen des Servers verwendet werden müssen. (Das ist mir nicht ganz klar)

Von: Die E-Mail-Adresse des Benutzers, der diese Anfrage sendet. Beispiel: Von: [email protected]

Host: Der Domänenname oder die IP-Adresse des Servers. Wenn es sich nicht um einen gängigen Port handelt, enthält er auch die Portnummer, zum Beispiel: Host: www.some.com:182

If-Match: Wird normalerweise in Anfragen verwendet, die die PUT-Methode verwenden, um Serverressourcen zu aktualisieren. Dabei wird der Server gefragt, ob sich das Tag der angeforderten Ressource vom Tag dieses If-Matches unterscheidet. Wenn sie gleich sind, beweist dies, dass die Ressource auf dem Server noch alt ist und jetzt aktualisiert werden kann. Wenn sie unterschiedlich sind, beweist dies, dass die Ressource aktualisiert wurde und nicht erneut aktualisiert werden muss (andernfalls werden möglicherweise die von anderen vorgenommenen Änderungen überschrieben).

If-Modified-Since: Fragt den Server, ob die angeforderte Ressource seit einer bestimmten Zeit geändert wurde. Wenn nicht, gibt der Server einen 304-Status zurück, um den Browser anzuweisen, den eigenen lokalen Cache des Browsers zu verwenden. Wenn sie geändert wurde, gibt er eine 200 zurück und sendet die neue Ressource (wenn die Ressource nicht existiert, gibt er natürlich eine 404 zurück).

If-None-Match: Es hat einen ähnlichen Zweck wie If-Modified-Since, wird aber nicht zeitbasiert bestimmt, sondern basierend auf etwas, das ETag genannt wird. Im nächsten Blog möchte ich etag vorstellen.

If-Range: teilt dem Server mit, dass er die fehlenden Teile der Ressource an den Browser sendet, wenn die Ressource nicht geändert wurde (basierend auf dem nach If-Range angegebenen Etag). Wenn die Ressource geändert wurde, sendet er eine Kopie der gesamten Ressource erneut an den Browser.

If-Unmodified-Since: Fragt den Server, ob die aktuell angeforderte Ressource seit einer bestimmten Zeit nicht geändert wurde.

Max-Forwards: Begrenzt die Anzahl der Weiterleitungen von Anforderungsinformationen im Proxyserver oder Gateway.

Pragma: Es scheint, dass es nur einen Wert gibt, nämlich: no-cache. Pragma:no-cache ist dasselbe wie cache-control:no-cache, außer dass cache-control:no-cache speziell in http1.1 angegeben ist, während Pragma:no-cache in http1.0 und 1.1 verwendet werden kann.

Proxy-Autorisierung: Authentifizierungsinformationen, die beim Verbinden mit einem Proxy verwendet werden, ähnlich dem Autorisierungsheader. Beispiel: Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Bereich: Im HTTP-Header bedeutet das Wort „Bereich“ „die sequentielle Anordnung der Daten im Byte-Format der Ressource und die Entnahme eines bestimmten Abschnitts der Daten“. Der Range-Header gibt die Daten von einem bestimmten Wert bis zu einem bestimmten Wert der angeforderten Ressource an. Beispielsweise gibt Range: bytes=500-999 die Daten von 500 bis 999 Bytes der angeforderten Ressource an. Dadurch wird das segmentierte Herunterladen und das mehrfädige Herunterladen von Daten erreicht.

Referer: bezeichnet die Adresse, von der auf die aktuell angeforderte URL verwiesen wird. Wenn Sie beispielsweise auf der Seite www.a.com/index.html auf einen Hyperlink klicken, der auf www.b.com verweist, lautet der Referrer in der Anforderung für www.b.com www.a.com/index.html. Der Bild-Hotlink-Schutz, den wir normalerweise sehen, wird auf diese Weise implementiert.

Upgrade: Fordern Sie den Server auf, auf ein anderes Protokoll zu aktualisieren, zum Beispiel: Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

User-Agent: Normalerweise die browserbezogenen Informationen des Benutzers. Beispiel: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20100101 Firefox/12.0

Via: Wird verwendet, um aufzuzeichnen, welche Proxys oder Gateways eine Anfrage durchläuft, bevor sie an den Zielserver gesendet wird. Beispielsweise stammt eine Anfrage von einem Browser (unter der Annahme, dass http/1.0 verwendet wird), wird an einen internen Proxy namens SomeProxy gesendet, dann an einen öffentlichen Proxy namens www.somenet.com (unter Verwendung von http/1.1) weitergeleitet und schließlich an den Zielserver www.someweb.com weitergeleitet. Der in someweb.com empfangene Via-Header sollte lauten: via:1.0 someProxy 1.1 www.someweb.com (Apache 1.1)

Warnung: Notieren Sie einige Warninformationen.

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.