cURL error 28 en WordPress y cómo resolverlo

Qué significa exactamente el error 28 en WordPress

Cuando WordPress muestra mensajes como cURL error 28, operation timed out o wp_remote_get error 28, está informando de que una petición saliente no ha podido completarse dentro del tiempo permitido.

Ese límite de tiempo afecta a muchas funciones internas del sistema. WordPress usa la API HTTP para comunicarse con repositorios, servicios externos, webhooks, herramientas de analítica, licencias de plugins, pasarelas de pago, motores de caché o servicios de seguridad. Si una de esas llamadas se queda esperando demasiado, aparece este aviso.

No siempre implica una caída total de la web. A veces el sitio carga con normalidad y el problema solo afecta a funciones concretas, como:

• actualizaciones automáticas que no terminan,
• errores en Site Health,
• fallos al conectar con APIs,
• retrasos en WooCommerce,
• problemas con REST API o loopback requests,
• cron interno que no llega a ejecutarse bien.

Causas más habituales del timeout

El error casi nunca tiene una única explicación. Estas son las causas más comunes y las que conviene revisar primero.

DNS lento o mal resuelto

Si el servidor tarda demasiado en resolver un dominio externo, la solicitud puede agotarse antes de iniciar la conexión real. Esto pasa con más frecuencia en hostings con resoluciones DNS lentas, cambios recientes de red o problemas temporales del proveedor.

Firewall, WAF o reglas de seguridad

Un cortafuegos del servidor, una protección del hosting o un sistema como ModSecurity puede bloquear o ralentizar peticiones salientes o llamadas internas al propio dominio. En algunos casos no las bloquea del todo, pero sí las deja pendientes hasta agotar el tiempo.

Plugins o temas que hacen llamadas externas

Algunos plugins consultan APIs con demasiada frecuencia o esperan respuestas de servicios de terceros que no responden bien. Es habitual en extensiones de SEO, traducción, backup, monitorización, feeds, licencias, automatizaciones o marketing.

Problemas con la REST API o las loopback requests

WordPress necesita poder llamarse a sí mismo en determinadas tareas. Si la REST API falla o el servidor no permite esas solicitudes internas, pueden aparecer errores 28 en salud del sitio, cron o editores visuales.

Saturación del servidor o recursos insuficientes

Si el hosting va justo de CPU, memoria o procesos PHP, una petición que normalmente sería rápida puede quedarse esperando demasiado. En entornos compartidos esto ocurre con más frecuencia en horas punta o con plugins pesados.

Proveedor externo caído o muy lento

A veces WordPress funciona bien, pero el servicio al que intenta acceder no responde a tiempo. En ese escenario, tocar la configuración local no soluciona el origen, aunque sí puede ayudar a aislarlo.

Cómo diagnosticar el problema sin ir a ciegas

Antes de cambiar ajustes del servidor o desactivar media web, conviene separar el síntoma de la causa. Un buen diagnóstico suele seguir este orden.

1. Identificar dónde aparece el error

No es lo mismo ver el aviso en Herramientas > Salud del sitio que en un plugin concreto, en WooCommerce o en el registro de depuración. Si el mensaje muestra una URL o dominio implicado, ya ofrece una pista importante.

2. Revisar si afecta a una función concreta o a todo el sitio

• Si falla solo una integración externa, el problema puede estar en esa API o en el plugin que la usa.
• Si fallan varias conexiones distintas, es más probable un problema de servidor, DNS o firewall.
• Si solo fallan las llamadas al propio dominio, conviene revisar loopback, REST API y reglas de seguridad.

3. Comprobar Salud del sitio y depuración

En muchos casos, WordPress muestra pistas adicionales en Salud del sitio. Si hace falta profundizar, activar temporalmente el modo de depuración puede ayudar a ver qué proceso dispara la petición lenta. Esa revisión debe hacerse con cuidado y, si es posible, en staging o con acceso controlado a logs.

4. Probar con plugins desactivados de forma temporal

Si sospechas de una extensión, lo razonable es desactivar solo las relacionadas con APIs, seguridad, caché, backups o automatizaciones, y comprobar si el timeout desaparece. Hacerlo en una tienda activa o en un sitio con tráfico requiere cautela, porque una desactivación precipitada puede afectar ventas, formularios o tareas programadas.

5. Revisar los registros del servidor

Los logs de Apache, Nginx, PHP o del panel de hosting suelen revelar bloqueos, límites de recursos, tiempos de ejecución, resoluciones fallidas o reglas de seguridad activadas. Cuando el error 28 persiste, este punto suele ser más útil que seguir probando ajustes al azar.

