Collabora Online peut sembler fonctionner correctement au premier abord, mais dysfonctionner dès que l'éditeur tente d'établir sa connexion WebSocket. Le symptôme classique est le chargement d'un document qui s'interrompt brusquement, signalant une fermeture inattendue de la connexion, parfois accompagnée d'une erreur wss://de requête dans le navigateur. En 2026, il existe une raison spécifique à la version à vérifier avant toute autre modification : la branche 26.04 a introduit une URL WebSocket plus compacte, et d'anciennes règles de proxy inverse peuvent entrer en conflit avec celle-ci.
Les notes de version officielles de Collabora CODE 26.04 indiquent que la version 26.04.1, publiée le 8 juin 2026, exigeait des utilisateurs de proxy inverse Apache2 qu'ils modifient leur règle ProxyPass pour la nouvelle URL WebSocket compacte. Les notes de version ultérieures (26.04.2.x) précisent que CODE peut utiliser l'ancienne URL lorsque la nouvelle route est indisponible et génère un avertissement d'audit renvoyant les administrateurs vers les recommandations actuelles concernant le proxy. La branche Collabora Online 26.04 pour entreprises est également à jour en 2026 ; par conséquent, les administrateurs doivent comparer toute configuration de proxy copiée d'un guide 24.04 ou 25.04 plus ancien avec la documentation la plus récente du fournisseur avant de considérer le problème comme une simple panne réseau.
Le message n'identifie pas de cause unique. Il signifie que la connexion WebSocket entre le navigateur et Collabora n'a pas été mise à jour correctement ou qu'elle a été établie puis interrompue de manière inattendue. Cette distinction est importante car les solutions diffèrent.
| Comportement observé | Premier contrôle le plus utile | Causes typiques |
|---|---|---|
| Échoue immédiatement à l'ouverture d'un document. | Réseau du navigateur > Journaux d'accès/d'erreurs WS et proxy inverse | Mauvaise /cool/route, en-têtes de mise à niveau manquants, règle Apache incompatible avec la version 26.04, incompatibilité hôte/origine |
| Fonctionne brièvement, puis se déconnecte à un intervalle régulier. | Délais d'inactivité des proxys, des serveurs d'entrée, des équilibreurs de charge et des pare-feu | Délai d'attente trop court pour une connexion WebSocket de longue durée. |
| La découverte fonctionne, mais l'édition échoue. | Tester le WebSocket séparément de/hosting/discovery | Les points de terminaison HTTP sont accessibles alors que la route WebSocket ne l'est pas. |
| Un seul navigateur ou chemin réseau est défaillant. | Comparer le protocole de requête et le comportement du proxy | Gestion HTTP/2 ou HTTP/3, transfert CONNECT, filtrage intermédiaire |
| Le journal du serveur rejette explicitement la mise à niveau. | Lisez l'erreur exacte de coolwsd | Incompatibilité de configuration de l'origine, de l'hôte, du port, de l'hôte WOPI ou du proxy |
Si le problème est apparu immédiatement après la migration depuis la version 25.04 ou une image CODE antérieure vers la version 26.04, le proxy inverse est le principal suspect. Il ne s'agit pas d'une simple supposition : Collabora a documenté la modification de l'URL WebSocket compacte dans les notes de version 26.04, et un problème officiel du projet a signalé des défaillances des WebSockets après une mise à niveau vers la version 26.04.1, jusqu'à la modification des règles du proxy Apache.
Ne résolvez pas ce problème en effectuant une rétrogradation sans modifier l'ancien proxy. Une restauration peut constituer une solution temporaire, mais la solution durable consiste à aligner le proxy sur la version que vous souhaitez utiliser. Pour Apache, utilisez les paramètres de proxy actuels de Collabora Online plutôt qu'une version antérieure à la 26.04. Le rapport de Collabora concernant les problèmes WebSocket de la version 26.04 décrit un cas où la mise à jour des règles Apache a permis de rétablir le fonctionnement.
Commencez par tester les points de terminaison Collabora ordinaires :
curl -I https://office.example.com/hosting/discovery
curl -I https://office.example.com/hosting/capabilitiesUne réponse positive indique que le DNS, le TLS, le proxy frontal et au moins une partie du service Collabora sont accessibles. Cela ne garantit cependant pas le bon fonctionnement de l'édition de documents. L'éditeur dépend d'une route WebSocket /cool/dont les exigences en matière de proxy sont différentes.
Ensuite, ouvrez les outils de développement de votre navigateur, reproduisez l'erreur et examinez le panneau Réseau avec le filtre WS. Une négociation WebSocket réussie entraîne normalement la mise à niveau de la connexion HTTP ; la RFC 6455 définit la réponse du serveur comme étant le code d'état HTTP 101 lorsque la mise à niveau réussit. Si vous obtenez une erreur 400, 404, 405, 502 ou une requête ayant échoué immédiatement, comparez cet horodatage avec les journaux du proxy inverse et de coolwsd.
Pour Nginx, les propriétés importantes sont simples : la requête doit atteindre le /cool/chemin Collabora, le proxy doit utiliser HTTP/1.1 pour un flux de mise à niveau WebSocket classique, les en Upgrade- Connectiontêtes doivent être transférés, l’hôte d’origine doit être préservé et le délai d’expiration de lecture doit être suffisamment long pour une session d’édition.
Le manuel du SDK Collabora indique depuis longtemps un emplacement WebSocket dédié avec Upgradedes en Connection- Hosttêtes longs proxy_read_timeout. Un problème de documentation officiel du projet Collabora a également souligné la nécessité d'en-têtes WebSocket sur la /coolroute principale. Un modèle conservateur compatible avec Ubuntu 26.04 est le suivant :
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;
}Ne copiez pas ce code par-dessus une configuration de production fonctionnelle sans adapter l'adresse amont, le modèle TLS, la gestion des chemins et les contrôles de sécurité existants. Il est préférable de préserver votre topologie tout en respectant les exigences actuelles de Collabora en matière de routage et d'en-tête.
Les sessions d'édition WebSocket sont de longue durée. Les valeurs Helm actuelles du projet Collabora le décrivent explicitement et utilisent un délai d'expiration important pour le proxy Nginx intégré. Si votre équilibreur de charge périphérique, votre point d'entrée Kubernetes, votre CDN, votre pare-feu ou votre proxy inverse ferme les connexions inactives plus tôt que prévu par l'application, les utilisateurs peuvent éditer normalement pendant un certain temps, puis être déconnectés à un intervalle régulier.
Si l'échec se produit systématiquement après un nombre de secondes sensiblement identique, examinez chaque intermédiaire du chemin au lieu d'augmenter uniquement le délai d'attente de Nginx. Le délai d'attente le plus court est prioritaire.
Dans une configuration courante, le protocole HTTPS est terminé au niveau de Nginx, Apache, HAProxy, Traefik ou d'un contrôleur d'entrée, et le trafic HTTP non chiffré est redirigé vers Collabora sur le port 9980. Dans cette architecture, la configuration officielle de Collabora exige que le serveur d'arrière-plan sache que le protocole TLS est terminé par le proxy. La documentation du SDK ssl.enable=falsedécrit ssl.termination=truece modèle.
Pour un déploiement Docker, cela s'exprime généralement via les paramètres supplémentaires de Collabora :
--o:ssl.enable=false --o:ssl.termination=trueN'utilisez ces options que lorsque le protocole TLS est effectivement terminé en amont. Si le proxy se connecte à Collabora via HTTPS, configurez cette topologie de manière cohérente plutôt que de mélanger les deux modèles. Une incompatibilité peut entraîner des schémas incorrects, des URL WebSocket erronées, des échecs de certificat ou des redirections empêchant la mise à niveau.
Collabora valide les origines WebSocket. Si le journal contient des informations telles que «Rejecting WebSocket upgrade suivi d'une origine et d'un hôte attendu », corrigez la correspondance nom d'hôte/port externe plutôt que d'ajouter des en-têtes permissifs de manière aléatoire. Le système de suivi des problèmes officiel de Collabora contient un exemple documenté où un nom de serveur configuré, incluant «:443 protocole », ne correspondait pas à l'origine du navigateur sans le port spécifié.
Les commandes utiles dépendent de votre installation :
docker logs collabora --tail 200
journalctl -u coolwsd --since "10 minutes ago"
nginx -t
apachectl configtestRecherchez la première erreur simultanément à l'échec de la requête WS. Les messages concernant les mises à niveau refusées, une syntaxe d'URI incorrecte, un hôte inattendu ou un serveur en amont indisponible sont plus exploitables que la fenêtre contextuelle générique du navigateur.
Il s'agit d'un cas plus spécifique, mais il est conseillé de le vérifier avant de reconstruire le serveur. Le projet Collabora a documenté un cas lié à Chromium où un proxy a transmis une requête WebSocket HTTP/2 CONNECT directement à coolwsd et a reçu une erreur 405 (Méthode non autorisée). Un autre problème signale des échecs de chargement de documents liés à HTTP/3/QUIC sur un chemin de proxy particulier. Ces signalements n'impliquent pas que HTTP/2 ou HTTP/3 doivent être systématiquement désactivés ; ils indiquent simplement que l'intermédiaire doit traduire le comportement du client en une connexion WebSocket compatible avec Collabora.
Si Firefox fonctionne alors que Chrome échoue sur le même compte et le même document, notez le protocole et le code d'état au niveau du proxy. Il est préférable de corriger le comportement du proxy/ingress plutôt que de désactiver globalement les protocoles modernes, sauf si votre environnement ne dispose d'aucune alternative compatible.
Commencez par tester la syntaxe du proxy. Ensuite, rechargez-le plutôt que de procéder à des redémarrages à l'aveugle répétés.
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2Pour les conteneurs, redémarrez le service Collabora uniquement si vous avez modifié son environnement ou coolwsdses paramètres. Une modification concernant uniquement le proxy ne nécessite généralement qu'un rechargement de ce dernier.
Utilisez une courte séquence de vérification au lieu de vous fier à l'ouverture réussie d'un seul document :
/hosting/discoveryet /hosting/capabilitiessoyez joignables via le même nom d'hôte public auquel les utilisateurs accèdent.Si vous avez effectué la mise à niveau vers la version 26.04 et utilisez Apache, la mise à jour des règles de proxy est prioritaire, car Collabora a explicitement documenté cette modification. Si la déconnexion survient après un délai fixe, vérifiez les paramètres de délai d'attente pour chaque saut réseau. Si l'échec est immédiat sur tous les navigateurs, contrôlez /cool/le routage, les en-têtes Upgrade, la cohérence des paramètres Host/Origin et la terminaison TLS. Si seul un navigateur rencontre ce problème, comparez la gestion du protocole HTTP avant de modifier Collabora.
L'essentiel est d'éviter de considérer par défaut une erreur de type « connexion socket fermée de manière inattendue » comme un plantage de l'application Collabora. Dans de nombreux déploiements, l'éditeur, le point de terminaison de découverte et l'hôte WOPI fonctionnent correctement, tandis que le proxy inverse gère mal le type de connexion le plus important pour l'édition en direct : la connexion WebSocket persistante.
Connectez les éditeurs de bureau ONLYOFFICE à votre serveur ownCloud, connectez-vous, ouvrez des fichiers cloud, gérez la connexion et résolvez les problèmes de configuration courants.
Résolvez les problèmes d'utilisation élevée du processeur de Collabora Online en identifiant les processus du kit occupés, en vérifiant les indicateurs et les journaux, en ajustant la concurrence et le nettoyage, et en vérifiant les correctifs en toute sécurité.
Découvrez comment personnaliser ONLYOFFICE Docs avec un logo d'en-tête et des couleurs d'interface, y compris les limites de licence, la configuration JSON du thème, les chemins Docker et les tests.
Corrigez les textes difficiles à lire dans LibreOffice Calc en vérifiant le thème de l'application, la police et les couleurs de remplissage des cellules, les styles et la mise en forme conditionnelle, puis vérifiez le résultat d'impression.
Débloquez en toute sécurité l'avertissement de verrouillage par utilisateur inconnu de LibreOffice. Vérifiez les sessions actives, protégez une copie, supprimez uniquement un verrouillage obsolète vérifié et testez le document.
Corrigez les problèmes de mise en page du texte arabe ou hébreu avec l'anglais dans LibreOffice Writer. Activez la mise en page complexe, définissez le sens des paragraphes et vérifiez le résultat.
Learn VLOOKUP and XLOOKUP in LibreOffice Calc, including exact matches, left lookups, not-found results, reverse search, INDEX/MATCH alternatives, and common errors.
Résolvez les problèmes de validation des preuves WOPI de Collabora Online en vérifiant les clés de découverte, la rotation des clés, les URL proxy, les horodatages et les listes d'autorisation des hôtes.
Activez le suivi des modifications pour tous les utilisateurs dans un document ONLYOFFICE, maintenez-le actif après la réouverture et comprenez les limites d'une option par défaut globale.
Comparez les délais d'expiration par vue, hors focus, d'inactivité des documents, de sauvegarde automatique et de proxy de Collabora Online, puis choisissez et vérifiez les paramètres pour votre déploiement.
