TURNサーバーとは何か？直接通信できないときのリレーの仕組み

この記事の最終更新日: 2026年5月30日

WebRTC、ビデオ通話、音声通話、オンラインゲーム、P2P通信などを調べていると、TURNサーバーという言葉が出てくることがあります。

前回のSTUNサーバーは、

自分が外からどのIPアドレス・ポート番号に見えているかを教えてくれるサーバー

でした。

一方、TURNサーバーはそれとは役割が違います。

TURNサーバーは、簡単に言うと、

端末同士が直接通信できないときに、通信を中継してくれるサーバー

です。

NAT越えでは、まず端末同士の直接通信を試します。

しかし、ネットワーク環境によっては、どうしても直接通信できないことがあります。

そのときに使われるのがTURNサーバーです。

この記事では、TURNサーバーとは何か、なぜ必要なのか、STUNとは何が違うのか、どのように通信をリレーするのかを初心者向けにわかりやすく解説します。

TURNサーバーとは？

TURNサーバーとは、NATの内側にある端末同士が直接通信できない場合に、通信を中継するサーバーです。

TURNは、

Traversal Using Relays around NAT

の略です。

日本語としては、

NATを越えるためにリレーを使う仕組み

と考えるとわかりやすいです。

たとえば、端末Aと端末Bが直接通信できない場合、TURNサーバーを間に挟みます。

端末A
↓
TURNサーバー
↓
端末B

端末Aと端末Bは直接つながっていません。

しかし、どちらの端末もTURNサーバーには接続できるため、TURNサーバーが通信を中継することで、結果的に端末同士が通信できるようになります。

なぜTURNサーバーが必要なのか？

インターネット上の通信では、多くの端末がNATの内側にいます。

たとえば、自宅のパソコンやスマホは、家庭用ルーターの内側にあります。

自宅PC
↓
家庭用ルーター NAT
↓
インターネット

この状態では、自宅PCから外部サーバーへアクセスすることは比較的簡単です。

自宅PC → Webサーバー

しかし、外部から自宅PCに直接接続するのは難しくなります。

なぜなら、ルーターは外から来た通信を、内部のどの端末に渡せばよいかわからないからです。

直接通信できないケース

NAT越えでは、STUNサーバーを使って外から見たIPアドレスとポート番号を調べ、端末同士の直接通信を試します。

しかし、次のような環境では直接通信できないことがあります。

• シンメトリックNAT
• 企業ネットワーク
• 学校や公共Wi-Fi
• UDP通信が制限されている環境
• ファイアウォールが厳しい環境
• 二重NAT
• CGNAT
• モバイル回線
• プロキシ経由のネットワーク

このような環境では、端末同士が直接通信しようとしても、パケットが届かなかったり、途中でブロックされたりします。

そこで、TURNサーバーを使います。

TURNサーバーの基本イメージ

TURNサーバーは、通信の中継所です。

端末Aと端末Bが直接通信できない場合でも、両方がTURNサーバーに接続できれば通信できます。

端末A → TURNサーバー → 端末B
端末B → TURNサーバー → 端末A

つまり、TURNサーバーは、

直接届けられない通信を、いったん預かって相手に転送するサーバー

です。

宅配で例えるなら、相手の家に直接届けられないときに、共通の中継センターを経由して荷物を送るようなイメージです。

STUNサーバーとの違い

TURNサーバーは、STUNサーバーとよく混同されます。

しかし、役割はまったく違います。

STUNは、直接通信するための「住所確認」です。

TURNは、直接通信できないときの「中継」です。

この違いは非常に重要です。

STUNだけでは解決できない理由

STUNサーバーを使うと、端末は自分が外からどう見えているかを知ることができます。

たとえば、端末AはSTUNサーバーから次のような情報を受け取ります。

端末Aは外から見ると 203.0.113.10:62001 に見える

端末Bも同じように、自分の外部アドレスを知ります。

端末Bは外から見ると 198.51.100.20:53001 に見える

この情報を交換すれば、端末同士で直接通信できそうに見えます。

端末A ←→ 端末B

しかし、NATやファイアウォールの種類によっては、相手からの通信を受け付けないことがあります。

