Voorkom dat codebewerkingssessies na 10 minuten eindigen.

Als een CODE-document na ongeveer 10 minuten betrouwbaar de verbinding verbreekt, controleer dan eerst het WebSocket-pad via elke reverse proxy of load balancer. Een inactiviteitstime-out van 600 seconden is een veelvoorkomende aanwijzing voor een configuratieprobleem, maar de timing alleen bewijst niet dat de proxy de oorzaak is; controleer welk onderdeel de verbinding verbreekt voordat u instellingen wijzigt. In de meeste implementaties is de praktische oplossing om de Collabora WebSocket-upgrade te behouden en de lees- en verzendtime-outs van de proxy langer in te stellen dan de langst verwachte bewerkingssessie.

Stel eerst vast waar de onderbreking optreedt.

Collabora Online maakt gebruik van een browserverbinding met de CODE-server, terwijl de documentintegratie ook afhankelijk is van WOPI-communicatie met de host, zoals Nextcloud. De richtlijnen voor reverse-proxy's van Collabora en de huidige Office-voorbeelden van Nextcloud beschrijven een aparte WebSocket-route voor documentsessies. Als die route ontbreekt, naar de verkeerde upstream-server wordt doorgestuurd of onderworpen is aan een inactiviteitstime-out, kan de editor de liveverbinding verliezen, terwijl de pagina zelf wel bereikbaar blijft.

Dat is een geverifieerde architectuurvereiste. Het betekent niet dat elke storing van tien minuten dezelfde oorzaak heeft: een cloud load balancer, ingress controller, firewall, VPN of andere proxy kan zijn eigen limiet opleggen. Beschouw het herhaalbare interval als een aanwijzing en controleer vervolgens de toegangs- en foutenlogboeken op het moment van de storing.

1. Noteer het exacte tijdstip waarop een sessie wordt verbroken en of dit gebeurt tijdens actief typen of alleen wanneer het document inactief is.
2. Open in de ontwikkelaarstools van de browser het paneel Netwerk, filter op "WS" en inspecteer de verbinding waarvan het pad eindigt op /ws. /cool/Noteer de status en sluit de verbinding indien de browser dit meldt.
3. Controleer op hetzelfde tijdstempel de logboeken van de reverse proxy of ingress, de CODE-serverlogboeken en de WOPI-hostlogboeken. Zoek naar een proxy-time-out, een upstream-reset, een abnormale WebSocket-sluiting of een WOPI-fout. De formulering van de logboeken verschilt per product en versie, dus ga er niet vanuit dat één bericht universeel is.

Als de WebSocket-verbinding na dezelfde geconfigureerde drempel van 600 seconden wordt verbroken, corrigeer dan de proxy of tussenpersoon die verantwoordelijk is voor die drempel. Als de verbinding na een ander interval wordt verbroken of als de logboeken een WOPI-fout of serverfout tonen, volg dan die aanwijzingen. De documentatie voor probleemoplossing van Nextcloud raadt specifiek aan om de connectiviteit in beide richtingen te controleren en zowel de Nextcloud- als de Collabora-logboeken te bekijken.

Houd de WebSocket-verbinding open via de proxy.

Voordat u een proxybestand bewerkt, moet u de actieve virtuele host en het daadwerkelijke upstream-schema en de poort voor CODE identificeren. Maak een back-up van de configuratie en controleer de syntaxis voordat u deze opnieuw laadt. Het onderstaande voorbeeld illustreert het vereiste WebSocket-gedrag voor een NGINX reverse proxy; het is geen complete Collabora virtuele host. Voeg het samen met de officiële configuratie voor uw implementatie en behoud daarbij de overige locatieblokken, TLS-instellingen, URI-afhandeling en beveiligingsregels.

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;
}

De Upgradeheaders Connectionzorgen ervoor dat het HTTP-verzoek wordt omgezet naar WebSocket. De langere lees- en verzendlimieten voorkomen dat deze proxy een stille verbinding na een korte standaardinterval sluit; ze zijn geen opdracht om een ​​sessie voor altijd open te houden. Pas het upstream-adres en de TLS-verificatie aan uw installatie aan en schakel certificaatcontroles niet uit om het voorbeeld werkend te krijgen.

