Solucionar el error de conexión de Collabora Online "Bueno, esto es vergonzoso"

El mensaje de Collabora Online «Vaya, qué vergüenza, no podemos conectarnos a tu documento» es un síntoma, no un diagnóstico. Aparece después de que se carga el editor, pero la sesión del documento no se completa. En las implementaciones actuales, la forma más rápida de solucionarlo es identificar qué conexión en la ruta WOPI está fallando, en lugar de modificar configuraciones aleatorias de Collabora.

Esta guía utiliza como referencia la documentación de administración actual de Nextcloud 35 y la guía del SDK 25.04 de Collabora Online. La misma lógica de resolución de problemas se aplica a muchas integraciones de ownCloud y WOPI personalizadas, pero los nombres exactos de las configuraciones pueden variar según la plataforma y la versión.

¿Qué suele provocar este error de conexión de Collabora?

Una sesión de navegador funcional depende de varias rutas independientes. El navegador del usuario debe acceder tanto al servidor de almacenamiento como a Collabora; el servidor de almacenamiento debe acceder a Collabora; Collabora debe acceder al servidor de almacenamiento; los protocolos y certificados deben ser compatibles; y el proxy inverso debe reenviar correctamente las rutas HTTP y WebSocket de Collabora. La página oficial de solución de problemas de Nextcloud enumera explícitamente estos requisitos de accesibilidad bidireccional.

Esto significa que no existe una única solución universalmente correcta. Elija la ruta de reparación en función de la primera prueba fallida:

1. Verificar los puntos finales de descubrimiento y capacidades de Collabora.

Comience con la URL pública de Collabora que realmente utiliza su integración. Abra estos puntos finales en un navegador y desde el servidor de almacenamiento:

https://office.example.com/hosting/discovery
https://office.example.com/hosting/capabilities

La documentación de solución de problemas de Nextcloud recomienda realizar ambas pruebas. El punto final de descubrimiento debería devolver XML, mientras que la herramienta de capacidades devuelve datos de capacidades de Collabora. Un tiempo de espera agotado, una advertencia de certificado, un error 404, una página de error con la marca del proxy o un bucle de redireccionamiento indican que debe solucionar los problemas de red o del proxy inverso antes de modificar la configuración de WOPI.

Primero, compruebe las URL públicas de descubrimiento y capacidades de Collabora; ambas deben ser accesibles a través del mismo nombre de host utilizado por la integración.

Para obtener orientación autorizada sobre los puntos finales, consulte la sección de solución de problemas de Nextcloud Office y el manual del SDK de Collabora Online 25.04 .

2. Prueba las cuatro direcciones de la red, no solo el navegador.

Un error común es suponer que, dado que office.example.comse abre en un navegador de escritorio, Collabora también puede obtener archivos del servidor de almacenamiento. Esto no está garantizado. Realice pruebas desde los hosts o contenedores reales:

# From the Nextcloud/storage server
curl -fsS https://office.example.com/hosting/discovery >/dev/null && echo OK

# From the Collabora host/container
curl -fsS https://cloud.example.com/status.php

# Then inspect Collabora logs
docker logs --tail 100 collabora

Si el nombre de host público se resuelve de forma diferente dentro de Docker, Kubernetes o una red privada, decida si corregir el DNS interno, agregar una asignación de host adecuada o enrutar a través del punto final público. El DNS interno suele ser más limpio a gran escala; una entrada en el archivo hosts es rápida para una instalación estática pequeña, pero se vuelve más difícil de mantener.

Ejecute pruebas de accesibilidad desde los propios servidores y, a continuación, utilice el registro de Collabora para diferenciar un fallo de red de un fallo de confianza WOPI.

3. Solucione el problema del proxy inverso si faltan rutas de WebSockets o Collabora.

Collabora no es una aplicación web estática normal. Su proxy inverso necesita rutas para los recursos del navegador, el descubrimiento/capacidades, el tráfico de documentos y los WebSockets. En el manual del SDK de Collabora, el ejemplo de Nginx reenvía /browser, /hosting/discovery, /hosting/capabilities, la /cool/.../wsruta del WebSocket y /coolel /looltráfico relacionado.

Para la ruta WebSocket, el proxy debe conservar el host y permitir la actualización HTTP. Un patrón simplificado de Nginx es:

location ~ ^/cool/(.*)/ws$ {
    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 $host;
    proxy_read_timeout 36000s;
}

No copie esto sin más si su método de terminación TLS es diferente. Collabora documenta patrones distintos para la terminación TLS y SSL de extremo a extremo. Si la terminación TLS se realiza en Nginx y la conexión de backend es HTTP, la configuración SSL interna de Collabora debe coincidir con ese diseño. Usar HTTPS en todas partes simplifica la comprensión, mientras que la terminación TLS en el proxy reduce la gestión de certificados dentro de los contenedores, pero introduce una nueva limitación de configuración.

Un proxy inverso correcto debe reenviar las rutas HTTP de Collabora y preservar la actualización de WebSocket para la sesión del documento.

4. Compruebe la coherencia del protocolo, el certificado y el nombre de host.

