コード編集セッションが10分で終了しないようにする

CODEドキュメントが約10分後に確実に切断される場合は、まずすべてのリバースプロキシまたはロードバランサーを経由するWebSocketパスを調べてください。600秒のアイドルタイムアウトはよくある設定上の手がかりですが、タイミングだけではプロキシが原因であるとは断定できません。設定を変更する前に、どのコンポーネントが接続を閉じているかを確認してください。ほとんどの環境では、Collabora WebSocketのアップグレードを維持したまま、プロキシの読み取りタイムアウトと送信タイムアウトを、想定される最長の編集セッションよりも長く設定するのが現実的な解決策です。

まず、接続が切断される場所を確認してください。

Collabora OnlineはCODEサーバーへのブラウザ接続を使用しますが、ドキュメント統合はNextcloudなどのホストとのWOPI通信にも依存しています。Collaboraのリバースプロキシに関するガイダンスとNextcloudの現在のOfficeの例では、ドキュメントセッション用に別のWebSocketルートが規定されています。このルートが存在しない場合、誤ったアップストリームに送信された場合、またはアイドルタイムアウトによって制御されている場合、ページ自体にはアクセスできるものの、エディタはライブ接続を失う可能性があります。

これは検証済みのアーキテクチャ要件です。ただし、10分間隔で発生する障害の原因がすべて同じであるとは限りません。クラウドロードバランサー、イングレスコントローラー、ファイアウォール、VPN、またはその他のプロキシが独自の制限を設けている可能性があります。再現性のある間隔を手がかりとして、障害発生時のアクセスログとエラーログを確認してください。

1. セッションが切断された正確な時刻と、それがアクティブな入力中に発生したのか、それともドキュメントがアイドル状態の間にのみ発生したのかを記録します。
2. /wsブラウザの開発者ツールで、ネットワークパネルを開き、「WS」でフィルタリングして、パスがで終わる接続を調べます/cool/。ブラウザがエラーを報告する場合は、そのステータスとクローズコードをメモしてください。
3. 同じタイムスタンプで、リバースプロキシまたはイングレスログ、CODEサーバーログ、およびWOPIホストログを確認してください。プロキシタイムアウト、アップストリームリセット、異常なWebSocket切断、またはWOPIエラーを探してください。ログの文言は製品やバージョンによって異なるため、1つのメッセージが普遍的であるとは限らないことに注意してください。

WebSocketが設定された600秒のしきい値で終了する場合は、そのしきい値を管理しているプロキシまたは中間サーバーを修正してください。別の間隔で終了する場合、またはログにWOPIエラーやサーバーエラーが表示される場合は、そちらの証拠に従ってください。Nextcloudのトラブルシューティングドキュメントでは、双方向の接続性を確認し、NextcloudとCollaboraの両方のログを確認することを特に推奨しています。

プロキシ経由でWebSocketを開いたままにする

プロキシ ファイルを編集する前に、アクティブな仮想ホストと、CODE の実際のアップストリーム スキームおよびポートを特定してください。設定をバックアップし、再読み込みする前に構文を検証してください。以下の例は、NGINX リバース プロキシに必要な WebSocket の動作を示しています。これは完全な Collabora 仮想ホストではありません。他のロケーション ブロック、TLS 設定、URI 処理、およびセキュリティ ルールを保持したまま、デプロイメントの公式設定に統合してください。

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980/cool/$1/ws;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_read_timeout 36000s;
    proxy_send_timeout 36000s;
}

およびヘッダーを使用するとUpgrade、ConnectionHTTP リクエストを WebSocket に切り替えることができます。読み取りおよび送信の制限を長く設定することで、このプロキシがデフォルトの短い間隔後に静かな接続を閉じるのを防ぎます。これらはセッションを永久に開いたままにするためのコマンドではありません。アップストリーム アドレスと TLS 検証は、ご使用の環境に合わせて調整してください。また、この例を動作させるためだけに証明書のチェックを無効にしないでください。

