ByteScope

WebRTC Connection Tester

「WebRTCが動くか」だけでなく — なぜ動かないのか、そしてどうすればよいかまで分かります。

ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。

Gathering ICE candidates…

ICE candidates

Asking 2 STUN servers… (up to 5 s)

Network checks

Public IPWaiting for STUN…

IPv6Waiting for candidates…

NAT typeComparing STUN mappings…

UDPWaiting for STUN…

Loopback connection test

ConnectionWaiting for candidate gathering…

Ping RTTMeasuring DataChannel round trips…

ThroughputWaiting for the connection…

Honest label: this measures your machine's WebRTC stack (loopback baseline — SCTP, DTLS and the browser's send path), not your internet speed. A real speed test needs remote test servers, which this site doesn't have.

Report

IPs stay masked unless revealed above.

WebRTC local diagnosis — bytescope.dev/webrtc-test

Candidates: (gathering…)

このツールについて

ローカル診断はページを開いた瞬間に実行されます：複数の公開STUNサーバーからICE候補が収集され、host・server-reflexive・relayに分類され、それぞれにその存在が何を意味するかの1行説明が付きます。2つの異なるSTUNサーバーがマッピングした公開ポートを比較することで、ツールはNATタイプを検出します：コーンNATはP2Pに適していますが、対称型（symmetric）NATは直接接続がしばしば失敗しTURNが必要であることを意味します — WebRTCデバッグで最も役立つ一文を、平易に述べたものです。server-reflexive候補がまったくない場合は、ネットワークがUDPをブロックしている（企業ネットワークで一般的）ことを意味し、診断はそう告げます。続いてループバックテストが、ページ内で実際に2つのpeer connectionを接続し、実際のDataChannelのスループットとレイテンシを測定します。

TURN検証機能は、WebRTC開発者が探し続けている機能です：turn:/turns:のURLと認証情報を入力すると、ツールはrelayのみの接続を強制し、あなたのTURNサーバーが実際にアロケーションを行うかを証明します — UDP、TCP、TLSの各トランスポートを個別にテストし、失敗の原因を診断します（認証情報の誤りか、ファイアウォールか、DNSか）。relay強制のスループットテストは、あなたのTURNサーバーが実際にどれだけの帯域を提供できるかを測定します — リレー経由の映像がきれいに見えるかを決める数値であり、ほとんどのツールが測定しないものです。

すべてブラウザ内で動作します。接続テストはあなたが選んだSTUN/TURNサーバーとのみ通信し、あなたのネットワークに関する情報が私たちに送信されることはありません。

よくある質問

host / srflx / relay の各候補は何を意味しますか？
WebRTCが試せるアドレスです：host = ローカルインターフェースのアドレス（モダンブラウザではmDNSで難読化されます）、srflx = STUNサーバーから見たあなたの公開アドレス（その存在はNATを越えられることを意味します）、relay = 直接経路が失敗したときにトラフィックを転送するTURNサーバー上のアドレスです。健全な構成ではhost + srflxが表示され、relayはTURNを設定したときにのみ現れます。
対称型（symmetric）NATとは何で、なぜP2Pを壊すのですか？
対称型NATは、通信する宛先ごとに異なる公開ポートを割り当てるため、STUNサーバーが観測したポートは実際のピアには役立ちません — ホールパンチングが失敗します。ツールは2つのSTUNサーバーからのマッピングを比較してこれを検出します：ポートが異なれば対称型です。対称型NAT同士のピアは、事実上ほぼ常にTURNリレーが必要です。
TURNサーバーがrelay候補を返さないのはなぜですか？
検証機能は原因を切り分けます：401 / 認証情報の失敗（ユーザー名・パスワードの誤り、または期限切れの時間制限付き認証情報）、アロケーションの失敗（サーバーに到達できない — ファイアウォールがポートをブロック、またはポート/トランスポートの誤り）、あるいはホスト名のDNS失敗です。UDP、TCP、TLSを個別にテストしてください — 企業ネットワークは443番のturns:のみを許可することがよくあります。
これはインターネット接続の速度テストですか？
いいえ — そしてページはそれを正直に述べています。スループットの数値はWebRTCの経路を測定します：あなたのマシンのWebRTCスタック（ループバック）、あなたのTURNサーバーの容量（relay強制）、または特定のピアツーピアリンクです。一般的なダウンロード/アップロード速度テストには専用のテストサーバーが必要で、サーバーレスのサイトが誠実に提供できるものではありません。
2ブラウザ間テストは何をしますか？
シグナリングサーバーを一切使わずに、2台のデバイス間で実際のWebRTC接続を構築します：一方がoffer（オファー）を圧縮テキストのブロブとして作成し、それを任意のメッセンジャーで送り、もう一方がanswer（アンサー）を貼り返すと、接続が確立します — そしてライブ統計が、直接接続かリレー経由か、往復時間、ビットレート、パケットロスを表示します。WebRTCシグナリングの仕組みのデモであると同時に、2つの実ネットワーク間の本物の接続性テストでもあります。