Rétablir la connexion WebSocket de Collabora via le proxy

Lorsque Collabora Online signale une fermeture inattendue de la connexion WebSocket, vérifiez d'abord si la requête WebSocket du navigateur passe coolwsdpar le proxy inverse. Assurez-vous que la route du proxy corresponde à la version de Collabora, conservez la mise à niveau WebSocket et le chemin d'URL, puis testez un document tout en observant le panneau Réseau du navigateur et les journaux du serveur. Si le problème est apparu après une mise à niveau vers CODE 26.04 derrière Apache, vérifiez ProxyPassd'abord les règles Apache : les notes de version 26.04 de Collabora mentionnent une modification de l'URL WebSocket compacte.

Un WebSocket est la connexion bidirectionnelle persistante utilisée par Collabora entre le navigateur et son serveur lorsqu'un document est ouvert. Un proxy inverse est le service qui reçoit la requête publique et la transmet à Collabora. Le message d'erreur fait référence à cette connexion, mais ne prouve pas que le proxy en soit la cause ; un hôte WOPI refusé, une URL publique incorrecte, une incompatibilité TLS ou un serveur d'arrière-plan erroné peuvent également interrompre la session.

Avant de modifier quoi que ce soit, identifiez votre itinéraire

Notez la version ou l'étiquette de l'image Collabora, le logiciel proxy, le nom d'hôte public de Collabora et si la connexion TLS se termine au niveau du proxy ou de Collabora. Vérifiez le nom du service et l'image actuelle sans modifier le déploiement :

docker compose ps collabora
docker compose images collabora

Remplacez collabora`<service_name>` par le nom du service dans votre fichier Compose. Pour un conteneur non Compose, utilisez `<container_name>` docker pset docker inspect`<image_name>` pour identifier le conteneur et l'image. Ne présumez pas que l' latestétiquette pointe toujours vers la même version que celle testée la semaine dernière.

1. Observez où s'arrête la négociation WebSocket

Dans votre navigateur, ouvrez les outils de développement, sélectionnez Réseau , filtrez par WS ou WebSocket, puis réessayez d'ouvrir un document. L'URL de la requête devrait être utilisée wss://lorsque la page publique est en HTTPS. Sélectionnez la requête ayant échoué et notez son statut, son chemin d'URL et ses en-têtes de réponse. Une connexion réussie renvoie généralement une réponse 101 Switching Protocolset reste ouverte tant que la session du document est active.

• Aucune requête WebSocket n'apparaît : vérifiez l'URL Collabora de l'application d'intégration, la console du navigateur, le DNS et toute erreur de redirection ou de contenu mixte avant de modifier les règles du serveur.
• La requête renvoie une erreur 400 ou 404 : comparez le chemin demandé avec la route utilisée par votre proxy et celle prise en charge par la version de Collabora installée. Une erreur 400 coolwsdindiquant « Requête invalide ou inconnue » peut signifier que la requête a atteint Collabora avec un chemin non accepté.
• La requête renvoie 502 ou 504 : vérifiez si le proxy peut atteindre le Collabora en amont configuré et si l’adresse et le port pointent vers le conteneur ou l’hôte correct.
• La requête renvoie le code 101, puis se ferme ultérieurement : vérifiez les délais d’inactivité du proxy, de l’équilibreur de charge, du pare-feu et du réseau client. Un WebSocket ayant une longue durée de vie, un intermédiaire qui ferme trop tôt les connexions inactives peut interrompre une ouverture qui aurait autrement réussi.

2. Comparez la règle de proxy avec votre version de Collabora

Utilisez les paramètres de proxy inverse actuels de Collabora pour le logiciel et la version du proxy que vous utilisez. Vérifiez que la route WebSocket est correctement gérée, que le proxy transmet les en-têtes de mise à niveau et qu'il conserve le chemin et la chaîne de requête encodée sans les rediriger ni les réécrire. Le proxy doit également transmettre l'hôte public et le schéma conformément au nom du serveur externe et aux paramètres de terminaison TLS configurés dans Collabora.

Pour Nginx, consultez la configuration WebSocket et ses directives HTTP/1.1 Upgradeet Connectionde redirection dans l'exemple actuel de Collabora. Pour Apache, comparez la ProxyPassrègle et son ordre avec l'exemple actuel ; ne copiez pas une ancienne /cool/…/wsconfiguration sans vérifier les exigences de votre version installée.

Cette vérification de version est importante pour CODE 26.04. Les notes de version de Collabora, publiées le 8 juin 2026, décrivent une URL WebSocket plus compacte et indiquent que les utilisateurs de proxy inverse Apache doivent s'adapter ProxyPass. Des travaux ultérieurs sur la version 26.04 ont ajouté un comportement de repli pour les anciennes URL ; une règle plus ancienne peut donc encore fonctionner sur certaines configurations. Le rapport de Collabora sur les problèmes WebSocket résolus pour la version 26.04 documente ce suivi. Ce comportement de repli ne remplace pas la configuration du proxy actuelle et son adéquation à la version installée. Consultez conjointement les notes de version de CODE 26.04 et l'exemple de SDK mis à jour.

3. Identifiez un échec et apportez-y une modification ciblée.

Démarrez un court flux de journalisation avant de réessayer avec le document. --sinceL'option de Docker limite la sortie initiale, tandis que --followle flux inclut les nouvelles lignes ; consultez la documentation sur les journaux de Docker Compose .

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

Enregistrez l'heure du test et recherchez la même requête dans les journaux de Collabora et du proxy. Si le navigateur demande un chemin que le proxy redirige vers le mauvais serveur, mettez à jour uniquement cette route WebSocket en utilisant l'exemple de version correspondante de Collabora. Si la requête atteint Collabora mais que l'hôte, l'origine ou le schéma est rejeté, comparez le nom d'hôte public et le port avec le nom de serveur configuré et les en-têtes transférés. Si le journal indique plutôt un rejet d'hôte WOPI ou un échec de requête d'informations de fichier, vérifiez l'hôte autorisé du serveur d'intégration et son accessibilité depuis le conteneur Collabora ; cette étape est distincte de la négociation WebSocket du navigateur.

Rechargez le proxy après avoir validé sa configuration avec sa commande de vérification syntaxique. Évitez de modifier simultanément la terminaison TLS, les listes d'hôtes autorisés et les réécritures d'URL : modifier un seul paramètre par test permet d'interpréter le résultat suivant. Ne désactivez pas la vérification TLS et n'autorisez pas tous les hôtes WOPI par commodité.

4. Vérifiez la correction depuis le navigateur jusqu'au document.

Réessayez avec le même document. Dans les outils de développement, vérifiez que la requête WebSocket aboutit 101 Switching Protocolset reste ouverte. Assurez-vous que le document se charge complètement, que la connexion est maintenue et qu'une modification mineure est enregistrée avec succès. Une connexion stable ne suffit pas si l'accès au fichier WOPI ou son enregistrement échoue toujours.

Si la connexion échoue toujours, comparez le chemin de la requête du navigateur, la ligne d'accès/d'erreur du proxy et l' coolwsdentrée de journal correspondante au même horodatage. Cette comparaison en trois points permet de déterminer si le navigateur, le proxy, la route Collabora ou l'hôte WOPI est le prochain élément à examiner. Lorsque vous demandez de l'aide, masquez les jetons d'accès, les identifiants de document, les noms d'utilisateur et les noms d'hôtes privés dans les détails du navigateur et les journaux.