Ein Load Balancer terminiert TLS korrekt, leitet die Anfrage intern aber per HTTP an WordPress weiter. Ohne verlässliche Information darüber, dass die öffentliche Anfrage ursprünglich per HTTPS einging, erzeugt WordPress unsichere URLs, falsche Cookies oder eine endlose Weiterleitung.
Die Lösung ist ein klarer Vertrag zwischen Proxy und Anwendung: Der Proxy setzt die maßgeblichen Header, WordPress vertraut ihnen nur aus bekannten Netzen und genau eine Ebene steuert die kanonische Weiterleitung.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Wie HTTPS hinter einem Reverse Proxy funktioniert
Öffentliches HTTPS und die Verbindung vom Proxy zum Ursprung sind zwei getrennte Strecken. Der Besucher kann sicher mit dem Proxy verbunden sein, während dieser intern HTTP verwendet. WordPress muss dann vor seiner URL-, Cookie- und Loginlogik erfahren, dass die ursprüngliche Anfrage per HTTPS kam.
Typische Signale sind Forwardedoder X-Forwarded-Proto. Sie sind nur vertrauenswürdig, wenn der vorgeschaltete Proxy Clientwerte entfernt und selbst einen eindeutigen Wert setzt.
Ein realistisches WordPress-Beispiel
Der Load Balancer hängt X-Forwarded-Proto: httpsan einen bereits vom Client gesendeten Wert an. WordPress erhält eine uneinheitliche Liste und erkennt die Anfrage nicht sicher als HTTPS. Nach dem Login wechseln Redirects zwischen HTTP und HTTPS.
Der Proxy wird so konfiguriert, dass er eingehende Werte verwirft und den Header selbst setzt. Die Serverkonfiguration wertet ihn nur für Anfragen aus dem Proxy-Netz aus, bevor WordPress startet. Danach sind Admin-URLs und Secure-Cookies stabil.
Warum ein enger Vertrauensbereich nötig ist
Wer beliebigen Client-Headern vertraut, ermöglicht Angreifern, das verwendete Protokoll oder die Client-IP vorzutäuschen. Wer sie gar nicht berücksichtigt, verursacht hinter TLS-Terminierung falsche URLs, Redirect-Schleifen und fehlerhafte OAuth- oder Webhook-Callbacks.
Der Ansatz ist relevant für Load Balancer, CDN, Ingress Controller und klassische Reverse Proxys. Wird TLS auch bis zum Ursprung verwendet, sollte die Anwendung dennoch wissen, welcher Proxy den Hostnamen, das Protokoll der ursprünglichen Anfrage und die Client-IP festlegt.
Der einfache Weg für Einsteiger
- Zeichnen Sie Browser, Proxy und WordPress-Ursprung als drei getrennte Stationen auf.
- Notieren Sie, wo TLS endet und welche Header der Proxy setzt.
- Beschränken Sie direkten Zugriff auf den Ursprung oder sichern Sie ihn gesondert.
- Konfigurieren Sie die HTTPS-Erkennung vor dem WordPress-Start.
- Lassen Sie nur eine Ebene für kanonische Redirects verantwortlich.
- Testen Sie Login, REST, Formulare, Callbacks und Cookies über den öffentlichen Weg.
Der technische Weg
Dokumentieren Sie für Forwarded, X-Forwarded-Proto, Host und Client-IP jeweils Quelle, zulässige Werte und Überschreibregel. Senden Sie am öffentlichen Endpunkt absichtlich gefälschte Header; der Proxy muss sie entfernen. Ein autorisierter Ursprungstest ohne Header zeigt, ob WordPress fälschlich HTTPS annimmt.
- Prüfen Sie
is_ssl(),home,siteurlund Secure-Cookies. - Kontrollieren Sie Canonicals, REST-URLs und OAuth-Callbacks.
- Trennen Sie Healthchecks, die bewusst per HTTP zum Ursprung laufen.
- Erfassen Sie die vollständige Client-IP-Kette nur aus vertrauenswürdigen Proxys.
Risiken, häufige Fehler, Backup und Rollback
Gleichzeitige Änderungen an Datenbank-URLs, Proxy-Headern und Redirect-Regeln machen Fehler schwer rückführbar. Ebenso problematisch sind mehrere Weiterleitungsstellen oder ein öffentlich erreichbarer Ursprung, der fremde Forwarded-Header akzeptiert.
- Sichern Sie Proxy-, Server- und WordPress-Konfiguration.
- Ändern Sie zuerst die Header-Vertrauenskette, danach die Anwendung.
- Halten Sie einen serverseitigen Notfallzugang bereit.
- Rollen Sie zurück, wenn Login, REST oder Callbacks nach der Änderung ausfallen.
Wie AIOWS unterstützt:
AIOWS SSL Manager
AIOWS SSL Manager unterstützt die WordPress-seitige Kontrolle einer HTTPS-Konfiguration hinter einem Proxy. Sobald der Proxy das Protokoll der ursprünglichen öffentlichen Anfrage korrekt weitergibt, können Sie damit prüfen, ob WordPress sichere Adressen verwendet und die unterstützten SSL-Einstellungen konsistent sind.
Beginnen Sie mit der Proxygrenze: Stellen Sie sicher, dass der Proxy Clientwerte überschreibt und dass WordPress nur bekannten Proxy-Adressen vertraut. Prüfen Sie anschließend mit SSL Manager die Anwendungsebene und testen Sie Startseite, Login, Administration, REST, Formulare und Callbacks. Vergleichen Sie dabei eine öffentliche Anfrage mit einem autorisierten Ursprungstest, ohne den Ursprung allgemein zugänglich zu machen.
Das Modul kann keine externe Header-Regel am Load Balancer setzen, den direkten Origin-Zugang absichern oder eine falsche Client-IP-Kette reparieren. Diese Aufgaben gehören zur Infrastruktur. Halten Sie deshalb die vorherigen Proxy- und WordPress-Werte getrennt fest. Wenn nach einer unterstützten WordPress-Änderung Redirects oder Sitzungen fehlschlagen, stellen Sie den früheren Zustand wieder her und prüfen zuerst den Proxyvertrag. Erst wenn Spoofingtests scheitern, sichere Cookies gesetzt werden und alle wichtigen Anwendungspfade funktionieren, ist die Konfiguration belastbar.
Passende AIOWS-Artikel
- Cloudflare Flexible SSL verursacht eine WordPress-Weiterleitungsschleife
- WWW- oder Non-WWW-HTTPS-Weiterleitung in WordPress
- WordPress-SSL-Zertifikat und HTTPS-Status prüfen
Fazit und empfohlener Weg
Stellen Sie über einen klar begrenzten, überprüfbaren Proxyvertrag sicher, dass das Protokoll der öffentlichen Besucheranfrage korrekt an WordPress weitergegeben wird. Sichern Sie den Ursprung, normalisieren Sie Header vor WordPress und testen Sie neben der Anwendung auch, dass gefälschte Clientwerte wirkungslos bleiben.