Collaboraの公式プロキシ設定例は、バージョンに応じた完全なルーティング設定の参考資料です。現在のガイドラインには長いプロキシタイムアウトが含まれています。Nextcloudの最新のDocker設定例にも専用の/cool/(.*)/wsWebSocketマッピングがあります。仮想ホスト全体をこの抜粋に置き換えるのではなく、これらの完全な設定例を使用してください。

• Collabora Onlineのリバースプロキシ設定
• Nextcloud 35 Dockerインストール例

NGINX の場合は、nginx -tテストが成功した後にのみ実行してリロードしてください。Apache の場合は、リロードする前に構成テストを実行してください。CODE が Kubernetes イングレスまたはクラウド ロード バランサーの背後で実行されている場合、CODE ホスト上の NGINX を変更しても、イングレスまたはプロバイダ エッジでのタイムアウト時間の短縮は修正されません。ログで特定されたコンポーネントを更新してください。

CODEだけでなく、すべてのネットワークホップをチェックしてください。

WebSocketトラフィックは、ブラウザ、CDNまたはファイアウォール、外部ロードバランサー、イングレス、ホストプロキシ、そしてCODEなど、複数の中間層を経由する可能性があります。ある層のタイムアウト時間が長すぎると、次の層のタイムアウト時間が短くなりすぎても、その設定は無効になります。各層のアイドルタイムアウトまたは接続タイムアウトを比較し、プラットフォームの制限とポリシーの範囲内で、WebSocketルートの制限時間を想定されるアイドル編集期間よりも長く設定してください。

ドキュメントのアイドルアンロード設定とプロキシのネットワークタイムアウトを混同しないでください。前者は、使用されていないドキュメントプロセスをアンロードするタイミングを制御するものであり、中間サーバーが既に閉じたWebSocketを修復するものではありません。同様に、タイムアウトを非常に長く設定しても、アップグレードルートの不具合、トラフィックのブロック、HTTP/HTTPS構成の不一致、またはCODEプロセスのクラッシュは解決されません。変更を加えるたびに、クローズ時間が移動するか、ログに記録された原因が消えることを確認してください。これにより、無関係な変更を加えることなく、責任のあるレイヤーを絞り込むことができます。

ユーザーのブラウザと WOPI ホストの両方が HTTPS 経由で CODE サービスにアクセスできることを確認し、CODE が WOPI ホストにアクセスできることを確認してください。Nextcloud との連携の場合、トラブルシューティング マニュアルでは、ブラウザから と を使用してパブリック エンドポイント/hosting/capabilitiesを確認し、次に CODE サーバーから Nextcloud ステータス エンドポイントを確認することを推奨しています。これらのチェックは基本的な接続性を確認するものであり、確立された WebSocket が 10 分間維持されることを証明するものではありません。/hosting/discoverycurl

時間制限付きセッションで修復内容を確認する

1. サポートされている検証手順を使用してプロキシまたはイングレス構成を再読み込みし、新しいドキュメントセッションを開きます。
2. 前回の不具合発生時間よりも長く文書を開いたままにしてください。編集中に一度テストを行い、問題が非アクティブ時に発生した場合は、文書をアイドル状態にしてもう一度テストしてください。
3. /cool/.../wsブラウザのネットワークパネルで接続が維持されていること、およびドキュメントがWOPIホスト経由で保存され続けていることを確認してください。
4. 同じ時間帯のログを確認してください。テストが成功した場合、プロキシのタイムアウトや予期しないWebSocketの切断は発生せず、ドキュメントを再度開いた後も編集内容が保持されます。

それでも切断される場合は、記録された障害発生時刻を復元し、各ホップのログと比較してください。イングレスで600秒の切断が発生している場合は、そのイングレスに問題があることを示しています。切断時刻が異なる場合やサーバー側のエラーが発生している場合は、別の場所に問題があることを示しています。「10分」という時間だけでは正確な原因を特定することはできません。タイムアウト名とデフォルト値は、プロキシ製品やリリースによって異なります。CODEバージョンとプロキシ製品を含む動作構成を文書化し、今後のアップグレード時に最新の公式サンプルと照らし合わせて確認できるようにしてください。