ONLYOFFICE Nextcloud連携における「トークンが無効です」エラーを修正する
JWTシークレット、認証ヘッダー、Docker設定、プロキシの動作、コネクタの状態を確認することで、NextcloudにおけるONLYOFFICEの「トークンが無効です」エラーを修正します。
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間のWebSocket接続が正常にアップグレードされなかったか、接続が確立された後に予期せず切断されたことを意味します。この違いは、修正方法が異なるため重要です。
| 観察された行動 | 最も役立つ最初のチェック | 典型的な原因 |
|---|---|---|
| ドキュメントを開くとすぐにエラーが発生します | ブラウザネットワーク > WSおよびリバースプロキシのアクセス/エラーログ | ルートが間違っている/cool/、アップグレードヘッダーが欠落している、Apacheルールが26.04と互換性がない、ホスト/オリジンが一致しない |
| 一時的には動作するが、一定間隔で接続が切断される。 | プロキシ、イングレス、ロードバランサー、ファイアウォールのアイドルタイムアウト | 長時間のWebSocket接続にはタイムアウトが短すぎます |
| 発見は機能するが、編集は機能しない | WebSocketを個別にテストします/hosting/discovery | HTTPエンドポイントには到達可能ですが、WebSocketルートには到達できません |
| ブラウザまたはネットワークパスが 1 つだけ失敗する | リクエストプロトコルとプロキシの動作を比較する | HTTP/2またはHTTP/3の処理、CONNECT転送、中間フィルタリング |
| サーバーログはアップグレードを明示的に拒否します | coolwsdの正確なエラーメッセージを読んでください。 | 発信元、ホスト、ポート、WOPIホスト、またはプロキシ設定の不一致 |
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 ルールを更新することで動作が回復した事例が記載されています。

まずは通常の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のログと照合してください。
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のルートおよびヘッダー要件に適合させつつ、トポロジーを維持することです。

WebSocket編集セッションは長時間継続します。Collaboraプロジェクトの現在のHelm設定では、この点が明示的に記述されており、バンドルされているNginxプロキシには長いプロキシタイムアウトが設定されています。エッジロードバランサー、Kubernetesイングレス、CDN、ファイアウォール、またはリバースプロキシが、アプリケーションの想定よりも早くアイドル状態の接続を閉じる場合、ユーザーはしばらくの間は正常に編集できますが、その後一定の間隔で切断されます。
毎回ほぼ同じ秒数でエラーが発生する場合は、Nginxのタイムアウト値を増やすだけでなく、パス上のすべての中間ノードを調べてください。タイムアウト値が最も短いノードが優先されます。
一般的なデプロイメントでは、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、証明書の失敗、またはアップグレードを中断させるリダイレクトが発生する可能性があります。
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構文の誤り、予期しないホスト、または利用できないアップストリームに関するメッセージは、一般的なブラウザのポップアップよりも対処しやすいものです。
これはより限定的なケースですが、サーバーを再構築する前に確認しておく価値があります。Collaboraプロジェクトでは、プロキシがHTTP/2 CONNECT WebSocketリクエストをcoolwsdに直接渡して405 Method Not Allowedを受け取ったChromium関連のケースが報告されています。また、別の問題では、特定のプロキシパスでHTTP/3/QUIC関連のドキュメント読み込みエラーが発生したことが記録されています。これらの報告は、HTTP/2またはHTTP/3を常に無効にする必要があるという意味ではなく、中間サーバーがクライアントの動作をCollaboraがサポートするWebSocket接続に変換する必要があるという意味です。
同じアカウントとドキュメントでFirefoxは正常に動作するのにChromeが動作しない場合は、プロキシでプロトコルとステータスコードを取得してください。環境に互換性のある代替手段がない場合を除き、最新のプロトコルを全体的に無効にするよりも、プロキシ/イングレスの動作を修正することを優先してください。
まずプロキシの構文テストを行い、その後、何度も闇雲に再起動するのではなく、リロードしてください。
sudo nginx -t && sudo systemctl reload nginx
sudo apachectl configtest && sudo systemctl reload apache2
コンテナの場合、Collaboraサービスを再起動しられるのは、サービス自体の環境またはcoolwsd設定を変更した場合のみです。プロキシのみの変更であれば、通常はプロキシのリロードだけで済みます。

単一の文書の正常なオープンに頼るのではなく、短い検証シーケンスを使用してください。
/hosting/discovery、/hosting/capabilitiesユーザーがアクセスするのと同じパブリックホスト名を通じてアクセスできます。26.04にアップグレードしてApacheを使用している場合は、Collaboraがその変更を明示的に文書化しているため、プロキシルールの更新が最優先事項です。一定時間後に切断が発生する場合は、すべてのネットワークホップのタイムアウト設定に注目してください。すべてのブラウザで即座に障害が発生する場合は、/cool/ルーティング、アップグレードヘッダー、ホスト/オリジンの一貫性、およびTLS終端を確認してください。特定のブラウザファミリーのみで障害が発生する場合は、Collabora自体を変更する前にHTTPプロトコルの処理を比較してください。
重要なのは、「ソケット接続が予期せず閉じられました」というエラーを、デフォルトでCollaboraアプリケーションのクラッシュとして扱わないようにすることです。多くの環境では、エディタ、検出エンドポイント、WOPIホストは正常に動作しているにもかかわらず、リバースプロキシがライブ編集に最も重要な接続タイプである、長時間接続が維持されるWebSocketを正しく処理できていないという問題が発生しています。
JWTシークレット、認証ヘッダー、Docker設定、プロキシの動作、コネクタの状態を確認することで、NextcloudにおけるONLYOFFICEの「トークンが無効です」エラーを修正します。
コールバック、内部URL、JWT、TLS、プロキシルーティング、ログ、ストレージを確認することで、NextcloudにおけるONLYOFFICEの「ドキュメントを保存できませんでした」エラーを修正します。
Collabora Onlineのソケット接続エラーを修正するには、26.04 WebSocketの変更点、プロキシルート、アップグレードヘッダー、タイムアウト、TLS、およびログを確認してください。
Collabora Onlineで多言語スペルチェックを有効にするには、サーバー辞書を追加し、言語コードを許可し、テキストに言語を割り当て、複数の言語を含む文書をテストします。
Calcデータ、名前付き画像プレースホルダー、およびBasicマクロを使用して、レコードごとに画像を挿入する信頼性の高いLibreOffice Writerメールマージを作成する方法を、トラブルシューティングと検証の手順とともに解説します。
WOPI、リバースプロキシ、TLS、DNS、WebSocket、およびサーバー間の接続可能性をチェックすることにより、Collabora Onlineのドキュメント接続障害を診断および修正します。
ONLYOFFICEデスクトップエディター(オフライン版)でPDFファイルを編集可能なDOCXファイルに変換します。「名前を付けて保存」の手順に従い、PDFファイルがスキャンされているか確認し、書式設定をチェックしてください。
SeafileをDockerまたは別のホストを使用してCollabora Onlineに接続します。デプロイメントのトレードオフを比較し、HTTPSとWOPIの設定を構成し、編集内容を確認します。
画像が多いLibreOffice Writerファイルで、入力、スクロール、保存が遅い場合の診断を行います。ディスプレイ設定をテストし、サイズの大きい画像を圧縮して、プロファイルまたはハードウェアの問題を特定します。
公式Helmチャートを使用して、Kubernetes上にCollabora CODEをデプロイします。イングレス、TLS、WOPIホストアクセス、シークレット、スケーリング、エンドツーエンドチェックを設定します。