Los de Collabora Online-verbindingsfout "Nou, dit is gênant" op.

Het Collabora Online-bericht "Dit is gênant, we kunnen geen verbinding maken met uw document" is een symptoom, geen diagnose. Het verschijnt nadat de editorshell is geladen, maar de documentsessie niet kan worden voltooid. In de huidige implementaties is de snelste manier om dit op te lossen, te achterhalen welke verbinding in het WOPI-pad mislukt, in plaats van willekeurige Collabora-instellingen te wijzigen.

Deze handleiding gebruikt de huidige Nextcloud 35-beheerdocumentatie en de SDK-richtlijnen van Collabora Online 25.04 als referentiepunten. Dezelfde probleemoplossingslogica is van toepassing op veel ownCloud- en aangepaste WOPI-integraties, maar de exacte instellingsnamen kunnen per platform en release verschillen.

Wat is doorgaans de oorzaak van deze Collabora-verbindingsfout?

Een werkende browsersessie is afhankelijk van verschillende afzonderlijke paden. De browser van de gebruiker moet zowel de opslagserver als Collabora kunnen bereiken; de opslagserver moet Collabora kunnen bereiken; Collabora moet de opslagserver kunnen bereiken; de protocollen en certificaten moeten compatibel zijn; en de reverse proxy moet de HTTP- en WebSocket-routes van Collabora correct doorsturen. De officiële pagina voor probleemoplossing van Nextcloud vermeldt deze vereisten voor bidirectionele bereikbaarheid expliciet.

Dat betekent dat er geen universeel correcte oplossing bestaat. Kies de reparatiemethode op basis van de eerste mislukte test:

1. Controleer de Collabora-ontdekkings- en mogelijkheden-eindpunten.

Begin met de openbare Collabora-URL die uw integratie daadwerkelijk gebruikt. Open deze eindpunten in een browser en vanaf de opslagserver:

https://office.example.com/hosting/discovery
https://office.example.com/hosting/capabilities

De huidige documentatie voor probleemoplossing van Nextcloud beveelt beide tests aan. Het discovery-eindpunt moet XML retourneren, terwijl capabilities Collabora-functionaliteitsgegevens retourneert. Een time-out, certificaatwaarschuwing, 404-fout, proxy-gerelateerde foutpagina of een oneindige omleidingslus betekent dat u het netwerk of de reverse proxy moet herstellen voordat u de WOPI-instellingen aanpast.

Controleer eerst de openbare Collabora-ontdekkings- en -functionaliteits-URL's; beide moeten bereikbaar zijn via dezelfde hostnaam die door de integratie wordt gebruikt.

Voor gezaghebbende richtlijnen voor eindpunten raadpleegt u de handleiding voor het oplossen van problemen met Nextcloud Office en de handleiding van de Collabora Online 25.04 SDK .

2. Test alle vier netwerkrichtingen, niet alleen de browser.

Een veelgemaakte fout is de aanname dat office.example.comCollabora, omdat het in een desktopbrowser wordt geopend, ook bestanden van de opslagserver kan ophalen. Dat is niet gegarandeerd. Test het vanaf de daadwerkelijke hosts of containers:

# From the Nextcloud/storage server
curl -fsS https://office.example.com/hosting/discovery >/dev/null && echo OK

# From the Collabora host/container
curl -fsS https://cloud.example.com/status.php

# Then inspect Collabora logs
docker logs --tail 100 collabora

Als de publieke hostnaam binnen Docker, Kubernetes of een privénetwerk anders wordt opgelost, moet u beslissen of u de interne DNS wilt corrigeren, een geschikte hostmapping wilt toevoegen of de routering via het publieke eindpunt wilt laten verlopen. Interne DNS is meestal overzichtelijker op grote schaal; een vermelding in het hosts-bestand is snel voor een kleine statische installatie, maar wordt lastiger te onderhouden.

Voer bereikbaarheidstests uit vanaf de servers zelf en gebruik vervolgens het Collabora-logboek om een ​​netwerkfout te onderscheiden van een WOPI-vertrouwensfout.

3. Herstel de reverse proxy als er WebSockets- of Collabora-routes ontbreken.

Collabora is geen normale statische webapplicatie. De reverse proxy heeft routes nodig voor browserassets, discovery/capabilities, documentverkeer en WebSockets. In de SDK-handleiding van Collabora stuurt het Nginx-voorbeeld /browser, /hosting/discovery, /hosting/capabilities, het /cool/.../wsWebSocket-pad en gerelateerd /coolverkeer door /lool.

Voor de WebSocket-route moet de proxy de host behouden en de HTTP-upgrade doorgeven. Een vereenvoudigd Nginx-patroon is:

location ~ ^/cool/(.*)/ws$ {
    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 $host;
    proxy_read_timeout 36000s;
}

Kopieer dit niet blindelings als u TLS op een andere manier beëindigt. Collabora documenteert aparte patronen voor end-to-end TLS- en SSL-beëindiging. Als TLS wordt beëindigd bij Nginx en de backend-verbinding HTTP is, moeten de interne SSL-instellingen van Collabora overeenkomen met dat ontwerp. Het gebruik van HTTPS overal is eenvoudiger te begrijpen, terwijl TLS-beëindiging bij de proxy de certificaatverwerking binnen containers vermindert, maar een extra configuratiebeperking introduceert.

Een correcte reverse proxy moet de HTTP-routes van Collabora doorsturen en de WebSocket-upgrade voor de documentensessie behouden.

4. Controleer de consistentie van het protocol, het certificaat en de hostnaam.

De huidige configuratiedocumentatie van Nextcloud Office vermeldt dat de Collabora Online-server hetzelfde protocol moet gebruiken als de Nextcloud-installatie, waarbij HTTPS wordt aanbevolen. In de praktijk kan een combinatie van openbare HTTP- en HTTPS-configuraties leiden tot geblokkeerde content, onjuiste redirect-bestemmingen of fouten bij de validatie van backend-certificaten.

