音声通話およびビデオ通話用のMatrix Coturn TURN/STUNサーバーの設定方法

Matrix の呼び出しに関する現在の変更は検出に影響しますが、Coturn の TURN 認証情報やポートには影響しません。Matrix.org は 2026 年 8 月 21 日の更新で、Element Call 0.24 ではホームサーバーの/.well-known/matrix/clientファイルによる MatrixRTC トランスポートの検出が非推奨になったと報告しました。スタンドアロンの Element Call デプロイメントでは MatrixRTC トランスポートのエンドポイントをサポートする必要があります。Element Web/Desktop および Element X では、クライアントが移行する間、フォールバックとして古い検出方法を維持していました。これは従来の TURN 設定とは別です。

このガイドでは、従来のWebRTC通話を使用するクライアントに一時的なICE認証情報を提供するSynapseのTURNサービス用にCoturnを設定します。現在のElement CallおよびMatrixRTCグループ通話では、LiveKitの選択的転送ユニット（SFU）とMatrixRTC認証サービスが使用されます。Coturn単体ではこれらのコンポーネントを置き換えることはできません。Element Callをセルフホストする場合は、公式のElement Callガイドに記載されているLiveKitパスを使用してください。選択したメディアアーキテクチャで別途TURNサービスが必要な場合にのみ、Coturnを追加してください。

まず、適切な通話経路を選択してください。

Synapse 上の MatrixRTC の場合、現在の Element Call セルフホスティングガイドでは、matrix_rtc.transportsドキュメントに記載されている実験的機能フラグを使用して、ホームサーバーのトランスポートレジストリを使用し、有効化しています。Matrix.org の 2026 通知によると、この検出方法の変更はスタンドアロンの Element Call デプロイメントに最も重要であり、他の管理者はサポート対象のクライアントがフォールバックを維持したままエンドポイントを準備することができます。実際に使用しているクライアントと Synapse リリースに対応するガイドを確認してください。

コターンが行うこと

STUNは、WebRTCクライアントが公開できるネットワークアドレスを検出できるようにします。TURNは、2つのクライアントがルーターやファイアウォールを介して直接接続を確立できない場合にメディアを中継します。Coturnはこれらの両方のサービスを実装しています。中継可能なネットワークがない場合、参加者が制限されたネットワークや関連性のないネットワークにいると、通話は鳴っても「接続中」のままになることがあります。

TURNサーバーには、パブリックIPアドレス、またはパブリックIPアドレスと適切な転送ルールを備えたNATゲートウェイが必要です。プライベート専用サーバーは、リモートのMatrixユーザー向けのインターネットリレーとして機能できません。小規模なSynapse展開の場合、Coturnをホームサーバーにインストールするか、別のパブリックホストを使用できます。別のホストを使用すると、ファイアウォールの境界が明確になり、独立したスケーリングが可能になります。同じホストにインストールする方が簡単ですが、リレーがプライベートサービスを公開しないように、ファイアウォールルールを慎重に設定する必要があります。

1. Coturnをインストールし、共有シークレットを準備します。

DebianまたはUbuntuでは、ディストリビューションパッケージをインストールしてください。

sudo apt update
sudo apt install coturn

このパッケージはsystemdサービスを提供し、メインの設定ファイルは一般的に です/etc/turnserver.conf。他のディストリビューションでは、独自のパッケージ名、サービス管理、および設定パスが使用されます。

強力な秘密鍵を生成します。例：

openssl rand -hex 32

CoturnとSynapseで同じシークレットを使用してください。パスワードと同様に扱ってください。ドキュメントのサンプル値を再利用したり、公開リポジトリにコミットしたり、公開バグレポートに含めたりしないでください。Synapseのバージョンがをサポートしている場合はturn_shared_secret_path、シークレットをYAMLにインラインで保存する代わりに、保護されたファイルに保存できます。Synapseはこの設定をバージョン1.116.0で追加しました。使用する前に、デプロイ済みのバージョンを確認してください。

2. 認証リレー用にCoturnを設定する

サービス名と共有シークレット認証を編集し/etc/turnserver.confて設定します。ドメインとシークレットのプレースホルダーを置き換えてください。

listening-port=3478
tls-listening-port=5349

fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_THE_SAME_RANDOM_SECRET
realm=turn.example.org

min-port=49152
max-port=65535

no-tcp-relay
no-multicast-peers
user-quota=12
total-quota=1200

