Collabora Onlineの「ソケット接続が予期せず閉じられました」エラーを修正する:WebSocketとプロキシのチェック

Collabora Online は一見正常に見えても、エディタがライブ WebSocket を確立しようとするとすぐにエラーが発生することがあります。よくある症状は、ドキュメントの読み込みが開始された後、ソケット接続が予期せず閉じられたというメッセージが表示され、場合によってはwss://ブラウザでリクエストが失敗したというエラーも表示されます。2026 バージョンでは、他の変更を行う前に確認すべきバージョン固有の理由が 1 つあります。26.04 ブランチでは、よりコンパクトな WebSocket URL が導入されており、古いリバースプロキシルールがこれと競合する可能性があるためです。

Collaboraの公式CODE 26.04リリースノートによると、2026年6月8日にリリースされたCODE 26.04.1では、Apache2リバースプロキシのユーザーは、新しいコンパクトなWebSocket URLに合わせてProxyPassルールを変更する必要がありました。後の26.04.2.xノートでは、新しいルートが使用できない場合、CODEは従来のURLにフォールバックし、管理者に現在のプロキシ推奨事項に戻るよう促す監査警告を発するとされています。エンタープライズ版のCollabora Online 26.04ブランチも2026年現在最新版であるため、管理者は、古い24.04または25.04ガイドからコピーしたプロキシ設定を最新のベンダードキュメントと比較してから、問題をランダムなネットワーク障害として扱うべきです。

Collabora Onlineのドキュメントウィンドウにブラウザの開発者ツールが表示され、「ネットワーク」タブの下にWebSocketリクエストの失敗が表示されている。
ブラウザでのWebSocketリクエストの失敗は、問題が通常のページ読み込みではなく、ライブエディタチャネルにあることを示す最も明確な兆候です。

エラーが実際に意味すること

このメッセージは、単一の根本原因を特定していません。これは、ブラウザとCollabora間のWebSocket接続が正常にアップグレードされなかったか、接続が確立された後に予期せず切断されたことを意味します。この違いは、修正方法が異なるため重要です。

観察された行動最も役立つ最初のチェック典型的な原因
ドキュメントを開くとすぐにエラーが発生しますブラウザネットワーク > WSおよびリバースプロキシのアクセス/エラーログルートが間違っている/cool/、アップグレードヘッダーが欠落している、Apacheルールが26.04と互換性がない、ホスト/オリジンが一致しない
一時的には動作するが、一定間隔で接続が切断される。プロキシ、イングレス、ロードバランサー、ファイアウォールのアイドルタイムアウト長時間のWebSocket接続にはタイムアウトが短すぎます
発見は機能するが、編集は機能しないWebSocketを個別にテストします/hosting/discoveryHTTPエンドポイントには到達可能ですが、WebSocketルートには到達できません
ブラウザまたはネットワークパスが 1 つだけ失敗するリクエストプロトコルとプロキシの動作を比較するHTTP/2またはHTTP/3の処理、CONNECT転送、中間フィルタリング
サーバーログはアップグレードを明示的に拒否しますcoolwsdの正確なエラーメッセージを読んでください。発信元、ホスト、ポート、WOPIホスト、またはプロキシ設定の不一致

1. 26.04へのアップグレード後に障害が発生したかどうかを確認してください。

25.04 またはそれ以前の CODE イメージから 26.04 に移行した直後に問題が発生した場合は、リバースプロキシを最初の疑わしい箇所として扱ってください。これは憶測ではなく、Collabora は 26.04 のリリースノートでコンパクト WebSocket URL の変更について説明しており、公式のプロジェクト課題では、Apache プロキシのルールが修正されるまで 26.04.1 へのアップグレード後に WebSocket が失敗するという報告がありました。

安易にダウングレードして古いプロキシをそのままにしておくことでこの問題を解決しないでください。ロールバックは一時的な復旧策にはなりますが、根本的な解決策は、プロキシを実際に使用するバージョンに合わせることです。Apache の場合は、26.04 より前のコピーではなく、最新のCollabora Online プロキシ設定を使用してください。Collabora の26.04 WebSocket の問題記録には、Apache ルールを更新することで動作が回復した事例が記載されています。

Apache Collaboraのリバースプロキシ設定を表示するテキストエディタ。26.04で導入されたコンパクトなWebSocket URLに関する注記付き。
Apacheを26.04にアップグレードした場合、以前正常に動作していたルールが現在も正しいと想定するのではなく、古いProxyPassルールを最新のCollaboraドキュメントと比較してください。

