Evita que las sesiones de edición de código finalicen a los 10 minutos.

Si un documento de CODE se desconecta sistemáticamente a los 10 minutos, primero inspeccione la ruta de WebSocket a través de cada proxy inverso o balanceador de carga. Un tiempo de espera de inactividad de 600 segundos es un indicio común de un problema de configuración, pero este dato por sí solo no demuestra que el proxy sea el responsable; verifique qué componente cierra la conexión antes de modificar la configuración. En la mayoría de las implementaciones, la solución práctica consiste en conservar la actualización de WebSocket de Collabora y establecer tiempos de espera de lectura y envío del proxy superiores a la duración máxima prevista de la sesión de edición.

Primero, confirme dónde se produce la desconexión.

Collabora Online utiliza una conexión de navegador al servidor CODE, mientras que la integración de documentos también se basa en la comunicación WOPI con el host, como Nextcloud. La guía de proxy inverso de Collabora y los ejemplos actuales de Office de Nextcloud documentan una ruta WebSocket independiente para las sesiones de documentos. Si esta ruta no existe, se envía al servidor de origen incorrecto o está sujeta a un tiempo de espera por inactividad, el editor puede perder la conexión en tiempo real, aunque la página siga estando accesible.

Se trata de un requisito arquitectónico verificado. Esto no significa que cada fallo de diez minutos tenga la misma causa: un balanceador de carga en la nube, un controlador de entrada, un cortafuegos, una VPN u otro proxy pueden imponer su propio límite. Considere el intervalo repetible como una pista y, a continuación, revise los registros de acceso y de errores en el momento del fallo.

1. Registre la hora exacta en que se interrumpe una sesión y si ocurre mientras se está escribiendo activamente o solo cuando el documento está inactivo.
2. En las herramientas para desarrolladores del navegador, abre el panel Red, filtra por “WS” e inspecciona la conexión cuya ruta termina en /ws. /cool/Anota su estado y el código de cierre si el navegador informa de alguno.
3. En la misma marca de tiempo, revise los registros del proxy inverso o de entrada, los registros del servidor CODE y los registros del host WOPI. Busque un tiempo de espera del proxy, un reinicio del servidor ascendente, un cierre anómalo de WebSocket o un error de WOPI. La redacción de los registros varía según el producto y la versión, por lo que no asuma que un mensaje es universal.

Si la conexión WebSocket finaliza en el mismo umbral de 600 segundos configurado, corrija el proxy o intermediario responsable de dicho umbral. Si finaliza en otro intervalo o los registros muestran un error de WOPI o del servidor, siga esa evidencia. La documentación de solución de problemas de Nextcloud recomienda específicamente verificar la conectividad en ambas direcciones y revisar los registros de Nextcloud y Collabora.

Mantén el WebSocket abierto a través del proxy.

Antes de editar un archivo proxy, identifique el host virtual activo y el esquema y puerto de origen reales para CODE. Realice una copia de seguridad de la configuración y valide la sintaxis antes de recargarla. El siguiente ejemplo ilustra el comportamiento de WebSocket requerido para un proxy inverso NGINX; no se trata de un host virtual completo de Collabora. Intégrelo en la configuración oficial de su implementación, conservando sus demás bloques de ubicación, configuración TLS, manejo de URI y reglas de seguridad.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

Los Upgradeencabezados Connectionpermiten que la solicitud HTTP cambie a WebSocket. Los límites de lectura y envío más largos impiden que este proxy cierre una conexión silenciosa tras un breve intervalo predeterminado; no son una orden para mantener una sesión abierta indefinidamente. Ajuste la dirección de origen y la verificación TLS para que coincidan con su instalación y no desactive las comprobaciones de certificados solo para que el ejemplo funcione.