syslog

use-auth-secretSynapse が使用する時間制限付き TURN 認証情報メカニズムを有効にします。匿名アクセスを設定したり、オープンリレーを公開したりしないでください。上記のクォータ値は、Synapse の Coturn ガイダンスから抽出した開始値です。想定されるユーザー数と容量に合わせて調整してください。no-tcp-relayクライアントがリレーに対して任意の TCP 宛先への接続を要求することを防ぎます。これは、クライアントから TURN へのトランスポートとして TCP を無効にする必要があるという意味ではありません。

TURNは、内部ネットワークアドレスや機密性の高いネットワークアドレスへのリレーとして悪用される可能性があります。現在のSynapse Coturnセキュリティ例に記載されている、拒否ピアのアドレス範囲全体（IPv4およびIPv6ネットワークに関連する範囲を含む）を適用してください。ユーザーが正当な理由でプライベートネットワークピアにアクセスする必要がある場合は、ルールをコピーする前に内容を確認してください。また、Coturnを常に最新の状態に保ち、ログとクォータを監視してください。

CoturnがNATの背後にある場合、パブリックアドレスを設定します。

TURNホストがルーターの背後にある場合は、Coturnが到達可能なリレーアドレスを通知するように、そのパブリックアドレスを構成に追加してください。

external-ip=YOUR_PUBLIC_IPV4
listening-ip=YOUR_PRIVATE_IPV4

サンプル値を実際のアドレスに置き換えてください。Coturnが既に正しいインターフェースにバインドされている場合は、リスニングアドレスは省略可能です。ルーターからこのサーバーにTURNリスナーとリレー範囲を転送してください。外部アドレスの不一致は、同じLAN内では動作するものの、異なるネットワーク間では失敗する一般的な原因です。

3. リスナーポートとリレーポートを開きます

ホストファイアウォールとクラウドファイアウォールまたはルーターの両方で、Coturnの設定に一致するポートを許可してください。

• 通常のTURNリスナーにはTCPとUDPの3478番ポートが使用されます。
• デフォルトのリレー範囲は、上記のUDP 49152～65535です。より狭い範囲を選択する場合は、Coturnとファイアウォールの両方で同じ範囲を設定してください。
• TCP 5349はTURN over TLS用、UDP 5349はDTLSを有効にして提供する場合にのみ使用します。

UFWの場合、基本的なUDP/TCPリスナーとUDPリレールールセットは次のようになります。

sudo ufw allow 3478/tcp
sudo ufw allow 3478/udp
sudo ufw allow 49152:65535/udp

5349 ルールは、対応する TLS または DTLS リスナーが設定され、公開されている場合にのみ追加してください。プロバイダのセキュリティ グループも確認してください。ホスト レベルの UFW ルールは、ブロックされたクラウド イングレス ルールを上書きすることはできません。Coturn の管理制御インターフェイスをインターネットに公開しないでください。

4. Synapseを設定してCoturn認証情報を発行する

アクティブな Synapse 設定 (通常は ) に、以下の TURN 設定を追加しますhomeserver.yaml。ホスト名は、パブリックに TURN ホストに解決される必要があります。

turn_uris:
  - "turn:turn.example.org:3478?transport=udp"
  - "turn:turn.example.org:3478?transport=tcp"
turn_shared_secret: "REPLACE_WITH_THE_SAME_RANDOM_SECRET"
turn_user_lifetime: 1h
turn_allow_guests: true

最初の 2 つの URI は、ポート 3478 で通常の TURN トランスポートを宣伝します。TLS が設定され、テストされている場合は、 のような URI も宣伝できますturns:turn.example.org:5349?transport=tcp。証明書、リスナー、ファイアウォール、およびクライアントの互換性がすべて整っていない限り、URI を宣伝しないでくださいturns:。Coturn の TLS 証明書と秘密鍵は、その設定ファイルで とcertで設定されます。pkey

turn_allow_guests客室およびゲストポリシーに合わせて設定してください。有効にすると、認証されていないゲストユーザーがTURN認証情報を要求できるようになります。これはゲスト通話に必要な場合もありますが、不正利用のリスクを高める可能性があります。無効にすると、ゲストの通話が不安定になる場合があります。いずれの場合も、監視と割り当てを設定してください。

ファイルを変更した後は、CoturnとSynapseを再起動してください。

sudo systemctl restart coturn
sudo systemctl restart matrix-synapse

