Nextcloud Talkのビデオ通話品質とTURNサーバー接続を修正する

Nextcloud Talkの通話問題は「ビデオ品質が悪い」と表現されることが多いですが、その根本原因は様々です。十分な帯域幅があっても、ファイアウォールがピアツーピアのWebRTCトラフィックをブロックしているために接続できない場合があります。また、TURN経由で正常に接続できたとしても、すべてのメディアが中継されるため、通話速度が遅く感じられる場合もあります。さらに、TURNサーバーが正常に動作していても、ハイパフォーマンスバックエンドではなく組み込みのピアツーピアトポロジを使用しているために、大規模な会議で問題が発生することもあります。

したがって、最も有用なトラブルシューティング方法は、接続性、メディアパス、スケーラビリティを分離することです。2026 年 10 月 6 日現在、Nextcloud のアップストリーム Talk ドキュメントでは、直接 WebRTC 接続が不可能な場合のフォールバックとして TURN が依然として説明されており、最大限の互換性のためにポート 443 が推奨されています。また、高性能バックエンドを使用している場合は、TURN サーバーが必要になる場合があることも記載されています。公式の Nextcloud Talk TURN ドキュメントとTalk の公式 coturn セットアップ ガイダンスを参照してください。

最初に修正すべきは、帯域幅、TURN、それとも高性能バックエンドのどれでしょうか？

症状のパターンに基づいて次の行動を選択することで、複数の設定を一度に変更するのを防ぐことができます。

ステップ1：障害の原因が接続性かメディア品質かを特定する

まずは2つの簡単なテストから始めましょう。1つ目は、通常のブロードバンド接続など、シンプルなネットワーク上で2つのクライアント間で通話を発信します。次に、社内Wi-Fi、VPN、モバイルホットスポットなどの制限のあるネットワークで同じテストを繰り返します。制限のあるネットワークでのみ通話が失敗する場合は、TURNが原因である可能性が高いです。両方の通話が接続されるものの、ビデオ品質が低い場合は、リレーアーキテクチャを変更する前に、ネットワークとデバイスの情報を収集してください。

Nextcloudの公式な接続手順では、まず直接ピアツーピア接続を試み、STUNを使用して到達可能なアドレスを検出し、直接接続が確立できない場合にTURNに頼ります。つまり、TURNは主に接続のフォールバック手段であり、ビデオ品質を向上させる万能な手段ではありません。中継経路の方が信頼性は高いものの、経路が長くなり、メディア帯域幅がTURNサーバーに分散されます。

ステップ2：Nextcloud Talk用にcoturnを設定する

セルフホスト型デプロイメントの場合、Nextcloudがドキュメントで推奨する最も一般的なTURN実装はcoturnです。Nextcloudはこの統合に共有シークレット認証を推奨しています。強力なランダムシークレットを生成し、coturnとTalkの管理設定の両方で同じ値を使用してください。

openssl rand -hex 32

最小限の構成には通常、リスニングポート、フィンガープリンティング、共有シークレット認証、レルム、およびピア制限が含まれます。正確なファイル場所は、オペレーティングシステムとパッケージによって異なります。代表的な構成は次のとおりです。

listening-port=443
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_RANDOM_SECRET
realm=turn.example.com
total-quota=0
bps-capacity=0
stale-nonce
no-multicast-peers

古いcoturnリリースでは、新しいリリースでは不要になったオプションが必要になる場合があります。そのため、古い設定をそのままコピーしないでください。Nextcloud coturnのドキュメントには、バージョンに依存する指示が明示的に記載されています。インストールされているcoturnのバージョンを、最新のNextcloud coturnの手順書と照らし合わせて確認してください。

coturnがNATの背後にある場合は、パブリックアドレスとプライベートアドレスのマッピングを正しく設定してください。coturnの設定リファレンスにはexternal-ipマッピングの説明があり、リレーポートはNATを介して一貫してマッピングされる必要があります。上流のcoturn設定例を参照してください。

