Herstel de WebSocket-verbinding van Collabora via de proxy.

Wanneer Collabora Online meldt dat een socketverbinding onverwacht is verbroken, controleer dan eerst of het WebSocket-verzoek van de browser coolwsdvia de reverse proxy loopt. Stem de proxyroute af op de Collabora-versie, behoud de WebSocket-upgrade en het URL-pad, en test vervolgens één document terwijl u het netwerkpaneel van de browser en de serverlogboeken in de gaten houdt. Als het probleem is ontstaan ​​na een upgrade naar CODE 26.04 achter Apache, controleer ProxyPassdan eerst de Apache-regels: in de release-opmerkingen van Collabora 26.04 wordt een wijziging voor de compacte WebSocket-URL vermeld.

Een WebSocket is de langdurige, tweewegverbinding die Collabora gebruikt tussen de browser en de server zolang een document open is. Een reverse proxy is de service die het openbare verzoek accepteert en doorstuurt naar Collabora. De foutmelding verwijst naar die verbinding, maar bewijst niet dat de proxy de oorzaak is; een geweigerde WOPI-host, een onjuiste openbare URL, een TLS-mismatch of een verkeerde backend kunnen de sessie ook stoppen.

Voordat je iets verandert, bepaal eerst je route.

Noteer de Collabora-versie of imagetag, de proxysoftware, de openbare Collabora-hostnaam en of TLS eindigt bij de proxy of bij Collabora. Controleer de servicenaam en de huidige image zonder de implementatie te wijzigen:

docker compose ps collabora
docker compose images collabora

Vervang dit collaboradoor de servicenaam in uw Compose-bestand. Voor een container die geen Compose-bestand gebruikt, gebruikt u docker psen docker inspectom de container en image te identificeren. Ga er niet vanuit dat de latesttag nog steeds verwijst naar dezelfde versie die u vorige week hebt getest.

1. Kijk waar de WebSocket-handshake stopt.

Open in de browser de ontwikkelaarstools, selecteer Netwerk , filter op WS of WebSocket en probeer een document opnieuw te openen. De URL die u moet gebruiken wss://wanneer de openbare pagina HTTPS gebruikt. Selecteer het mislukte verzoek en noteer de status, het URL-pad en de antwoordheaders. Een succesvolle handshake retourneert normaal gesproken een succesvolle verbinding 101 Switching Protocolsen blijft open zolang de documentensessie actief is.

• Er verschijnt geen WebSocket-verzoek: controleer de Collabora-URL van de integratie-app, de browserconsole, DNS en eventuele omleidings- of mixed-contentfouten voordat u de serverregels bewerkt.
• Het verzoek retourneert een 400- of 404-fout: vergelijk het aangevraagde pad met de route die uw proxy doorstuurt en de route die wordt ondersteund door de geïnstalleerde Collabora-versie. Een 400-fout met de coolwsdmelding "Ongeldig of onbekend verzoek" kan betekenen dat het verzoek Collabora heeft bereikt met een pad dat niet wordt geaccepteerd.
• Het verzoek retourneert 502 of 504: controleer of de proxy de geconfigureerde Collabora-upstream kan bereiken en of het adres en de poort naar de juiste container of host verwijzen.
• Het verzoek retourneert 101 en sluit vervolgens later: controleer de time-outs voor inactiviteit van de proxy, load balancer, firewall en clientnetwerk. Een WebSocket-verbinding is langdurig actief, dus een tussenliggende server die inactieve verbindingen te vroeg sluit, kan een anders succesvolle opening verstoren.

2. Vergelijk de proxyregel met uw Collabora-versie.

Gebruik de huidige reverse-proxy-instellingen van Collabora voor de proxysoftware en -versie die u gebruikt. Controleer of de WebSocket-route als een WebSocket wordt behandeld, of de proxy de upgrade-headers doorstuurt en of het pad en de gecodeerde queryreeks behouden blijven in plaats van deze om te leiden of te herschrijven. De proxy moet ook de openbare host en het schema consistent verzenden met de door Collabora geconfigureerde externe servernaam en TLS-terminatie-instellingen.