Los ejemplos oficiales de proxy de Collabora son la referencia para la configuración de enrutamiento completa y adecuada a la versión. Su guía actual incluye tiempos de espera de proxy prolongados; el ejemplo actual de Docker de Nextcloud también cuenta con una /cool/(.*)/wsasignación de WebSocket específica. Utilice esos ejemplos completos en lugar de reemplazar todo su host virtual con este pequeño fragmento:

• Configuración del proxy inverso de Collabora Online
• Ejemplo de instalación de Nextcloud 35 con Docker

Para NGINX, ejecute nginx -ty recargue solo después de que la prueba sea exitosa. Para Apache, utilice su prueba de configuración antes de recargar. Si CODE se ejecuta detrás de un ingress de Kubernetes o un balanceador de carga en la nube, cambiar NGINX en el host de CODE no solucionará un tiempo de espera más corto en el ingress o en el borde del proveedor; actualice el componente que identifiquen los registros.

Comprueba cada salto de red, no solo el código.

El tráfico WebSocket puede pasar por más de un intermediario: navegador, CDN o cortafuegos, balanceador de carga externo, entrada, proxy de host y, finalmente, código. Un tiempo de espera prolongado en una capa no puede anular un tiempo de espera más corto en la siguiente. Compare el tiempo de espera de inactividad o conexión de cada capa y establezca un límite para la ruta WebSocket mayor que el período de edición de inactividad previsto, dentro de los límites y la política de la plataforma.

No confunda la configuración de descarga por inactividad de un documento con el tiempo de espera de red del proxy. La primera controla cuándo se puede descargar un proceso de documento no utilizado; no repara un WebSocket que un intermediario ya haya cerrado. Del mismo modo, establecer un tiempo de espera muy largo no soluciona una ruta de actualización incorrecta, tráfico bloqueado, una configuración HTTP/HTTPS incompatible o un fallo del proceso CODE. Después de cada cambio, confirme que el tiempo de cierre se modifica o que la causa registrada desaparece; esto permite identificar la capa responsable sin introducir cambios no relacionados.

Compruebe que tanto el navegador del usuario como el host WOPI puedan acceder al servicio CODE mediante HTTPS, y que CODE pueda acceder al host WOPI. Para una integración con Nextcloud, su manual de solución de problemas recomienda comprobar los puntos finales públicos /hosting/capabilitiesy /hosting/discoverydesde un navegador y curl, a continuación, comprobar el punto final de estado de Nextcloud desde el servidor CODE. Estas comprobaciones confirman la accesibilidad básica; no demuestran por sí solas que una conexión WebSocket establecida se mantenga activa durante diez minutos.

Verifique la reparación con una sesión cronometrada.

1. Recargue la configuración del proxy o del ingress utilizando el paso de validación compatible y, a continuación, abra una nueva sesión de documento.
2. Mantenga el documento abierto durante más tiempo que el intervalo de tiempo que falló anteriormente. Realice una prueba mientras edita y, si el problema se produce durante la inactividad, otra con el documento inactivo.
3. Confirme que la /cool/.../wsconexión permanece abierta en el panel de red del navegador y que el documento continúa guardándose a través del host WOPI.
4. Revise los registros del mismo intervalo de tiempo. Una prueba exitosa significa que no aparece ningún tiempo de espera de proxy coincidente ni un cierre inesperado de WebSocket, y que las ediciones se mantienen después de volver a abrir el documento.

Si la desconexión persiste, restaure el tiempo de fallo registrado y compárelo con los registros de cada salto. Un cierre de 600 segundos en el punto de entrada indica que el problema se debe a ese punto; un tiempo de cierre diferente o un error del servidor apuntan a otro lugar. La causa precisa no se puede determinar solo con "10 minutos", y los nombres y valores predeterminados de los tiempos de espera varían según los productos y versiones del proxy. Mantenga documentada la configuración que funciona correctamente, con la versión de CODE y el producto del proxy, para que las futuras actualizaciones puedan compararse con los ejemplos oficiales actuales.