Empêcher la fin automatique des sessions d'édition de code après 10 minutes.

Si un document CODE se déconnecte systématiquement au bout d'une dizaine de minutes, vérifiez d'abord le chemin WebSocket via chaque proxy inverse ou équilibreur de charge. Un délai d'inactivité de 600 secondes est un indice de configuration courant, mais ce délai seul ne prouve pas que le proxy soit en cause ; vérifiez quel composant ferme la connexion avant de modifier les paramètres. Dans la plupart des déploiements, la solution pratique consiste à conserver la mise à niveau WebSocket de Collabora et à configurer les délais d'expiration de lecture et d'envoi du proxy à une durée supérieure à celle de la session d'édition la plus longue prévue.

Tout d'abord, confirmez où se produit la déconnexion.

Collabora Online utilise une connexion navigateur au serveur CODE, tandis que l'intégration des documents repose également sur une communication WOPI avec l'hôte, tel que Nextcloud. La documentation de Collabora relative au proxy inverse et les exemples Office actuels de Nextcloud décrivent une route WebSocket distincte pour les sessions de documents. Si cette route est absente, dirigée vers un serveur amont incorrect ou soumise à un délai d'inactivité, l'éditeur peut perdre sa connexion, même si la page reste accessible.

Il s'agit d'une exigence architecturale vérifiée. Cela ne signifie pas pour autant que chaque panne de dix minutes a la même cause : un équilibreur de charge cloud, un contrôleur d'entrée, un pare-feu, un VPN ou un autre proxy peut imposer sa propre limite. Considérez l'intervalle reproductible comme un indicateur, puis consultez les journaux d'accès et d'erreurs au moment de la panne.

1. Enregistrez l'heure exacte à laquelle une session se déconnecte et si cela se produit pendant la saisie active ou seulement lorsque le document est inactif.
2. Dans les outils de développement du navigateur, ouvrez le panneau Réseau, filtrez sur « WS » et examinez la connexion dont le chemin se termine /wssous /cool/. Notez son état et fermez le code si le navigateur en signale un.
3. Au même moment, consultez les journaux du proxy inverse ou du serveur d'entrée, les journaux du serveur CODE et les journaux de l'hôte WOPI. Recherchez un délai d'attente du proxy, une réinitialisation du serveur en amont, une fermeture anormale de WebSocket ou une erreur WOPI. La formulation des journaux varie selon le produit et la version ; par conséquent, aucun message n'est universel.

Si la connexion WebSocket s'interrompt après le délai configuré de 600 secondes, corrigez le problème au niveau du proxy ou de l'intermédiaire qui gère ce délai. Si elle s'interrompt après un autre intervalle ou si les journaux indiquent une erreur WOPI ou serveur, suivez plutôt ces indications. La documentation de dépannage de Nextcloud recommande spécifiquement de vérifier la connectivité bidirectionnelle et de consulter les journaux de Nextcloud et de Collabora.

Maintenez la connexion WebSocket ouverte via le proxy

Avant de modifier un fichier proxy, identifiez l'hôte virtuel actif ainsi que le schéma et le port en amont utilisés par CODE. Sauvegardez la configuration et vérifiez la syntaxe avant de la recharger. L'exemple ci-dessous illustre le comportement WebSocket requis pour un proxy inverse NGINX ; il ne s'agit pas d'un hôte virtuel Collabora complet. Intégrez-le à la configuration officielle de votre déploiement, en conservant ses autres blocs d'emplacement, paramètres TLS, gestion des URI et règles de sécurité.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

Les en-têtes UpgradeHTTP Connectionet WebSocket permettent de basculer la requête HTTP vers WebSocket. Les limites de lecture et d'envoi plus longues empêchent ce proxy de fermer une connexion inactive après un court intervalle par défaut ; il ne s'agit pas d'une commande pour maintenir une session ouverte indéfiniment. Adaptez l'adresse du serveur en amont et la vérification TLS à votre installation et ne désactivez pas les vérifications de certificat simplement pour que l'exemple fonctionne.

