Correction du problème de déconnexion des sessions d'édition de documents CODE après 10 minutes

Si un document Collabora Online Development Edition (CODE) s'ouvre normalement, que les modifications fonctionnent, puis que l'éditeur se déconnecte au bout de 10 minutes environ, commencez par vérifier le chemin WebSocket entre le navigateur et CODE. Une coupure systématique de 600 secondes est bien plus révélatrice d'un problème de proxy inverse, de contrôleur d'entrée, d'équilibreur de charge ou de pare-feu que des délais d'inactivité par défaut de CODE.

Cette distinction est importante car modifier les paramètres d'inactivité de CODE peut masquer le véritable problème sans résoudre la connexion qui achemine le trafic d'édition. Le modèle de configuration Collabora actuel prévoit un délai d'inactivité de 15 minutes par vue et d'une heure par document, et non une limite de 10 minutes par session d'édition. Voir le modèle coolwsd.xml en amont . Si les utilisateurs sont en train de saisir du texte au moment de la déconnexion, un paramètre CODE basé uniquement sur l'inactivité est une explication encore moins convaincante.

Que signifie généralement une déconnexion de 10 minutes ?

Vérifié : L’exemple Nginx publié par Collabora utilise des en-têtes de mise à niveau WebSocket et un entier long proxy_read_timeout 36000spour la connexion WebSocket principale. Nginx indique que les connexions WebSocket proxy sont fermées lorsqu’aucune donnée n’est reçue dans le délai de lecture configuré, dont la proxy_read_timeoutvaleur par défaut est de 60 secondes. Consultez le manuel du SDK Collabora Online et la documentation du proxy WebSocket de Nginx .

Dépendance à l'environnement : un délai d'attente de 600 secondes peut être introduit par une autre couche proxy, même si le serveur Nginx en amont semble correctement configuré. Parmi les composants courants, on trouve Kubernetes Ingress, HAProxy, un équilibreur de charge cloud, un WAF ou un proxy inverse en amont. La valeur exacte du délai d'attente et la clé de configuration dépendent de ce composant.

Le symptôme seul ne prouve pas que Nginx soit en cause : « déconnexions après 10 minutes » ne suffit pas. Il est nécessaire de capturer l’erreur WebSocket et de corréler son horodatage avec les journaux du proxy et de CODE avant de modifier plusieurs couches simultanément.

Action : reproduire l’erreur avec les outils de développement du navigateur ouverts et enregistrer la durée de vie exacte de la requête WebSocket.

Étape 1 : Confirmer que c’est bien le WebSocket qui tombe en panne.

Ouvrez un document, puis les outils de développement de votre navigateur et accédez à l'onglet Réseau. Filtrez le trafic WebSocket. Le trafic lié à l'édition de code inclut généralement une /cool/connexion WebSocket. Laissez le document ouvert au-delà du point de défaillance.

Lors de la déconnexion de la session, examinez la requête WebSocket. Les informations les plus pertinentes sont sa durée, le délai de fermeture, le statut HTTP lors de la mise à jour initiale et la présence éventuelle d'une erreur réseau signalée par le navigateur. Une connexion initiale correcte 101 Switching Protocolssuivie d'une fermeture après environ 600 secondes indique un problème de durée de vie de la connexion ou de politique d'inactivité quelque part dans le processus.

Si la connexion WebSocket ne se met jamais à jour correctement, il ne s'agit pas d'un problème de délai d'attente de 10 minutes ; commencez par corriger le routage et les en-têtes WebSocket. Si la connexion WebSocket reste établie malgré l'affichage d'une erreur de stockage ou d'enregistrement dans l'éditeur, examinez plutôt le chemin d'accès WOPI/stockage.

Action : notez l’heure de début et l’heure de déconnexion, puis comparez ces horodatages avec les journaux d’accès/d’erreurs du proxy inverse et les journaux du conteneur ou du service CODE.

Étape 2 : Vérifiez la règle de proxy inverse CODE avant de modifier les valeurs d’inactivité de CODE

Pour Nginx, l'important est que l'emplacement WebSocket transmette les en-têtes de mise à jour et dispose d'un délai d'expiration de lecture suffisamment long. Le manuel du SDK de Collabora illustre ce modèle pour le WebSocket principal :

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

Si la connexion TLS est terminée par Nginx et que CODE sert intentionnellement du HTTP simple en aval, le schéma en amont peut être http://différent. Ne copiez pas ce schéma aveuglément : il doit correspondre à la configuration de votre instance CODE.

Une idée fausse courante est que ce paramètre proxy_connect_timeoutcontrôle la durée de vie d'une session d'édition déjà établie. En réalité, il ne la contrôle pas ; il s'applique lors de l'établissement de la connexion au serveur en amont. Le paramètre le plus pertinent pour une session WebSocket proxy établie, avec des périodes sans données en amont, est `http_output_session` proxy_read_timeout. Nginx documente ce comportement dans la documentation de son module proxy HTTP .

Action : localisez le bloc Nginx correspondant à l’URL WebSocket CODE et vérifiez que le délai d’expiration y est bien défini, et non pas dans un bloc non lié location.

Étape 3 : Prendre en compte les modifications apportées au proxy CODE 26.04

En octobre 2026, les notes de version de Collabora pour CODE 26.04 mentionnent la version 26.04.4.2, publiée le 24 septembre 2026. La série 26.04 a introduit une URL WebSocket plus compacte. Collabora indique que les configurations de proxy existantes peuvent nécessiter une mise à jour ; dans les versions ultérieures de CODE 26.04, l'ancienne URL pourra être utilisée et un avertissement d'audit sera émis si le proxy n'est pas mis à jour. Les utilisateurs d'Apache2 ont été spécifiquement invités à mettre à jour leur règle ProxyPass lors de la sortie de la version 26.04. Consultez les notes de version officielles de CODE 26.04 .

