Timeouts predeterminados de los clientes HTTP por lenguaje y biblioteca: ninguno, 5 segundos o 100 segundos

Qué es

Cliente	Valor por defecto si no se configura ningún timeout
Python requests	ninguno — "requests do not time out unless a timeout value is set explicitly. Without a timeout, your code may hang for minutes or more"
Python httpx	5 segundos — "raise a TimeoutException after 5 seconds of network inactivity", aplicado por separado a la conexión, la lectura, la escritura y la obtención de una conexión del pool
Go net/http.Client	ninguno a nivel global — "A Timeout of zero means no timeout", y cero es el valor cero de la estructura; http.DefaultTransport solo limita el establecimiento de la conexión (30 s) y el handshake TLS (10 s)
.NET HttpClient.Timeout	100 segundos — "default value is 100,000 milliseconds"
curl, fase de conexión (CURLOPT_CONNECTTIMEOUT, --connect-timeout)	300 segundos
curl, transferencia completa (CURLOPT_TIMEOUT, --max-time)	ninguno — "0 (zero) which means it never times out during transfer"
axios	ninguno — "default is 0 (no timeout)"
Node.js undici y el fetch global basado en él (headersTimeout/bodyTimeout)	300 segundos cada uno (300e3 ms), más un connectTimeout de 10 segundos; sin un plazo global para la petición

Por qué importa

Limitarse a «usar el valor por defecto de la biblioteca» no es seguro, porque los valores predeterminados van desde unos pocos segundos de margen hasta una espera prácticamente ilimitada. La propia documentación de requests advierte de que omitir el timeout puede bloquear el código "for minutes or more"; en la práctica, indefinidamente, porque hereda el comportamiento bloqueante del socket del sistema operativo. En el http.Client de Go ocurre lo mismo: un campo Timeout con valor cero, que es con el que arranca &http.Client{}, significa que no hay timeout global; el transporte por defecto solo limita el establecimiento de la conexión, de modo que un servidor que acepta la conexión y después se queda detenido mantiene la llamada abierta. curl incluye dos parámetros de timeout distintos con valores por defecto distintos: CURLOPT_CONNECTTIMEOUT (300 segundos) limita solo la fase de conexión (resolución de nombres más los handshakes TCP y TLS), mientras que CURLOPT_TIMEOUT, que cubre toda la petición, vale cero por defecto (ilimitado). Por eso, un script que configura solo uno de los dos no está protegido frente a un servidor lento pero conectado. axios coincide exactamente con el valor por defecto de curl para el timeout total: "no timeout". httpx es la excepción en el sentido contrario: por defecto corta una conexión detenida tras solo 5 segundos de inactividad. undici de Node queda en un punto intermedio, con 5 minutos para las cabeceras de la respuesta y 5 minutos de inactividad en el cuerpo, lo que aun así permite que una respuesta que llega con cuentagotas se prolongue indefinidamente.

Cómo aplicarlo

• Fija un timeout explícito en cada llamada HTTP saliente que haga un agente; no confíes nunca en «lo que haga la biblioteca».
• En curl, configura tanto --connect-timeout como --max-time: con uno solo, la otra dimensión queda sin límite.
• En httpx, aumenta de forma explícita el timeout por defecto de 5 segundos para las llamadas a servicios upstream lentos.
• Al diagnosticar, distingue entre «la petición terminó fallando por timeout» y «la petición sigue colgada»: lo segundo suele indicar que la biblioteca no tiene ningún timeout por defecto.

Trampas

• Suponer que http.Client{} de Go tiene un timeout por defecto razonable; no tiene ninguno.
• Suponer que configurar el timeout de conexión de curl también limita el tiempo total de la transferencia.
• Suponer que httpx y requests comparten un mismo valor por defecto en todo el ecosistema de Python; no es así.