Voor Nginx, bekijk de WebSocket-specifieke locatie en de HTTP/1.1-, Upgradeen Connectionforwarding-richtlijnen in het huidige voorbeeld van Collabora. Vergelijk voor Apache de ProxyPassregel en de volgorde met het huidige voorbeeld; plak geen oude /cool/…/wsovereenkomst zonder eerst te controleren wat uw geïnstalleerde versie nu vereist.

Deze versiecontrole is belangrijk voor CODE 26.04. De release-opmerkingen van Collabora, gepubliceerd op 8 juni 2026, beschrijven een compactere WebSocket-URL en geven aan dat gebruikers van Apache reverse-proxy's zich ProxyPasshierop moeten aanpassen. Latere werkzaamheden aan 26.04 hebben een fallback-functionaliteit toegevoegd voor oudere URL's, waardoor een oudere regel mogelijk nog steeds werkt in sommige builds; het opgeloste WebSocket-rapport van Collabora voor 26.04 documenteert deze vervolgactie. De fallback is geen vervanging voor het afstemmen van de huidige proxyconfiguratie op de geïnstalleerde versie. Lees de release-opmerkingen van CODE 26.04 en het bijgewerkte SDK-voorbeeld samen.

3. Leg één mislukking vast en voer één gerichte wijziging door.

Start een korte logstream voordat u het document opnieuw probeert te laden. --sinceDe optie van Docker beperkt de initiële uitvoer, terwijl --follownieuwe regels worden gestreamd; zie de Docker Compose-logreferentie .

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

Noteer het tijdstip van de test en zoek naar hetzelfde verzoek in de Collabora- en proxylogboeken. Als de browser een pad opvraagt ​​dat de proxy naar de verkeerde backend routeert, werk dan alleen die WebSocket-route bij met behulp van het versie-overeenkomende voorbeeld van Collabora. Als het verzoek Collabora bereikt, maar de host, oorsprong of het schema wordt geweigerd, vergelijk dan de openbare hostnaam en poort met de geconfigureerde servernaam en de doorgestuurde headers. Als het logboek in plaats daarvan een WOPI-hostweigering of een mislukt verzoek om bestandsinformatie weergeeft, controleer dan de toegestane host van de integratieserver en de bereikbaarheid ervan vanuit de Collabora-container; dit is een aparte stap van de WebSocket-handshake van de browser.

Herlaad de proxy nadat u de configuratie ervan hebt gevalideerd met het eigen syntaxcontrolecommando van die proxy. Vermijd het gelijktijdig wijzigen van TLS-terminatie, host-whitelists en URL-herschrijvingen: het wijzigen van één oorzaak per test maakt het volgende resultaat interpreteerbaar. Schakel TLS-verificatie niet uit en sta niet elke WOPI-host toe als snelkoppeling.

4. Controleer of de correctie in de browser is doorgevoerd in het document.

Probeer hetzelfde document opnieuw. Controleer in de ontwikkelaarstools of het WebSocket-verzoek wordt geretourneerd 101 Switching Protocolsen open blijft. Controleer of het document volledig is geladen, de verbinding stabiel blijft en een kleine bewerking accepteert die succesvol wordt opgeslagen. Een goede verbindingsstatus alleen is niet voldoende als de toegang tot of het opslaan van WOPI-bestanden nog steeds mislukt.

Als de handshake nog steeds mislukt, vergelijk dan het aanvraagpad van de browser, de toegangs-/foutmelding van de proxy en de bijbehorende coolwsdlogvermelding op hetzelfde tijdstempel. Deze vergelijking op drie punten laat zien of de browser, proxy, Collabora-route of WOPI-host de volgende plek is om te onderzoeken. Wanneer u om hulp vraagt, verwijder dan toegangstokens, document-ID's, gebruikersnamen en privé-hostnamen uit zowel de browsergegevens als de logbestanden.