コードドキュメント編集セッションが10分後に切断される問題を修正

Collabora Online Development Edition (CODE) ドキュメントが正常に開き、編集作業を行った後、ほぼ正確に 10 分後にエディタが切断される場合は、ブラウザと CODE 間の WebSocket パスから調査を開始してください。600 秒で切断される現象が再現される場合は、CODE のデフォルトのアイドル タイマーよりも、リバース プロキシ、イングレス コントローラ、ロード バランサー、またはファイアウォールのタイムアウトが原因である可能性が高いです。

この区別が重要なのは、CODE 自体のアイドル設定を先に変更すると、編集トラフィックを伝送する接続を修正することなく、本当の問題を隠蔽してしまう可能性があるからです。現在の Collabora 設定テンプレートでは、ビューごとのアイドルタイムアウトが 15 分、ドキュメントのアイドルタイムアウトが 1 時間となっており、編集セッションの制限は 10 分ではありません。上流のcoolwsd.xml テンプレートを参照してください。切断が発生したときにユーザーがアクティブに入力している場合、アイドル専用の CODE 設定ではさらに説明が弱くなります。

10分間のデジタルデトックスが通常意味すること

検証済み： Collaboraが公開しているNginxのサンプルでは、​​WebSocketアップグレードヘッダーとメインWebSocket用のlongを使用していますproxy_read_timeout 36000s。Nginx自体にも、プロキシ経由のWebSocket接続は、設定された読み取りタイムアウト内にデータが受信されない場合に閉じられることが明記されており、一般的なproxy_read_timeoutデフォルト値は60秒です。Collabora Online SDKマニュアルとNginx WebSocketプロキシのドキュメントを参照してください。

環境依存： CODEの前面にあるNginxホストが正しく動作しているように見えても、別のプロキシ層によって600秒のタイムアウトが発生する可能性があります。よくある例としては、Kubernetes Ingress、HAProxy、クラウドロードバランサー、WAF、またはアップストリームのリバースプロキシなどが挙げられます。正確なタイムアウト値と設定キーは、そのコンポーネントによって異なります。

症状だけでは証明できません。「10分後に切断される」というだけでは、Nginxが原因であるとは断定できません。複数のレイヤーを一度に変更する前に、失敗したWebSocketをキャプチャし、そのタイムスタンプをプロキシログとCODEログと照合してください。

対処方法：ブラウザの開発者ツールを開いて障害を再現し、WebSocketリクエストの正確な実行時間を記録してください。

ステップ1：実際にWebSocketがクラッシュしていることを確認する

ドキュメントを開き、ブラウザの開発者ツールを開いてネットワークパネルに切り替えます。WebSocketトラフィックをフィルタリングします。コード編集トラフィックには通常、/cool/パスの下にWebSocketが含まれます。障害発生箇所以降もドキュメントを開いたままにしておきます。

セッションが切断されたら、WebSocketリクエストを調べます。最も有用な情報は、リクエストの継続時間、切断タイミング、初期アップグレード時のHTTPステータス、およびブラウザがネットワークエラーを報告したかどうかです。初期接続が正常に終了し、101 Switching Protocolsその後約600秒で切断された場合は、接続の有効期間または非アクティブポリシーが経路のどこかに設定されていることを示唆します。

WebSocketのアップグレードが正常に完了しない場合は、「10分間のタイムアウト」の問題ではありません。まずWebSocketのルーティングとヘッダーを修正してください。エディタでストレージまたは保存エラーが表示されている間もWebSocketが接続されたままの場合は、WOPI/ストレージパスを調査してください。

対処方法：開始時刻と切断時刻を記録し、それらのタイムスタンプをリバースプロキシのアクセス/エラーログ、およびCODEコンテナまたはサービスログと比較します。

ステップ2：CODEのアイドル値を変更する前に、CODEリバースプロキシルールを確認します。

Nginxの場合、重要なのはWebSocketロケーションがアップグレードヘッダーを渡し、十分な長さの読み取りタイムアウトを持っていることです。CollaboraのSDKマニュアルには、メインのWebSocketについて次のパターンが示されています。

location ~ ^/cool/(.*)/ws$ {
    proxy_pass https://127.0.0.1:9980;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "Upgrade";
    proxy_set_header Host $host;
    proxy_read_timeout 36000s;
}

TLSがNginxで終端され、CODEが意図的にその背後でプレーンなHTTPを提供している場合、アップストリームのスキームはhttp://代わりに別のものになる可能性があります。スキームを盲目的にコピーしないでください。CODEインスタンスの設定方法と一致している必要があります。

よくある誤解の一つは、proxy_connect_timeoutが既に確立された編集セッションの有効期間を制御するというものです。そうではありません。 は、アップストリームへの接続を確立する際に適用されます。アップストリームデータが存在しない期間がある確立されたプロキシ WebSocket に最も直接的に関連する設定は です。 Nginx は、HTTP プロキシ モジュールのリファレンスproxy_read_timeoutでこの動作を説明しています。

アクション: CODE WebSocket URL に一致する実際の Nginx ブロックを見つけて、タイムアウトが無関係なブロックだけでなく、そこに設定されていることを確認しますlocation。

ステップ3：CODE 26.04プロキシの変更を考慮する

