Ein Websitebetreiber aktiviert gleichzeitig ein HTTPS-Plugin, eine Apache-Regel und die entsprechende CDN-Funktion. Daraufhin springen Anfragen zwischen HTTP und HTTPS, weil das CDN den Ursprung per HTTP erreicht und WordPress jede weitergeleitete Anfrage für unsicher hält.
Eine zusätzliche Weiterleitung verschärft den Fehler. Benötigt werden funktionierendes TLS, ein eindeutiger kanonischer Host, genau eine zuständige Stelle für die Weiterleitung und verlässliche Protokollinformationen zwischen Proxy und WordPress.
- 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 Rückweg
- Wie AIOWS unterstützt: AIOWS SSL Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
HTTPS zu erzwingen bedeutet, unterstützte HTTP-Anfragen auf eine kanonische HTTPS-Adresse umzuleiten, nachdem Zertifikat und verschlüsselter Übertragungsweg funktionieren. Die Regel kann beim CDN, Webserver oder in WordPress liegen; dieselbe Entscheidung sollte jedoch nicht mehrfach getroffen werden.
Bei einem Proxy kann der Besucher HTTPS nutzen, während die Verbindung zu WordPress per HTTP erfolgt. WordPress darf weitergeleitete Protokoll-Header nur von bekannten Proxys übernehmen. Andernfalls drohen Schleifen oder manipulierte Angaben.
Ein realistisches WordPress-Beispiel
Im Beispiel leitet das CDN Besucher auf HTTPS um, der Ursprung sieht jedoch eine HTTP-Verbindung und das Plugin reagiert mit einer weiteren Weiterleitung. Zusätzlich ändert die Apache-Regel den Hostnamen. Dadurch geraten auch Webhooks und wp-adminin die Schleife.
Nachdem direktes HTTPS am Ursprung geprüft wurde, übernimmt das CDN allein die öffentliche Weiterleitung. WordPress wertet das Proxyschema aus einer vertrauenswürdigen Quelle aus; die doppelten Plugin- und Apache-Regeln entfallen. So erreicht jede Kombination aus Host und Protokoll das Ziel genau einmal.
Warum es wichtig ist und wann es eingesetzt wird
Einheitliches HTTPS schützt Sitzungen und Formulardaten und verhindert, dass WordPress Adressen mit unterschiedlichen Protokollen erzeugt. Fehlerhafte Regeln können dagegen Besucher und Administratoren aussperren, API-Callbacks unterbrechen oder eine Schleife am Edge zwischenspeichern.
Die Erzwingung beginnt erst, wenn alle öffentlichen Hostnamen gültige Zertifikate besitzen, der Weg zum Ursprung geklärt ist und WordPress die vorgesehenen kanonischen Adressen verwendet. HSTS wird später separat bewertet, weil Browser diese Vorgabe langfristig speichern.
Der einfache Weg für Einsteiger
- Prüfen Sie, ob jeder unterstützte Hostname direkt per HTTPS und mit gültigem Zertifikat erreichbar ist.
- Notieren Sie WordPress- und Website-Adresse, CDN-Modus, Webserverregeln und vorhandene Plugin-Weiterleitungen.
- Bestimmen Sie genau eine Stelle für die HTTP-zu-HTTPS-Weiterleitung und deaktivieren Sie Überschneidungen.
- Ist ein vertrauenswürdiger Proxy vorgeschaltet, muss WordPress dessen weitergeleitetes Protokoll sicher erkennen.
- Testen Sie Hauptdomain und
www, HTTP und HTTPS, Anmeldung, Abmeldung, Passwort-Reset, Formulare, REST-Anfragen und Webhooks, bevor die Regel dauerhaft wird.
Der technische Weg
Erstellen Sie eine kleine Matrix der öffentlichen Hostnamen und Protokolle und prüfen Sie Status sowie Location-Header ohne Cookies. Eine HTTP-Anfrage sollte den HTTPS-Host üblicherweise mit genau einer Weiterleitung erreichen; eine korrekte HTTPS-Anfrage darf nicht allein wegen der internen Proxyverbindung erneut umgeleitet werden.
Kontrollieren Sie die Vertrauensgrenze für Forwardedund X-Forwarded-Proto, Multisite-Domain-Mapping, Healthchecks, OAuth- und Zahlungs-Callbacks, REST und XML-RPC, geplante Aufrufe sowie Caches für Weiterleitungen.
Risiken, häufige Fehler, Backup und Rückweg
Kombinieren Sie nicht unkoordiniert Plugin-, Server- und CDN-Regeln und vertrauen Sie nicht den Forwarded-Headern beliebiger Clients. Verfrühte Datenbankänderungen, umgeleitete Healthchecks, gecachte Schleifen und HSTS während der Fehlersuche erschweren die Wiederherstellung.
Ein geprüfter Zugang zum Ursprung oder zur Administration muss erhalten bleiben. Fallen Anmeldung, Callbacks oder Healthchecks aus, deaktivieren Sie die einzelne neue Regel und stellen Sie gegebenenfalls die vorherigen WordPress-Adressen wieder her. Geleert wird nur der von der Änderung betroffene Weiterleitungs-Cache.
Wie AIOWS unterstützt:
AIOWS SSL Manager
Der AIOWS SSL Manager zeigt unterstützte WordPress-Einstellungen für HTTPS, Weiterleitungen und Mixed Content an einer Stelle. Er kann die WordPress-seitige Weiterleitung übernehmen, wenn diese Zuständigkeit bewusst gewählt und konkurrierende Regeln entfernt wurden.
Vor der Aktivierung müssen Zertifikat und Verbindung zum Ursprung funktionieren, die kanonischen WordPress-Adressen feststehen und ein Rückweg zur Administration verfügbar sein. Danach folgen die Host-Protokoll-Matrix sowie Tests von Anmeldung, Formularen, REST-Aufrufen und Callbacks.
Externe Zertifikate, den Origin-Modus eines CDN oder Webserverregeln kann das Modul nicht korrigieren. Die jeweiligen Betreiber müssen diese Ebenen so abstimmen, dass AIOWS verlässliche Protokollinformationen erhält und nicht gegen eine zweite Weiterleitung arbeitet.
Passende AIOWS-Artikel
- Mixed Content in WordPress beheben: HTTPS-Fehler richtig lösen
- WordPress trotz SSL nicht sicher: Vollständige Fehlerbehebung
- HTTP mit .htaccess auf HTTPS in WordPress umleiten
Fazit und empfohlener Weg
Prüfen Sie zuerst das TLS-Vertrauen, legen Sie einen kanonischen Host und genau eine Stelle für Weiterleitungen fest und behandeln Sie das Proxyschema ausdrücklich. Erst nach Tests aller Host-Protokoll-Kombinationen, der Verwaltung und der Callbacks sollte die Regel dauerhaft werden; HSTS bleibt eine eigene Entscheidung.