Controleer deze items samen:

• De Collabora-URL die in uw opslagplatform is opgeslagen, is de exacte openbare URL die gebruikers kunnen bereiken.
• Het certificaat dat door die hostnaam wordt gepresenteerd, is geldig voor die hostnaam en wordt vertrouwd door de opslagserver.
• Collabora kan het HTTPS-certificaat van de opslagserver valideren.
• Uw reverse proxy stuurt de oorspronkelijke host en het schema correct door.
• Er vindt geen omleiding plaats van de geconfigureerde Collabora-hostnaam naar een andere hostnaam die WOPI niet verwacht.

Een zelfondertekend certificaat kan in een testomgeving acceptabel zijn als elk onderdeel expliciet is geconfigureerd om het te vertrouwen, maar dat gemak gaat ten koste van de draagbaarheid en leidt er vaak toe dat upgrades of het opnieuw opbouwen van containers later mislukken. Voor een productieomgeving is een openbaar of door de organisatie vertrouwd certificaat de veiligere keuze.

5. Corrigeer de WOPI-toegangslijsten in plaats van ze uit te schakelen.

Als de detectie werkt en de Collabora-logboeken berichten weergeven zoals Unauthorized WOPI host'geen acceptabele WOPI-host die overeenkomt met het doel', dan is het probleem verschoven van basisconnectiviteit naar vertrouwensconfiguratie. De officiële documentatie voor probleemoplossing van Nextcloud verwijst beheerders in dit geval specifiek naar de containerlogboeken.

Wat de opslag betreft, raadt Nextcloud aan om WOPI-verzoeken te beperken tot de IP-adressen van de Collabora-servers met behulp van de instelling 'Toegestane lijst voor WOPI-verzoeken' . Aan de Collabora-kant moeten de toegestane WOPI-opslaghosts overeenkomen met de opslag-URL's die Collabora daadwerkelijk ontvangt. Voor meerdere opslagdomeinen beschrijft de huidige SDK van Collabora WOPI-aliasgroepen.

Zorg ervoor dat de URL van de Collabora-server en de WOPI-toegangslijst overeenkomen met de daadwerkelijke implementatie; gebruik een beperkt aantal vertrouwde vermeldingen in plaats van de validatie uit te schakelen.

Zie de Nextcloud Office-configuratie voor de huidige server-URL en richtlijnen voor de WOPI-whitelist. Als u ownCloud Infinite Scale gebruikt, gebruikt de samenwerkingsservice COLLABORATION_APP_ADDRde URL voor de Office-app en COLLABORATION_WOPI_SRCde extern bereikbare WOPI-bron; raadpleeg de documentatie van de ownCloud-samenwerkingsservice .

Wanneer moet je de ingebouwde CODE gebruiken in plaats van een aparte Collabora-server?

Voor een kleine Nextcloud-installatie vermindert de ingebouwde CODE-server het aantal extern beheerde componenten. Het nadeel is dat de server nog steeds afhankelijk is van de mogelijkheid voor de Nextcloud-instantie om zichzelf te bereiken via de hostnaam die in de browser wordt gebruikt. De documentatie voor probleemoplossing van Nextcloud vermeldt dit expliciet en suggereert om die hostnaam correct op te lossen wanneer de ingebouwde CODE-server geen verbinding kan maken.

Een aparte Collabora-server is doorgaans een betere oplossing wanneer u onafhankelijke schaalbaarheid, een gecentraliseerde service voor meerdere opslaginstanties of een productiearchitectuur met duidelijkere resourcegrenzen nodig hebt. Het voegt DNS-, proxy-, certificaat-, firewall- en WOPI-vertrouwensconfiguratie toe, waardoor de operationele belasting hoger is.

Wat je vooral niet moet doen

• Schakel WOPI-validatie niet als eerste oplossing uit. Dit kan de daadwerkelijke mismatch in de hostnaam maskeren en de beveiliging verzwakken.
• Stel poort 9980 niet rechtstreeks open alleen omdat de proxy niet werkt. Herstel het proxyprobleem, tenzij directe openstelling een opzettelijk en beveiligd onderdeel van het ontwerp is.
• Ga er niet van uit dat een 200-respons van de Collabora-homepage bewijst dat documentbewerking werkt. Ontdekking, mogelijkheden, WOPI-bestandstoegang en WebSockets zijn aparte processen.
• Wijzig niet meerdere lagen tegelijk. Test na elke wijziging om te weten of DNS, TLS, proxying of WOPI-vertrouwen de werkelijke oorzaak was.

Definitieve verificatiechecklist

Controleer na elke wijziging het systeem in deze volgorde:

1. Openen /hosting/discoveryvanuit /hosting/capabilitieseen browser.
2. Haal dezelfde eindpunten op van de opslagserver.
3. Haal de URL voor de status van de opslagserver op van de Collabora-server.
4. Open een document terwijl u zowel de Collabora- als de opslaglogboeken in de gaten houdt.
5. Controleer of de browser de Collabora WebSocket-verbinding tot stand brengt zonder herhaaldelijk te worden verbroken.
6. Controleer of een tweede gebruiker een testdocument kan openen en bewerken als gezamenlijk bewerken vereist is.

Als alle zes controles slagen, zou de algemene melding "Nou, dit is gênant" geen verbindingsfout meer mogen maskeren. Als de melding blijft verschijnen, leg dan de exacte Collabora-logregels en de netwerkfoutmelding van de browser vast voor één poging om een ​​document te openen; deze twee bewijsstukken zijn nuttiger dan de algemene UI-melding zelf.