Les exemples de proxy officiels de Collabora font autorité en matière de configuration de routage complète et adaptée à la version. Leurs recommandations actuelles préconisent des délais d'expiration de proxy longs ; l'exemple Docker actuel de Nextcloud inclut également un /cool/(.*)/wsmappage WebSocket dédié. Utilisez ces exemples complets plutôt que de remplacer l'intégralité de votre hôte virtuel par ce court extrait :

• Paramètres de proxy inverse de Collabora Online
• Exemple d'installation de Nextcloud 35 avec Docker

Pour NGINX, exécutez nginx -tet rechargez uniquement après la réussite du test. Pour Apache, utilisez son test de configuration avant de recharger. Si CODE s'exécute derrière un ingress Kubernetes ou un équilibreur de charge cloud, la modification de NGINX sur l'hôte CODE ne résoudra pas un délai d'attente plus court au niveau de l'ingress ou du fournisseur ; mettez à jour le composant identifié dans les journaux.

Vérifiez chaque saut de réseau, pas seulement le code.

Le trafic WebSocket peut transiter par plusieurs intermédiaires : navigateur, CDN ou pare-feu, équilibreur de charge externe, serveur d'entrée, proxy hôte, puis code. Un délai d'attente long à un niveau ne peut pas compenser un délai d'attente plus court au niveau suivant. Comparez les délais d'inactivité ou de connexion de chaque niveau et configurez la limite de la route WebSocket pour qu'elle soit supérieure à la période d'inactivité prévue, dans le respect des limites et de la politique de la plateforme.

Ne confondez pas le paramètre de déchargement automatique d'un document avec le délai d'expiration réseau du proxy. Le premier détermine quand un processus de document inactif peut être déchargé ; il ne répare pas une connexion WebSocket déjà fermée par un intermédiaire. De même, définir un délai d'expiration très long ne corrige pas un mauvais itinéraire de mise à niveau, un trafic bloqué, une configuration HTTP/HTTPS incompatible ou un plantage du processus CODE. Après chaque modification, vérifiez que le délai de fermeture est modifié ou que la cause consignée disparaît ; cela permet de cibler la couche responsable sans introduire de modifications non pertinentes.

Vérifiez que le navigateur de l'utilisateur et l'hôte WOPI peuvent accéder au service CODE via HTTPS, et que CODE peut accéder à l'hôte WOPI. Pour une intégration Nextcloud, son manuel de dépannage recommande de vérifier les points de terminaison publics /hosting/capabilitieset /hosting/discoveryexternes depuis un navigateur curl, puis de consulter le point de terminaison d'état Nextcloud depuis le serveur CODE. Ces vérifications confirment l'accessibilité de base ; elles ne prouvent pas à elles seules qu'une connexion WebSocket établie est maintenue pendant dix minutes.

Vérifiez la réparation à l'aide d'une session chronométrée

1. Rechargez la configuration du proxy ou de l'entrée en utilisant son étape de validation prise en charge, puis ouvrez une nouvelle session de document.
2. Laissez le document ouvert plus longtemps que la durée de la précédente erreur. Effectuez un test en cours d'édition et, si le problème signalé survient en période d'inactivité, un autre test lorsque le document est inactif.
3. Vérifiez que la /cool/.../wsconnexion reste ouverte dans le panneau Réseau du navigateur et que le document continue de s'enregistrer via l'hôte WOPI.
4. Consultez les journaux pour la même période. Un test réussi signifie qu'aucun délai d'expiration de proxy ni fermeture WebSocket inattendue ne se produit et que les modifications sont conservées après la réouverture du document.

Si la déconnexion persiste, rétablissez l'heure de défaillance enregistrée et comparez-la aux journaux de chaque saut. Une fermeture de 600 secondes au niveau du point d'entrée indique que le problème vient de ce point ; une heure de fermeture différente ou une erreur côté serveur indique un autre problème. La cause précise ne peut être établie à partir de la seule durée de « 10 minutes », et les noms et valeurs par défaut des délais d'expiration varient selon les produits proxy et leurs versions. Conservez la configuration fonctionnelle avec la version du code et le produit proxy documentés afin que les futures mises à jour puissent être comparées aux exemples officiels actuels.