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.