nginx 502 „Bad Gateway“-Fehler bei der Einstellung als Proxy über SSL/HTTPS

Ein wenig Experimentieren hat gezeigt, dass nginx für meinen Gebrauch ein großartiger Caching-Proxy ist. So gut, dass ich mich fragte, was passieren würde, wenn ich anfangen würde, die Server miteinander zu verketten (Proxy A —> Proxy B —> nginx Server C, alles über HTTPS/SSL).

Die Antwort war… 502 Bad Gateway (502 Schlechte Gateway)-Fehler.

Ich hatte es eingerichtet und dann Integrity von PeacockMedia (kostenlose/Donationware im Mac App Store) benutzt, um die Site auszuprobieren. Falls Sie noch nie davon gehört haben, Integrity ist so etwas wie ein Broken-Link-Checker für MacOS – schnell und kinderleicht zu benutzen. Wie auch immer… es warf sofort einen Haufen 502 Fehler für die HTTPS-Versionen der Site auf.

Ich habe es überprüft, indem ich versucht habe, eine Seite manuell über HTTPS in einem Webbrowser zu laden, und tatsächlich, 502 Fehler.

——

Es stellte sich heraus, dass mein Problem darin bestand, dass ich gerade von einem einfachen proxy_pass https://123.45.67.89; in der Location zu dem ganzen „upstream backend“-Ding gewechselt hatte, mit so etwas wie diesem:

upstream backend {
     server 123.45.67.89;
     server 12.34.56.789 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend;
     }
}
 

Das funktioniert nicht ganz, und der Grund dafür war, dass Sie den Port im Abschnitt „upstream backend“ angeben müssen, wenn es sich nicht um Port 80 handelt. Es reicht nicht aus, daß die proxy_pass-Zeile mit https begann – ich mußte ihr auch explizit sagen, daß sie Port 443 benutzen soll.

So lautete die Arbeitsversion natürlich wie folgt:

upstream backend-ssl {
     server 123.45.67.89:443;
     server 12.34.56.789:443 backup;
}
server {
     listen 443;
     server_name example.com;
     location / {
         proxy_pass https://backend-ssl;
     }
}
 

Das heißt nicht, dass dies die einzige Ursache für 502 Fehler beim Umgang mit dem Caching-Proxy von nginx ist (Timeouts sind nach meinem Verständnis eine weitere häufige Ursache).

Aber wenn Sie gerade erst das Upstream-Bit implementiert haben, lohnt es sich, nachzuschauen, ob Sie dasselbe Problem haben.

Falls nicht, lohnt es sich, einen Blick in Ihr Fehlerprotokoll zu werfen, um die Dinge einzugrenzen. Normalerweise ist es in Ihrem Logs-Verzeichnis zu finden: Wenn Sie Ubuntu benutzen, ist /var/log/nginx/error.log der Ort, an dem es oft zu finden ist.

6 Anmerkungen | Sagen Sie einen Kommentar

  1. ishwar auf Oktober 1, 2014 - Klicken Sie hier, um zu antworten
    danke, ich hatte das genaue Problem.
  2. Du hast gerade mein Leben gerettet
  3. Faruk auf November 20, 2019 - Klicken Sie hier, um zu antworten
    Vielen Dank! Das hat mir viel Zeit erspart
  4. Jason auf April 13, 2020 - Klicken Sie hier, um zu antworten
    Herzlichen Dank! Wirklich hilfreich
  5. dinesh kannan auf September 1, 2020 - Klicken Sie hier, um zu antworten
    It works man , danke
  6. Yu-Cheng,Chen auf November 1, 2021 - Klicken Sie hier, um zu antworten
    Ich habe viel Zeit damit verbracht, andere Methoden auszuprobieren, aber keine von ihnen hat funktioniert.

Sagen Sie einen Kommentar

Sie können einen Alias und gefälschte E-Mails verwenden Wenn Sie sich jedoch für die Verwendung einer echten E-Mail entscheiden, werden "Gravatare" unterstützt. Lesen Sie die Datenschutzerklärung für weitere Details.