つまり、

外から見た住所がわかっても、そこに通信を届けられるとは限らない

ということです。

このような場合、STUNだけでは不十分です。

そこでTURNサーバーが必要になります。

TURNサーバーの通信の流れ

TURNサーバーを使う通信の流れを、簡単に見ていきましょう。

1. 端末がTURNサーバーに接続する

まず、端末AがTURNサーバーに接続します。

端末A → TURNサーバー

この通信は、端末Aから外向きに開始されるため、NATを通過しやすいです。

端末Bも同じようにTURNサーバーへ接続します。

端末B → TURNサーバー

2. TURNサーバーが中継用のアドレスを割り当てる

TURNサーバーは、端末Aのために中継用のアドレスを用意します。

端末A用の中継アドレス：TURNサーバー:ポートA

端末Bにも同じように、中継用のアドレスが割り当てられます。

端末B用の中継アドレス：TURNサーバー:ポートB

この中継用のアドレスを、リレー候補と呼ぶことがあります。

WebRTCでは、ICE candidateの中の relay candidate にあたります。

3. 相手と中継アドレスを交換する

端末Aと端末Bは、シグナリングサーバーなどを通じて、通信候補を交換します。

端末A：
「直接通信候補もあるけど、TURN経由ならこのアドレスを使って」

端末B：
「こちらもTURN経由ならこのアドレスを使って」

この候補交換自体は、TURNサーバーではなく、別のシグナリングの仕組みで行われることが一般的です。

4. 直接通信できない場合、TURN経由で通信する

直接通信が失敗した場合、TURNサーバー経由の通信に切り替えます。

端末A
↓
TURNサーバー
↓
端末B

端末Bから端末Aに返す通信も、TURNサーバーを経由します。

端末B
↓
TURNサーバー
↓
端末A

これにより、端末同士が直接つながらなくても、通信を成立させることができます。

TURNサーバーは「最後の手段」として使われる

TURNサーバーは便利ですが、基本的には最初から使うものではありません。

理由は、サーバー負荷と通信コストが大きいからです。

STUNを使って端末同士が直接通信できる場合、映像や音声データは端末間で直接流れます。

端末A ←→ 端末B

一方、TURNを使う場合は、すべてのデータがTURNサーバーを通ります。

端末A → TURNサーバー → 端末B

ビデオ通話のように通信量が多いサービスでは、TURNサーバーに大きな負荷がかかります。

そのため、実務では次のような流れが一般的です。

1. まず直接通信を試す
2. STUNで外部アドレスを確認する
3. 直接通信できればそのまま通信する
4. 直接通信できなければTURNで中継する

TURNは、直接通信できない場合のフォールバックとして使われることが多いです。

WebRTCにおけるTURNサーバーの役割

WebRTCでは、TURNサーバーは非常に重要です。

WebRTCは、ブラウザ同士で音声、映像、データをやり取りする技術です。

たとえば、次のような用途があります。

• ビデオ通話
• 音声通話
• 画面共有
• P2Pファイル送信
• リアルタイムチャット
• ブラウザゲーム

WebRTCでは、できるだけ端末同士で直接通信しようとします。

しかし、直接通信できない環境もあります。

そのときにTURNサーバーを用意していないと、接続が失敗する可能性があります。

つまり、本番向けのWebRTCサービスでは、

TURNサーバーは接続成功率を上げるために重要

です。

STUNだけで実装すると、一部の環境では通話や通信が成立しないことがあります。

ICEとTURNの関係

WebRTCでは、ICEという仕組みが使われます。

ICEは、

使えそうな通信経路を集めて、実際に試し、最適な経路を選ぶ仕組み

です。

ICEでは、いくつかの通信候補を集めます。

TURNサーバーが提供するのは、主にこの relay candidate です。

通信経路としては、次のような優先順位になることが多いです。

1. ローカルネットワーク内で直接通信
2. NAT越しに直接通信
3. TURNサーバー経由で通信

TURNは最も確実性が高い一方で、コストと遅延が増えやすい経路です。

TURNサーバーを使うと何が重くなるのか？

TURNサーバーでは、実際の通信データを中継します。