2. HTTPは動作するがWebSocketは失敗することを証明する

まずは通常のCollaboraエンドポイントをテストしてください。

curl -I https://office.example.com/hosting/discovery
curl -I https://office.example.com/hosting/capabilities

応答が成功すれば、DNS、TLS、フロントエンドプロキシ、およびCollaboraサービスの少なくとも一部に到達可能であることが証明されます。ただし、ドキュメント編集が機能することは証明されません。エディタは、異なるプロキシ要件を持つWebSocketルートに依存しています/cool/。

次に、ブラウザの開発者ツールを開き、エラーを再現して、ネットワークパネルでWSフィルタを使用して確認します。WebSocketハンドシェイクが成功すると、通常はHTTP接続がアップグレードされます。RFC 6455では、アップグレードが成功した場合のサーバー応答をHTTPステータス101と定義しています。代わりに400、404、405、502、または即座に失敗したリクエストが表示される場合は、そのタイムスタンプをリバースプロキシとcoolwsdのログと照合してください。

3. NginxのWebSocketパスとヘッダーを修正する

Nginx の場合、重要なプロパティは単純明快です。リクエストは Collabora/cool/パスに到達する必要があり、プロキシは従来の WebSocket アップグレードフローのために HTTP/1.1 を使用する必要があり、ヘッダーUpgradeとConnectionヘッダーが転送される必要があり、元のホストが保持され、読み取りタイムアウトは編集セッションに十分な長さである必要があります。

Collabora SDK マニュアルには、以前から専用の WebSocket ロケーションが示されておりUpgrade、 、Connection、Host、 および長い が含まれていproxy_read_timeoutます。Collabora プロジェクトの公式ドキュメントでも、より広範なルートでの WebSocket ヘッダーの必要性が指摘されています/cool。保守的な 26.04 対応パターンは次のとおりです。

location ^~ /cool/ {
    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-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_read_timeout 3600s;
}

稼働中の本番環境構成に、アップストリームアドレス、TLSモデル、パス処理、および既存のセキュリティ制御を調整せずにこの設定を貼り付けないでください。正しい選択は、現在のCollaboraのルートおよびヘッダー要件に適合させつつ、トポロジーを維持することです。

ターミナルエディタに、HTTP/1.1、WebSocket Upgradeヘッダー、転送されたホスト情報、および長いタイムアウトを含む、/cool/ の Nginx Collabora ロケーションが表示されています。
Collabora WebSocketプロキシには、/cool/ルート、HTTP/1.1アップグレード処理、元のホスト、および長時間の編集セッションに適したタイムアウトが必要です。

タイムアウト値が重要な理由

WebSocket編集セッションは長時間継続します。Collaboraプロジェクトの現在のHelm設定では、この点が明示的に記述されており、バンドルされているNginxプロキシには長いプロキシタイムアウトが設定されています。エッジロードバランサー、Kubernetesイングレス、CDN、ファイアウォール、またはリバースプロキシが、アプリケーションの想定よりも早くアイドル状態の接続を閉じる場合、ユーザーはしばらくの間は正常に編集できますが、その後一定の間隔で切断されます。

毎回ほぼ同じ秒数でエラーが発生する場合は、Nginxのタイムアウト値を増やすだけでなく、パス上のすべての中間ノードを調べてください。タイムアウト値が最も短いノードが優先されます。

4. TLS終端処理を一貫性のあるものにする

一般的なデプロイメントでは、HTTPS は Nginx、Apache、HAProxy、Traefik、またはイングレス コントローラーで終端され、プレーン HTTP はポート 9980 で Collabora に転送されます。この設計では、Collabora の公式構成では、バックエンドが TLS がプロキシによって終端されることを認識する必要があります。SDK マニュアルssl.enable=falseには、ssl.termination=trueこのモデルに関するドキュメントが記載されています。

Dockerデプロイメントの場合、これは通常、Collaboraの追加パラメータによって表現されます。

--o:ssl.enable=false --o:ssl.termination=true

これらは、TLSが実際に上流で終端されている場合にのみ使用してください。プロキシが代わりにHTTPS経由でCollaboraに接続する場合は、2つのモデルを混在させるのではなく、そのトポロジを一貫して構成してください。不一致があると、誤ったスキーム、誤ったWebSocket URL、証明書の失敗、またはアップグレードを中断させるリダイレクトが発生する可能性があります。

