Votre site n'a pas pu compléter une demande de loopback
WordPress a fait une requête HTTP à sa propre adresse et n'a pas obtenu de réponse. Plusieurs fonctionnalités dépendent de ce travail.
Your site could not complete a loopback request. This may prevent the Site Health check from working…
Faites la même requête que le site fait, à partir du serveur lui-même, et lisez ce qui revient. Une connexion refusée, une erreur TLS et une 401 sont trois problèmes différents, et la réponse vous indique lequel vous avez dans une seule commande.
Les causes les plus probables d’abord.
Parcourez la liste dans l’ordre. Vérifiez chaque cause avant de modifier quoi que ce soit : les correctifs diffèrent et une supposition coûte plus cher qu’une commande.
| Cause | Comment vérifier | Correctif |
|---|---|---|
| Authentification HTTP devant le site | La requête retourne 401. Un site de mise en scène derrière un nom d'utilisateur et mot de passe est le cas classique — le navigateur connaît les identifiants et WordPress ne le fait pas. | Exemptez le chemin loopback de l'authentification, ou donnez à WordPress les identifiants pour ses propres demandes. |
| Le serveur ne peut pas résoudre son propre nom d'hôte | La requête échoue avec une erreur DNS alors que la même URL fonctionne depuis votre ordinateur portable. L'enregistrement public existe; le propre résolveur de la machine ne le sait pas. | Ajoutez une entrée d'hôtes pointant le domaine du site à l'adresse loopback, donc les requêtes du serveur se font rester local au lieu de sortir et de revenir. |
| Un pare-feu bloque les requêtes sortantes pour lui-même | La connexion est refusée ou est parfois hors de la portée sans réponse HTTP, et rien n'apparaît dans le journal d'accès du site. | Permettre au serveur d'atteindre son propre adresse publique et son propre port. Règles d'évacuation qui ne permettent rien d'autre que quelques destinations attraper ce cas sans que personne ne s'en rende compte. |
| Un certificat que le serveur ne fait pas confiance | La demande échoue sur la vérification TLS — chaîne autosignée ou incomplète — alors qu'un navigateur l'accepte parce que les navigateurs possèdent un magasin de fiducie différent. | Installez la chaîne complète du certificat ou pointez le loopback à http sur l'interface locale afin que TLS ne soit pas impliqué dans une requête qui ne quitte jamais la machine. |
Corriger l’erreur, étape par étape.
Les commandes supposent un accès à WP-CLI et au terminal. Si vous n’en disposez pas, chaque étape explique comment procéder depuis le tableau de bord ou via SFTP.
Faire la demande que le site fait
Exécutez ceci sur le serveur, pas sur votre ordinateur portable. La distinction est le point entier de la vérification.
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-cron.phpDemandez à WordPress d'essayer, et imprimez l'échec
L'API HTTP WP applique ses propres timeouts et les paramètres TLS, de sorte que son résultat peut différer de celui de curl.
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;'
Gardez la demande sur la machine
Une entrée hôte enlève le DNS et le voyage aller-retour à travers le bord de l'équation.
# /etc/hosts 127.0.0.1 example.com www.example.com
Si c'est HTTP auth, laissez le site le passer
Définir les identifiants WordPress devrait utiliser pour ses propres requêtes, dans wp-config.php.
define( 'WP_HTTP_BASIC_AUTH_USER', 'staging' ); define( 'WP_HTTP_BASIC_AUTH_PASS', 'the-password' );
Re-cours santé du site et vérifier cron rattrapé
Une boucle de retour restaurée permet généralement de rattraper immédiatement un retard dans les événements prévus, ce qui est la confirmation pratique.
wp cron event list --fields=hook,next_run_relative
Ce que la plateforme prend en charge.
Cron s'exécute depuis la plate-forme plutôt que par une requête que le site se fait, donc un loopback défaillant ne peut pas arrêter le travail programmé ici — ce qui rend cet échec si dommageable ailleurs: il arrête la publication, les mises à jour et les courriels en attente à la fois, sans rien dans l'interface pour le dire. Les sites de positionnement sont protégés sans HTTP auth dans le chemin de requête, de sorte que la cause la plus commune ne se pose pas.
Questions fréquentes.
Est-ce que ça brise quelque chose ou juste un avertissement ?
Ça échoue seulement sur la mise en scène.
Puis-je l'ignorer si cron fonctionne à partir d'un planning système ?
Pourquoi ça marche depuis mon navigateur, mais pas depuis le serveur ?
Si le problème vient d’ailleurs.
Ces erreurs peuvent se présenter de façon similaire dans le navigateur.