Si un documento de Collabora Online Development Edition (CODE) se abre con normalidad, las ediciones funcionan y, a continuación, el editor se desconecta casi exactamente a los 10 minutos, revise la ruta WebSocket entre el navegador y CODE. Un límite repetible de 600 segundos sugiere mucho más un problema con un proxy inverso, un controlador de entrada, un balanceador de carga o un tiempo de espera del cortafuegos que con los temporizadores de inactividad predeterminados documentados de CODE.
Esa distinción es importante porque modificar primero la configuración de inactividad de CODE puede ocultar el problema real sin solucionar la conexión que transmite el tráfico de edición. La plantilla de configuración actual de Collabora documenta un tiempo de espera de inactividad de 15 minutos por vista y un tiempo de espera de una hora para documentos inactivos, no un límite de 10 minutos para sesiones de edición. Consulte la plantilla coolwsd.xml original . Si los usuarios están escribiendo activamente cuando se produce la desconexión, una configuración de CODE que solo permite el estado de inactividad es una explicación aún menos convincente.
Verificado: El ejemplo de Nginx publicado por Collabora utiliza encabezados de actualización de WebSocket y un valor largo proxy_read_timeout 36000spara el WebSocket principal. Nginx documenta que las conexiones WebSocket a través de proxy se cierran cuando no se reciben datos dentro del tiempo de espera de lectura configurado, cuyo proxy_read_timeoutvalor predeterminado genérico es de 60 segundos. Consulte el manual del SDK en línea de Collabora y la documentación del proxy WebSocket de Nginx .
Depende del entorno: una capa de proxy diferente puede introducir un tiempo de espera de 600 segundos incluso cuando el host Nginx que se encuentra frente a CODE parece correcto. Algunos ejemplos comunes son Kubernetes Ingress, HAProxy, un balanceador de carga en la nube, un WAF o un proxy inverso ascendente. El tiempo de espera exacto y la clave de configuración dependen de dicho componente.
El síntoma por sí solo no lo demuestra: «se desconecta después de 10 minutos» no prueba que Nginx sea el componente responsable. Captura la conexión WebSocket fallida y correlaciona su marca de tiempo con los registros del proxy y del código antes de modificar varias capas a la vez.
Acción: reproduzca el fallo con las herramientas para desarrolladores del navegador abiertas y registre la duración exacta de la solicitud WebSocket.
Abre un documento, luego abre las herramientas para desarrolladores del navegador y ve al panel Red. Filtra el tráfico de WebSocket. El tráfico de edición de código normalmente incluye un WebSocket en la /cool/ruta especificada. Mantén el documento abierto incluso después de que se produzca el fallo.
Cuando se desconecta la sesión, inspeccione la solicitud WebSocket. Los datos más útiles son su duración, el momento de cierre, el estado HTTP durante la actualización inicial y si el navegador informa de un error de red. Un inicio correcto 101 Switching Protocolsseguido de un cierre alrededor de los 600 segundos indica la existencia de una política de duración de la conexión o de inactividad en algún punto de la ruta.
Si la actualización del WebSocket no se completa correctamente, no se trata de un problema de "tiempo de espera de 10 minutos"; primero, corrija el enrutamiento y los encabezados del WebSocket. Si el WebSocket permanece conectado mientras el editor muestra un error de almacenamiento o guardado, investigue la ruta WOPI/almacenamiento.
Acción: anote la hora de inicio y la hora de desconexión, y luego compare esas marcas de tiempo con los registros de acceso/error del proxy inverso y los registros del contenedor o servicio de CODE.
Para Nginx, lo importante es que la ubicación del WebSocket pase los encabezados de actualización y tenga un tiempo de espera de lectura suficientemente largo. El manual del SDK de Collabora muestra este patrón para el WebSocket principal:
location ~ ^/cool/(.*)/ws$ {
proxy_pass https://127.0.0.1:9980;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $host;
proxy_read_timeout 36000s;
}Si Nginx finaliza la conexión TLS y CODE sirve HTTP simple intencionadamente detrás de él, el esquema de conexión ascendente podría ser http://diferente. No copie el esquema sin más: debe coincidir con la configuración de su instancia de CODE.
Un error común es pensar que proxy_connect_timeoutcontrola la duración de una sesión de edición ya establecida. No es así; se aplica mientras se establece la conexión con el servidor ascendente. La configuración más directamente relevante para un WebSocket proxy establecido con períodos sin datos del servidor ascendente es proxy_read_timeout. Nginx documenta este comportamiento en su referencia del módulo proxy HTTP .
Acción: localice el bloque Nginx real que coincide con la URL de WebSocket de CODE y confirme que el tiempo de espera está configurado allí, no solo en un bloque no relacionado location.
A partir de octubre de 2026, las notas de la versión actual de CODE 26.04 de Collabora indican CODE 26.04.4.2, publicada el 24 de septiembre de 2026. La serie 26.04 introdujo una URL de WebSocket más compacta. Collabora señala que las configuraciones de proxy existentes podrían necesitar actualizaciones; en versiones posteriores de 26.04, CODE puede recurrir a la URL anterior y emitir una advertencia de auditoría si el proxy no se actualiza. Se indicó específicamente a los usuarios de Apache2 que actualizaran su regla ProxyPass cuando se introdujo la versión 26.04. Consulte las notas de la versión oficial de CODE 26.04 .
Esto no significa que cada desconexión de 10 minutos se deba al cambio de URL compacta. Significa que, en la versión 26.04, debe verificar las reglas de su proxy inverso con la documentación de la versión que esté utilizando, especialmente si el problema apareció después de una actualización.
Acción: compruebe su versión de CODE en la información "Acerca de" del producto o en la etiqueta de la imagen del contenedor, y luego compare su configuración de proxy con las directrices actuales de Collabora para proxies. No dé por sentado que una regla copiada de una implementación anterior de la versión 24.04 sigue siendo la ideal.
Si Nginx es solo una capa delante de CODE, extender su tiempo de espera puede no ser suficiente. Para Kubernetes que utiliza ingress-nginx, el proyecto documenta anotaciones por Ingress llamadas nginx.ingress.kubernetes.io/proxy-read-timeouty nginx.ingress.kubernetes.io/proxy-send-timeout. Su guía de WebSocket recomienda valores mayores a una hora para conexiones de larga duración. Consulte la referencia oficial de anotaciones de Ingress-Nginx y las notas de WebSocket .
metadata:
annotations:
nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"Para HAProxy, el ejemplo del SDK de Collabora utiliza un tiempo de espera de túnel largo para el tráfico de estilo WebSocket. Para Apache, el tiempo de espera genérico del proxy se controla mediante ProxyTimeout, pero CODE 26.04 también requiere atención al patrón ProxyPass de WebSocket actual. La propia documentación de mod_proxy de Apache explica qué ProxyTimeoutcontrola.
Acción: dibuje la ruta de conexión desde el navegador hasta el código e inspeccione cada salto. Un límite de 600 segundos en cualquier salto puede provocar la finalización de la sesión.
Después de editar la configuración de Nginx, pruébela antes de recargar:
sudo nginx -t
sudo systemctl reload nginxSi Nginx se ejecuta en un contenedor, utilice el procedimiento equivalente de validación y recarga compatible con contenedores en lugar de asumir que systemctlexiste. Lo importante es validar la sintaxis antes de reemplazar la configuración en ejecución.
Acción: cambie una capa a la vez, registre el valor anterior, valide la configuración y luego vuelva a probar el mismo flujo de trabajo del documento.
No interrumpas las pruebas al volver a abrir el documento. Mantén la misma sesión de edición abierta mucho después de que se haya producido el fallo. Para un síntoma que dura 10 minutos, un periodo de validación de 20 a 30 minutos es más útil que una prueba rápida de dos minutos. Mantén abierto el panel de Red y realiza ediciones ocasionales para poder distinguir entre la edición activa y una pestaña completamente inactiva.
Un buen resultado presenta tres características: la conexión WebSocket permanece establecida durante más de 10 minutos, el editor continúa aceptando ediciones sin solicitar reconexión y no aparece ningún tiempo de espera correspondiente en los registros intermedios o de CODE.
Si la conexión se sigue cerrando exactamente 10 minutos después de haber aumentado el tiempo de espera del proxy más cercano, eso es una prueba útil de que otro salto todavía tiene una política de 600 segundos.
Acción: continuar rastreando hacia afuera hasta que se identifique el componente que emite el cierre o el tiempo de espera.
La plantilla de configuración de CODE actual indica per_view.idle_timeout_secs900 segundos, o 15 minutos. Su descripción señala que la vista se atenúa y las actualizaciones se detienen cuando el usuario está inactivo. El valor predeterminado a nivel de documento idle_timeout_secses de 3600 segundos, o una hora, antes de que se descargue un documento inactivo.
Vale la pena comprobar esos valores para ver si coinciden con su comportamiento, pero ninguno de los valores predeterminados explica una desconexión exacta de 600 segundos. Si alguien personalizó previamente coolwsd.xmllas variables de entorno, los valores de Helm o los parámetros del contenedor, su implementación puede diferir de los valores predeterminados.
Acción: inspeccione la configuración efectiva de CODE solo después de haber determinado si la falla es de nivel de red o de nivel de aplicación. No aumente todos los valores de inactividad como primera medida.
| Comportamiento observado | Próxima comprobación más útil | Lo que no se debe asumir |
|---|---|---|
| El WebSocket se cierra aproximadamente a los 600 segundos mientras el usuario está activo. | Tiempo de espera del proxy, entrada, balanceador de carga o firewall | Ese código tiene un límite de edición incorporado de 10 minutos. |
| WebSocket nunca llega a HTTP 101 | Actualizar encabezados, enrutamiento, esquema TLS ascendente, rutas de proxy actuales 26.04 | El hecho de que aumentar los tiempos muertos por sí solo ayudará |
| El fallo comenzó después de actualizar a CODE 26.04. | Compare las reglas de representación con la guía 26.04 vigente. | Que una configuración de proxy antigua de 24.04 es automáticamente equivalente |
| Solo las pestañas inactivas/en segundo plano se ven afectadas. | Comportamiento de inactividad por vista de CODE más tiempos de espera de inactividad intermedios | Que los fallos de sesión activa y de sesión inactiva tienen la misma causa. |
| WebSocket permanece abierto pero fallan los guardados. | Registros de WOPI/almacenamiento y solicitudes de guardado | Que el tiempo de espera de WebSocket es la causa principal |
Para una sesión de edición de CODE que se desconecta después de 10 minutos de forma repetible, la secuencia más eficiente es: confirmar el fallo de WebSocket, verificar la regla de proxy inverso correspondiente, inspeccionar cada tiempo de espera intermedio, tener en cuenta los cambios en la ruta del proxy de CODE 26.04, recargar de forma segura y realizar pruebas más allá del límite anterior. Modifique la configuración de inactividad de CODE solo cuando el comportamiento observado y la configuración efectiva apunten realmente a ello.
Si el tiempo de fallo no es reproducible, o si los registros de CODE muestran fallos, terminación de procesos, presión de memoria o errores WOPI simultáneamente, deje de tratarlo como un simple caso de tiempo de espera agotado. Estos síntomas requieren un diagnóstico diferente.
Solucione los problemas de las sesiones CODE de Collabora Online que se desconectan después de unos 10 minutos revisando los tiempos de espera de WebSocket, las reglas del proxy, la configuración de entrada y los registros de CODE.
Restrinja las exportaciones de código de Collabora Online mediante WOPI CheckFileInfo. Aprenda cuándo usar DisableExport, HideExportOption y controles de descarga independientes del host.
Aprende a alternar entre las vistas Compacta y con Pestañas en CODE, a contraer la barra del bloc de notas y a ocultar pestañas o comandos específicos mediante la API PostMessage de WOPI.
Configure la terminación SSL para Collabora CODE detrás de Nginx, con ajustes de Docker, proxy WebSocket, comprobaciones de validación y guía para la resolución de problemas.
Mantener sus documentos importantes protegidos de cualquier fuente externa sería extremadamente beneficioso. A veces, al escribir un documento, se vuelve urgente...
Una de las ventajas de un sistema de gestión de bases de datos relacionales como Access 2010 es que permite configurar fácilmente tablas y relaciones con restricciones para que
En MS Access, la función IIF devuelve un valor si una condición especificada se evalúa como VERDADERO, u otro valor si se evalúa como FALSO. Función IIF
El espaciado es muy importante al crear documentos, ya que afecta su apariencia y presentación. Puedes aumentarlo o disminuirlo fácilmente.
Los gráficos y diagramas son una excelente manera de representar sus datos. Microsoft Excel 2010 ofrece casi todos los tipos de gráficos y facilita su dibujo para que...
Las aplicaciones de la suite Microsoft Office ofrecen una forma más sencilla de personalizar la Cinta, las Pestañas y la barra de herramientas de Acceso rápido, pero ¿qué sucede si necesita instalar una copia nueva?
![Exportar/Importar configuraciones de la cinta de opciones y de la barra de herramientas de acceso rápido [Office 2010]](https://tips-cdn.webtech360.com/resources8/r252/image-8447-0829093801831.webp "Exportar/Importar configuraciones de la cinta de opciones y de la barra de herramientas de acceso rápido [Office 2010]")