たとえば、ビデオ通話では次のようなデータが流れます。

• 音声データ
• 映像データ
• 画面共有データ
• データチャネルの通信

これらがすべてTURNサーバーを通ると、サーバー側では次の負荷が発生します。

• ネットワーク帯域の消費
• CPU負荷
• メモリ使用
• 同時接続数の管理
• 通信ログや監視
• 地理的な遅延対策

特に映像データは通信量が大きいため、TURNサーバーの運用コストに直結します。

TURNサーバーのメリット

TURNサーバーの最大のメリットは、接続成功率を上げられることです。

直接通信できない環境でも、TURNサーバーに接続できれば通信できる可能性があります。

主なメリットは次のとおりです。

• 厳しいNAT環境でも通信できる可能性がある
• 企業ネットワークや公共Wi-Fiでも接続成功率を上げられる
• WebRTCの失敗率を下げられる
• ユーザーにポート開放を求めなくてよい
• P2P通信が失敗したときのフォールバックになる

利用者から見ると、TURNサーバーは見えません。

しかし、裏側では通信を成立させるための重要な保険になっています。

TURNサーバーのデメリット

一方で、TURNサーバーにはデメリットもあります。

特に大きいのは、コストと遅延です。

サーバーコストがかかる

TURNサーバーは実データを中継するため、通信量が増えるほどコストも増えます。

特にビデオ通話では、映像データが大きいため、帯域コストが問題になります。

遅延が増えることがある

直接通信なら、端末Aから端末Bへ最短経路で通信できます。

しかし、TURNを使うと、通信は一度TURNサーバーを経由します。

端末A → TURNサーバー → 端末B

この分だけ、遅延が増えることがあります。

TURNサーバーが障害点になる

TURNサーバーが落ちると、直接通信できないユーザーの通信が失敗します。

そのため、本番運用では冗長化や監視が必要になります。

TURNサーバーの設定例

WebRTCでは、次のようにICEサーバーとしてTURNサーバーを指定します。

const configuration = {
  iceServers: [
    {
      urls: "stun:stun.example.com:3478"
    },
    {
      urls: "turn:turn.example.com:3478",
      username: "user",
      credential: "password"
    }
  ]
};

const peerConnection = new RTCPeerConnection(configuration);

STUNサーバーとTURNサーバーを両方指定するのが一般的です。

STUNで直接通信を試し、直接通信できない場合にTURN経由の候補を使います。

TURNサーバーでは認証が重要

TURNサーバーは、必ず認証を設定するべきです。

なぜなら、TURNサーバーは通信を中継するため、悪用されると大量の通信を流される可能性があるからです。

認証なしで公開すると、第三者に勝手に使われ、帯域を消費されたり、攻撃の踏み台にされたりするリスクがあります。

そのため、TURNサーバーでは次のような対策が重要です。

• ユーザー名とパスワードによる認証
• 短時間で失効する認証情報
• 利用制限
• レート制限
• ログ監視
• 不正利用検知
• ファイアウォール設定

TURNサーバーは便利ですが、公開サーバーとして運用する場合は、セキュリティ設計が必須です。

TURNサーバーはどこに置くべきか？

TURNサーバーは、ユーザーに近い場所に置くほど遅延を抑えやすくなります。

たとえば、日本のユーザー向けサービスなら、日本国内や近隣リージョンにTURNサーバーを置くと、通信遅延を抑えやすくなります。

一方で、海外ユーザーも多い場合は、複数リージョンにTURNサーバーを配置することもあります。

考慮すべきポイントは次のとおりです。

• ユーザーの地域
• 通信量
• レイテンシ
• 帯域コスト
• 冗長化
• 障害時の切り替え
• 監視体制
• TURN over TCP / TLS の必要性

リアルタイム通信では遅延が体験品質に直結するため、TURNサーバーの配置は重要です。

TURN over TCP / TLSとは？

通常、リアルタイム通信ではUDPが使われることが多いです。

UDPは低遅延通信に向いているため、音声通話やビデオ通話でよく使われます。

しかし、企業ネットワークや公共Wi-Fiでは、UDP通信が制限されていることがあります。