La documentación actual de configuración de Office en Nextcloud indica que el servidor de Collabora Online debe usar el mismo protocolo que la instalación de Nextcloud, recomendándose HTTPS. En la práctica, las configuraciones mixtas de HTTP/HTTPS públicas pueden provocar el bloqueo de contenido, redireccionamientos incorrectos o fallos en la validación del certificado del servidor.

Verifique estos elementos en conjunto:

• La URL de Collabora guardada en su plataforma de almacenamiento es la URL pública exacta a la que acceden los usuarios.
• El certificado presentado por ese nombre de host es válido para dicho nombre de host y cuenta con la confianza del servidor de almacenamiento.
• Collabora puede validar el certificado HTTPS del servidor de almacenamiento.
• Su proxy inverso reenvía correctamente el host y el esquema originales.
• No existe ninguna redirección desde el nombre de host de Collabora configurado a otro nombre de host que WOPI no espere.

Un certificado autofirmado puede ser aceptable en un entorno de laboratorio si cada componente está configurado explícitamente para confiar en él, pero esta comodidad se consigue a costa de la portabilidad y, con frecuencia, provoca fallos posteriores en las actualizaciones o reconstrucciones de contenedores. Para entornos de producción, una cadena de certificados de confianza pública o de la organización es la opción más segura.

5. Corrija las listas de permisos de WOPI en lugar de deshabilitarlas.

Si la detección funciona y los registros de Collabora muestran mensajes como " Unauthorized WOPI hostno se encontró ningún host WOPI aceptable que coincida con el destino", el problema ha pasado de la conectividad básica a la configuración de confianza. La documentación oficial de solución de problemas de Nextcloud indica específicamente a los administradores que consulten los registros del contenedor en este caso.

En cuanto al almacenamiento, Nextcloud recomienda restringir las solicitudes WOPI a las direcciones IP de los servidores de Collabora mediante la configuración de la lista de permitidos para solicitudes WOPI . En Collabora, los hosts de almacenamiento WOPI permitidos deben coincidir con las URL de almacenamiento que recibe. Para dominios de almacenamiento múltiples, la documentación del SDK actual de Collabora describe los grupos de alias WOPI.

Mantenga la URL del servidor Collabora y la lista de permisos de WOPI alineadas con la implementación real; utilice entradas de confianza específicas en lugar de desactivar la validación.

Consulte la configuración de Nextcloud Office para obtener la URL del servidor actual y la guía de la lista de permitidos de WOPI. Si utiliza ownCloud Infinite Scale, su servicio de colaboración utiliza COLLABORATION_APP_ADDRpara la URL de la aplicación de Office y COLLABORATION_WOPI_SRCpara la fuente WOPI accesible externamente; consulte la documentación del servicio de colaboración de ownCloud .

¿Cuándo conviene utilizar el código integrado en lugar de un servidor Collabora independiente?

Para una instalación pequeña de Nextcloud, el servidor CODE integrado reduce la cantidad de componentes gestionados externamente. La desventaja es que aún depende de que la instancia de Nextcloud pueda acceder a sí misma a través del nombre de host utilizado en el navegador. La documentación de solución de problemas de Nextcloud lo menciona explícitamente y sugiere resolver correctamente dicho nombre de host cuando el servidor CODE integrado no puede conectarse.

Un servidor Collabora independiente suele ser la mejor opción cuando se necesita escalabilidad independiente, un servicio centralizado para múltiples instancias de almacenamiento o una arquitectura de producción con límites de recursos más definidos. Añade configuración de DNS, proxy, certificados, cortafuegos y confianza WOPI, por lo que la carga operativa es mayor.

Qué no hacer

• No desactive la validación WOPI como primera solución. Esto puede ocultar la discrepancia real del nombre de host y debilitar la seguridad.
• No exponga el puerto 9980 directamente solo porque el proxy esté fallando. Repare el proxy a menos que la exposición directa sea un diseño intencional y seguro.
• No dé por sentado que una respuesta 200 de la página principal de Collabora demuestra que la edición de documentos funciona. El descubrimiento, las funcionalidades, el acceso a archivos WOPI y los WebSockets son procesos independientes.
• No modifique varias capas a la vez. Realice pruebas después de cada cambio para determinar si la causa real fue DNS, TLS, el proxy o la confianza WOPI.

Lista de verificación final

Después de realizar un cambio, verifique el sistema en este orden:

1. Abrir /hosting/discoverydesde /hosting/capabilitiesun navegador.
2. Obtenga los mismos puntos finales del servidor de almacenamiento.
3. Desde el servidor de Collabora, obtenga la URL de estado del servidor de almacenamiento.
4. Abra un documento mientras supervisa los registros de Collabora y de almacenamiento.
5. Confirme que el navegador establece la conexión WebSocket de Collabora sin desconexiones repetidas.
6. Confirme que un segundo usuario puede abrir y editar un documento de prueba si se requiere edición colaborativa.

Si las seis comprobaciones se realizan correctamente, el mensaje genérico «Vaya, qué vergüenza» ya no debería ocultar un fallo de conexión. Si el mensaje persiste, registre las líneas exactas del registro de Collabora y el fallo de red del navegador correspondiente a un intento de apertura del documento; estas dos pruebas son más útiles que el propio mensaje genérico de la interfaz de usuario.