Cela ne signifie pas que chaque déconnexion de 10 minutes est due à la modification de l'URL compacte. Cela signifie que sur la version 26.04, vous devez vérifier vos règles de proxy inverse en les comparant à la documentation de la version que vous utilisez, surtout si le problème est apparu après une mise à jour.

Action : vérifiez votre version de CODE dans la section « À propos » du produit ou dans l’étiquette de l’image du conteneur, puis comparez votre configuration de proxy avec les recommandations actuelles de Collabora concernant les proxys. Ne considérez pas qu’une règle copiée d’un déploiement antérieur (version 24.04) soit toujours optimale.

Étape 4 : Vérifier Kubernetes Ingress, HAProxy, Apache et les autres boîtiers intermédiaires

Si Nginx n'est qu'une couche en amont du code, l'augmentation de son délai d'expiration peut s'avérer insuffisante. Pour Kubernetes utilisant ingress-nginx, le projet documente les annotations par Ingress nommées `ingress-nginx` nginx.ingress.kubernetes.io/proxy-read-timeoutet ` nginx.ingress.kubernetes.io/proxy-send-timeoutingress-nginx-timeout`. Ses recommandations concernant WebSocket préconisent des valeurs supérieures à une heure pour les connexions persistantes. Consultez la documentation officielle d'Ingress-Nginx sur les annotations et les notes WebSocket .

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

Pour HAProxy, l'exemple du SDK de Collabora utilise un délai d'expiration de tunnel long pour le trafic de type WebSocket. Pour Apache, le délai d'expiration générique du proxy est géré par `mod_proxy` ProxyTimeout, mais la norme CODE 26.04 exige également une attention particulière au modèle ProxyPass WebSocket actuel. La documentation de `mod_proxy` d'Apache explique les ProxyTimeoutparamètres de contrôle.

Action : tracer le chemin de connexion du navigateur au code et examiner chaque étape. Une limite de 600 secondes à chaque étape peut toujours interrompre la session.

Étape 5 : Validez et rechargez le proxy en toute sécurité

Après avoir modifié la configuration Nginx, testez-la avant de la recharger :

sudo nginx -t
sudo systemctl reload nginx

Si Nginx s'exécute dans un conteneur, utilisez la procédure de validation et de rechargement adaptée aux conteneurs au lieu de supposer systemctlson existence. Il est essentiel de valider la syntaxe avant de remplacer la configuration en cours d'exécution.

Action : modifier une couche à la fois, enregistrer la valeur précédente, valider la configuration, puis tester à nouveau le même flux de travail documentaire.

Étape 6 : Valider la correction avec un test plus long que l’ancienne limite

Ne cessez pas les tests lorsque le document se rouvre. Laissez la même session d'édition ouverte bien au-delà du point de défaillance précédent. Pour un symptôme durant 10 minutes, une période de validation de 20 à 30 minutes est plus utile qu'un test rapide de deux minutes. Gardez le panneau Réseau ouvert et effectuez des modifications occasionnelles afin de distinguer une session d'édition active d'un onglet totalement inactif.

Un bon résultat présente trois signes : la connexion WebSocket reste établie pendant plus de 10 minutes, l’éditeur continue d’accepter les modifications sans invites de reconnexion et aucun délai d’attente correspondant n’apparaît dans les journaux intermédiaires ou CODE.

Si la connexion se ferme toujours exactement 10 minutes après l'augmentation du délai d'expiration du proxy le plus proche, cela constitue une preuve utile qu'un autre nœud a toujours une politique de 600 secondes.

Action : poursuivre le traçage vers l’extérieur jusqu’à ce que le composant qui émet le signal de fermeture ou le délai d’expiration soit identifié.

Ne confondez pas les temporisateurs d'inactivité de CODE avec une coupure réseau de 10 minutes.

Le modèle de configuration CODE en amont indique actuellement une durée per_view.idle_timeout_secsde 900 secondes, soit 15 minutes. Sa description précise que l'affichage est assombri et que les mises à jour s'arrêtent lorsque l'utilisateur est inactif. La idle_timeout_secsvaleur par défaut au niveau du document est de 3 600 secondes, soit une heure, avant qu'un document inactif ne soit déchargé.

Il est utile de vérifier ces valeurs si votre comportement y correspond, mais aucune des valeurs par défaut n'explique une déconnexion de 600 secondes. Si quelqu'un a précédemment personnalisé coolwsd.xmlles variables d'environnement, les valeurs Helm ou les paramètres du conteneur, votre déploiement peut différer des valeurs par défaut.

Action : n’inspectez la configuration CODE effective qu’après avoir déterminé si la panne se situe au niveau du réseau ou de l’application. N’augmentez pas systématiquement toutes les valeurs inactives dans un premier temps.

Tableau de diagnostic rapide

En résumé

Pour une session d'édition de code qui se déconnecte systématiquement après 10 minutes, la procédure la plus efficace est la suivante : confirmer l'échec de la connexion WebSocket, vérifier la règle de proxy inverse correspondante, examiner chaque délai d'expiration intermédiaire, prendre en compte les modifications apportées au chemin du proxy dans CODE 26.04, recharger la page en toute sécurité et tester au-delà de l'ancien délai. Ne modifiez les paramètres d'inactivité de CODE que si le comportement observé et la configuration effective le justifient.

Si le délai d'attente n'est pas reproductible, ou si les journaux CODE indiquent des plantages, des arrêts de processus, une saturation de la mémoire ou des erreurs WOPI au même moment, il ne s'agit plus d'un simple dépassement de délai. Ces symptômes nécessitent un diagnostic différent.