Restablecer la conexión WebSocket de Collabora a través del proxy

Cuando Collabora Online informa que una conexión de socket se cerró inesperadamente, primero verifique si la solicitud WebSocket del navegador llega coolwsda través del proxy inverso. Asegúrese de que la ruta del proxy coincida con la versión de Collabora, conserve la actualización de WebSocket y la ruta URL, y luego pruebe un documento mientras observa el panel de red del navegador y los registros del servidor. Si el problema comenzó después de una actualización a CODE 26.04 detrás de Apache, revise ProxyPassprimero las reglas de Apache: las notas de la versión 26.04 de Collabora mencionan un cambio en la URL compacta de WebSocket.

Un WebSocket es la conexión bidireccional de larga duración que Collabora utiliza entre el navegador y su servidor mientras un documento está abierto. Un proxy inverso es el servicio que acepta la solicitud pública y la reenvía a Collabora. El mensaje de error apunta a esa conexión, pero no prueba que el proxy sea la causa; un host WOPI rechazado, una URL pública incorrecta, una discrepancia en TLS o un servidor backend erróneo también pueden interrumpir la sesión.

Antes de cambiar nada, identifica tu ruta.

Anote la versión de Collabora o la etiqueta de imagen, el software proxy, el nombre de host público de Collabora y si TLS finaliza en el proxy o en Collabora. Verifique el nombre del servicio y la imagen actual sin modificar la implementación:

docker compose ps collabora
docker compose images collabora

Reemplaza collaboracon el nombre del servicio en tu archivo Compose. Para un contenedor que no sea Compose, usa docker psy docker inspectpara identificar el contenedor y la imagen. No asumas que la latestetiqueta sigue apuntando a la misma versión que probaste la semana pasada.

1. Observa dónde se detiene el protocolo de enlace de WebSocket.

En el navegador, abre Herramientas para desarrolladores, selecciona Red , filtra por WS o WebSocket e intenta abrir un documento nuevamente. La URL de la solicitud debe usarse wss://cuando la página pública sea HTTPS. Selecciona la solicitud fallida y anota su estado, ruta URL y encabezados de respuesta. Un handshake exitoso normalmente devuelve 101 Switching Protocolsy permanece abierto mientras la sesión del documento esté activa.

• No aparece ninguna solicitud WebSocket: compruebe la URL de Collabora de la aplicación de integración, la consola del navegador, el DNS y cualquier error de redirección o contenido mixto antes de editar las reglas del servidor.
• La solicitud devuelve un código 400 o 404: compare la ruta solicitada con la ruta que reenvía su proxy y la ruta compatible con la versión de Collabora instalada. Un código 400 que coolwsdindica "Solicitud no válida o desconocida" puede significar que la solicitud llegó a Collabora con una ruta que no acepta.
• La solicitud devuelve 502 o 504: compruebe si el proxy puede alcanzar el servidor ascendente de Collabora configurado y si la dirección y el puerto apuntan al contenedor o host correcto.
• La solicitud devuelve 101 y luego se cierra: revise los tiempos de espera por inactividad del proxy, el balanceador de carga, el firewall y la red del cliente. Un WebSocket es de larga duración, por lo que un intermediario que cierra las conexiones inactivas demasiado pronto puede interrumpir una apertura que, de otro modo, sería exitosa.

2. Compare la regla proxy con su versión de Collabora.

Utilice la configuración actual del proxy inverso de Collabora para el software y la versión del proxy que esté utilizando. Verifique que la ruta WebSocket se gestione como tal, que el proxy reenvíe los encabezados de actualización y que conserve la ruta y la cadena de consulta codificada en lugar de redirigirlas o reescribirlas. El proxy también debe enviar el host público y el esquema de forma coherente con el nombre del servidor externo y la configuración de terminación TLS de Collabora.

Para Nginx, revise la ubicación específica de WebSocket y sus directivas HTTP/1.1, Upgradey Connectionde reenvío en el ejemplo actual de Collabora. Para Apache, compare la ProxyPassregla y el orden con el ejemplo actual; no copie una /cool/…/wscoincidencia antigua sin verificar lo que solicita su versión instalada.

Esta comprobación de versión es importante para CODE 26.04. Las notas de la versión de Collabora, publicadas el 8 de junio de 2026, describen una URL de WebSocket más compacta e indican que los usuarios de proxy inverso Apache deben adaptarse ProxyPassa ella. Posteriormente, en la versión 26.04, se añadió un comportamiento alternativo para las URL antiguas, por lo que una regla anterior podría seguir funcionando en algunas compilaciones; el informe de Collabora sobre WebSocket 26.04 resuelto documenta este seguimiento. El comportamiento alternativo no sustituye la necesidad de que la configuración del proxy actual coincida con la versión instalada. Lea conjuntamente las notas de la versión de CODE 26.04 y el ejemplo actualizado del SDK.

3. Identifique un fallo y realice un cambio específico.

Inicie un flujo de registro corto antes de volver a intentar el documento. --sinceLa opción de Docker limita la salida inicial, mientras que --followgenera nuevas líneas; consulte la referencia de registros de Docker Compose .

docker compose logs --since=2m --follow collabora

Registre la hora de la prueba y busque la misma solicitud en los registros de Collabora y del proxy. Si el navegador solicita una ruta que el proxy redirige al backend incorrecto, actualice solo esa ruta WebSocket utilizando el ejemplo de Collabora que coincide con la versión. Si la solicitud llega a Collabora pero se rechaza el host, el origen o el esquema, compare el nombre de host y el puerto públicos con el nombre del servidor configurado y los encabezados reenviados. Si el registro muestra un rechazo de host WOPI o una solicitud de información de archivo fallida, verifique el host permitido del servidor de integración y su accesibilidad desde el contenedor de Collabora; este es un paso independiente del protocolo de enlace WebSocket del navegador.

Recargue el proxy tras validar su configuración con el comando de comprobación de sintaxis propio del proxy. Evite modificar simultáneamente la terminación TLS, las listas de hosts permitidos y las reescrituras de URL: cambiar una causa por prueba permite interpretar el siguiente resultado. No desactive la verificación TLS ni permita todos los hosts WOPI como acceso directo.

4. Verifique la corrección del navegador al documento.

Vuelva a intentar con el mismo documento. En las Herramientas para desarrolladores, confirme que la solicitud WebSocket se completa 101 Switching Protocolsy permanece abierta. Confirme que el documento termina de cargarse, permanece conectado y acepta una pequeña edición que se guarda correctamente. Un estado de conexión correcto por sí solo no es suficiente si el acceso o el guardado de archivos WOPI siguen fallando.

Si el protocolo de enlace sigue fallando, compare la ruta de la solicitud del navegador, la línea de acceso/error del proxy y la coolwsdentrada de registro correspondiente con la misma marca de tiempo. Esta comparación de tres puntos indica si el navegador, el proxy, la ruta de Collabora o el host WOPI son los siguientes puntos a investigar. Al solicitar ayuda, oculte los tokens de acceso, los identificadores de documentos, los nombres de usuario y los nombres de host privados tanto de los detalles del navegador como de los registros.