Zu viele Weiterleitungen nach der Umstellung von WordPress auf HTTPS

Was dieser Fehler bedeutet und wie du ihn erkennst

• Die Website funktionierte vor der HTTPS-Umstellung über HTTP und zeigt danach „zu viele Weiterleitungen“ an.
• Der Browser wechselt wiederholt zwischen HTTP und HTTPS oder fordert dieselbe HTTPS-Adresse immer wieder an.
• Die gesamte Website kann ausfallen, oder nur /wp-admin, die Anmeldeseite oder ausgewählte Pfade können in einer Schleife hängen.
• Beim Aufruf der HTTP-Adresse kann zunächst eine erwartete HTTPS-Weiterleitung erfolgen, gefolgt von wiederholten Weiterleitungen statt einer normalen Antwort.
• Im privaten Browsermodus oder auf einem anderen Gerät kann sich die Website anders verhalten, da Weiterleitungen, Cookies oder Websitedaten zwischengespeichert sein können.

Hauptursachen nach Wahrscheinlichkeit

1. Die WordPress-URL-Einstellungen verwenden weiterhin HTTP. Wenn entweder WordPress-Adresse (URL) oder Website-Adresse (URL) HTTP verwendet, während eine andere Ebene HTTPS verlangt, kann WordPress auf ein Protokoll umleiten, das mit der Richtlinie des Servers kollidiert.
2. HTTPS wird auf mehreren Ebenen erzwungen. Ein Sicherheits-Plugin, Logik in wp-config.php, eine .htaccess- oder Nginx-Regel, eine Hosting-Einstellung und eine Proxy-Regel können sich überschneiden oder unterschiedliche Annahmen über das Anfrageprotokoll treffen.
3. Ein CDN oder Reverse Proxy beendet TLS. Der Besucher verbindet sich über HTTPS, während die Verbindung zum Ursprung über HTTP erfolgt. Wenn das ursprüngliche Protokoll fehlt, falsch ist oder nicht sicher vertrauenswürdig behandelt wird, kann WordPress wiederholt annehmen, dass die Anfrage unsicher ist.
4. Ein Plugin oder Theme leitet einen bestimmten Pfad weiter. Plugins für Anmeldung, Administration, kanonische URLs, Sicherheit und Mitgliedschaften können nur /wp-login.php, /wp-admin oder ausgewählte Seiten betreffen.
5. Eine veraltete zwischengespeicherte Weiterleitung oder ein Browser-Cookie verschleiert die Korrektur. Dies ist als ursprüngliche Ursache weniger wahrscheinlich, kann aber den Eindruck erwecken, dass eine korrigierte Konfiguration weiterhin fehlerhaft ist.
6. Alte HTTP-Referenzen sind noch in Inhalten oder in der Konfiguration vorhanden. Diese verursachen normalerweise Warnungen zu gemischten Inhalten oder eine zusätzliche Weiterleitung, nicht jedoch eine websiteweite Weiterleitungsschleife. Untersuchen Sie sie, nachdem die Hauptkette repariert wurde.

So behebst du den Fehler

1. Weiterleitungskette untersuchen

Verwenden Sie für eine erste Prüfung ein privates Browserfenster. Wenn Sie Shell-Zugriff haben, setzen Sie eine Shell-Variable auf die tatsächliche HTTPS-Adresse der betroffenen Website und führen Sie diese schreibgeschützte Anfrage aus:

SITE_URL='the actual HTTPS site address'
curl -IL "$SITE_URL"

Notieren Sie jeden Statuscode und jeden Location:-Header. Ein Wechsel zwischen HTTP und HTTPS deutet normalerweise auf einen Konflikt bei der Protokollerkennung oder bei Weiterleitungsregeln hin. Die wiederholte Ausgabe derselben HTTPS-Adresse spricht eher für eine kanonische Weiterleitung, ein Plugin, einen Proxy oder eine zwischengespeicherte Weiterleitung. Übergeben Sie keine Zugangsdaten, Cookies oder Autorisierungs-Header.

2. Beide WordPress-URL-Einstellungen prüfen

Wenn das Dashboard verfügbar ist, öffnen Sie Einstellungen → Allgemein und prüfen Sie, ob WordPress-Adresse (URL) und Website-Adresse (URL) denselben vorgesehenen HTTPS-Ursprung verwenden, einschließlich eines gegebenenfalls erforderlichen Unterverzeichnisses.

Wenn die Schleife den Zugriff auf das Dashboard verhindert, kann ein autorisierter Administrator mit SFTP- oder Datenbankzugriff die Werte vorübergehend in wp-config.php definieren:

define( 'WP_HOME', 'the actual canonical HTTPS address' );
define( 'WP_SITEURL', 'the actual canonical HTTPS address' );

Erstellen Sie zuerst eine Sicherung der Datei und nehmen Sie eine kontrollierte Änderung vor. Solange diese Konstanten definiert sind, überschreiben sie die entsprechenden Dashboard-Felder. Entfernen oder verwalten Sie sie daher nach dem Test bewusst.