5. coolwsdログでホストとオリジンの不一致を確認する

CollaboraはWebSocketのオリジンを検証します。ログに「」などの語句Rejecting WebSocket upgradeに続いてオリジンと想定されるホストが含まれている場合は、許可ヘッダーを無作為に追加するのではなく、外部ホスト名とポートの関係を修正してください。Collaboraの公式課題トラッカーには、設定されたサーバー名に「」が含まれていても、:443明示的なポート番号がないブラウザのオリジンと一致しない例が記載されています。

便利なコマンドは、インストール環境によって異なります。

docker logs collabora --tail 200
journalctl -u coolwsd --since "10 minutes ago"
nginx -t
apachectl configtest

WSリクエストの失敗と同時に発生する最初のエラーを探してください。アップグレードの拒否、URI構文の誤り、予期しないホスト、または利用できないアップストリームに関するメッセージは、一般的なブラウザのポップアップよりも対処しやすいものです。

6. Chromiumベースのブラウザのみで問題が発生する場合は、HTTP/2またはHTTP/3の処理を検査してください。

これはより限定的なケースですが、サーバーを再構築する前に確認しておく価値があります。Collaboraプロジェクトでは、プロキシがHTTP/2 CONNECT WebSocketリクエストをcoolwsdに直接渡して405 Method Not Allowedを受け取ったChromium関連のケースが報告されています。また、別の問題では、特定のプロキシパスでHTTP/3/QUIC関連のドキュメント読み込みエラーが発生したことが記録されています。これらの報告は、HTTP/2またはHTTP/3を常に無効にする必要があるという意味ではなく、中間サーバーがクライアントの動作をCollaboraがサポートするWebSocket接続に変換する必要があるという意味です。

同じアカウントとドキュメントでFirefoxは正常に動作するのにChromeが動作しない場合は、プロキシでプロトコルとステータスコードを取得してください。環境に互換性のある代替手段がない場合を除き、最新のプロトコルを全体的に無効にするよりも、プロキシ/イングレスの動作を修正することを優先してください。

7. 設定を検証した後でのみ再起動してください。

まずプロキシの構文テストを行い、その後、何度も闇雲に再起動するのではなく、リロードしてください。

sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2

コンテナの場合、Collaboraサービスを再起動しられるのは、サービス自体の環境またはcoolwsd設定を変更した場合のみです。プロキシのみの変更であれば、通常はプロキシのリロードだけで済みます。

Collaboraの検出エンドポイントと機能エンドポイントからのHTTP応答が成功したことを示すターミナル画面と、確立されたWebSocketセッションを示すサーバーログ行。
通常のCollabora HTTPエンドポイントとライブWebSocketセッションの両方を確認してください。検出が成功しただけでは、編集が修正されたことを証明するには不十分です。

修正内容を自分で確認する方法

単一の文書の正常なオープンに頼るのではなく、短い検証シーケンスを使用してください。

  • 確認済みであり/hosting/discovery、/hosting/capabilitiesユーザーがアクセスするのと同じパブリックホスト名を通じてアクセスできます。
  • ドキュメントを開き、ブラウザのWSリクエストが正常にアップグレードされ、4xx/5xxエラーが返されないことを確認してください。
  • 何度か編集を行い、以前の障害発生間隔よりも長く待ってから、接続が安定していることを確認してください。
  • ドキュメントを保存して閉じ、再度開いてWOPIの往復通信が正常であることを確認してください。
  • coolwsdとプロキシのログを確認し、WebSocketのアップグレード拒否、URI解析エラー、または再接続ループの繰り返しがないか確認してください。
  • デプロイメントにロードバランサーまたはイングレスがある場合は、ポート9980に直接接続するのではなく、実際の運用ルートを介してテストを繰り返してください。

どの修正方法を選ぶべきでしょうか?

26.04にアップグレードしてApacheを使用している場合は、Collaboraがその変更を明示的に文書化しているため、プロキシルールの更新が最優先事項です。一定時間後に切断が発生する場合は、すべてのネットワークホップのタイムアウト設定に注目してください。すべてのブラウザで即座に障害が発生する場合は、/cool/ルーティング、アップグレードヘッダー、ホスト/オリジンの一貫性、およびTLS終端を確認してください。特定のブラウザファミリーのみで障害が発生する場合は、Collabora自体を変更する前にHTTPプロトコルの処理を比較してください。