De officiële proxy-voorbeelden van Collabora zijn leidend voor de complete, versie-specifieke routeringsconfiguratie. Hun huidige richtlijnen bevatten lange proxy-time-outs; het huidige Docker-voorbeeld van Nextcloud heeft ook een aparte /cool/(.*)/wsWebSocket-mapping. Gebruik die complete voorbeelden in plaats van uw volledige virtuele host te vervangen door dit kleine fragment:

• Collabora Online reverse proxy-instellingen
• Installatievoorbeeld van Nextcloud 35 met Docker

Voor NGINX moet u de nginx -tconfiguratie pas opnieuw laden nadat de test is geslaagd. Voor Apache moet u de configuratietest uitvoeren voordat u de configuratie opnieuw laadt. Als CODE achter Kubernetes Ingress of een cloud load balancer draait, zal het wijzigen van NGINX op de CODE-host een kortere time-out bij de Ingress of provider edge niet verhelpen; werk in dat geval het onderdeel bij dat in de logs wordt genoemd.

Controleer elke netwerkhop, niet alleen de CODE.

WebSocket-verkeer kan via meerdere tussenpersonen lopen: browser, CDN of firewall, externe load balancer, ingress, hostproxy en vervolgens CODE. Een lange time-out op de ene laag kan een kortere time-out op de volgende laag niet overschrijven. Vergelijk de inactiviteits- of verbindingstime-out van elke laag en stel de limiet van de WebSocket-route langer in dan de verwachte inactiviteitsperiode, binnen de limieten en het beleid van dat platform.

Verwar de instelling voor het automatisch afsluiten van een document niet met de netwerktime-out van de proxy. De eerste bepaalt wanneer een ongebruikt documentproces kan worden afgesloten; deze herstelt geen WebSocket die al door een tussenliggende server is gesloten. Evenmin lost het instellen van een zeer lange time-out een foutieve upgraderoute, geblokkeerd verkeer, een onjuiste HTTP/HTTPS-configuratie of een CODE-procescrash op. Controleer na elke wijziging of de sluitingstijd verandert of dat de geregistreerde oorzaak verdwijnt; dit verkleint de verantwoordelijke laag zonder onnodige wijzigingen aan te brengen.

Controleer of zowel de browser van de gebruiker als de WOPI-host de CODE-service via HTTPS kunnen bereiken, en of CODE de WOPI-host kan bereiken. Voor een Nextcloud-integratie wordt in de handleiding voor probleemoplossing aanbevolen om de openbare /hosting/capabilitiesen /hosting/discoveryeindpunten te controleren vanuit een browser en met curl, en vervolgens het Nextcloud-status-eindpunt vanaf de CODE-server te controleren. Deze controles bevestigen de basisbereikbaarheid; ze bewijzen op zichzelf niet dat een tot stand gebrachte WebSocket-verbinding tien minuten lang blijft bestaan.

Controleer de reparatie met een getimede sessie.

1. Herlaad de proxy- of ingress-configuratie met behulp van de ondersteunde validatiestap en open vervolgens een nieuwe documentsessie.
2. Houd het document langer open dan de vorige foutmelding optrad. Test het document eerst tijdens het bewerken en, als het probleem zich voordoet tijdens inactiviteit, test het daarna nogmaals in de stand-by modus.
3. Controleer /cool/.../wsin het netwerkpaneel van de browser of de verbinding open blijft en of het document nog steeds via de WOPI-host wordt opgeslagen.
4. Bekijk de logbestanden voor hetzelfde tijdsvenster. Een geslaagde test betekent dat er geen overeenkomende proxy-time-out of onverwachte WebSocket-sluiting optreedt en dat de wijzigingen behouden blijven na het opnieuw openen van het document.

Als de verbinding nog steeds verbroken wordt, herstel dan het geregistreerde tijdstip van de fout en vergelijk dit met de logboeken bij elke hop. Een sluitingstijd van 600 seconden bij de ingang wijst op die ingang; een andere sluitingstijd of een fout aan de serverzijde wijst op een andere oorzaak. De precieze oorzaak kan niet worden vastgesteld op basis van alleen "10 minuten", en time-outnamen en standaardwaarden variëren per proxyproduct en -release. Zorg ervoor dat de werkende configuratie met de CODE-versie en het proxyproduct gedocumenteerd is, zodat toekomstige upgrades kunnen worden gecontroleerd aan de hand van de huidige officiële voorbeelden.