Ihre Website konnte keine Loopback-Anfrage abschließen
WordPress hat eine HTTP-Anfrage an seine eigene Adresse gestellt und keine Antwort erhalten. Mehrere Funktionen hängen davon ab, dass es funktioniert.
Your site could not complete a loopback request. This may prevent the Site Health check from working…
Machen Sie die gleiche Anfrage, die die Site vom Server selbst macht, und lesen Sie, was zurückkommt. Eine abgelehnte Verbindung, ein TLS-Fehler und ein 401 sind drei verschiedene Probleme, und die Antwort sagt Ihnen, welches Sie in einem einzigen Befehl haben.
Die wahrscheinlichsten Ursachen zuerst.
Gehen Sie die Liste der Reihe nach durch. Prüfen Sie jede Ursache, bevor Sie etwas ändern, da die Lösungen unterschiedlich sind und eine Vermutung mehr Zeit kostet als ein Befehl.
| Ursache | So prüfen Sie es | Lösung |
|---|---|---|
| HTTP-Authentifizierung vor der Website | Die Anfrage gibt 401 zurück. Eine Staging-Site hinter einem Benutzernamen und einem Passwort ist der klassische Fall - der Browser kennt die Anmeldeinformationen und WordPress nicht. | Entferne den Loopback-Pfad von der Authentifizierung oder gib WordPress die Anmeldeinformationen für seine eigenen Anforderungen. |
| Der Server kann seinen eigenen Hostnamen nicht auflösen | Die Anforderung schlägt mit einem DNS-Fehler fehl, während die gleiche URL von Ihrem Laptop aus funktioniert. Der öffentliche Datensatz existiert; der maschineneigene Resolver weiß es nicht. | Fügen Sie einen Hosteintrag hinzu, der auf die Domain der Site an die Loopback-Adresse verweist, so dass der Server anfordert, lokal zu bleiben, anstatt hinaus und zurück zu gehen. |
| Eine Firewall blockiert ausgehende Anfragen an sich selbst | Die Verbindung wird abgelehnt oder läuft ohne HTTP-Antwort aus, und im Zugriffsprotokoll der Website erscheint nichts. | Der Server kann seine eigene öffentliche Adresse und seinen Port erreichen. Egress-Regeln, die nur wenige Ziele erlauben, fangen diesen Fall, ohne dass es jemand merkt. |
| Ein Zertifikat, dem der Server nicht vertraut | Die Anforderung schlägt bei der TLS-Verifizierung fehl - selbstsignierte oder unvollständige Kette -, während ein Browser sie akzeptiert, weil Browser einen anderen Trust-Store tragen. | Installieren Sie die vollständige Zertifikatskette oder zeigen Sie den Loopback auf http auf der lokalen Schnittstelle, damit TLS nicht an einer Anforderung beteiligt ist, die den Computer niemals verlässt. |
Schritt für Schritt zur Lösung.
Die Befehle setzen WP-CLI und Shell-Zugriff voraus. Jeder Schritt erklärt, was er tut, damit Sie ihn bei Bedarf im Dashboard oder per SFTP ausführen können.
Stellen Sie die Anfrage, die die Website stellt
Führen Sie dies auf dem Server aus, nicht auf Ihrem Laptop. Der Unterschied ist der ganze Punkt des Checks.
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-cron.phpBitten Sie WordPress, es zu versuchen, und drucken Sie den Fehler
Die WP HTTP API wendet ihre eigenen Timeouts und TLS-Einstellungen an, so dass sich das Ergebnis von den Curls unterscheiden kann.
wp eval '$r = wp_remote_get( home_url( "/" ) ); echo is_wp_error( $r ) ? $r->get_error_message() : wp_remote_retrieve_response_code( $r ), PHP_EOL;'
Behalten Sie die Anforderung auf der Maschine
Ein Host-Eintrag entfernt DNS und die Rundreise durch den Rand aus der Gleichung.
# /etc/hosts 127.0.0.1 example.com www.example.com
Wenn es HTTP auth ist, lassen Sie die Site daran vorbei
Legen Sie die Anmeldeinformationen fest, die WordPress für seine eigenen Anforderungen verwenden soll, in wp-config.php.
define( 'WP_HTTP_BASIC_AUTH_USER', 'staging' ); define( 'WP_HTTP_BASIC_AUTH_PASS', 'the-password' );
Re-Run Site Health und Check Cron aufgegriffen
Ein wiederhergestellter Loopback löscht normalerweise sofort einen Rückstand an geplanten Ereignissen, was die praktische Bestätigung ist.
wp cron event list --fields=hook,next_run_relative
Darum kümmert sich die Plattform.
Cron läuft von der Plattform und nicht durch eine Anfrage, die die Site an sich selbst stellt, so dass ein fehlgeschlagener Loopback die geplante Arbeit hier nicht stoppen kann - was diesen Fehler anderswo so schädlich macht: Es stoppt die Veröffentlichung, Updates und Schlangen-E-Mails auf einmal, ohne dass es in der Benutzeroberfläche so ist. Staging-Sites sind ohne HTTP auth im Anfragepfad geschützt, so dass die häufigste Ursache nicht auftritt.
Häufige Fragen.
Ist das wirklich etwas zu brechen, oder nur eine Warnung?
Es scheitert nur an der Inszenierung. Warum?
Kann ich es ignorieren, wenn cron von einem Systemplan aus läuft?
Warum funktioniert es von meinem Browser aus, aber nicht vom Server?
War es keiner davon?
Diese Fehler können im Browser ähnlich aussehen.