Qué importa primero: WordPress o un plugin esperó demasiado tiempo para un servicio externo. Los hechos importantes son el servidor de destino, operación, valor de tiempo de espera y si DNS, conexión o tiempo de respuesta se consumió.
Qué indica realmente este síntoma
Este error a menudo aparece en Site Health, actualizaciones, pagos pasarelas, licencias, webhooks o APIs remotas. El aumento del tiempo de espera puede ocultar una dependencia lenta mientras mantiene a los trabajadores PHP ocupados por más tiempo.
Recopila pruebas antes de cambiar nada
- Captura el error completo, incluyendo URL y duración del tiempo de espera.
- Prueba la resolución DNS, la conexión TCP y la respuesta HTTPS por separado del servidor.
- Identifica la operación plugin, tema o núcleo que hizo la solicitud.
- Compara una petición fallida con una solicitud exitosa de otra red o servidor.
Causas más habituales
- Latencia del servicio remoto: La API o punto final del proveedor es lento o no está disponible.
- Retardo DNS: El servidor no puede resolver el destino de forma rápida o consistente.
- Firewall saliente: Hosting o reglas de seguridad bloquean el destino o el puerto.
- Saturación del trabajador: El servidor local está demasiado ocupado para comenzar o completar la llamada de salida a tiempo.
Secuencia segura de diagnóstico y reparación
- Ejecute una solicitud cronometrada desde el servidor WordPress y Registra DNS, conéctese y tiempo total.
- Verifica el certificado de destino y redirija para que la solicitud no esté en bucle.
- Establazca un tiempo límite adecuado a la operación y maneje el fallo explícitamente.
- Mover llamadas de fondo no críticos fuera de las solicitudes de los visitantes cuando sea posible.
Cómo distinguir entre las causas probables
No trates Latencia del servicio remoto y Retardo DNS como causas equivalentes. La API o punto final del proveedor es lento o no está disponible. En cambio, el servidor no puede resolver el destino de forma rápida o consistente. Para distinguirlas, usa estas dos comprobaciones: Captura el error completo, incluyendo URL y duración del tiempo de espera; y prueba la resolución DNS, la conexión TCP y la respuesta HTTPS por separado del servidor. Con esos datos podrás decidir si conviene aplicar la primera acción controlada —Ejecute una solicitud cronometrada desde el servidor WordPress y Registra DNS, conéctese y tiempo total— 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 establazca tiempos de espera globales muy altos de HTTP. Una dependencia fallida puede entonces agotar a los trabajadores de PHP y convertir un problema de integración en una interrupción en todo el sitio.
Cómo verificar la reparación
- La solicitud externa se completa dentro de un plazo limitado predecible.
- El fallo se maneja sin bloquear cargas de página, checkout o cron.
- No aparecen nuevas entradas de cURL 28 durante una ventana de prueba representativa.
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.