Collabora-Code hinter Nginx mit TLS-Terminierung ausführen

Dokumente können nach der Verwendung von Collabora CODE hinter HTTPS verzögert werden, da Proxy und CODE unterschiedliche Auffassungen darüber haben, wo die TLS-Verschlüsselung endet, oder der Proxy den WebSocket-Verkehr verwirft. Konfigurieren Sie Nginx so, dass es das öffentliche Zertifikat präsentiert, an einen privaten CODE-Listener weiterleitet und die WebSocket-Routen durchgibt. Die CODE-Einstellungen lauten: [Hier die Einstellungen einfügen ssl.enable=false] ssl.termination=true.

Dieses Beispiel verwendet Nginx auf dem Docker-Host. Für einen Proxy in einem anderen Container verwenden Sie stattdessen das private Docker-Netzwerk. Versionsspezifische Optionen finden Sie in den Proxy-Einstellungen von Collabora und im Leitfaden zum CODE-Docker-Image .

Verstehen Sie, was SSL-Terminierungsänderungen bedeuten

TLS-Terminierung bedeutet, dass Nginx die HTTPS-Verbindung und das Zertifikat des Browsers verwaltet, während CODE dahinter HTTP auf Port 9980 verwendet. Halten Sie diesen Listener privat: Binden Sie ihn an die Loopback-Schnittstelle eines einzelnen Hosts oder verwenden Sie ein privates Docker-Netzwerk. Falls der Datenverkehr vom Proxy zu CODE ein nicht vertrauenswürdiges Netzwerk durchläuft, schützen Sie diese Verbindung mit TLS oder einem Tunnel.

Bereiten Sie den Container und das Zertifikat vor.

1. Wählen Sie den öffentlichen Hostnamen. Erstellen Sie einen DNS-Eintrag, der office.example.comauf den Nginx-Proxy verweist. Besorgen Sie sich ein Zertifikat für genau diesen Hostnamen und installieren Sie dessen Zertifikatskette und privaten Schlüssel auf dem Proxy.
2. Halten Sie den Port von CODE privat. Bei direkt auf dem Docker-Host installiertem Nginx sollte der Container-Port nur über die Loopback-Schnittstelle veröffentlicht werden. Die entsprechende Zuordnung in Compose lautet [hier die entsprechende Zuordnung einfügen] 127.0.0.1:9980:9980. Veröffentlichen Sie den Port nicht 9980:9980auf jeder Host-Schnittstelle, es sei denn, eine Firewall oder das Netzwerkdesign schränken dies explizit ein.
3. Legen Sie den TLS-Modus von CODE fest. Fügen Sie im Compose-Dienst die beiden Optionen zur CODE-Konfiguration hinzu. Das folgende Beispiel verwendet eine Bildvariable, damit Sie das exakte Tag, das Sie geprüft und getestet haben, anheften können.

services:
  collabora:
    image: ${COLLABORA_CODE_IMAGE}
    restart: unless-stopped
    ports:
      - "127.0.0.1:9980:9980"
    environment:
      extra_params: "--o:ssl.enable=false --o:ssl.termination=true"

Verwenden Sie COLLABORA_CODE_IMAGEein getestetes, festgelegtes Image-Tag. Behalten Sie Ihre WOPI-Host-Zulassungsliste und Authentifizierungseinstellungen bei; die TLS-Terminierung ersetzt diese nicht. Falls Nginx ein weiterer Docker-Dienst ist, lassen Sie die Host-Portzuordnung weg und verwenden Sie den Proxy http://collabora:9980im gemeinsamen privaten Netzwerk.

Konfigurieren Sie Nginx so, dass TLS-Datenverkehr beendet und CODE-Datenverkehr weitergeleitet wird.

4. Fügen Sie den virtuellen HTTPS-Host hinzu. Platzieren Sie die folgenden Pfade im Nginx-Serverblock für den öffentlichen Collabora-Hostnamen. Ersetzen Sie die Beispielpfade für Hostname und Zertifikat. Diese Konfiguration gilt für eine Collabora-URL auf Stammebene, nicht für eine URL, die unter einem Pfad wie z. B. `/var/www/collabora` eingebunden wird /office/.

