CollaboraのWebSocket接続をプロキシ経由で復元する

Collabora Online でソケット接続が予期せず切断されたという報告があった場合は、まずブラウザの WebSocket リクエストがcoolwsdリバースプロキシを経由しているかどうかを確認してください。プロキシのルートを Collabora のバージョンに合わせ、WebSocket のアップグレードと URL パスを保持した上で、ブラウザのネットワーク パネルとサーバー ログを監視しながら 1 つのドキュメントをテストしてください。Apache の背後で CODE 26.04 にアップグレードした後に問題が発生した場合は、ProxyPassまず Apache のルールを確認してください。Collabora の 26.04 リリース ノートには、コンパクトな WebSocket URL の変更について記載されています。

WebSocketは、ドキュメントが開いている間、Collaboraがブラウザとサーバー間で使用する、持続的な双方向接続です。リバースプロキシは、公開リクエストを受け付けてCollaboraに転送するサービスです。エラーメッセージはこの接続を指し示していますが、プロキシが原因であることを証明するものではありません。拒否されたWOPIホスト、誤った公開URL、TLSの不一致、または間違ったバックエンドもセッションを停止させる可能性があります。

変更を加える前に、ルートを確認してください。

Collaboraのバージョンまたはイメージタグ、プロキシソフトウェア、公開されているCollaboraホスト名、TLSがプロキシで終了するかCollaboraで終了するかをメモしてください。デプロイメントを変更せずに、サービス名と現在のイメージを確認してください。

docker compose ps collabora
docker compose images collabora

collaboraCompose ファイル内のサービス名に置き換えてください。Compose コンテナ以外の場合は、コンテナとイメージを識別するためにdocker psとを使用してください。タグが先週テストしたバージョンと同じバージョンを指しているとは限らないので注意してください。docker inspectlatest

1. WebSocketハンドシェイクがどこで停止するかを確認します。

ブラウザで開発者ツールを開き、「ネットワーク」を選択し、WSまたはWebSocketでフィルタリングして、ドキュメントを再度開いてみてください。wss://公開ページがHTTPSの場合は、リクエストURLを使用する必要があります。失敗したリクエストを選択し、そのステータス、URLパス、およびレスポンスヘッダーをメモしてください。ハンドシェイクが成功すると、通常は101 Switching Protocolsドキュメントセッションがアクティブな間、接続が維持されます。

• WebSocketリクエストが表示されない場合は、サーバールールを編集する前に、統合アプリのCollabora URL、ブラウザコンソール、DNS、およびリダイレクトまたは混合コンテンツのエラーを確認してください。
• リクエストが400または404を返す場合：リクエストされたパスを、プロキシが転送するルートと、インストールされているCollaboraのバージョンでサポートされているルートと比較してください。coolwsd「無効または不明なリクエスト」と表示される400は、Collaboraが受け入れないパスでリクエストが到達したことを意味する可能性があります。
• リクエストが502または504を返す場合：プロキシが設定済みのCollaboraアップストリームに到達できるかどうか、およびアドレスとポートが正しいコンテナまたはホストを指しているかどうかを確認してください。
• リクエストは101を返した後、しばらくしてから閉じます。プロキシ、ロードバランサー、ファイアウォール、およびクライアントネットワークのアイドルタイムアウトを確認してください。WebSocketは長時間持続するため、アイドル状態の接続を早すぎるタイミングで閉じる中間機器があると、正常に確立された接続が中断される可能性があります。

2. プロキシルールをCollaboraのバージョンと比較してください。

使用しているプロキシソフトウェアとバージョンに合わせて、 Collaboraの最新のリバースプロキシ設定を使用してください。WebSocketルートがWebSocketとして処理されていること、プロキシがアップグレードヘッダーを転送していること、パスとエンコードされたクエリ文字列がリダイレクトや書き換えではなく保持されていることを確認してください。また、プロキシは、Collaboraで設定されている外部サーバー名とTLS終端設定と一貫して、パブリックホストとスキームを送信する必要があります。

Nginx の場合は、 Collabora の最新例にある WebSocket 固有のロケーションと HTTP/1.1、Upgradeおよび転送ディレクティブを確認してください。Apache の場合は、ルールと順序を最新例と比較してください。インストールされているリリースで現在要求されている内容を確認せずに、古いマッチをそのまま貼り付けないでください。ConnectionProxyPass/cool/…/ws

このバージョンチェックはCODE 26.04で重要です。2026年6月8日に公開されたCollaboraのリリースノートでは、よりコンパクトなWebSocket URLについて説明されており、ApacheリバースプロキシのユーザーはProxyPassこれに合わせて調整する必要があるとされています。その後の26.04の作業で、従来のURLに対するフォールバック動作が追加されたため、古いルールでも一部のビルドでは動作する可能性があります。Collaboraの解決済み26.04 WebSocketレポートには、そのフォローアップが記載されています。フォールバックは、現在のプロキシ構成をインストール済みのバージョンに合わせることの代わりにはなりません。CODE 26.04のリリースノートと更新されたSDKサンプルを併せてお読みください。

3. 失敗事例を一つ特定し、それに基づいて的を絞った変更を行う。

ドキュメントを再試行する前に、短いログストリームを開始します。Docker の--sinceオプションは最初の出力を制限し、--follow新しい行をストリームします。Docker Compose のログリファレンスを参照してください。

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

テストの時刻を記録し、Collaboraとプロキシのログで同じリクエストを探します。ブラウザがプロキシが間違ったバックエンドにルーティングするパスをリクエストした場合は、Collaboraのバージョンに一致する例を使用して、そのWebSocketルートのみを更新します。リクエストがCollaboraに到達したが、ホスト、オリジン、またはスキームが拒否された場合は、パブリックホスト名とポートを、構成済みのサーバー名と転送されたヘッダーと比較します。代わりにログにWOPIホストの拒否またはファイル情報リクエストの失敗が表示された場合は、統合サーバーの許可されたホストとCollaboraコンテナからの到達可能性を確認します。これは、ブラウザのWebSocketハンドシェイクとは別の手順です。

プロキシの設定をそのプロキシ独自の構文チェックコマンドで検証した後、プロキシを再起動してください。TLS終端、ホスト許可リスト、URL書き換えを同時に変更することは避けてください。テストごとに原因を1つずつ変更することで、次の結果を解釈しやすくなります。TLS検証を無効にしたり、すべてのWOPIホストをショートカットとして許可したりしないでください。

4. ブラウザからドキュメントへの修正を確認する

同じドキュメントを再度試してください。開発者ツールで、WebSocketリクエストが応答して接続101 Switching Protocolsが維持されていることを確認してください。ドキュメントの読み込みが完了し、接続が維持され、小さな編集が受け入れられて正常に保存されることを確認してください。WOPIファイルへのアクセスや保存が失敗する場合は、接続状態が正常であるだけでは不十分です。

ハンドシェイクがそれでも失敗する場合は、ブラウザのリクエストパス、プロキシのアクセス/エラー行、およびcoolwsd同じタイムスタンプのログエントリを比較してください。この3点比較により、ブラウザ、プロキシ、Collaboraルート、またはWOPIホストのいずれを次に調査すべきかがわかります。サポートを依頼する際は、ブラウザの詳細とログの両方から、アクセストークン、ドキュメント識別子、ユーザー名、およびプライベートホスト名を削除してください。