Su aplicación WebSocket se ejecuta localmente. En la puesta en escena detrás de nginx, todo parece estar bien, hasta el último minuto: la conexión se cierra, el cliente intenta volver a conectarse, el usuario ve un flash "desconectado". Los registros de la aplicación no muestran excepciones. Sólo el apoderado decidió que la sesión estaba inactiva.
Este patrón, exactamente 60 segundos, es uno de los diagnósticos más rápidos en alojamiento web. Antes de optimizar el controlador onMessage, cronometre la interrupción: la cantidad de segundos a menudo identifica al culpable.
WebSocket detrás de un proxy inverso
El navegador envía una solicitud HTTP con "Actualización: websocket". El proxy debe transmitir los encabezados "Actualización" y "Conexión", no aplicar un tiempo de espera HTTP clásico a una conexión duradera y dejar pasar tramas bidireccionales sin almacenamiento en búfer indefinidamente.
| Componente | Ajuste crítico | Error común |
|---|---|---|
| nginx | proxy_read_timeout | Años 60 por defecto |
| HAProxy | tiempo de espera del túnel | tiempo de espera del cliente demasiado corto |
| AWSALB | tiempo de espera inactivo | 60 s mínimo configurable |
| Llamarada de nube | WebSocketsON | límite de tiempo de espera + necesidad de ping |
WebSocket no es una solicitud HTTP “larga”; es un protocolo independiente después de la actualización. El apoderado debe tratarlo como tal.
Configuración típica de nginx
mapa $http_upgrade $conexión_upgrade {
actualización predeterminada;
'' cerca;
}
ubicación /ws/ {
proxy_pass http://backend;
proxy_http_versión 1.1;
proxy_set_header Actualizar $http_upgrade;
proxy_set_header Conexión $connection_upgrade;
proxy_read_timeout 3600s;
proxy_send_timeout 3600s;
}
Ajuste 3600s a su caso: alineado con el latido de la aplicación, no con el infinito. También verifique que el backend acepte conexiones largas y que el firewall intermedio no imponga su propio límite de inactividad.
Latido de la aplicación: obligatorio en producción
Incluso con tiempos de espera elevados, envíe un ping de WebSocket (o un mensaje JSON ligero) cada 30 a 45 segundos si algún eslabón de la cadena se corta a los 60 o 100 segundos. En el lado de los canales Node (ws), Python (websockets) o Phoenix: active el ping/pong nativo o impleméntelo explícitamente.
Intencionalmente prueba un minuto de inactividad del usuario, no solo tráfico continuo. Una sesión que permanece abierta durante una videollamada sin un mensaje de aplicación revela rápidamente los límites del proxy o CDN.
CDN y alojamiento gestionado
Si el WebSocket pasa a través de Cloudflare o un WAF, habilite WebSockets en el panel, verifique la duración o los límites de mensajes por plan y siga haciendo ping con más frecuencia que el tiempo de espera. En origen directo sin CDN, el problema a menudo se reduce a nginx o HAProxy.
En PaaS (Clever Cloud, Railway, Heroku), lea la documentación sobre conexiones largas: algunos enrutadores imponen límites estrictos. Compare ofertas adecuadas a través de nuestro directorio si las conexiones en tiempo real son fundamentales para su producto.
La parte superior: el error no está en su controlador onMessage
Decide y avanza sin puntos ciegos
Primero, determine el intervalo de desconexión exacto y correlacionelo con los tiempos de espera documentados de cada enlace (nginx, balanceador de carga, CDN, PaaS). Luego corrija los encabezados de actualización y los tiempos de espera del proxy, luego agregue un ping/pong más frecuente que el tiempo de espera más corto. Prueba desde producción con un minuto de inactividad voluntaria: localhost a menudo oculta la capa intermedia. Documente la configuración final en el runbook de implementación para evitar que una nueva implementación de nginx restablezca los valores predeterminados.
Preguntas frecuentes
¿Por qué 60 segundos exactamente?
nginx proxy_read_timeout predeterminado y valor actual en los balanceadores de carga. Un intervalo fijo apunta a la capa de transporte, no a una excepción aleatoria de la aplicación.
¿Qué directivas nginx para WebSocket?
HTTP/1.1, Actualización, Actualización de conexión, alto proxy_read/send_timeout, mapa $http_upgrade para conexiones HTTP y WebSocket mixtas.
¿Cloudflare admite WebSockets de larga duración?
Sí en planes compatibles; Se recomienda un ping de aplicación para sesiones silenciosas o muy largas.
¿Deberíamos aumentar el tiempo de espera sin límite?
No: combine un tiempo de espera alineado con el latido del corazón y un ping regular con más frecuencia que el eslabón más estricto de la cadena.
Si su WebSocket se cae en ese momento, no depure el mensaje: depure quién cierra la conexión y después de exactamente cuántos segundos.