その場合、TURN over TCP や TURN over TLS が使われることがあります。

TURN over UDP
TURN over TCP
TURN over TLS

特にTURN over TLSは、HTTPSと同じ443番ポートを使う構成にすることで、厳しいネットワーク環境でも通りやすくなる場合があります。

ただし、TCPやTLSを使うと、UDPより遅延が増えることがあります。

そのため、次のような使い分けになります。

基本：UDPで直接通信
失敗：TURN over UDP
さらに厳しい環境：TURN over TCP / TLS

TURNサーバーを使えば必ず通信できるのか？

TURNサーバーは接続成功率を大きく上げます。

しかし、完全に万能ではありません。

たとえば、次のような環境ではTURNでも失敗することがあります。

• 外部通信そのものが厳しく制限されている
• TURNサーバーへの接続先ポートがブロックされている
• 認証情報が間違っている
• TURNサーバーが落ちている
• ネットワーク品質が極端に悪い
• プロキシや検閲により通信が制限されている

とはいえ、STUNだけに比べると、TURNを用意した方が接続成功率はかなり高くなります。

よくある誤解

TURNサーバーはSTUNサーバーの上位互換ではない

TURNはSTUNの上位互換というより、役割が違います。

STUNは住所確認。

TURNは通信中継。

このように考えるとわかりやすいです。

TURNを使えば常に高品質になるわけではない

TURNは通信を成立させるためには便利ですが、直接通信よりも遅延やコストが増える場合があります。

そのため、可能なら直接通信し、必要な場合だけTURNを使うのが一般的です。

TURNサーバーは無料で無制限に使えるものではない

TURNサーバーは実際のデータ通信を中継します。

そのため、利用者が増えると通信量も増え、コストがかかります。

個人開発や小規模サービスでも、ビデオ通話機能を提供する場合はTURNの帯域コストを意識する必要があります。

開発者が押さえるべきポイント

WebRTCやP2P通信を実装する場合、開発者は次のポイントを押さえておくとよいです。

• STUNだけでは接続できないユーザーが出る
• 本番運用ではTURNサーバーを用意した方がよい
• TURNは通信コストが高くなりやすい
• TURNサーバーには認証が必要
• ユーザーに近いリージョンに置くと遅延を抑えやすい
• UDPが使えない環境向けにTCP/TLSも検討する
• 監視、ログ、帯域制限、冗長化が重要
• ICEの候補選択を理解しておくとトラブルシュートしやすい

特にWebRTCでは、TURNサーバーを用意していないと、

一部のユーザーだけ通話できない
特定の社内ネットワークだけ接続できない
スマホ回線では動くが会社Wi-Fiでは失敗する

といった問題が起きることがあります。

TURNサーバーを一言でまとめると

TURNサーバーを一言でまとめると、次のようになります。

TURNサーバーとは、端末同士が直接通信できないときに、通信を中継してくれるサーバー

もう少し実務寄りに言うと、

WebRTCやP2P通信で、直接接続できないユーザーのために用意するリレーサーバー

です。

STUNが「外から見た自分の住所を知る仕組み」だとすれば、TURNは「直接届けられない通信を中継する仕組み」です。

まとめ

TURNサーバーは、NAT越えにおいて非常に重要な役割を持っています。

NAT環境では、端末同士が直接通信できないことがあります。

STUNサーバーを使えば、外から見たIPアドレスとポート番号はわかります。

しかし、それだけで必ず通信できるわけではありません。

直接通信できない場合に、通信を中継してくれるのがTURNサーバーです。

最後に、STUN・TURN・ICEの関係を整理すると、次のようになります。

STUN：
外から見たIPアドレスとポート番号を調べる

TURN：
直接通信できないときに通信を中継する

ICE：
使える通信経路を集めて、最適な経路を選ぶ

TURNサーバーは便利ですが、通信量、コスト、遅延、セキュリティを考慮して運用する必要があります。

WebRTCやリアルタイム通信を本番サービスとして提供するなら、TURNサーバーは単なるオプションではなく、接続成功率を高めるための重要なインフラです。

daigoro

大阪のエンジニアが書いているブログ。