server {
    listen 443 ssl;
    server_name office.example.com;
    ssl_certificate /etc/letsencrypt/live/office.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/office.example.com/privkey.pem;

    location ^~ /browser {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location ^~ /hosting/discovery {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
    location ^~ /hosting/capabilities {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    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 $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 36000s;
    }
    location ^~ /cool/adminws {
        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 $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_read_timeout 36000s;
    }
    location ~ ^/(c|l)ool {
        proxy_pass http://127.0.0.1:9980;
        proxy_set_header Host $http_host;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Leiten Sie die Routen für Editor-Assets, -Erkennung und -Funktionen weiter. Die /cool/.../wsentsprechenden /cool/adminwsSpeicherorte benötigen HTTP/1.1- und Upgrade-Header, damit Nginx WebSockets tunneln kann; ein langes Lese-Timeout hält Bearbeitungssitzungen offen. Siehe die Dokumentation zum WebSocket-Proxying von Nginx .

Wenden Sie die Änderung an und überprüfen Sie das versionsabhängige Verhalten.

5. Überprüfen Sie Nginx vor dem Neuladen. Führen Sie den Befehl aus nginx -t. Fahren Sie nur fort, wenn Nginx meldet, dass der Konfigurationstest erfolgreich war; laden Sie Nginx anschließend mit dem normalen Dienstbefehl Ihres Systems neu.
6. Erstellen Sie den CODE-Container neu. Wenden Sie die Compose-Änderung an docker compose up -d collabora. Überprüfen Sie die Containerprotokolle auf Startfehler und stellen Sie sicher, dass die aktive Konfiguration beide SSL-Optionen enthält.

Zur Versionskontextinformation: Im Collabora-Repository wurde am 22. Juli 2026 ein Bericht verzeichnet, der besagt, dass die integrierte coolwsd --probeIntegritätsprüfung in CODE 26.04.2.2 und höher HTTPS auf Port 9980 prüfen kann, selbst wenn die TLS-Verbindung am Proxy endet. Dies kann dazu führen, dass ein Container als fehlerhaft markiert wird, obwohl der öffentliche Endpunkt antwortet. Überprüfen Sie den entsprechenden Eintrag für Ihr Image-Tag ; testen Sie den öffentlichen Endpunkt und eine Bearbeitungssitzung, bevor Sie den Integritätsstatus allein als Beweis für einen TLS-Fehler werten. Führen Sie Integritätsprüfungen weiterhin durch, sofern diese nicht durch eine andere Überwachungsmethode ersetzt werden.

Überprüfen Sie die HTTPS-Erkennung und eine echte Bearbeitungssitzung.

Die Anfrage kann https://office.example.com/hosting/discoveryüber einen Browser oder mit einem entsprechenden Tool curlgestellt werden. Sie sollte WOPI-Discovery-XML über HTTPS zurückgeben, wobei die URLs den öffentlichen HTTPS-Hostnamen verwenden. Eine Zertifikatswarnung deutet auf ein Problem mit dem Hostnamen oder dem Zertifikat hin; HTTP-URLs deuten auf eine Diskrepanz zwischen TLS-Modus oder Weiterleitungsschema hin; ein 502-Fehler bedeutet, dass der Proxy CODE nicht erreichen kann.

Öffnen Sie anschließend ein Testdokument vom verbundenen WOPI-Host und prüfen Sie, ob die Bearbeitung funktioniert. In den Entwicklertools des Browsers /cool/.../wssollte die Anfrage eine WebSocket-Verbindung herstellen. Falls die Erkennung funktioniert, die Bearbeitung aber nicht, überprüfen Sie die WebSocket-Adressen und -Header. Stellen Sie sicher, dass die Integration den WOPI-Host zulässt und auf den entsprechenden Pfad verweist https://office.example.com.

Erfolgreiche Einrichtung: Das Zertifikat wird als vertrauenswürdig eingestuft, die Erkennung erfolgt über HTTPS, Port 9980 bleibt privat, und ein Testdokument wird über den WebSocket geöffnet und bearbeitet.