Tecnología · GUÍA PRÁCTICA
Error 28 de curl: mide DNS, conexión, TLS y primer byte antes de ampliar límites
El error 28 indica que se alcanzó una condición de tiempo, no qué capa esperó. Registra las fases de curl, compara una sola variante y cambia el límite solo después de probar la fase lenta.

curl 28 es una alarma de presupuesto de tiempo. Puede ocurrir antes de crear una conexión TCP, durante TLS, mientras se espera el primer byte o después de empezar la transferencia. El mismo código exige reparaciones distintas. Conserva el comando y el entorno, mide fases acumuladas y cambia una variable cada vez.
Fija la reproducción antes de editar límites
Registra URL exacta sin secretos, método HTTP, host o CI, proxy, ruta DNS, familia IP y salida de curl -V. Ejecuta la misma solicitud en el entorno que falla y guarda el código. Que funcione en un entorno y falle en otro prueba una frontera, no que el servicio esté sano para todos los clientes.
Emite un registro de fases con --write-out
En una solicitud sin efectos muestra time_namelookup, time_connect, time_appconnect, time_starttransfer y time_total. Son tiempos acumulados desde el inicio. Compara valores adyacentes para aislar DNS, TCP, TLS, espera del primer byte y transferencia del cuerpo.
Clasifica la primera fase que no termina
Una demora de nombre apunta a DNS; una conexión TCP lenta o ausente a ruta, familia IP, cortafuegos, proxy o escucha. TCP completo seguido de TLS lento apunta al saludo o confianza. TLS completo con primer byte lento apunta al servidor o sus dependencias. Un fallo tardío con bytes recibidos apunta a rendimiento o cuerpo detenido.
Prueba una sola variante controlada
Mantén método y destino. Compara con un host conocido; si la política lo permite, prueba IPv4/IPv6, el proxy configurado o --resolve, uno por uno. No envíes credenciales de producción a otro host. Cada comparación debe responder una pregunta y conservar tiempos antes y después.
Separa presupuestos de conexión, transferencia y reintento
--connect-timeout limita la conexión; --max-time limita cada transferencia completa. Los reintentos reinician el contador por intento y --retry-max-time limita la ventana. Amplía el límite solo si la fase lenta es esperada y el trabajo puede esperar con seguridad.
Demuestra la corrección y conserva una reversión simple
Repite el comando original para distinguir una mejora de un éxito transitorio. Guarda tiempos, URL efectiva, estado HTTP, IP remota si existe, código de salida y el único cambio. Si la espera sigue sin explicación, restaura la configuración y escala con el registro; no desactives certificados ni controles de red.
