高度なIPアドレス・DNS漏洩テスト：ネットワークセキュリティ確認

多くのユーザーは「住宅用プロキシ」を購入すれば一般の家庭用ユーザーとして完全に偽装できると考えています。しかし、最新のリスク検知エンジンはGeoIPデータベース（IP2LocationやMaxMind等）の静的な属性タグだけに依存していません。出口IPが住宅用ISP名義であっても、転送ゲートウェイはほぼクラウド上のLinuxサーバーで動作しており、明確なクロスレイヤーの矛盾が生じます：第一にトランスポート層のTCPスタック署名：出口サーバーは最初のSYNハンドシェイク時にWindowsやApple固有の順序ではなく、Linux標準のオプション順序（MSS, SACK_PERM, TS, NOP, WS）を送信します。第二にパスMTUの不一致：家庭用PPPoEは通常MTU 1492（モバイル回線は1400〜1430）ですが、データセンターの物理イーサネットは標準で1500（MSS=1460）です。リスク判定システムが住宅用IPでありながらデータセンターMTUとLinux TCPスタックを検知すると、自動化プロキシと判定します。

💡 お使いの接続のTCP終端位置を確認するには、プロキシ匿名性テストをご利用ください。

IPアドレス自体には物理的な位置情報が直接埋め込まれているわけではありません。表示される位置情報は各サイトが採用する商用GeoIPデータベースとその更新周期に依存します：第一にデータソースと推計モデルの違い：MaxMind、IP2Location、DB-IPなどのプロバイダーはBGP広報経路、Whois登録情報、ネットワーク遅延プローブをそれぞれ異なる重み付けで解析し、更新間隔も数日から数ヶ月と様々です。第二にAnycastルーティングとCDNエッジ配信：Cloudflareなどは世界中数百箇所のデータセンターから同一IP帯を広報しており、最も近いエッジ拠点へ自動ルーティングされます。第三に国境を越えたIP帯の再割り当て：ホスティング業者が他国サーバーへIPを移管した際、古いデータベースでは過去の位置が表示されます。当サイトでは複数DBの照合と光速RTT遅延による三辺測量を組み合わせて物理位置を検証しています。

IP不正スコア（リスクスコア）とは、その接続がボット、不正アクセス、または偽装通信である可能性をリスクエンジンが数値化（通常0〜100）した指標です。主な評価要素には以下が含まれます：第一に過去のレピュテーション履歴とブラックリスト：直近24〜72時間以内にクレデンシャルスタッフィング、過剰スクレイピング、スパム送信、ポートスキャン等に関与した履歴があるか。第二にASN種別とインフラ属性：データセンター（ホスティング）や公開プロキシ/VPN帯は家庭用固定回線や携帯キャリアよりも基準リスクが高くなります。第三に複数エンドポイントおよびプロトコルの一貫性：同一セッション内でのIPv4/IPv6出口分離、DNSサーバーの地理的乖離、WebRTCによるローカルIP露出などが存在するかです。

💡 リスクスコア上昇の原因となる経路漏洩を特定するには、スプリットトンネルテストをご活用ください。

VPNやプロキシを有効にしていても、サイドチャネルを通じて本来の身元が外部へ漏洩することがあります：第一にDNS漏洩：ブラウザがドメインを解決する際、プロキシクライアントがOSレベルのDNS要求を完全に捕捉していないと、平文のDNS要求がローカルISPのDNSサーバーへ直接送信され、閲覧先ドメインと実位置が露呈します。第二にWebRTC漏洩：WebRTCはリアルタイム通信用ブラウザ技術であり、P2P接続確立時にHTTP/SOCKSプロキシを迂回してUDP経由で直接STUNパケットを送信するため、端末の真のローカルおよびパブリックIPが露出します。当サイトのホームページではDNS出口とWebRTCの状態をリアルタイムに診断できます。

💡 ハードウェアレベルのCanvas、Audio、WebRTC漏洩を検証するには、ブラウザ指紋テストをご覧ください。

ホームページのネットワークスタックパネルでは、関連する3つのプローブを並行して実行しています。1つはAレコードのみを持つドメイン（iptestv4.myipdns.com）、1つはAAAAレコードのみを持つドメイン（iptestv6.myipdns.com）、3つ目はAとAAAAの両方のファミリを持つデュアルスタックドメインです。最初の2つは強制プローブです。それぞれのホスト名は1つのアドレスファミリにしか解決されないため、端末側に選択の余地がなく、IPv4とIPv6におけるそれぞれの真の出口IPを個別に取得できます。3つ目は強制せず、逆にシステム自身がどちらのファミリを選択したかを観察します。これが「優先プロトコル」欄であり、OSとブラウザのアドレス選択ポリシー（Happy Eyeballs、RFC 8305：デュアルスタック到達時はIPv6を優先試行し、失敗時のみIPv4にフォールバック）によって決定され、当サイトが指定するものではありません。3つを並べて確認することが不可欠なのは、多くのプロキシやVPNクライアントがIPv4しか中継しないためです。IPv4出口がプロキシのASNにある一方でIPv6出口が家庭用ISPのままであり、優先プロトコルがIPv6を示している場合、デュアルスタック対応サイトにアクセスする際、トラフィックの大半はトンネルをまったく通過していません。これは「VPNを有効にしているのに実身元が露出している」典型例であり、エラーも一切表示されません。

⚠ 当サイトはお客様の両ファミリの出口が異なるネットワークに分かれているか否かを提示するのみであり、プロキシソフトウェアの設定方法を指示することはできません。逆も同様であり、IPv6欄が利用不可と表示されていても安全性を意味するものではありません。単にお使いの回線にIPv6がない場合もあれば、プロキシがIPv6を完全に無効化している場合もあります（後者は多くの場合において適切な挙動です）。

