Collabora Online puede parecer que funciona correctamente a primera vista, pero puede fallar en cuanto el editor intenta establecer una conexión WebSocket activa. El síntoma habitual es que el documento empieza a cargarse y luego informa de que la conexión se ha cerrado inesperadamente, a veces acompañado de una wss://solicitud fallida en el navegador. En la versión 2026, hay un motivo específico para comprobarlo antes de realizar cualquier otro cambio: la rama 26.04 introdujo una URL de WebSocket más compacta, y las reglas de proxy inverso antiguas pueden entrar en conflicto con ella.
Las notas de la versión oficial de Collabora CODE 26.04 indican que CODE 26.04.1, publicada el 8 de junio de 2026, requería que los usuarios de proxy inverso Apache2 modificaran su regla ProxyPass para la nueva URL compacta de WebSocket. Las notas posteriores de la versión 26.04.2.x señalan que CODE puede recurrir a la URL anterior cuando no se puede usar la nueva ruta y emite una advertencia de auditoría que remite a los administradores a las recomendaciones de proxy vigentes. La rama empresarial Collabora Online 26.04 también está vigente en 2026, por lo que los administradores deben comparar cualquier configuración de proxy copiada de una guía anterior de la versión 24.04 o 25.04 con la documentación más reciente del proveedor antes de considerar el problema como un fallo de red aleatorio.
El mensaje no identifica una única causa raíz. Significa que la conexión WebSocket entre el navegador y Collabora no se actualizó correctamente o se estableció y luego se interrumpió inesperadamente. Esta distinción es importante porque las soluciones son diferentes.
| Comportamiento observado | Primera comprobación más útil | Causas típicas |
|---|---|---|
| Falla inmediatamente al abrir un documento. | Red del navegador > Registros de acceso/errores de WS y proxy inverso | Ruta incorrecta /cool/, encabezados Upgrade faltantes, regla de Apache incompatible con 26.04, discrepancia entre Host y Origen |
| Funciona brevemente y luego se desconecta a intervalos regulares. | Tiempos de espera por inactividad del proxy, el ingress, el balanceador de carga y el firewall | El tiempo de espera es demasiado corto para un WebSocket de larga duración. |
| La función de detección funciona, pero la edición falla. | Pruebe el WebSocket por separado de/hosting/discovery | Los puntos finales HTTP son accesibles, mientras que la ruta WebSocket no lo es. |
| Solo falla un navegador o una ruta de red. | Comparar el protocolo de solicitud y el comportamiento del proxy | Manejo de HTTP/2 o HTTP/3, reenvío de CONNECT, filtrado de intermediarios. |
| El registro del servidor rechaza explícitamente la actualización. | Lea el error exacto de coolwsd | Desajuste en la configuración de origen, host, puerto, host WOPI o proxy. |
Si el problema apareció inmediatamente después de actualizar de la versión 25.04 o una imagen CODE anterior a la 26.04, considere el proxy inverso como la principal causa. Esto no es una suposición: Collabora documentó el cambio de la URL compacta de WebSocket en las notas de la versión 26.04, y un informe oficial del proyecto indicó que los WebSockets fallaban después de actualizar a la versión 26.04.1 hasta que se modificaron las reglas del proxy Apache.
No intente solucionar esto degradando la versión sin modificar el proxy anterior. Si bien revertir la versión puede ser una solución temporal, la solución definitiva consiste en alinear el proxy con la versión que desea ejecutar. Para Apache, utilice la configuración actual del proxy de Collabora Online en lugar de una copia anterior a la versión 26.04. El propio registro de incidencias de WebSocket de Collabora para la versión 26.04 documenta un caso en el que la actualización de las reglas de Apache restauró el funcionamiento.
Pruebe primero los puntos finales habituales de Collabora:
curl -I https://office.example.com/hosting/discovery
curl -I https://office.example.com/hosting/capabilitiesUna respuesta exitosa demuestra que DNS, TLS, el proxy de front-end y al menos parte del servicio Collabora son accesibles. No demuestra que la edición de documentos funcionará. El editor depende de una ruta WebSocket en /cool/, que tiene requisitos de proxy diferentes.
A continuación, abre las herramientas para desarrolladores del navegador, reproduce el fallo e inspecciona el panel de Red con el filtro WS. Un intercambio de claves WebSocket exitoso normalmente actualiza la conexión HTTP; la RFC 6455 define la respuesta del servidor como estado HTTP 101 cuando la actualización se realiza correctamente. Si, en cambio, ves 400, 404, 405, 502 o una solicitud fallida inmediata, correlaciona esa marca de tiempo con los registros del proxy inverso y de coolwsd.
Para Nginx, las propiedades importantes son sencillas: la solicitud debe llegar a la /cool/ruta de Collabora, el proxy debe usar HTTP/1.1 para un flujo de actualización de WebSocket clásico, los encabezados Upgradey Connectiondeben reenviarse, el Host original debe conservarse y el tiempo de espera de lectura debe ser lo suficientemente largo para una sesión de edición.
El manual del SDK de Collabora ha mostrado durante mucho tiempo una ubicación dedicada para WebSocket con Upgrade, Connection, Host, y un largo proxy_read_timeout. Un problema de documentación oficial del proyecto Collabora también señaló la necesidad de encabezados WebSocket en la /coolruta más amplia. Un patrón conservador compatible con 26.04 es:
location ^~ /cool/ {
proxy_pass http://127.0.0.1:9980;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_read_timeout 3600s;
}No copie esto sobre una configuración de producción en funcionamiento sin adaptar la dirección de origen, el modelo TLS, el manejo de rutas y los controles de seguridad existentes. Lo correcto es conservar su topología y, al mismo tiempo, cumplir con los requisitos actuales de enrutamiento y encabezado de Collabora.
Las sesiones de edición de WebSocket son de larga duración. Los valores actuales de Helm del proyecto Collabora lo describen explícitamente y utilizan un tiempo de espera de proxy amplio para el proxy Nginx incluido. Si su balanceador de carga perimetral, entrada de Kubernetes, CDN, firewall o proxy inverso cierra las conexiones inactivas antes de lo que la aplicación espera, los usuarios pueden editar normalmente durante un tiempo y luego desconectarse a intervalos regulares.
Cuando el fallo se produce aproximadamente cada vez después de la misma cantidad de segundos, inspeccione cada intermediario en la ruta en lugar de aumentar únicamente el tiempo de espera de Nginx. El tiempo de espera más corto es el que prevalece.
Una implementación común finaliza HTTPS en Nginx, Apache, HAProxy, Traefik o un controlador de entrada y reenvía HTTP simple a Collabora en el puerto 9980. En este diseño, la configuración oficial de Collabora requiere que el backend sepa que TLS es finalizado por el proxy. El manual del SDK documenta ssl.enable=falseesto ssl.termination=truepara este modelo.
Para un despliegue de Docker, esto se suele expresar mediante los parámetros adicionales de Collabora:
--o:ssl.enable=false --o:ssl.termination=trueUtilice estas opciones únicamente cuando la conexión TLS se finalice correctamente en la ruta de origen. Si el proxy se conecta a Collabora mediante HTTPS, configure esa topología de forma coherente en lugar de mezclar ambos modelos. Una incompatibilidad puede generar esquemas incorrectos, URL de WebSocket erróneas, fallos de certificado o redirecciones que impidan la actualización.
Collabora valida los orígenes de WebSocket. Si el registro contiene texto como Rejecting WebSocket upgradeseguido de un origen y un host esperado, corrija la relación entre el nombre de host externo y el puerto en lugar de agregar encabezados permisivos al azar. El sistema oficial de seguimiento de errores de Collabora contiene un ejemplo documentado donde un nombre de servidor configurado :443no coincidía con el origen del navegador sin ese puerto explícito.
Los comandos útiles dependen de su instalación:
docker logs collabora --tail 200
journalctl -u coolwsd --since "10 minutes ago"
nginx -t
apachectl configtestBusque el primer error al mismo tiempo que la solicitud WS fallida. Los mensajes sobre actualizaciones rechazadas, sintaxis URI incorrecta, un host inesperado o un servidor ascendente no disponible son más útiles que la ventana emergente genérica del navegador.
Este es un caso más específico, pero vale la pena verificarlo antes de reconstruir el servidor. El proyecto Collabora ha documentado un caso relacionado con Chromium en el que un proxy envió una solicitud HTTP/2 CONNECT WebSocket directamente a coolwsd y recibió un error 405 (Método no permitido). Otro problema registra fallos de carga de documentos relacionados con HTTP/3/QUIC en una ruta de proxy específica. Estos informes no implican que HTTP/2 o HTTP/3 deban estar siempre deshabilitados; significan que el intermediario debe traducir el comportamiento del cliente a una conexión WebSocket compatible con Collabora.
Si Firefox funciona mientras que Chrome falla en la misma cuenta y documento, capture el protocolo y el código de estado en el proxy. Es preferible corregir el comportamiento del proxy/entrada en lugar de deshabilitar globalmente los protocolos modernos, a menos que su entorno no cuente con una alternativa compatible.
Primero, comprueba la sintaxis del proxy. Luego, recarga en lugar de realizar reinicios a ciegas repetidos:
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2Para los contenedores, reinicie el servicio Collabora solo cuando haya modificado su entorno o coolwsdconfiguración. Un cambio que afecte únicamente al proxy normalmente solo requiere recargarlo.
Utilice una secuencia de verificación corta en lugar de depender de la apertura exitosa de un único documento:
/hosting/discoveryque /hosting/capabilitiesson accesibles a través del mismo nombre de host público al que acceden los usuarios.Si actualizó a la versión 26.04 y usa Apache, actualizar las reglas del proxy es la acción de máxima prioridad, ya que Collabora documentó explícitamente este cambio. Si la desconexión ocurre después de un período fijo, revise la configuración de tiempo de espera en cada salto de red. Si el fallo es inmediato en todos los navegadores, verifique /cool/el enrutamiento, los encabezados de actualización, la coherencia de Host/Origin y la terminación TLS. Si solo falla una familia de navegadores, compare el manejo del protocolo HTTP antes de modificar Collabora.
La clave está en evitar interpretar el error "conexión de socket cerrada inesperadamente" como un fallo de la aplicación Collabora por defecto. En muchas implementaciones, el editor, el punto final de descubrimiento y el host WOPI funcionan correctamente, mientras que el proxy inverso gestiona incorrectamente el tipo de conexión más importante para la edición en tiempo real: el WebSocket, que requiere una conexión de larga duración.
Solucione los errores de conexión de socket de Collabora Online revisando el cambio de WebSocket 26.04, las rutas de proxy, los encabezados de actualización, los tiempos de espera, TLS y los registros.
Habilite la revisión ortográfica multilingüe en Collabora Online agregando diccionarios de servidor, permitiendo códigos de idioma, asignando idiomas al texto y probando documentos con varios idiomas.
Create a reliable LibreOffice Writer mail merge with per-record images using Calc data, a named image placeholder, and a Basic macro, with troubleshooting and verification steps.
Diagnostica y soluciona los fallos de conexión de documentos de Collabora Online comprobando WOPI, el proxy inverso, TLS, DNS, WebSockets y la accesibilidad entre servidores.
Convierta un PDF a un DOCX editable en los editores de escritorio de ONLYOFFICE sin conexión. Siga los pasos de Guardar como, compruebe si el PDF se ha escaneado y revise el formato.
Conecte Seafile a Collabora Online mediante Docker o un servidor independiente. Compare las ventajas y desventajas de la implementación, configure los ajustes de HTTPS y WOPI, y verifique la edición.
Diagnostica la lentitud al escribir, desplazarte y guardar archivos de LibreOffice Writer con muchas imágenes. Prueba la configuración de pantalla, comprime imágenes de gran tamaño y detecta problemas de perfil o de hardware.
Implementa Collabora CODE en Kubernetes con el gráfico oficial de Helm. Configura el acceso a hosts, TLS y WOPI, los secretos, el escalado y las comprobaciones de extremo a extremo.
Reduce el tamaño de una presentación grande de LibreOffice Impress comprimiendo las fotos de gran tamaño, eligiendo una resolución y calidad JPEG adecuadas, y revisando el archivo guardado sin sacrificar la legibilidad de las diapositivas.
Instale Collabora Online CODE en Docker, publíquelo de forma segura a través de un proxy inverso, conéctelo a Nextcloud Office y verifique la edición de documentos basada en el navegador.
