STUNとTURNの違いとは？NAT越えでの役割を初心者向けに整理

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

WebRTC、ビデオ通話、音声通話、オンラインゲーム、P2P通信などを調べていると、STUNやTURNという言葉が出てきます。

どちらもNAT越えで使われる技術ですが、役割は大きく違います。

簡単に言うと、次のように整理できます。

STUN：
外から見た自分のIPアドレスとポート番号を調べる仕組み

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

つまり、STUNは「住所確認」、TURNは「中継」です。

この記事では、STUNとTURNの違い、NAT越えでの役割、WebRTCでどう使われるのかを初心者向けにわかりやすく整理します。

まずNAT越えとは？
STUNとは？
TURNとは？
STUNとTURNの違い
例えるなら「住所確認」と「宅配中継所」
1. STUNは住所確認
2. TURNは中継所
NAT越えではなぜSTUNが必要なのか？
NAT越えではなぜTURNが必要なのか？
STUNだけでは不十分な理由
TURNはなぜコストが高いのか？
STUNとTURNはどちらが重要？
1. STUNが重要な理由
2. TURNが重要な理由
WebRTCではSTUNとTURNをどう使うのか？
WebRTCの設定例
STUNとTURNの通信イメージ
1. STUNの場合
2. TURNの場合
どちらを使うべきか？
STUNだけでよいケース
TURNが必要になりやすいケース
STUNとTURNのよくある誤解
1. STUNを使えば必ずNAT越えできる
2. TURNはSTUNの上位互換である
3. TURNを使えば常に高品質になる
4. STUN/TURNだけでWebRTCが完結する
開発者向けに押さえるポイント
STUNとTURNを一言でまとめると
まとめ

まずNAT越えとは？

STUNとTURNを理解するには、まずNAT越えを知る必要があります。

NAT越えとは、

NATの内側にいる端末同士が、インターネット越しに通信できるようにするための技術や工夫

です。

家庭や会社のネットワークでは、多くの場合、端末はルーターの内側にいます。

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

自宅PCには、次のようなプライベートIPアドレスが割り当てられます。

192.168.1.10

しかし、このIPアドレスはインターネット上では直接使えません。

インターネット側から見ると、ルーターによって変換されたグローバルIPアドレスとポート番号に見えます。

203.0.113.10:62001

このように、NAT環境では「自分が外からどう見えているか」が変わります。

そのため、端末同士で直接通信しようとすると、通信できないことがあります。

STUNとは？

STUNとは、簡単に言うと、

自分が外からどのIPアドレス・ポート番号に見えているかを調べる仕組み

です。

STUNサーバーに問い合わせることで、端末は自分の外部アドレスを知ることができます。

たとえば、自宅PCのローカルアドレスが次のようなものだったとします。

192.168.1.10:50000

この端末がSTUNサーバーに問い合わせると、STUNサーバーは次のように教えてくれます。

あなたは外から見ると 203.0.113.10:62001 に見えています

つまりSTUNは、

NATの外側から見た自分の住所を教えてくれる仕組み

です。

TURNとは？

TURNとは、簡単に言うと、

端末同士が直接通信できないときに、通信を中継する仕組み

です。

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

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

この場合、端末Aと端末Bは直接つながっていません。

しかし、両方の端末がTURNサーバーには接続できるため、TURNサーバーが通信を中継します。

つまりTURNは、

直接届けられない通信を、代わりに運んでくれる中継サーバー

です。

STUNとTURNの違い

STUNとTURNの違いを表にすると、次のようになります。

項目	STUN	TURN
役割	外から見たIPアドレス・ポートを調べる	通信を中継する
通信データの扱い	基本的に中継しない	実際のデータを中継する
サーバー負荷	軽い	重い
通信コスト	低い	高い
遅延	少ない	増えやすい
使う場面	直接通信できるか試すとき	直接通信できないとき
WebRTCでの候補	server reflexive candidate	relay candidate

一番重要なのは、次の違いです。

STUN：通信相手に教えるための「外から見た自分の住所」を調べる

TURN：直接通信できないときに「通信そのもの」を中継する

STUNは住所確認。

TURNは中継。

この理解でかなり整理しやすくなります。

例えるなら「住所確認」と「宅配中継所」

STUNとTURNは、宅配に例えるとわかりやすいです。

STUNは住所確認

STUNは、

自分の荷物を届けてもらうために、外から見える住所を確認する

ようなものです。

自分では「マンションの部屋番号」しか知らないけれど、外部から見たときにどの入口・どの受付番号に見えているかを確認するイメージです。