当サイトはお客様の端末内のシステム設定を直接読み取ることはしません。ブラウザからは技術的にアクセスできず、端末内のDNS設定を読み取れると主張するウェブページはすべて推測に過ぎません。実際の手法は逆向きに測定することです。当サイトは自前の権威DNSサーバーを運用しており、測定ごとに一時的なランダムサブドメイン（例：k3f9x2ab.leakv4.myipdns.com）を生成してブラウザに名前解決させます。このドメイン名は世界中で一度しか現れず、どのキャッシュにも存在しないため、再帰的名前解決の経路は必ず当サイトの権威サーバーまで直接問い合わせを行わなければならず、当サイトは誰が問い合わせに来たかを記録してページに返します。したがって「DNS出口」欄に表示されるのは、再帰リゾルバが実際に外部インターネットへ抜けた際のアドレスであり、システム設定に入力したアドレスではありません。8.8.8.8を設定した場合でも、実際に問い合わせに来るのはそのクラスタ内の特定の送信ノードであり、他国のアドレスであることも珍しくありません。大手パブリックDNSはAnycastとクラスタリングを採用しているため、1回の測定で複数の異なるアドレスが表示されることも極めて正常です。真の判定基準はアドレスの一致ではなく、この出口がご自身の契約プロバイダ（ISP）のネットワーク内にあり、通信IPの出口がプロキシ上にある場合、DNSがトンネルを通過していないことを示します。

⚠ この手法で確認できるのは当サイトの権威サーバー自身に誰が問い合わせたかのみであり、お客様が検索した他のドメインを把握することは一切不可能です。また既知の限界として、プロキシがDNSクエリも完全に中継している場合、表示されるのはプロキシ事業者のリゾルバとなり、ローカルISPへの漏洩がないことは確認できますが、DNSログ自体はプロキシ事業者から閲覧可能な状態となります。これは別の考慮事項であり、当サイトで判定できる範囲外です。

WebRTCを通じて複数のSTUNサーバーに個別プローブを送信し、返却されたsrflx候補、すなわちNAT変換を経た後に相手サーバーから実際に観測されたパブリックIPとポートを収集します。判定基準は1つだけです。候補をマッピングされたパブリックIPごとにグループ化し、同一IPの下で2つ以上の異なるポートが出現した場合は対称型NATと判定し（送信先が変わるごとに異なる外部ポートを割り当て）、それ以外はコーン型NATと判定します（同一の内部ポートに対して常に同一の外部ポートを割り当て）。ポート比較の前にグループ化を行うのは意図的な設計です。分流プロキシ環境では異なるSTUNサーバーが異なる出口を経由することがあり、ポート番号が不一致となりますが、これはNATの性質ではなく通信経路の違いに起因するため、グループ化を行わないとすべて対称型と誤認されてしまいます。「不明」と表示される要因は2つあります。第1に、4秒のタイムアウト内にsrflx候補が1件も受信できなかった場合（ブラウザでWebRTCが無効、拡張機能による遮断、またはUDP送信の規制）。第2に、候補が1件のみ受信され、そのパブリックIPが当サイトへのアクセスIPと一致しない場合です。ブラウザ側の重複排除か通信の分流かを判別できないため、安全側に倒して不明と表示します。

⚠ 誠実な説明：当サイトはコーン型と対称型の2分類のみを区別し、完全コーン／制限コーン／ポート制限コーンの細分化は行いません。RFC 3489の4分類モデルは送信元ポートと宛先アドレスの組み合わせを細かく制御しながら反復プローブを行う必要がありますが、ブラウザ内のWebRTCにはそうした制御権限が存在しません。ウェブツールが4分類のいずれかを報告している場合、大半はこの2つの判定結果にラベルを付け替えているに過ぎません。

ホームページでの1回の測定では、それぞれ異なるドメインに対して並行して6つのプローブを発行します。IPv4専用が1つ、IPv6専用が1つ、IPv4とIPv6それぞれでプロトコルスタック指紋を収集するものが2つ、システムがどちらのファミリを優先するかを観測するデュアルスタックドメイン宛てが1つ、そしてHTTP/1.1を強制する専用プローブが1つです。これらは重複リクエストではなく、プローブごとに収集する対象が完全に異なります。別々に送信することが不可欠な理由は、当サイトの診断がクロスレイヤーの照合に基づいているためです。同一端末であってもIPv4とIPv6、HTTP/1.1とHTTP/2（および利用可能な場合のHTTP/3）の間で露出するプロトコルスタックの特徴はそれぞれ異なり、個別に測定して初めて相互比較が可能になります。さらに、並行処理は単に速度のためではありません。もし順次送信した場合、途中でネットワークの切り替えやプロキシの再接続が発生すると、実際には存在しないハイブリッドな架空端末のデータが生成されてしまいます。並行送信により、6つのプローブが同一瞬間の同一ネットワーク経路を観測することが担保されます。そのうちHTTP/1.1プローブは意図的に1回のみリクエストを送信します。HTTP/1.1にはHPACK動的テーブルが存在しないため、複数回送信しても追加の情報は得られず、1回に限定することで取得ヘッダーが今回の測定レコードと厳密に1対1対応することを保証します。

⚠ その代償として、初回読み込み時に複数のサブドメインへ同時に接続するため、広告ブロッカーや厳格なプライバシー拡張機能によって一部が遮断されることがあります。その場合、該当欄にはグレーのドットが表示されて不明状態で停止しますが、他のプローブの結果を流用して見かけ上の完全な数値を補完することは決してありません。