Synapseのsystemdユニット名が異なる場合は、実際のユニット名を使用してください。影響を受けるクライアントをリロードまたは再起動してください。SynapseのTURN設定は定期的に更新されるため、クライアントにすぐに変更が反映されない場合があります。

TLS上でTURNを有効にすべきでしょうか？

UDP/TCP TURNを3478番ポートで開始し、リレー候補が正しく動作することを確認してください。TLS経由のTURNは、ユーザーのネットワークで必要な場合にのみ追加してください。例えば、TLSのようなトラフィックは許可するものの、通常のUDPはブロックする企業ファイアウォールなどが該当します。TLSは接続性を向上させますが、証明書の更新、別のリスナー、クライアントの互換性チェックといった処理が追加されます。

Matrix固有の注意点があります。現在のSynapse Coturnガイドでは、Let's Encrypt証明書を使用したTLS/DTLSは、同ガイドに記載されているように、Element AndroidおよびiOSを含むChromiumのWebRTCライブラリを使用するMatrixクライアントでは動作しないと警告しています。TLS URIを公開する前に、クライアントのバージョンとの互換性を確認してください。同ガイドでは、まず基本サービスを設定し、その後TLS/DTLSを追加することを推奨しています。

5. 認証情報を確認し、外部ネットワークからテストする

まず、Coturnが実行されていることを確認し、そのログを確認してください。

sudo systemctl status coturn
sudo journalctl -u coturn -f

次に、認証済みのMatrixクライアントセッションから、Synapseの現在のクライアント/サーバーAPIエンドポイントへのリクエストを調べます/_matrix/client/v3/voip/turnServer。正常な応答には、ユーザー名、パスワード、有効期限、および設定したTURN URIが含まれているはずです。この応答を公開しないでください。認証情報は、リレー用の一時的なアクセストークンです。

公式の WebRTC Trickle ICE サンプルを使用して、Synapse から返されたユーザー名とパスワードでテストします。TURN URI と認証情報を追加し、ICE 収集テストを実行して、タイプが の候補を探しますrelay。STUN に応答するだけのサーバーは、サーバー反射型の候補を表示する可能性がありますが、メディアの中継に失敗する場合があります。モバイル接続または LAN 外のネットワークからテストし、異なるネットワーク上の参加者間で実際の通話を行います。

よくある故障を診断する

• TURN 認証情報が表示されません: Synapse が正しい構成をロードし、正常に再起動し、共有シークレットが設定されていることを確認してください。リクエスト応答を調べて を探します/voip/turnServer。
• 認証情報は表示されるが、リレー候補が形成されない場合： TCP/UDP 3478、公開されているホスト名、秘密鍵の一致、Coturnログ、およびUDPリレー範囲をすべてのファイアウォールで確認してください。
• 通話は1つのLAN内では正常に動作するが、ネットワークをまたぐと失敗する：検査external-ip、ポート転送、および戻り経路。Coturnは、クライアントが到達できるパブリックアドレスを通知する必要があります。
• TLSが無効になっている場合にのみ通話が接続されます。証明書チェーン、TLSリスナー、通知されたturns:URI、およびクライアント固有の互換性を確認してください。
• 従来の通話は機能しますが、Element Call は機能しません。MatrixRTC /LiveKit トランスポートの設定を別途確認してください。Coturn テストが正常に完了しても、LiveKit SFU または MatrixRTC 認証サービスが検証されたことにはなりません。

ブラウザクライアントの場合、ブラウザのWebRTC診断機能で、メディアがリレー候補を選択したかどうかを確認できます。MatrixRTCの場合は、Synapseがトランスポートエンドポイントを公開していること、およびLiveKit WebSocketと認証ルートに到達可能であることを確認してください。現在のエンドポイントと、サポートするクライアントが必要とするドキュメント化された検出フォールバックの両方をテストしてください。

設定リファレンス

• Synapse: TURNサーバーの設定
• Synapse: Coturnのインストール、セキュリティ、NAT、およびTLSの設定
• TURNおよびMatrixRTCのSynapse設定リファレンス
• Coturnの公式turnserver.confの例
• 要素呼び出し：MatrixRTCセルフホスティングガイド
• LiveKitのデプロイとTURNの設定
• Matrix.org の Element Call 0.24 トランスポート検出に関するアップデート
• Matrixクライアント/サーバーAPI仕様（TURN認証情報エンドポイントを含む）