Collabora Online CODE で「Unauthorized WOPI Host」エラーを修正する

最も迅速かつ確実な解決策は、ストレージプラットフォームから送信される WOPI ソース URL に表示されるホスト名とポート番号を Collabora Online CODE が信頼するように設定することです。単一の Nextcloud サーバーの場合は、CODE ホストの許可リストにその Nextcloud ホスト名を設定し、コンテナを再作成して再度テストしてください。複数の Nextcloud インスタンスを運用している場合は、それぞれを明示的に許可してください。すべてのホストに対して WOPI アクセスを許可することでエラーを解決しないでください。

「認証されていないWOPIホスト」とは、通常、CollaboraがWOPIリクエストで指定されたストレージホストを拒否したことを意味します。これだけでは、ユーザーのパスワード、ドキュメントのアクセス許可、TLS証明書、またはリバースプロキシに問題があることを証明するものではありません。これらの要素は他の接続障害の原因となる可能性があるため、設定を変更する前にCollaboraのログを使用して具体的な原因を確認してください。

デプロイメントに合った変更を選択してください

以下の例では、Nextcloudhttps://cloud.example.comと Collabora をそれぞれ と に設定していますhttps://office.example.com。両方の名前とポートを、ご使用のインストールaliasgroup1環境で使用されている値に置き換えてください。Nextcloud の Docker セットアップ ガイドでは、単一のストレージ ホストに を使用し、2 番目の Nextcloud ホスト用に別のエイリアス グループを追加する方法を説明しています。Collabora の WOPI 設定では、ホスト名とポートに基づいてホストのマッチングを定義しています。エイリアスは、同じストレージ ホストの別名です。

1. Collaboraが拒否したホストを確認してください。

まずはCODEコンテナのログから始めましょう。Docker Composeデプロイメントでは、以下を実行します。

docker compose logs --since=10m collabora

collaboraCompose ファイル内のサービス名に置き換えてください。通常の Docker では、 を使用しますdocker logs --since 10m CONTAINER_NAME。ドキュメントを開くのに失敗したメッセージの近くで、 のようなメッセージを探してくださいNo acceptable WOPI hosts found matching the target host [cloud.example.com] in config。角括弧で囲まれたホスト名がヒントです。そこに表示されているストレージ ホストを追加してください。Collabora サーバーのパブリック ホスト名ではありません。

ログにWOPI URLのホスト名とポート番号が表示されている場合は、それらも記録してください。それらを設定済みのエントリと比較してください。 へのリクエストは、cloud.example.com:443などの内部コンテナ名のエントリと一致しない場合がありますnextcloud。たとえ両方の名前が同じマシンに解決される場合でも同様です。リバースプロキシ、スプリットホライズンDNS、および複数のパブリックURLが存在すると、この不一致を見落としやすくなります。

ログにDNSルックアップの失敗、接続拒否、証明書エラーなど、別のエラーが表示されている場合は、WOPIホストリストを拡大するのではなく、その問題を修正してください。

2. CODEの信頼できるWOPIホスト設定を更新する

1台のNextcloudホストにサービスを提供するDocker Composeインストールの場合、サービスの関連部分は次のようになります。

services:
  collabora:
    image: collabora/code
    environment:
      - aliasgroup1=https://cloud.example.com:443

既存のサービスオプション、シークレット、ボリューム、ポート、リバースプロキシ設定はそのまま維持してください。この例では許可リストのエントリのみを示しており、完全な本番環境用Composeファイルではありません。実行しているCODEバージョンで既にサポートされている設定スタイルを使用し、変更後はレンダリングされた構成または起動時の構成を確認してください。コンテナイメージと構成インターフェースは時間の経過とともに変更される可能性があります。

単一ホストの場合、広範囲の正規表現よりも正確なホストエントリの方が監査が容易です。インストールがdomain環境変数に依存している場合は、イメージに付属のエスケープ規則を確認し、式が意図したストレージホスト名のみに一致することを確認してください。エスケープされていないワイルドカードや、無関係なサブドメインに一致する親ドメインパターンはコピーしないでください。

複数の Nextcloud インスタンスを使用する場合は、CODE リリースでサポートされているメカニズムを使用して、独立したホストごとに個別の明示的なグループを追加してください。たとえば、Nextcloud の Docker 統合ガイドには、aliasgroup22 番目のクラウドホスト名の追加エントリが示されています。エイリアスは、内部名と公開名など、1 つの Nextcloud サーバーに実際に複数の名前でアクセスできる場合にのみ追加してください。移行後に古いホスト名を削除できるように、これらの名前のリストを文書で保管してください。

3. コンテナを再作成し、Nextcloudの個別の許可リストを確認します。

Compose ファイルを編集した後、新しい環境が適用されるようにサービスを再作成してください。

docker compose up -d --force-recreate collabora

正しいサービス名を使用してください。次に、コンテナが正常に起動し、起動設定またはログに想定されるホストが表示されていることを確認してください。サポートリクエストに環境ダンプ全体を貼り付けることは避けてください。パスワードやその他の機密情報が漏洩する可能性があります。

Nextcloud の Office 管理設定には、「WOPI リクエストの許可リスト」という別の設定項目があります。このリストは、Nextcloud への WOPI リクエストを行うことができる IP アドレスを制限します。Collabora では、想定される Collabora サーバーのアドレスのみに制限することを推奨しています。Nextcloud がこの警告を表示する場合は、プロキシやコンテナ ネットワークが関与している場合に異なる可能性がある、Nextcloud が実際にリクエストに対して認識するアドレスを追加してください。このチェックは CODE ホスト エントリとは区別してください。CODE はストレージ ホスト名を信頼しますが、Nextcloud の許可リストはリクエスト元のサーバーの IP アドレスに関係します。

