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.