2026年10月現在、Collaboraの最新CODE 26.04リリースノートには、2026年9月24日にリリースされたCODE 26.04.4.2が記載されています。26.04シリーズでは、よりコンパクトなWebSocket URLが導入されました。Collaboraは、既存のプロキシ設定を更新する必要がある場合があると述べています。後の26.04ビルドでは、プロキシが更新されていない場合、CODEは従来のURLにフォールバックし、監査警告を発することができます。Apache2ユーザーは、26.04が導入された際にProxyPassルールを更新するように特に指示されました。CODE 26.04の公式リリースノートを参照してください。

これは、10分ごとの接続切断がすべてコンパクトURLの変更によって引き起こされているという意味ではありません。26.04では、特にアップグレード後に問題が発生した場合は、実際に使用しているバージョンのドキュメントと照らし合わせてリバースプロキシのルールを確認する必要があるという意味です。

対処方法：製品の「バージョン情報」またはコンテナイメージタグでCODEバージョンを確認し、プロキシ設定を最新のCollaboraプロキシガイドラインと比較してください。古い24.04環境からコピーしたルールが依然として最適であるとは限らないことに注意してください。

ステップ4：Kubernetes Ingress、HAProxy、Apache、およびその他のミドルボックスを確認する

NginxがCODEの1つ前のレイヤーに過ぎない場合、タイムアウトを延長するだけでは不十分な場合があります。ingress-nginxを使用するKubernetesの場合、プロジェクトではIngressごとのアノテーションとという名前について説明していますnginx.ingress.kubernetes.io/proxy-read-timeout。WebSocketnginx.ingress.kubernetes.io/proxy-send-timeoutのガイダンスでは、長時間接続の場合は1時間を超える値を推奨しています。公式のIngress-NginxアノテーションのリファレンスとWebSocketの注記を参照してください。

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-read-timeout: "3600"
    nginx.ingress.kubernetes.io/proxy-send-timeout: "3600"

HAProxy の場合、Collabora の SDK の例では、WebSocket スタイルのトラフィックに対して長いトンネルタイムアウトを使用しています。Apache の場合、一般的なプロキシタイムアウトは によって制御されますProxyTimeoutが、CODE 26.04 では、現在の WebSocket ProxyPass パターンにも注意を払う必要があります。Apache のmod_proxy のドキュメントには、 が何を制御するかが説明されていますProxyTimeout。

対策：ブラウザからCODEへの接続経路を描画し、各ホップを検査してください。いずれかのホップで600秒の制限が経過すると、セッションが終了する可能性があります。

ステップ5：プロキシを検証し、安全に再読み込みする

Nginxの設定を編集した後は、リロードする前にテストしてください。

sudo nginx -t
sudo systemctl reload nginx

Nginxがコンテナ内で実行されている場合は、既存の設定が存在すると想定するのではなく、コンテナに対応した検証およびリロード手順を使用してくださいsystemctl。重要なのは、実行中の設定を置き換える前に構文を検証することです。

手順：一度に1つのレイヤーを変更し、以前の値を記録し、設定を検証してから、同じドキュメントワークフローを再テストします。

ステップ6：以前のカットオフよりも長いテストで修正を検証する

ドキュメントが再び開いたときにテストを中止しないでください。以前のエラー発生時点を過ぎても、同じ編集セッションを接続したままにしてください。10分間の症状であれば、2分間の簡易テストよりも20～30分間の検証期間の方が効果的です。ネットワークパネルを開いたままにして、時折編集を行い、アクティブな編集状態と完全にアイドル状態のタブを区別できるようにしてください。

良好な結果には3つの兆候があります。WebSocket接続が10分以上維持されること、エディタが再接続を促すことなく編集を受け付け続けること、そして中間ログまたはCODEログに対応するタイムアウトが発生しないことです。

最も近いプロキシのタイムアウト時間を延長した後も、接続がちょうど10分で切断される場合は、別のホップに依然として600秒のポリシーが設定されていることを示す有用な証拠となります。

対処方法：クローズまたはタイムアウトを発生させているコンポーネントが特定されるまで、追跡を継続します。

CODEのアイドルタイマーと10分間のネットワーク切断を混同しないでください。

上流のCODE構成テンプレートでは、現在per_view.idle_timeout_secs900秒（15分）と記載されています。説明によると、ユーザーが操作していない間は画面が暗くなり、更新が停止します。ドキュメントレベルのidle_timeout_secsデフォルト値は3600秒（1時間）で、この時間経過後にアイドル状態のドキュメントがアンロードされます。

これらの値は、実際の動作と一致するかどうかを確認する価値がありますが、どちらのデフォルト値も正確に600秒の切断を説明するものではありません。以前に誰かがcoolwsd.xml環境変数、Helmの値、またはコンテナパラメータをカスタマイズしていた場合、デプロイメントはデフォルト値と異なる可能性があります。

対処方法：障害がネットワークレベルのものかアプリケーションレベルのものかを特定した後で、有効なCODE構成を検査してください。最初の対応として、すべてのアイドル値を増加させないでください。

迅速診断表

結論

CODE編集セッションが10分後に繰り返し切断される場合、最も効率的な手順は次のとおりです。WebSocketの失敗を確認し、一致するリバースプロキシルールを検証し、すべての中間タイムアウトを調べ、CODE 26.04のプロキシパスの変更を考慮し、安全に再起動し、以前のカットオフを超えてテストします。CODEのアイドル設定を変更するのは、観測された動作と実際の構成がそれを示している場合に限ります。

障害発生時刻が再現できない場合、またはCODEログにクラッシュ、プロセス終了、メモリ不足、WOPIエラーが同時に記録されている場合は、単純なタイムアウトとして扱うのはやめてください。これらの症状には別の診断が必要です。