リバースプロキシを使用する場合は、NextcloudがWOPIリンクで公開するホスト名が、CODEが信頼するように設定されているホスト名と同じであることを確認してください。Nextcloud OfficeサーバーのURLとリバースプロキシの公開ホスト設定を確認してください。WOPI URL内のストレージホストが実際にそのホスト名でない限り、Officeホスト名をWOPIストレージの許可リストに追加しないでください。

4. 完全な接続を確認する

まず、ブラウザとNextcloudサーバーからCollaboraサービスのエンドポイントを確認してください。例のホスト名を、ご自身のOffice URLに置き換えてください。

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

これらのチェックはエンドポイントが応答することを確認するものであり、WOPI ドキュメント要求が承認されることを証明するものではありません。次に、CODE が Nextcloud が公開しているのと同じホストを使用して Nextcloud にアクセスできることを確認します。例:

curl -fsS https://cloud.example.com/status.php

最後に、テストドキュメントを開き、CODEとNextcloudのログを同時に監視してください。正常に動作すれば、エディタが起動し、「適切なWOPIホストがありません」というメッセージが消え、小さな変更の保存ができるようになります。影響を受けるユーザーと同じ共有権限と編集権限を持つ通常のユーザーアカウントでテストしてください。

主な選択肢を比較する方法

1つの正確なホストと正規表現

単一クラウド環境の場合、通常は、目的のポート番号を含む正確なホスト名が最適です。これは、確認が容易で、意図しない一致を最小限に抑えることができます。意図的に管理されたホスト名のセットが共通のパターンを持つ場合は、正規表現が役立ちますが、監査が難しく、記述範囲が広すぎると意図しないサブドメインを許可してしまう可能性があります。検証済みのニーズを満たす、最も限定的な正規表現を使用してください。

1つのCODEインスタンスと、別々のインスタンス

共有CODEサービスを使用すると、管理するサービスの数を減らすことができ、明示的なグループで複数のNextcloudインスタンスをサポートできます。チームがより強力な構成分離や独立したメンテナンス期間を必要とする場合は、個別のCODEインスタンスが有効な場合があります。ただし、その代償として、パッチ適用、監視、ルーティングを行うインフラストラクチャが増えます。どちらのオプションも、WOPIホスト名の不一致を自動的に修正するわけではありません。各インスタンスは、適切なストレージホストを信頼する必要があります。

コンテナ環境設定とXML編集の比較

Docker CODE デプロイメントの場合は、イメージがサポートする構成インターフェイスを使用し、それを Compose または別のデプロイメントソースオブトゥルースに保持してください。これにより、コンテナが再作成されたときに変更を再現できます。coolwsd.xml管理パッケージや意図的なカスタムデプロイメントの場合は直接編集が役立ちますが、実行中のコンテナ内で生成されたファイルを編集するのは不安定で、置き換えやアップグレード時に失われる可能性があります。使用するパッケージ、Helm チャート、またはイメージの手順に従ってください。

避けるべきよくある間違い

• office.example.com拒否された WOPI ストレージ ホストの場合に許可しますcloud.example.com。
• WOPI URLにパブリックDNS名が含まれている場合にプライベートコンテナ名を入力する、またはその逆。
• Nextcloud WOPI IP 許可リストが空白の場合と CODE のホスト構成が同じ制御であると仮定します。
• エディタを読み込むためだけに、広範囲のワイルドカードを追加したり、ホスト検証を無効にしたりする。
• プロキシ、TLS、WOPIのルールを一度に変更すると、結果の診断が難しくなります。
• 検出エンドポイントのみをテストし、それを文書認証が機能する証拠として扱う。

別の解決策を使うべき時

リクエスト間で拒否されたホストが変更された場合は、名前を追加する前に、正規の Nextcloud URL、信頼できるプロキシ ヘッダー、および代替のウェブ ルートを確認してください。すべてのホスト名が一致しているにもかかわらずエラーが解消されない場合は、アクティブな CODE 構成を編集したファイルまたは環境設定と比較し、コンテナが再作成されたことを確認してください。Kubernetes または Helm の場合は、稼働中の Pod ではなく、チャート値または管理対象構成ソースを編集してください。ログに証明書、ファイアウォール、WebSocket、または DNS エラーが表示されている場合は、適切なサーバー ログとネットワーク チェックを使用して、そのレイヤーのトラブルシューティングを行ってください。

これらの手順は、2026年10月6日に公開されたNextcloud 35管理マニュアルおよびCollaboraが公開しているWOPI構成スキーマに準拠しています。具体的な構成キーは、デプロイ方法やイメージのバージョンによって異なる場合があるため、変更を適用する前に、インストールされているリリースのドキュメントと照らし合わせて確認してください。

公式資料

• Nextcloud Officeのトラブルシューティングと接続チェック
• Collabora向けのNextcloudのDockerサンプル（WOPIホスト設定を含む）
• Nextcloud Officeの設定とWOPI IP許可リストに関するガイダンス
• Collabora Onlineが公開しているcoolwsd.xml設定スキーマ
• Collabora Onlineのプロキシ設定に関するドキュメント