PAGUP Agent ControlWordPress-Zugriff für KI-Assistenten
Kostenlos testen

WordPress erkennt HTTPS hinter Cloudflare oder einem Reverse Proxy nicht

Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.

Prüfen Sie, ob die exakt verwendete URL mit gültiger HTTPS-Verbindung lädt.

Wahrscheinliche Ursachen

  • Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.
  • Der Proxy übermittelt die Schema-Information nicht, die WordPress zur HTTPS-Erkennung benötigt.
  • WordPress Home URL und Site URL verwenden unterschiedliche Schemata, Hosts oder Pfade.
  • Eine Weiterleitung ändert Schema, Host oder Pfad und kann Authentifizierungsheader verlieren.
  • Ein anderes Plugin verändert HTTPS-Erkennung, REST-Zugriff oder Verfügbarkeit von Application Passwords.

Diagnosereihenfolge

  1. Prüfen Sie, ob die exakt verwendete URL mit gültiger HTTPS-Verbindung lädt.
  2. Prüfen Sie, ob WordPress selbst die Anfrage als HTTPS erkennt, nicht nur der Browser.
  3. Prüfen Sie vertrauenswürdige Proxy-Header für die Übermittlung des ursprünglichen HTTPS-Schemas.
  4. Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
  5. Verfolgen Sie jede Weiterleitung und prüfen Sie Schema, Host, Pfad und Authorization.
  6. Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.

Die kleinste passende Korrektur anwenden

  1. Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
  2. Richten Sie Home URL, Site URL, öffentlichen Host, HTTPS-Schema und REST-Basis aus.
  3. Entfernen oder korrigieren Sie die unerwartet verändernde Weiterleitung.
  4. Passen Sie nur die bestätigte False-Positive-Regel, Route oder Methode an.
  5. Eskalieren Sie mit bereinigter versionierter Evidenz, wenn das Verhalten pluginspezifisch bleibt.

Ergebnis überprüfen

  • Der Hinweis verschwindet nur unter der korrigierten Bedingung und kehrt nicht auf unbeteiligten Adminseiten zurück.
  • Die authentifizierte Anfrage erreicht den kanonischen Endpunkt ohne unerwartete Weiterleitung.
  • Der REST-Index antwortet über die kanonische HTTPS-URL und zeigt erwartete Namespaces.
  • Die authentifizierte Anfrage entspricht dem vorgesehenen dedizierten Benutzer.

Was Sie nicht tun sollten

  • Fügen Sie keinen ungeprüften dauerhaften Proxy-Workaround vor Bestätigung des Vertrauenspfads hinzu.
  • Deaktivieren Sie WAF oder Sicherheits-Plugin nicht global für eine einzelne Anfrage.
  • Bearbeiten Sie WordPress Core oder Drittanbieter-Plugin-Dateien nicht als ersten Diagnoseschritt.
  • Vergeben Sie keinen Administratorzugriff nur damit ein Verbindungstest gelingt.
  • Teilen Sie kein Application Password, keinen Authorization-Header, Token oder Cookie in Prompt, Ticket, Log oder Screenshot.

Häufige Fragen

Soll ich HTTPS mit einem dauerhaften Code-Snippet erzwingen?

Erst wenn Hosting- und Proxy-Vertrag verstanden sind. Ein generisches Snippet kann eine Origin-Fehlkonfiguration verbergen oder einem ungeprüften Forwarded-Header vertrauen.

Verwandte Leitfäden

Quellen und Überprüfung

Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .