Qué importa primero: WordPress utiliza loopback solicitudes para tareas programadas, el editor y operaciones de fondo. Fallo significa que el propio cliente HTTP del servidor no puede completar una solicitud al público del sitio URL.
Qué indica realmente este síntoma
El extremo frontal puede funcionar para los visitantes mientras que los loopbacks fallan internamente porque el servidor DNS, IPv6, TLS, autenticación básica o WAF sigue una ruta diferente.
Recopila pruebas antes de cambiar nada
- Copie el loopback exacto de URL y el error de Site Health.
- Solicita que URL desde el servidor WordPress e Inspecciona DNS, redireccionamientos y TLS.
- Comprobar si la protección de estadificación, la autenticación básica o las reglas de mantenimiento bloquean las llamadas internas.
- Compara la resolución IPv4 e IPv6 si el dominio publica ambos.
Causas más habituales
- Problema de auto-DNS: El servidor resuelve el dominio a una dirección inalcanzable u obsoleta.
- Límite de autenticación: Autenticación básica, SSO o una puerta de mantenimiento bloquean la solicitud interna.
- Fallo en la validación de TLS: El servidor no puede validar su propia cadena de certificados.
- Firewall o regla CDN: La IP saliente del servidor es desafiada o bloqueada al regresar a través del borde público.
Secuencia segura de diagnóstico y reparación
- Hacer que el canónico URL del sitio sea accesible desde el anfitrión sin debilitar la seguridad pública.
- Corregir la división DNS o la configuración de servidors solo cuando refleja la ruta de producción real.
- Permitir la ruta de bucle autenticada del servidor a través de la capa de protección específica.
- Volver a probar Site Health y una verdadera operación cron o editor que depende de loopbacks.
Cómo distinguir entre las causas probables
No trates Problema de auto-DNS y Límite de autenticación como causas equivalentes. El servidor resuelve el dominio a una dirección inalcanzable u obsoleta. En cambio, autenticación básica, SSO o una puerta de mantenimiento bloquean la solicitud interna. Para distinguirlas, usa estas dos comprobaciones: Copie el loopback exacto de URL y el error de Site Health; y solicita que URL desde el servidor WordPress e Inspecciona DNS, redireccionamientos y TLS. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Hacer que el canónico URL del sitio sea accesible desde el anfitrión sin debilitar la seguridad pública— o si debes conservar el estado actual y ampliar la investigación.
En un sitio de WordPress en producción, repite la petición que falla mientras compruebas una página que funciona correctamente y el área de administración. Un fallo aislado en una ruta requiere un rollback más acotado que un problema que afecta a PHP, la base de datos o todas las peticiones. Documenta la fecha y hora exactas, la URL o transacción afectada, el último estado correcto conocido y cada cambio realizado durante el diagnóstico. Ese registro permite distinguir una reparación reproducible de una desaparición temporal del síntoma.
Qué no debes hacer
No desactives las pruebas de loopback o cron como una solución. El fallo oculto aparecerá más tarde como tareas perdidas, actualizaciones estancadas o errores del editor.
Cómo verificar la reparación
- Site Health informa de una solicitud con éxito.
- Un solo evento programado se ejecuta sin un disparador cron externo.
- El editor de bloques y las comprobaciones de actualización de fondo se completan normalmente.
Que el síntoma visible desaparezca no es suficiente. Cierra la incidencia solo cuando la acción original que fallaba, el recorrido de negocio relacionado y los registros relevantes confirmen que el problema ha desaparecido.