NuevoBlack Friday: 50 % de descuento en tu primer pago
Solución de problemas de WordPress

Su sitio no pudo completar una solicitud de devolución

WordPress hizo una solicitud HTTP a su propia dirección y no obtuvo una respuesta. Varias características dependen de que funcione.

Your site could not complete a loopback request. This may prevent the Site Health check from working…

Respuesta breve

Haga la misma petición que el sitio hace, desde el servidor en sí, y lea lo que vuelve. Una conexión rechazada, un error TLS y un 401 son tres problemas diferentes, y la respuesta le dice cuál tiene en un solo comando.

Diagnóstico

Las causas más probables primero.

Revisa la lista en orden. Cada comprobación permite confirmar o descartar una causa antes de hacer cambios: las soluciones son distintas y adivinar cuesta más que ejecutar un comando.

CausaCómo comprobarloSolución
autenticación HTTP delante del sitioLa solicitud devuelve 401. Un sitio de puesta en escena detrás de un nombre de usuario y contraseña es el caso clásico — el navegador sabe las credenciales y WordPress no.Exemptrema el camino de vuelta de la autenticación, o da WordPress las credenciales para sus propias solicitudes. La eliminación de la protección no es necesaria.
El servidor no puede resolver su propio nombre de hostLa solicitud falla con un error DNS mientras que la misma URL funciona desde su computadora portátil. El registro público existe; el propio resolver de la máquina no lo sabe.Agregue una entrada de hosts indicando el dominio del sitio en la dirección de la vuelta, por lo que solicita que el servidor se mantenga local en lugar de salir y volver.
Un cortafuegos bloquea las solicitudes de salida para sí mismoLa conexión se rechaza o se da unas veces sin respuesta HTTP, y nada aparece en el registro de acceso del sitio.Permitir al servidor alcanzar su propia dirección pública y puerto. Reglas de Egress que no permiten nada más que algunos destinos capturan este caso sin que nadie note.
Un certificado que el servidor no confíaLa solicitud no se aplica a la verificación TLS — cadena auto-firmada o incompleta— mientras que un navegador la acepta porque los navegadores llevan una tienda de confianza diferente.Instala la cadena de certificado completo, o señala el bucleback en http en la interfaz local, por lo que TLS no está involucrado en una solicitud que nunca deja la máquina.
Guía

Solución paso a paso.

Los comandos requieren WP-CLI y acceso a la consola. Si no los tienes, cada paso explica cómo hacer lo mismo desde el panel o por SFTP.

  1. Haga la solicitud que el sitio está haciendo

    Ejecute esto en el servidor, no en su portátil. La distinción es el punto completo del cheque.

    curl -sS -o /dev/null -w '%{http_code}\n' https://example.com/wp-cron.php
  2. Pida a WordPress para probar, e imprimir el fracaso

    La API WP HTTP aplica sus propios timeouts y ajustes TLS, por lo que su resultado puede diferir de la rúbrica.

    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;'
  3. Mantenga la solicitud en la máquina

    Una entrada de hosts elimina DNS y el viaje redondo a través del borde de la ecuación.

    # /etc/hosts
    127.0.0.1  example.com www.example.com
  4. Si es HTTP auth, que el sitio lo supere

    Establecer las credenciales WordPress debe utilizar para sus propias solicitudes, en wp-config.php.

    define( 'WP_HTTP_BASIC_AUTH_USER', 'staging' );
    define( 'WP_HTTP_BASIC_AUTH_PASS', 'the-password' );
  5. Re-run Site Health y check cron atrapado

    Un retroceso restaurado generalmente aclara un atraso de los eventos programados inmediatamente, que es la confirmación práctica.

    wp cron event list --fields=hook,next_run_relative
En MagicWP

De esto se encarga la plataforma.

Cron se ejecuta desde la plataforma en lugar de a través de una solicitud que el sitio se hace a sí mismo, por lo que un fallo de la vuelta no puede detener el trabajo programado aquí — lo que hace que este fracaso tan dañino en otro lugar: deja de publicar, actualizaciones y correo electrónico apagado a la vez, sin nada en la interfaz para decirlo.

Preguntas frecuentes

Preguntas frecuentes.

¿Esto está rompiendo algo o sólo una advertencia?
Rompe cosas reales en silencio: WP-Cron, el plugin y la protección mortal del terrorismo de los editores temáticos, y algunas revisiones de actualización dependen de que el sitio se alcance. Nada muestra un error — el trabajo simplemente no sucede.
Sólo falla en el estancamiento. ¿Por qué?
El apilamiento es generalmente el único sitio detrás de la autenticación HTTP, y que devuelve 401 a cada solicitud incluyendo el propio sitio. Es la causa más común de esta advertencia.
¿Puedo ignorarlo si el cron funciona de un programa de sistema?
En gran medida, sí — un cron del sistema que utiliza WP-CLI no hace ninguna solicitud HTTP, por lo que la dependencia más importante ya está cubierta. La protección mortal del terrorismo de los editores todavía utiliza el retroceso.
¿Por qué funciona desde mi navegador pero no desde el servidor?
Su navegador resuelve DNS públicamente y lleva una tienda de confianza de certificado completo. El servidor puede resolver de manera diferente, ser bloqueado por sus propias reglas de egreso, o rechazar una cadena que su navegador acepta.
Errores relacionados

Si el problema era otro.

Estos errores pueden parecerse en el navegador.