重要なのは、「ソケット接続が予期せず閉じられました」というエラーを、デフォルトでCollaboraアプリケーションのクラッシュとして扱わないようにすることです。多くの環境では、エディタ、検出エンドポイント、WOPIホストは正常に動作しているにもかかわらず、リバースプロキシがライブ編集に最も重要な接続タイプである、長時間接続が維持されるWebSocketを正しく処理できていないという問題が発生しています。

公式資料

コメントを残す

ONLYOFFICE Nextcloud連携における「トークンが無効です」エラーを修正する

ONLYOFFICE Nextcloud連携における「トークンが無効です」エラーを修正する

JWTシークレット、認証ヘッダー、Docker設定、プロキシの動作、コネクタの状態を確認することで、NextcloudにおけるONLYOFFICEの「トークンが無効です」エラーを修正します。

NextcloudでONLYOFFICEの「ドキュメントを保存できませんでした」エラーを修正する

NextcloudでONLYOFFICEの「ドキュメントを保存できませんでした」エラーを修正する

コールバック、内部URL、JWT、TLS、プロキシルーティング、ログ、ストレージを確認することで、NextcloudにおけるONLYOFFICEの「ドキュメントを保存できませんでした」エラーを修正します。

Collabora Onlineの「ソケット接続が予期せず閉じられました」エラーを修正する:WebSocketとプロキシのチェック

Collabora Onlineの「ソケット接続が予期せず閉じられました」エラーを修正する:WebSocketとプロキシのチェック

Collabora Onlineのソケット接続エラーを修正するには、26.04 WebSocketの変更点、プロキシルート、アップグレードヘッダー、タイムアウト、TLS、およびログを確認してください。

Collabora Onlineで複数の言語のスペルチェックを有効にする方法

Collabora Onlineで複数の言語のスペルチェックを有効にする方法

Collabora Onlineで多言語スペルチェックを有効にするには、サーバー辞書を追加し、言語コードを許可し、テキストに言語を割り当て、複数の言語を含む文書をテストします。

LibreOffice Writerで画像を含む自動メールマージを作成する方法

LibreOffice Writerで画像を含む自動メールマージを作成する方法

Calcデータ、名前付き画像プレースホルダー、およびBasicマクロを使用して、レコードごとに画像を挿入する信頼性の高いLibreOffice Writerメールマージを作成する方法を、トラブルシューティングと検証の手順とともに解説します。

Collabora Onlineの「これは恥ずかしい」接続エラーを修正する

Collabora Onlineの「これは恥ずかしい」接続エラーを修正する

WOPI、リバースプロキシ、TLS、DNS、WebSocket、およびサーバー間の接続可能性をチェックすることにより、Collabora Onlineのドキュメント接続障害を診断および修正します。

ONLYOFFICEデスクトップエディターでPDFを編集可能なDOCXに変換する方法

ONLYOFFICEデスクトップエディターでPDFを編集可能なDOCXに変換する方法

ONLYOFFICEデスクトップエディター(オフライン版)でPDFファイルを編集可能なDOCXファイルに変換します。「名前を付けて保存」の手順に従い、PDFファイルがスキャンされているか確認し、書式設定をチェックしてください。

Collabora OnlineをSeafileに接続する方法:設定オプションと手順

Collabora OnlineをSeafileに接続する方法:設定オプションと手順

SeafileをDockerまたは別のホストを使用してCollabora Onlineに接続します。デプロイメントのトレードオフを比較し、HTTPSとWOPIの設定を構成し、編集内容を確認します。

画像を含む大容量ドキュメントでのLibreOffice Writerの動作遅延を修正する

画像を含む大容量ドキュメントでのLibreOffice Writerの動作遅延を修正する

画像が多いLibreOffice Writerファイルで、入力、スクロール、保存が遅い場合の診断を行います。ディスプレイ設定をテストし、サイズの大きい画像を圧縮して、プロファイルまたはハードウェアの問題を特定します。

Helmを使用してKubernetes上にCollabora CODEをセットアップする方法

Helmを使用してKubernetes上にCollabora CODEをセットアップする方法

公式Helmチャートを使用して、Kubernetes上にCollabora CODEをデプロイします。イングレス、TLS、WOPIホストアクセス、シークレット、スケーリング、エンドツーエンドチェックを設定します。