STUNサーバー：
「外から見ると、あなたはこの住所に見えています」

TURNは中継所

TURNは、

相手の家に直接届けられないので、いったん中継所を経由して届ける

ようなものです。

自分 → 中継所 → 相手

つまり、STUNは「確認」、TURNは「運搬」です。

NAT越えではなぜSTUNが必要なのか？

NATの内側にいる端末は、自分のローカルIPアドレスしか知らないことがあります。

たとえば、端末Aが自分のIPアドレスを次のように認識していたとします。

192.168.1.10

しかし、このIPアドレスは家庭内ネットワークでしか使えません。

端末Bに対して、

192.168.1.10 に送ってください

と伝えても、インターネット越しには届きません。

そこでSTUNサーバーに問い合わせます。

端末A → STUNサーバー

STUNサーバーは、外から見た端末Aのアドレスを返します。

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

この情報を端末Bに伝えることで、端末Bは端末Aへの直接通信を試せます。

NAT越えではなぜTURNが必要なのか？

STUNで外から見たアドレスがわかっても、必ず直接通信できるとは限りません。

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

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

このような環境では、外から見た住所がわかっても、相手からの通信が届かないことがあります。

端末A ←→ 端末B
直接通信に失敗

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

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

TURNサーバーが通信を中継することで、端末同士が直接つながれなくても通信できます。

STUNだけでは不十分な理由

STUNは非常に便利ですが、万能ではありません。

STUNができるのは、基本的に次のことです。

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

しかし、STUNは通信を中継しません。

つまり、

外から見た住所がわかる

ことと、

その住所に通信が届く

ことは別です。

たとえば、建物の住所がわかっていても、入口が封鎖されていたら中に入れません。

NATやファイアウォールが厳しい場合、外部アドレスがわかっても通信できないことがあります。

その場合にTURNが必要になります。

TURNはなぜコストが高いのか？

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

たとえば、ビデオ通話でTURNが使われると、次のようなデータがTURNサーバーを通ります。

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

つまり、TURNサーバーは大量の通信を処理する必要があります。

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

このため、TURNでは次のコストが発生します。

サーバー費用
ネットワーク帯域費用
CPU・メモリ負荷
監視・運用コスト
冗長化のコスト
地理的配置のコスト

特にビデオ通話では映像データが大きいため、TURNの帯域コストは無視できません。

そのため、実務ではTURNを最初から使うのではなく、直接通信が無理な場合のフォールバックとして使うことが多いです。

STUNとTURNはどちらが重要？

STUNとTURNは、どちらか一方だけが重要というより、役割が違います。

STUNが重要な理由

STUNは、直接通信できる可能性を探るために重要です。

STUNによって外部アドレスを取得できれば、端末同士が直接通信できる可能性があります。

直接通信できれば、TURNサーバーを経由しなくて済みます。

そのため、通信コストや遅延を抑えられます。

TURNが重要な理由

TURNは、直接通信できない場合の保険として重要です。

STUNだけだと、ネットワーク環境によっては通信できないユーザーが出ます。

TURNサーバーを用意しておくと、直接通信に失敗しても中継通信に切り替えられます。

つまり、TURNは接続成功率を上げるために重要です。

WebRTCではSTUNとTURNをどう使うのか？

WebRTCでは、STUNとTURNはICEという仕組みの中で使われます。

ICEとは、

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

です。

ICEでは、複数の通信候補を集めます。

候補	説明
host candidate	ローカルIPアドレスを使う候補
server reflexive candidate	STUNで取得した外部アドレス
relay candidate	TURNサーバー経由の候補

WebRTCでは、まず使える候補を集めます。

1. 自分のローカルIPを候補にする
2. STUNで外部アドレスを取得する
3. TURNで中継用アドレスを取得する
4. 相手と候補を交換する
5. 接続できる経路を試す
6. 最適な経路を使う

この流れの中で、STUNとTURNはそれぞれ別の役割を持ちます。

WebRTCの設定例

WebRTCでは、次のようにSTUNサーバーと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サーバー経由の候補が使われます。

STUNとTURNの通信イメージ

STUNとTURNの違いを、通信の流れで比較してみます。

STUNの場合

端末A → STUNサーバー
STUNサーバー → 端末A

STUNサーバー：
「あなたは外から見ると 203.0.113.10:62001 です」

STUNサーバーは、住所確認だけを行います。

その後の通信は、可能であれば端末同士で直接行います。