UDP、TCP、TLS：どれを有効にすべきか？

リアルタイムメディアの場合、TCPの再送信動作やヘッドオブラインブロッキングを回避できるため、通常はUDPが推奨されるトランスポートプロトコルです。しかし、一部の企業ネットワークやゲストネットワークではUDPが完全にブロックされています。ウェブライクなトラフィックのみを許可するネットワークでは、TCPまたはTURN over TLSが代替手段として有効です。

最大限の接続性を確保するため、Nextcloudはポート443でのリッスンを推奨しており、TURN/TLSをサポートしています。両方を使用することturn:でturns:互換性は向上しますが、証明書や追加のトランスポートパスの管理も必要になります。すべてのユーザーがUDPが正常に動作することが確認されている管理されたネットワーク上にいる場合は、UDP優先のシンプルな設計の方が運用しやすいでしょう。ユーザーがホテル、顧客サイト、ロックダウンされたオフィス、VPNなどから頻繁に接続する場合は、TCP/TLSフォールバックを設定することで、追加の設定を行う価値が通常あります。

ステップ3：リスナーポートとリレーポートを正しく開く

よくある間違いは、TURNリスナーポートのみを開放することです。クライアントはまずリスナーを介してcoturnに接続しますが、coturnはメディア用のリレーエンドポイントも割り当てます。coturnのアップストリームのデフォルト設定49152-65535では、リレー割り当てにUDPポートが使用されます。ホストファイアウォール、クラウドセキュリティグループ、アップストリームルーター、またはNATデバイスによってその範囲がブロックされている場合、認証は成功してもメディアの送受信が失敗する可能性があります。

デフォルトのリレー範囲を維持することも、min-portおよびを使用して意図的に範囲を縮小することもできますmax-port。トレードオフは単純です。広い範囲は運用が簡単で、十分な割り当て容量を提供します。狭い範囲はファイアウォール ポリシーで記述しやすいですが、同時接続リレーがポートを必要とする数が多すぎると容量のボトルネックになる可能性があります。任意の小さな数値を選択するのではなく、予想される同時接続数に基づいて縮小範囲のサイズを決定します。

TURNホストがルーターの背後にプライベートアドレスを持っている場合、選択したリレー範囲に対して1対1のポートマッピングを維持し、coturnでパブリックアドレスマッピングを設定します。ホストのインターフェースに直接パブリックIPアドレスが割り当てられている場合は、NATマッピングの手順は不要です。

ステップ4：Nextcloud TalkにTURNサーバーを追加する

Nextcloud の管理エリアを開き、Talk 設定に移動します。URLhttp://やhttps://URL ではなく、ベア ホストとポートを使用して TURN サーバーを追加します。Nextcloud の現在の Talk ドキュメントによると、TURN スキームは個別に選択されるため、サーバー フィールドは の形式になりますturn.example.com:443。

coturnで設定した共有シークレットと同じものを入力し、サーバーが実際に受け入れるプロトコルを有効にします。TLSを使用する場合は、対応するTURNスキームを選択し、証明書がTURNホスト名と一致していることを確認してください。また、独自のTURNサービスをSTUNサーバーとして使用することもできます。これによりホスト管理が簡素化されますが、独立した障害ドメインや地理的に分散したリレーが必要な場合は、STUNとTURNを分離しておくと便利です。

スクリーンショット、チケット、または公開設定例に共有シークレットを記載しないでください。Nextcloudは、クライアントの一時的なTURN認証情報を生成するためにこのシークレットを使用します。

ステップ5：ICE候補をテストし、次に制限付きネットワークからテストする

Talkの設定を保存した後、管理チェックを実行して、TURNサーバーが使用可能なICE候補を返すかどうかを確認します。チェックが成功すれば、ブラウザが設定済みのTURNサービスから有効な候補を取得できたことが証明されます。ただし、すべてのユーザーネットワーク、すべてのリレーパス、すべての大規模通話が良好に動作することを保証するものではありません。

