Beispiel für die Konfiguration der domänenübergreifenden Fehlerbehebung in nginx

Die domänenübergreifende Nginx-Konfiguration wird wie folgt nicht wirksam

Server {
  hören Sie 80;
  Servername localhost;
  
  # Schnittstelle für Weiterleitungsort /api/ {
   # Domänenübergreifende Anforderungsadressen zulassen * als Platzhalter add_header 'Access-Control-Allow-Origin' '*';
   # Legen Sie die Anforderungsmethode auf domänenübergreifend fest: add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   # Festlegen, ob die Cookie-Übertragung zugelassen werden soll add_header 'Access-Control-Allow-Credentials' 'true';
   # Festlegen des Anforderungsheaders. Warum legen Sie hier kein Platzhalterzeichen fest? * Weil add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' nicht unterstützt wird.
   # Reverse-Proxy-Proxy-Passwort 127.0.0.1:8081/ festlegen;
  }
 }

Die domänenübergreifende Konfiguration von Nginx im Internet ist hauptsächlich die obige Version. Viele Leute kopieren sie jedoch einfach und wenden sie nicht wirklich an. Deshalb habe ich diesen Artikel geschrieben, um diejenigen, die ihn benötigen, daran zu erinnern, ihn nicht blind zu kopieren und zu lernen, ihn zu analysieren.

Nginx ändert die folgende Konfiguration, damit sie wirksam wird

Server {
  hören Sie 80;
  Servername localhost;
  
  # Schnittstelle für Weiterleitungsort /api/ {
   # Domänenübergreifende Anforderungsadressen zulassen * als Platzhalter add_header 'Access-Control-Allow-Origin' '*';
   # Legen Sie die Anforderungsmethode auf domänenübergreifend fest: add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE';
   # Festlegen, ob die Cookie-Übertragung zugelassen werden soll add_header 'Access-Control-Allow-Credentials' 'true';
   # Festlegen des Anforderungsheaders. Warum legen Sie hier kein Platzhalterzeichen fest? * Weil add_header 'Access-Control-Allow-Headers' 'Authorization,Content-Type,Accept,Origin,User-Agent,DNT,Cache-Control,X-Mx-ReqToken,X-Data-Type,X-Requested-With,X-Data-Type,X-Auth-Token' nicht unterstützt wird.
   
   # Setze Optionen für die Anforderungsverarbeitung, wenn ( $request_method = 'OPTIONS' ) { 
    Rückgabe 200;
   }
   # Reverse-Proxy-Proxy-Passwort 127.0.0.1:8081/ festlegen;
  }
 }

Der Hauptunterschied zwischen den beiden Codes ist die folgende Codezeile

wenn ( $request_method = 'OPTIONEN' ) { 
  Rückgabe 200;
}

Weil der Browser eine Optionsvorprüfungsanforderung für die Post-Anforderung sendet, die hauptsächlich den Anforderungsheader an den Server sendet. Wenn der Server dies zulässt, sendet er die eigentliche Post-Anforderung. Daher zeigt f12, dass Post häufig zwei Anforderungen sendet. Da der Java-Code im Backend die Optionsanforderung nicht verarbeitet, meldet die Optionsschnittstellenanforderung 403 Verboten. Hier gibt nginx direkt 200 an die Optionsanforderung zurück, ohne die Schnittstellenebene zu erreichen, und lässt den Post-Response-Header direkt zu, wodurch die obige ungültige Konfiguration wirksam werden kann.

Ein kleiner Wissenspunkt

Proxy-Passwort 127.0.0.1:8081/;

Zur Frage, ob der Reverse-Proxy hinzugefügt werden soll oder nicht;

Besuchen Sie http://localhost/api/user/login;

• Wenn Sie / hinzufügen, lautet der tatsächliche Zugriff 127.0.0.1:8081/Benutzer/Anmeldung;
• Ohne / lautet der tatsächliche Zugriff 127.0.0.1:8081/api/user/login;

Das Hinzufügen eines Schrägstrichs bedeutet, dass alle /API-Anfragen an das Stammverzeichnis weitergeleitet werden, d. h. /API wird durch / ersetzt. Zu diesem Zeitpunkt ändert sich der Schnittstellenpfad, und es gibt eine /API-Ebene weniger. Wie wäre es ohne Schrägstrich? Somit geht der /api-Pfad bei einer Weiterleitung auf den Domänennamen 127.0.0.1:8081 nicht verloren.

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.