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

Weiterleitungsschleife bei einer WordPress-KI-Verbindung: HTTP, HTTPS und kanonische URL

Eine Weiterleitung ändert Schema, Host oder Pfad und kann Authentifizierungsheader verlieren.

Verfolgen Sie jede Weiterleitung und prüfen Sie Schema, Host, Pfad und Authorization.

Wahrscheinliche Ursachen

  • Eine Weiterleitung ändert Schema, Host oder Pfad und kann Authentifizierungsheader verlieren.
  • WordPress Home URL und Site URL verwenden unterschiedliche Schemata, Hosts oder Pfade.
  • Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.
  • Der Client ruft falsche Domain, Basispfad, REST-Route oder MCP-Endpunkt auf.
  • Hosting, Reverse Proxy, Weiterleitung oder WAF entfernt den Authorization-Header vor WordPress.

Diagnosereihenfolge

  1. Verfolgen Sie jede Weiterleitung und prüfen Sie Schema, Host, Pfad und Authorization.
  2. Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
  3. Prüfen Sie, ob WordPress selbst die Anfrage als HTTPS erkennt, nicht nur der Browser.
  4. Bestätigen Sie mit bereinigter Serverevidenz, dass der Authorization-Header WordPress erreicht.
  5. Bestätigen Sie Schema, Host, Basispfad und Endpunkt in der Client-Konfiguration.
  6. Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.

Die kleinste passende Korrektur anwenden

  1. Entfernen oder korrigieren Sie die unerwartet verändernde Weiterleitung.
  2. Richten Sie Home URL, Site URL, öffentlichen Host, HTTPS-Schema und REST-Basis aus.
  3. Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
  4. Konfigurieren Sie Server oder Proxy so, dass der Authorization-Header WordPress erreicht.
  5. Korrigieren Sie Endpunkt, Transport, Toolname oder Credential-Referenz ohne Berechtigungen zu erweitern.

Ergebnis überprüfen

  • Die authentifizierte Anfrage erreicht den kanonischen Endpunkt ohne unerwartete Weiterleitung.
  • Bereinigte Serverevidenz bestätigt, dass der Authorization-Header WordPress erreicht.
  • Die authentifizierte Anfrage entspricht dem vorgesehenen dedizierten Benutzer.
  • Der genehmigte enge Lesezugriff liefert reproduzierbar eine Antwort.

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.

Verwandte Leitfäden

Quellen und Überprüfung

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