3. Feststellen, wo TLS beendet wird

Ermitteln Sie, ob der Browser direkt eine Verbindung zum Webserver herstellt oder ein CDN, ein Load Balancer oder ein Reverse Proxy dazwischengeschaltet ist. Wenn ein Proxy TLS beendet, kann der Ursprung eine HTTP-Verbindung erhalten, obwohl der Besucher HTTPS verwendet hat.

Bitten Sie den Hosting- oder Proxy-Administrator zu bestätigen, dass das ursprüngliche Protokoll konsistent weitergeleitet wird und WordPress es nur von dem vorgesehenen vertrauenswürdigen Proxy erkennt. Vertrauen Sie X-Forwarded-Proto nicht blind von beliebigen Clients; ein nicht validierter weitergeleiteter Header kann Sicherheitsprobleme verursachen.

4. HTTPS-Erzwingung auf eine gezielte Ebene reduzieren

Listen Sie alle Stellen auf, die HTTP auf HTTPS umleiten können:

• CDN- oder Load-Balancer-Regeln
• SSL-Einstellungen im Hosting-Panel
• Apache-.htaccess- oder Nginx-Konfiguration
• Sicherheits- oder SSL-Plugins
• Benutzerdefinierter Code in wp-config.php oder im Theme

Belassen Sie die Erzwingung auf der Ebene, die zur Hosting-Architektur passt, üblicherweise am Edge oder auf dem Webserver, und deaktivieren Sie konkurrierende Weiterleitungen auf Anwendungsebene. Sichern Sie die Konfiguration und holen Sie die Zustimmung eines Administrators ein, bevor Sie Serverregeln ändern. Validieren Sie die Konfiguration vor jedem genehmigten Reload oder Neustart. Starten Sie einen Webserver in der Produktion nicht als ersten Diagnoseschritt neu.

5. Anmelde- und Administrationspfade separat testen

Wenn das Frontend funktioniert, aber /wp-admin oder die Anmeldung in einer Schleife hängt, prüfen Sie kürzlich geänderte Sicherheits-, Anmelde-, Kanonische-URL- und Caching-Plugins mithilfe eines genehmigten Wartungsverfahrens. Ein Plugin-Konflikt ist wahrscheinlicher, wenn nur ein Pfad betroffen ist. Wenn ein Plugin zum Test deaktiviert werden muss, dokumentieren Sie die Änderung, bewahren Sie Zugriffskontrollen und aktivieren oder ersetzen Sie es nach dem Test wieder.

6. Caches leeren und erneut testen

Nachdem Sie das ursprüngliche Verhalten dokumentiert und eine kontrollierte Korrektur vorgenommen haben, löschen Sie die Websitedaten des Browsers und leeren Sie WordPress-Seiten- oder Objekt-Caches sowie Hosting- und CDN-Caches. Testen Sie erneut die HTTP-Adresse, die HTTPS-Startseite, die Anmeldeseite und eine repräsentative interne Seite. Eine zwischengespeicherte 301- oder 302-Weiterleitung kann bestehen bleiben, nachdem die aktive Konfiguration korrigiert wurde.

7. Verbleibende HTTP-Referenzen aktualisieren

Sichern Sie die Datenbank, bevor Sie gespeicherte URLs ändern, sobald die Weiterleitungskette repariert ist. Verwenden Sie ein zuverlässiges WordPress-Migrationstool oder WP-CLI für eine Suche-und-Ersetzen-Operation, zunächst mit einem Dry Run, und verwenden Sie ein Tool, das serialisierte WordPress-Daten verarbeitet. Ersetzen Sie nur den alten Website-Ursprung durch den HTTPS-Ursprung. Ersetzen Sie nicht pauschal jeden http://-Wert, da URLs von Drittanbietern und absichtlich externe Ressourcen möglicherweise nicht zur Website gehören.

Vorbeugung und Überprüfung der Lösung

• Dokumentieren Sie den kanonischen HTTPS-Ursprung der Website und aktualisieren Sie während der Migration beide WordPress-URL-Einstellungen.
• Wählen Sie einen dokumentierten Ort für die HTTP-zu-HTTPS-Weiterleitung und prüfen Sie die anderen Ebenen, bevor Sie ein Force-SSL-Plugin aktivieren.
• Dokumentieren Sie, ob ein CDN oder Reverse Proxy TLS beendet und wie der Ursprung das ursprüngliche Protokoll erfährt.
• Testen Sie nach jeder Änderung der HTTPS-Konfiguration die Startseite, eine interne Seite, die Anmeldung und das Dashboard.
• Sichern Sie Konfiguration und Datenbank, bevor Sie wp-config.php, Rewrite-Regeln oder gespeicherte URLs bearbeiten.
• Führen Sie nach der Aktivierung der Weiterleitungen eine gezielte Migration auf HTTPS-URLs durch und prüfen Sie auf Referenzen zu gemischten Inhalten.

Häufig gestellte Fragen