{"id":1977,"date":"2026-08-20T13:36:34","date_gmt":"2026-08-20T10:36:34","guid":{"rendered":"https:\/\/allinonewpsettings.com\/blog\/?p=1977"},"modified":"2026-08-04T11:29:01","modified_gmt":"2026-08-04T11:29:01","slug":"wordpress-https-probleme-hinter-einem-reverse-proxy","status":"publish","type":"post","link":"https:\/\/allinonewpsettings.com\/blog\/de\/wordpress-https-probleme-hinter-einem-reverse-proxy\/","title":{"rendered":"WordPress-HTTPS hinter einem Reverse Proxy richtig konfigurieren"},"content":{"rendered":"

Ein Load Balancer terminiert TLS korrekt, leitet die Anfrage intern aber per HTTP an WordPress weiter. Ohne verl\u00e4ssliche Information dar\u00fcber, dass die \u00f6ffentliche Anfrage urspr\u00fcnglich per HTTPS einging, erzeugt WordPress unsichere URLs, falsche Cookies oder eine endlose Weiterleitung.<\/p>\n

Die L\u00f6sung ist ein klarer Vertrag zwischen Proxy und Anwendung: Der Proxy setzt die ma\u00dfgeblichen Header, WordPress vertraut ihnen nur aus bekannten Netzen und genau eine Ebene steuert die kanonische Weiterleitung.<\/p>\n

\nInhaltsverzeichnis<\/strong><\/p>\n
    \n
  1. Was das Thema bedeutet<\/a><\/li>\n
  2. Ein realistisches WordPress-Beispiel<\/a><\/li>\n
  3. Warum es wichtig ist und wann es eingesetzt wird<\/a><\/li>\n
  4. Der einfache Weg f\u00fcr Einsteiger<\/a><\/li>\n
  5. Der technische Weg<\/a><\/li>\n
  6. Risiken, h\u00e4ufige Fehler, Backup und Rollback<\/a><\/li>\n
  7. Wie AIOWS unterst\u00fctzt: AIOWS SSL Manager<\/a><\/li>\n
  8. Passende AIOWS-Artikel<\/a><\/li>\n
  9. Fazit und empfohlener Weg<\/a><\/li>\n
  10. Offizielle Quellen<\/a><\/li>\n<\/ol>\n<\/div>\n

    Wie HTTPS hinter einem Reverse Proxy funktioniert<\/h2>\n

    \u00d6ffentliches HTTPS und die Verbindung vom Proxy zum Ursprung sind zwei getrennte Strecken. Der Besucher kann sicher mit dem Proxy verbunden sein, w\u00e4hrend dieser intern HTTP verwendet. WordPress muss dann vor seiner URL-, Cookie- und Loginlogik erfahren, dass die urspr\u00fcngliche Anfrage per HTTPS kam.<\/p>\n

    Typische Signale sind Forwarded<\/code> oder X-Forwarded-Proto<\/code>. Sie sind nur vertrauensw\u00fcrdig, wenn der vorgeschaltete Proxy Clientwerte entfernt und selbst einen eindeutigen Wert setzt.<\/p>\n

    Ein realistisches WordPress-Beispiel<\/h2>\n

    Der Load Balancer h\u00e4ngt X-Forwarded-Proto: https<\/code> an einen bereits vom Client gesendeten Wert an. WordPress erh\u00e4lt eine uneinheitliche Liste und erkennt die Anfrage nicht sicher als HTTPS. Nach dem Login wechseln Redirects zwischen HTTP und HTTPS.<\/p>\n

    Der Proxy wird so konfiguriert, dass er eingehende Werte verwirft und den Header selbst setzt. Die Serverkonfiguration wertet ihn nur f\u00fcr Anfragen aus dem Proxy-Netz aus, bevor WordPress startet. Danach sind Admin-URLs und Secure-Cookies stabil.<\/p>\n

    Warum ein enger Vertrauensbereich n\u00f6tig ist<\/h2>\n

    Wer beliebigen Client-Headern vertraut, erm\u00f6glicht Angreifern, das verwendete Protokoll oder die Client-IP vorzut\u00e4uschen. Wer sie gar nicht ber\u00fccksichtigt, verursacht hinter TLS-Terminierung falsche URLs, Redirect-Schleifen und fehlerhafte OAuth- oder Webhook-Callbacks.<\/p>\n

    Der Ansatz ist relevant f\u00fcr 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\u00fcnglichen Anfrage und die Client-IP festlegt.<\/p>\n

    Der einfache Weg f\u00fcr Einsteiger<\/h2>\n
      \n
    1. Zeichnen Sie Browser, Proxy und WordPress-Ursprung als drei getrennte Stationen auf.<\/li>\n
    2. Notieren Sie, wo TLS endet und welche Header der Proxy setzt.<\/li>\n
    3. Beschr\u00e4nken Sie direkten Zugriff auf den Ursprung oder sichern Sie ihn gesondert.<\/li>\n
    4. Konfigurieren Sie die HTTPS-Erkennung vor dem WordPress-Start.<\/li>\n
    5. Lassen Sie nur eine Ebene f\u00fcr kanonische Redirects verantwortlich.<\/li>\n
    6. Testen Sie Login, REST, Formulare, Callbacks und Cookies \u00fcber den \u00f6ffentlichen Weg.<\/li>\n<\/ol>\n

      Der technische Weg<\/h2>\n

      Dokumentieren Sie f\u00fcr Forwarded<\/code>, X-Forwarded-Proto<\/code>, Host und Client-IP jeweils Quelle, zul\u00e4ssige Werte und \u00dcberschreibregel. Senden Sie am \u00f6ffentlichen Endpunkt absichtlich gef\u00e4lschte Header; der Proxy muss sie entfernen. Ein autorisierter Ursprungstest ohne Header zeigt, ob WordPress f\u00e4lschlich HTTPS annimmt.<\/p>\n