少なくとも1つの制限付きネットワークから実際の通話を繰り返してください。これは、ユーザーネットワークがUDP、DNS解決、または特定のトランスポートをブロックしている場合でも、サーバー側のチェックが通過する可能性があるため重要です。UDPが失敗しても443番ポートでのTCP/TLSが成功した場合は、フォールバックパスを維持してください。すべてのパスが失敗した場合は、ファイアウォールログ、coturnログ、DNS、証明書の有効性、共有シークレット、およびNATマッピングを確認してください。

高性能バックエンドはいつ追加すべきですか？

TURNと高性能バックエンドは、それぞれ異なる問題を解決します。TURNは、クライアントが必要なWebRTCパスを確立できない場合にトラフィックを中継します。高性能バックエンドは、複数参加者によるメディアの処理方法を変更することで、各参加者が他のすべての参加者に個別のストリームをアップロードする必要がなくなります。

NextcloudのTalkインターフェースには、高性能バックエンドを使用せずに実行することは、プロジェクト内で一般的に2～3人程度の非常に小規模な通話にのみ適していると警告されています。参加者数が増えるにつれて問題が発生する場合は、TURNを追加することでより多くのクライアントに接続できるようになる可能性がありますが、ピアツーピアのアップロードとCPU負荷は解消されません。グループ通話を拡張する前に、 Nextcloud Talkのシステム要件とプロジェクトの高性能バックエンドに関するガイダンスを確認してください。

高性能バックエンドを使用している場合でも、制限のあるネットワークからユーザーが接続する場合に備えて、TURN を利用できるようにしておいてください。Nextcloud のドキュメントには、20000-40000バックエンドのデフォルトの WebRTC メディア範囲が記載されており、特に、ポート 443 に制限されているクライアントは、パケットをそのバックエンド範囲に中継するために TURN が必要になる場合があると明記されています。

セルフホスト型TURNとマネージド型TURNの比較

実用的なチューニングチェックリスト

• 可能な限りWebRTCを直接使用するようにしてください。通常、中継コストと遅延を最小限に抑えることができます。
• 信頼性を確保するためにTURNを提供します。これは、NATやファイアウォールが不安定な状況における代替手段として扱います。
• 互換性のために、まずUDPを使用し、TCP/TLSは後で使用するようにしてください。ポート443は、Nextcloudが推奨するファイアウォールに最も優しいリスナーポートです。
• リスナーだけでなく、リレー範囲全体を開放してください。ファイアウォールとNATのルールを実際のmin-port/max-port構成に合わせてください。
• TURNの帯域幅を監視してください。中継通話では、TURNホストを介して大量のメディアトラフィックが流れる可能性があるため、CPUよりもネットワーク容量の方が重要になる場合が多くあります。
• 規模の問題と接続性の問題を分けて考えましょう。大規模な会議の場合は、TURN経由でトラフィックを増やすのではなく、高性能バックエンドの利用を検討してください。
• 実際のユーザーネットワークで検証してください。ICEテストは必須ですが、ホテル、企業、VPN、モバイルネットワークでは動作が異なる可能性があります。

結論

Nextcloud Talkが一部のネットワークでは動作するが他のネットワークでは動作しない場合は、適切なアクセスが可能なTURNサービスを設定し、リスナー、共有シークレット、NATマッピング、およびリレーポートを確認してください。通話は接続されるものの通話品質が低い場合は、TURNは遅延を軽減するのではなく、むしろ増加させる可能性があるため、まずクライアントネットワークとエンドポイントの負荷を測定してください。参加者数の増加に伴って問題が深刻化する場合は、通常、高性能バックエンドを使用するのがより適切なアーキテクチャ上の解決策であり、TURNは制限付きネットワークとの互換性パスとして残されます。