プロキシ匿名性テスト:VPNの漏洩とプライバシー確認

匿名レベル

プライバシー・セキュリティ診断

プロキシ匿名性診断

ネットワーク接続特性、TLS/TCP フィンガープリント、プライバシー露出リスクを詳細に分析します。

TLS / TCP 詳細フィンガープリント分析

Client Hello、JA4 フィンガープリント、TCP ウィンドウパラメータを解析し、プロキシツールや難読化を特定します。

多国間 IP ドリフト・分流検証

複数プローブの送信元 IP を分析し、地理的ドリフト、プロキシの負荷分散、ルーティングリークを検出します。

WebRTC & DNS プライバシーリーク保護

WebRTC によるリアル IP 漏洩や DNS 汚染をリアルタイムで検出し、プロキシの匿名性レベルを評価します。

ネットワークプロトコルスタック深度診断

TCP SYN オプション、TLS JA3/JA4 指紋、HTTP/2/3 パラメータを直結パケットで解析し、プロキシ偽装の矛盾を暴きます。

ネットワークスタック指紋を見る →

匿名性スコアの判定根拠について

このテストがどのように結論を導き出しているのか、各シグナルが実際に何を証明しているのか、そして何を改善できるのかを解説します。

この2つの情報は異なるレイヤーから取得されており、ブラウザ側で偽装できるのは一方のみだからです。User-Agentは単なる文字列であり、ブラウザや拡張機能で容易に書き換えられます。しかし、接続を確立するTCP SYNパケットはOSカーネルによって生成され、オプション順序、ウィンドウ拡大係数、タイムスタンプの挙動はLinux、Windows、Appleシステム間で異なります。Apple製デバイスはMSS, NOP, WS, NOP, NOP, TS, SACK_PERM, EOLの順序で送信し、LinuxはMSS, SACK_PERM, TS, NOP, WSの順で送信します。ブラウザがiOSと申告しているにもかかわらずカーネル署名がLinuxである場合、当サーバーに届いたTCP接続はお使いのスマートフォンから直接開かれたものではありません。プロキシサーバーやCDNエッジノードなどの別マシンによって再構築された接続です。

💡 デバイスのハードウェアやCanvas整合性を確認するには、ブラウザ指紋テストをご利用ください。

SYNパケットで通知される最大セグメント長(MSS)からパスMTUを逆算できます(IPv4ではMSS+40バイト、IPv6ではMSS+60バイト)。回線種別ごとに特徴的な値が存在します:PPPoE経由の家庭用ブロードバンドは1492、モバイルキャリアは通常1400〜1430、WireGuardトンネルはデフォルトで1420、そしてデータセンター内の物理イーサネット接続は1500となります。したがって、スマートフォンが1500を報告することは明らかな矛盾です(この値を提供するモバイル回線は存在しません)。一方、デスクトップ端末ではオフィスLANやPPPoE不要の光回線でも1500に達するため判定の証拠力は低く、重み付けも大幅に下げています。

💡 プロキシの経路異常が疑われる場合は、スプリットトンネルテストで複数エンドポイントを検証してください。

IPアドレスのレピュテーション(評価)とプロトコルの挙動は完全に独立しているからです。住宅用IPを購入しても、データベース上の属性が変わるだけで、出口マシンがパケットを構築する方法自体は変わりません。出口がLinuxサーバーである場合、依然としてLinux固有のTCPオプションを送信し、データセンターMTUを通知し、自身の指紋でTLSハンドシェイクを終端します。IPリストのみを参照するリスク判定システムにはクリーンな住宅用IPに見えますが、プロトコルスタックを検証するシステムにはサーバーであることが看破されます。これは最も一般的な盲点であり、当テストが「プロトコルから実証された証拠」と「単なるアドレス評価に基づく証拠」を明確に分けて表示する理由です。

💡 詳細なASN情報やリスクスコアはMyIPDNSホームページでご確認いただけます。

プロトコル層で矛盾が検出されず、アドレスデータベースの情報のみに基づいて判定していることを意味します。これは、お使いの端末とプロキシサーバーが同じOSファミリーを使用している場合に発生します。LinuxデスクトップからLinuxプロキシを経由すると一貫したLinux署名が生成されるため、クロスレイヤー分析で比較対象がなくなります。当テストではこの判定の限界を隠さず正直に明記しています。「protocol」と表記された証拠は実際のパケットから実証されたものですが、「reputation」と表記されたものはそうではありません。レピュテーションのみに依存する信頼度の低い判定は、決定的な証拠ではなく参考情報として捉えてください。

💡 開発者の方は無料IP APIから構造化データを取得できます。

一部は設定の問題であり、一部は物理的な事実です。データセンターMTUは、サーバー側のトンネルインターフェースMTUを1420〜1450の間に設定することで一般回線のトンネルに見せかけることができます。TCPタイムスタンプのオフセット共有は、出口ホストのカーネルを「アドレスペアごとにハッシュする」方式から「接続ごとにランダムに再生成する」方式へ更新することで解消されます。一方、出口OSとブラウザ申告OSの不一致はクライアント側の設定では一切修正できません。出口ホストで同一OSファミリーを動かすか、出口側でSYNオプションを書き換えるしかありません。これらはブラウザ内部から生成されるものではないため、いかなるブラウザ拡張機能でも変更できません。

💡 設定変更後はホームページに戻り、再診断を実行してください。

いいえ、特定できません。本テストで説明されている内容はすべて当プローブに実際に到達したパケット(出口アドレスのみを保持)から推測されたものです。接続が途中で再構築されたことや再構築したマシンの特性を把握することはできますが、最初にセッションを開始した端末の実IPアドレスはその通信内に含まれておらず、復元することも不可能です。なお、本サイトのWebRTCおよびDNS漏洩テストでお使いのブラウザやリゾルバからローカルアドレスが漏洩していると判定された場合は別途警告が表示されますが、これは別系統の仕組みによるものです。

💡 ルーティングやDNSの乖離診断は経路漏洩診断をご覧ください。