Pasos prácticos para solucionarlo

La solución depende del origen, pero estas acciones son las más razonables y habituales.

Actualizar WordPress, plugins y tema

Una versión antigua puede generar incompatibilidades con la API HTTP, librerías del servidor o servicios externos. Es una comprobación básica, pero conviene hacerla antes de escalar el diagnóstico.

Descartar conflicto con plugins

Si el error empezó tras instalar o actualizar un plugin, la sospecha es clara. Desactiva temporalmente el componente afectado y repite la acción que producía el timeout. Si desaparece, ya tienes una línea de trabajo concreta: reconfigurar, sustituir o escalar al desarrollador del plugin.

Comprobar DNS del servidor

Si el hosting resuelve mal dominios externos, algunas conexiones salientes pueden fallar aunque el sitio cargue bien para los usuarios. Este punto suele requerir intervención del proveedor, especialmente si el problema está en la red, en resolvers lentos o en una configuración del sistema que no controlas desde WordPress.

Revisar firewall, CDN o capa de seguridad

Si usas WAF, proxy, CDN o reglas estrictas de seguridad, conviene comprobar si están afectando llamadas a la REST API, al wp-cron o a conexiones salientes. En ocasiones, una exclusión bien planteada resuelve el timeout sin abrir riesgos innecesarios.

Confirmar que el servidor permite loopback y solicitudes salientes

Algunos entornos bloquean peticiones hacia el propio dominio o limitan conexiones externas por políticas de seguridad. Cuando WordPress no puede comunicarse consigo mismo, aparecen errores en programación de tareas, actualizaciones o plugins que dependen de llamadas internas.

Evaluar recursos del hosting

Si el problema coincide con picos de tráfico, procesos pesados o colas largas de PHP, puede ser una señal de que el plan actual se queda corto. Antes de cambiar de proveedor, conviene revisar consumo real, procesos concurrentes, caché y tareas automáticas mal optimizadas.

Aumentar el timeout solo si tiene sentido

Subir el tiempo de espera puede ser útil en casos concretos, pero no debería ser la primera ni la única medida. Si una API tarda demasiado por un bloqueo, un DNS lento o un servidor saturado, solo estarás retrasando el error. Aumentar el timeout sin diagnóstico puede ocultar el problema durante un tiempo, pero no resolverlo.

Errores frecuentes al intentar arreglarlo

• Desactivar plugins sin orden ni copia previa: puede romper funciones críticas y dificultar saber qué cambio produjo el efecto real.
• Culpar a WordPress sin revisar el servidor: el error 28 suele estar relacionado con red, recursos, DNS o terceros, no siempre con el núcleo.
• Aumentar límites a ciegas: más tiempo de espera no equivale a una solución estable.
• Ignorar el dominio que falla: si el mensaje menciona una URL concreta, esa pista vale más que probar ajustes genéricos.
• No revisar logs: cuando el error es persistente, los registros del servidor suelen ahorrar mucho tiempo.

Cuándo conviene escalar la revisión técnica

Si el timeout afecta pagos, sincronizaciones, reservas, envíos de formularios, conexiones con CRM o tareas automáticas, conviene revisar el problema con más método y menos ensayo-error. También merece escalarse cuando:

• el error aparece aunque hayas probado con plugins desactivados,
• afecta a varias APIs distintas,
• hay avisos en Salud del sitio sobre REST API o loopback,
• el hosting no ofrece una causa clara,
• el problema es intermitente y cuesta reproducirlo.

Para una revisión útil suelen hacer falta el mensaje exacto del error, fecha aproximada de inicio, cambios recientes en plugins o servidor, capturas de Salud del sitio y acceso a logs o panel de hosting. No siempre hace falta tocar producción de inmediato, y en muchos casos es preferible reproducirlo primero en un entorno de pruebas.

Conclusión práctica

El cURL error 28 en WordPress no es un fallo aislado, sino una señal de que una conexión necesaria está tardando más de lo debido. La forma más eficaz de solucionarlo es determinar qué solicitud falla, desde dónde se lanza y qué capa la está frenando. A partir de ahí, la corrección suele pasar por ajustar un plugin, revisar DNS, desbloquear peticiones internas, corregir reglas de seguridad o valorar si el hosting está limitado para el uso real del sitio.

Si el error aparece en procesos importantes o de forma recurrente, lo más prudente es evitar cambios masivos sin diagnóstico. Una revisión técnica ordenada suele ahorrar tiempo, reduce el riesgo de romper otras funciones y permite decidir si el problema está en WordPress, en la infraestructura o en un servicio externo.