Guía completa de tiempos de conexión en Nginx: keepalive_timeout, send_timeout, proxy_read_timeout y proxy_send_timeout

En Nginx, el manejo de los tiempos de espera (timeouts) es fundamental para optimizar el rendimiento y evitar bloqueos de recursos. Cada una de estas directivas controla cuánto tiempo Nginx mantiene abiertas las conexiones o espera la transmisión de datos entre el cliente, el proxy (Nginx) y el servidor backend.

A continuación, explicamos cada parámetro en detalle:

1. `keepalive_timeout`

Función

Define cuánto tiempo Nginx mantiene abierta una conexión keep-alive con el cliente (por ejemplo, un navegador) después de haber completado una solicitud.
Esto permite reutilizar la misma conexión TCP para múltiples peticiones, reduciendo la latencia y el consumo de CPU por apertura de conexiones nuevas.

Valor configurado

keepalive_timeout 3600; → 3660 segundos (1 hora).

Efecto práctico

Si el cliente no envía nuevas solicitudes dentro de ese tiempo, Nginx cierra la conexión.
Un tiempo más alto mejora el rendimiento en clientes recurrentes.
Un tiempo demasiado alto puede mantener conexiones inactivas que consumen memoria y sockets innecesariamente.

2. `send_timeout`

Función

Es el tiempo máximo que Nginx espera para enviar datos al cliente.
Si el cliente deja de recibir datos o no confirma la recepción dentro de este periodo, Nginx cerrará la conexión.

Valor configurado

send_timeout 3600; → 3600 segundos (1 hora).

Efecto práctico

Protege contra clientes lentos o caídos que no leen la respuesta completa.
Si el cliente no lee los datos en ese tiempo, la conexión se interrumpe.
Útil para prevenir bloqueos cuando se sirven archivos grandes o transmisiones lentas.

3. `proxy_read_timeout`

Función

Define cuánto tiempo Nginx espera una respuesta completa del servidor backend (proxy_pass) después de enviarle una solicitud.
Si el backend tarda más de ese tiempo en comenzar o continuar enviando datos, Nginx aborta la conexión.

Valor configurado

proxy_read_timeout 3600; → 3600 segundos (1 hora).

Efecto práctico

Es común aumentarlo cuando el backend ejecuta procesos largos (por ejemplo, generación de reportes o consultas pesadas).
Si se configura muy bajo, Nginx puede cerrar la conexión antes de que el backend termine de responder.
Si se configura muy alto, puede dejar conexiones colgadas en caso de fallo del backend.

4. `proxy_send_timeout`

Función

Establece el tiempo máximo que Nginx permite para enviar una solicitud completa al backend.
Si no logra transmitir los datos dentro del tiempo especificado, se interrumpe la conexión.

Valor configurado

proxy_send_timeout 3600; → 3600 segundos (1 hora).

Efecto práctico

Se aplica principalmente cuando el cliente envía datos grandes (por ejemplo, subidas de archivos mediante POST).
Un valor muy bajo podría causar errores 504 (Gateway Timeout) en peticiones pesadas.
Un valor alto asegura que Nginx disponga de tiempo suficiente para transmitir completamente la solicitud al backend.

Resumen comparativo

Directiva	Flujo de conexión	Controla	Tiempo configurado	Descripción breve
`keepalive_timeout`	Cliente ↔ Nginx	Reutilización de conexión	3600 s	Cierra conexiones inactivas entre cliente y Nginx.
`send_timeout`	Nginx → Cliente	Envío de datos al cliente	3600 s	Corta la conexión si el cliente no recibe datos.
`proxy_read_timeout`	Backend → Nginx	Lectura de respuesta del backend	3600 s	Aborta si el backend tarda en responder.
`proxy_send_timeout`	Nginx → Backend	Envío de solicitud al backend	3600 s	Cierra si Nginx no puede enviar datos al backend.

Recomendaciones generales de ajuste

Tipo de aplicación	`keepalive_timeout`	`send_timeout`	`proxy_read_timeout`	`proxy_send_timeout`
Sitio web estático	30–120 s	60 s	60 s	60 s
API REST / Web dinámica	60–300 s	60–120 s	120–300 s	120–300 s
Descargas o streaming	300–3600 s	600–3600 s	600–3600 s	600–3600 s
Aplicaciones con backend pesado	600–3600 s	600–3600 s	1200–7200 s	600–3600 s

Conclusión

Estas directivas permiten ajustar la resiliencia y eficiencia de Nginx frente a conexiones lentas, procesos largos o clientes inactivos. Configurarlas correctamente según el tipo de aplicación evita errores 504/502, mejora la experiencia del usuario y optimiza el uso de recursos del servidor.