端末A ←→ 端末B

TURNの場合

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

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

音声や映像などのデータもTURNサーバーを通ります。

どちらを使うべきか？

基本的には、STUNとTURNは両方使うことが多いです。

ただし、役割としては次のように考えます。

まずSTUNで直接通信を試す
↓
直接通信できれば、そのままP2P通信
↓
直接通信できなければ、TURNで中継通信

実務では、次のような流れになります。

低コスト・低遅延：
STUNを使って直接通信を試す

高い接続成功率：
TURNをフォールバックとして用意する

つまり、STUNはコストと遅延を抑えるために重要で、TURNは接続失敗を減らすために重要です。

STUNだけでよいケース

STUNだけで十分なケースもあります。

たとえば、次のような場合です。

検証用途
社内実験
小規模なデモ
失敗しても問題ない通信
利用者のネットワーク環境がある程度限定されている

ただし、本番サービスでは、STUNだけに頼ると一部のユーザーが接続できない可能性があります。

特に一般ユーザー向けのWebRTCサービスでは、TURNも用意した方が安全です。

TURNが必要になりやすいケース

TURNが必要になりやすいのは、接続成功率を重視するサービスです。

たとえば、次のようなケースです。

ビデオ通話サービス
音声通話サービス
オンライン面談
遠隔診療
オンライン授業
カスタマーサポート通話
ブラウザ上のP2P通信
企業ネットワークの利用者が多いサービス

これらのサービスでは、一部のユーザーだけ接続できない状態でも大きな問題になります。

そのため、TURNサーバーを用意して、直接通信できない場合でも通信できるようにしておくことが重要です。

STUNとTURNのよくある誤解

STUNを使えば必ずNAT越えできる

これは誤解です。

STUNは外部アドレスを知るための仕組みです。

外部アドレスがわかっても、NATやファイアウォールの設定によっては通信できないことがあります。

TURNはSTUNの上位互換である

これも誤解です。

TURNはSTUNの上位互換ではありません。

役割が違います。

STUN：住所確認
TURN：通信中継

このように分けて理解する必要があります。

TURNを使えば常に高品質になる

TURNを使うと接続成功率は上がりやすいですが、通信品質が常に良くなるわけではありません。

TURNサーバーを経由するため、直接通信より遅延が増えることがあります。

また、TURNサーバーの場所や性能によって通信品質が変わります。

STUN/TURNだけでWebRTCが完結する

STUN/TURNは重要ですが、WebRTC全体の一部です。

実際には、次のような仕組みも関係します。

シグナリング
SDP
ICE
DTLS
SRTP
コーデック
ネットワーク品質制御

STUN/TURNは、主に接続経路を見つけるための要素です。

開発者向けに押さえるポイント

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

STUNは外部アドレス確認用
TURNは中継通信用
STUNだけでは本番運用で失敗するユーザーが出る可能性がある
TURNは接続成功率を上げるが、通信コストがかかる
TURNサーバーには認証を設定する
TURNサーバーはユーザーに近いリージョンに置く
UDPが使えない環境向けにTURN over TCP/TLSも検討する
ICE candidateの種類を理解するとトラブルシュートしやすい
「一部の環境だけつながらない」はNAT越え周りを疑う

特に本番環境では、STUNだけで済ませるのではなく、TURNも含めた設計を考えることが重要です。

STUNとTURNを一言でまとめると

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

STUN：
外から見た自分のIPアドレスとポート番号を教えてくれる仕組み

TURN：
直接通信できないときに通信を中継してくれる仕組み

さらに短く言うなら、

STUNは住所確認
TURNは中継

です。

まとめ

STUNとTURNは、どちらもNAT越えで使われる重要な技術です。

しかし、役割は大きく違います。

STUNは、外から見たIPアドレスとポート番号を調べるために使われます。

TURNは、直接通信できない場合に、通信を中継するために使われます。

WebRTCでは、ICEという仕組みの中でSTUNとTURNが使われ、複数の通信経路から最適なものを選びます。

基本的な流れは次のとおりです。

STUNで外部アドレスを確認する
↓
端末同士で直接通信を試す
↓
直接通信できれば、そのまま通信する
↓
直接通信できなければ、TURNで中継する

初心者のうちは、まず次の理解で十分です。

STUNは「外から見た自分の住所」を調べる。TURNは「直接届かない通信」を中継する。

この違いがわかると、NAT越え、WebRTC、P2P通信、ビデオ通話の仕組みがかなり理解しやすくなります。

daigoro

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