「WebRTCが動くか」だけでなく — なぜ動かないのか、そしてどうすればよいかまで分かります。
ファイルはブラウザから送信されません — 処理はすべてローカルで行われます。
ICE 候補を収集中…
2 個の STUN サーバーに問い合わせ中…（最大 5 秒）
パブリック IPSTUN の応答を待機中…
IPv6候補を待機中…
NAT タイプSTUN マッピングを比較中…
UDPSTUN の応答を待機中…
接続候補収集を待機中…
Ping RTTDataChannel の往復時間を測定中…
スループット接続を待機中…
正確な基準: これはマシン固有の WebRTC スタック（ループバック基準 — SCTP、DTLS、ブラウザの送信パス）を測定するものであり、インターネット回線速度ではありません。実際の速度テストにはリモートテストサーバーが必要です。
IP は上記で表示しない限りマスクされたままです。
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サーバーが実際にどれだけの帯域を提供できるかを測定します — リレー経由の映像がきれいに見えるかを決める数値であり、ほとんどのツールが測定しないものです。
2ブラウザ間の接続が確立すれば、診断以外にも使えます：暗号化されたDataChannelを通じて、任意のサイズのファイルをブラウザからブラウザへ直接送信できます — バックプレッシャー付きのチャンク転送で、両側にライブの進捗と速度が表示され、データをサーバー（当サイトのものも、他の誰のものも）が保持することは一切ありません。また、接続ブロブをデバイス間でコピペする代わりにQRコードとして表示でき — 長いofferは自動循環する短いフレーム列に分割されます — BarcodeDetector APIをサポートするブラウザでは内蔵のカメラスキャナーで読み取れます。
すべてブラウザ内で動作します。接続テストはあなたが選んだSTUN/TURNサーバーとのみ通信し、ネットワークに関する情報が当サイトに送信されることはありません。
WebRTCが試せるアドレスです：host = ローカルインターフェースのアドレス（モダンブラウザではmDNSで難読化されます）、srflx = STUNサーバーから見たあなたの公開アドレス（その存在はNATを越えられることを意味します）、relay = 直接経路が失敗したときにトラフィックを転送するTURNサーバー上のアドレスです。健全な構成ではhost + srflxが表示され、relayはTURNを設定したときにのみ現れます。
対称型NATは、通信する宛先ごとに異なる公開ポートを割り当てるため、STUNサーバーが観測したポートは実際のピアには役立ちません — ホールパンチングが失敗します。ツールは2つのSTUNサーバーからのマッピングを比較してこれを検出します：ポートが異なれば対称型です。対称型NAT同士のピアは、事実上ほぼ常にTURNリレーが必要です。
検証機能は原因を切り分けます：401 / 認証情報の失敗（ユーザー名・パスワードの誤り、または期限切れの時間制限付き認証情報）、アロケーションの失敗（サーバーに到達できない — ファイアウォールがポートをブロック、またはポート/トランスポートの誤り）、あるいはホスト名のDNS失敗です。UDP、TCP、TLSを個別にテストしてください — 企業ネットワークは443番のturns:のみを許可することがよくあります。
いいえ — そしてページはそれを正直に述べています。スループットの数値はWebRTCの経路を測定します：お使いのマシンのWebRTCスタック（ループバック）、お使いのTURNサーバーの容量（relay強制）、または特定のピアツーピアリンクです。一般的なダウンロード/アップロード速度テストには専用のテストサーバーが必要で、サーバーレスのサイトが誠実に提供できるものではありません。
シグナリングサーバーを一切使わずに、2台のデバイス間で実際のWebRTC接続を構築します：一方がoffer（オファー）を圧縮テキストのブロブとして作成し、それを任意のメッセンジャーで送り、もう一方がanswer（アンサー）を貼り返すと、接続が確立します — そしてライブ統計が、直接接続かリレー経由か、往復時間、ビットレート、パケットロスを表示します。WebRTCシグナリングの仕組みのデモであると同時に、2つの実ネットワーク間の本物の接続性テストでもあります。
ファイルはWebRTCの暗号化されたDataChannel（DTLS）を通じてブラウザからブラウザへ送られます — アップロードの工程がなく、漏洩したり期限切れになったりするサーバー上のコピーも存在しません。直接接続なら、データは2台のマシン間の経路から一切出ません（リレー経由の接続はお使いのTURNサーバーを通りますが、暗号化されたままです）。ファイルは64 KBのチャンクでバックプレッシャー付きで送信されるため、サイズの上限は転送自体ではなく受信側ブラウザのメモリ（保存前にそこでファイルが組み立てられます）で決まります — 数百メガバイトは日常的に扱えます。
圧縮されたofferブロブは約1,900文字です — 技術的には1つのQRコードに収まりますが、それほど密度の高いコードは画面からのスキャンに失敗しがちです。そのため長いブロブは、パート表示付きで自動的に循環する、読み取りやすい短いコードの列として表示されます。スキャナーはフレームを任意の順序で収集してブロブを再構築します。読み取りにはブラウザネイティブのBarcodeDetector API（ChromeとEdge）を使います — 未対応のブラウザでは、スマートフォンのカメラアプリでスキャンするか、常に機能するコピペにフォールバックしてください。