VPN接続の確認に、接続ボタンだけを見るのは不十分です。より確実に確認するには、まず出口IPを比較し、次にDNSの解決経路を調べ、最後に実際に使うアプリで検証します。それぞれ確認できる内容は異なり、ブラウザーで問題がなくても、端末全体の通信がVPNを経由しているとは限りません。
まず、どの通信をVPN経由にしたいか確認する
「有効」の判断基準は、実現したい使い方によって異なります。ルールで通信を振り分けている場合、国内サイトは直接接続し、指定した海外サイトはプロキシ経由にする設定が意図どおりの動作かもしれません。対応する通信をすべてVPN経由にしたい場合は、地域の選択だけでなく、通信の適用範囲を確認しましょう。先に目的を明確にすると、正常な振り分けと設定漏れを区別できます。
一般的なクライアントでは、システムプロキシを設定する方法のほか、仮想ネットワークインターフェースやTUNモードを使う方法があります。システムプロキシは、システムのプロキシ設定に従うアプリに接続先を提供するもので、すべてのプログラムに利用を強制するわけではありません。TUNモードは仮想ネットワークインターフェースを通じて通信を取り込みますが、実際の適用範囲はルーティング、プロセスの除外、プロトコルの対応状況、クライアントの設定によって変わります。「グローバル」もプロキシルール全体を指す場合があり、端末上のすべての通信を取り込むとは限りません。
接続中の表示は、クライアントが何らかの接続状態になったことを示します。ノードの遅延テストは、特定の確認リクエストに応答があったことを示すものです。どちらも、対象アプリの通信が想定した出口を経由した証明にはなりません。
出口IPを比較する:接続前の状態を記録する
出口IPとは、ウェブサイト側から見えるリクエスト元のグローバルIPアドレスです。自分のIPアドレスのページで確認できますが、結果が示すのはそのページへのリクエスト経路だけです。確認先のドメインが直接接続のルールに該当すると、ほかのサイトがプロキシ経由でも、確認ページには普段の出口IPが表示されることがあります。
- クライアントを切断し、基準値を記録します。使用予定のブラウザーでグローバルIPアドレスを調べ、アドレス、表示されたネットワークの事業者と地域を控えます。テスト中は同じネットワークに接続し、ネットワークの切り替えによる影響を避けてください。
- 接続先のノードに接続し、もう一度確認します。結果を更新します。ページがキャッシュされている場合は、いったん閉じてから開き直してください。以前読み込んだタブに表示されている古い情報だけで判断しないようにしましょう。
- 適用されたルールを確認します。クライアントの接続一覧やログを見て、確認先のドメインがプロキシ経由か直接接続か、どのノードが実際に選ばれているかを確認します。
- 実際に使うアプリでも確認します。ブラウザーのIPアドレスが変わっていても、利用予定のアプリで確認が必要です。ブラウザー拡張機能によるプロキシ設定はブラウザーだけに適用されることがあり、ほかのプログラムの通信まではわかりません。
IPアドレスが変われば、リクエストの経路が変わった可能性はありますが、選択したノードを経由した証拠にはなりません。接続ネットワークの切り替え、上流の出口IPのローテーション、別のプロキシでもアドレスは変わることがあります。反対に、地域名が変わらなくても接続に失敗したとは限りません。位置情報データベースの更新が遅れていたり、複数のノードが同じ出口を共有していたりする場合もあります。IPアドレス、ネットワークの事業者、クライアントの記録を合わせて確認しましょう。
DNSを確認する:地域名ではなく名前解決の経路を見る
DNSは、ドメイン名を接続可能なアドレスに変換します。DNSリークとは一般に、名前解決のリクエストが想定した保護経路を通らず、ローカルネットワークや意図しないDNSサービスに送られる状態を指します。判断のポイントは実際の名前解決経路が設定どおりかどうかであり、検査結果に特定の国名が表示されるかどうかではありません。
ブラウザーのDNS検査ページは、通常、一時的なドメイン名の問い合わせを発生させ、検査側から見えた再帰DNSサーバーの出口を表示します。そこに表示されるアドレスが、端末に直接設定されているDNSアドレスとは限りません。パブリックDNSサービスはエニーキャストや転送を使う場合があるため、DNSサービスの所在地がプロキシノードと一致しないこともあります。
- ✅ まず切断した状態でDNS検査を実行して結果を記録し、接続後に同じテストを行って比較します。
- ✅ クライアントのDNS制御、リモートDNS、通信の振り分け設定を確認します。設定名はクライアントによって異なるため、実際の説明を確認してください。
- ✅ ブラウザーで独自のセキュアDNSが有効になっていないか確認します。ブラウザー内蔵の名前解決とシステムの名前解決は、別の経路を通る場合があります。
- ✅ 検査ページの地域表示だけで判断せず、クライアントのログでDNSリクエストと上流への接続が想定した経路を通っているか確認します。
- ❌ 検査ページに複数のDNSサービスが表示されただけでリークと判断しないでください。また、「暗号化DNSを使っている」ことと「DNSが必ずプロキシを経由する」ことは同じではありません。
暗号化DNSが保護するのは、端末からDNSサービスまでの問い合わせ通信です。DNSサービスへの接続が直接通信なら、DNSサービスからはローカルのグローバルIPアドレスが見えることがあります。一方、DNSサービスが別の地域にあっても、設定どおりの動作である可能性があります。地域名ではなく、通信経路を基準に判断しましょう。
Windowsでは、nslookup example.comを使うと、通常のDNS問い合わせで使用したサーバーや応答を確認する参考になります。ただし、ブラウザーも同じ名前解決方法を使っているとは限らず、これだけでDNSリークがないと証明することもできません。ブラウザーのセキュアDNS、クライアント内の名前解決、システムの名前解決は、それぞれ独立している場合があります。
アプリごとの検証:ブラウザーで確認した後に見るポイント
アプリによってはシステムプロキシに従わず、別の通信方式を使うこともあります。まずクライアントを起動し、対象アプリを完全に終了してから開き直し、新しい検索、更新、再生リクエストを送信します。キャッシュ済みのページやダウンロード済みのコンテンツ、バックグラウンドで維持された既存の接続を見るだけでは、判断材料として不十分です。
次に、クライアントの接続一覧で対象のプロセスや関連ドメインを探します。適用されたルール、直接接続かプロキシ経由か、選択されたノード、操作時に新しい接続や通信量の変化があったかを確認しましょう。アプリは複数のドメインに接続することがあります。ログイン、画像、API、メディアの通信に同じルールが適用されるとは限らないため、ホーム画面だけで確認を終えないでください。
| 確認できたこと | 考えられる原因 | 次に確認すること |
|---|---|---|
| ブラウザーの出口IPは変わったが、アプリでは変化がない | アプリがシステムプロキシを使わない、またはプロセスルールで除外されている | アプリのプロキシ設定、プロセスルール、TUNの適用範囲を確認する |
| 出口IPは変わったが、DNSは接続前と似ている | 名前解決が元の経路を使っている、または同じパブリックDNSサービスを使っている | DNS設定とログを確認し、表示名だけで判断しない |
| IP確認ページに普段の出口IPが表示される | 確認先のドメインが直接接続になっている、またはブラウザーがプロキシを使っていない | まず確認リクエストに適用されたルールを調べ、次に通信の適用範囲を確認する |
| クライアントに通信量はあるが、対象アプリは使えない | 通信量がバックグラウンドの確認通信や別のプログラムによる可能性がある | 総通信量では判断せず、対象ドメインやプロセスごとに確認する |
| ウェブページは使えるが、リアルタイム通信やメディアに問題がある | 関連するUDP通信、ドメイン、アドレスファミリーが想定どおり処理されていない | プロトコルの対応状況、通信の振り分けルール、アプリの接続記録を確認する |
モバイル端末でVPNの表示が出ていても、ネットワーク拡張機能やトンネルが動作していることを示すだけで、すべてのアプリが同じ出口を経由しているとは限りません。Androidのアプリ別設定、Appleプラットフォームでのルート除外、ほかのネットワークツールの設定によって、適用範囲が変わることがあります。利用中のクライアントで設定できる内容を確認してください。
誤判定しやすいポイント:キャッシュ、アドレスファミリー、地域制限
既存の接続やキャッシュで変化が見えないことがある
ノードを切り替えたあとも、確立済みの接続は元の経路を使い続けることがあります。ページの内容がキャッシュから表示される場合もあります。接続ボタンを何度も押すより、対象アプリを開き直して新しいリクエストを送るほうが切り分けに役立ちます。DNSキャッシュを消去する場合は、使用中のOSに合った方法を使い、ブラウザー独自のキャッシュも考慮してください。
アドレスファミリーによって通信経路が異なることがある
端末が複数のアドレスファミリーでグローバルネットワークに接続できる場合があります。確認ページで一方のアドレスを調べても、もう一方もVPN経由になっているとは限りません。クライアントやルールの適用範囲が一部の通信に限られていると、アプリが別の経路を優先することがあります。クライアントのアドレスファミリー対応状況とルーティング設定を確認し、結果を個別に表示できるツールで照合しましょう。システム機能をむやみに無効にするのは避けてください。
WebRTCの検査結果はアドレスの種類を区別する
ブラウザーのリアルタイム通信は、通常のウェブページとは異なる経路を使う場合があります。WebRTCの検査でローカルインターフェースのアドレスや、隠す処理が施されたホスト名が表示されても、それだけでグローバルIPの漏えいとはいえません。想定外のローカルグローバルIPアドレスが表示された場合は、ブラウザーのポリシー、UDPの経路、クライアントの適用範囲をさらに確認してください。ひとつのウェブページの検査結果ですべてのアプリの状態を判断することはできません。
サービスの地域制限表示だけでは通信経路を判定できない
サービス提供元は、アカウントの地域、支払い情報、位置情報の利用許可、過去のセッション、IPアドレスのリスク判定などを組み合わせてアクセス可否を決める場合があります。そのため、出口IPが変わっても地域制限の表示が続くからといって、プロキシが無効とは限りません。反対に、あるサービスが使えても、ほかのアプリやDNSが想定どおりVPNを経由している証明にはなりません。通信経路の有効性と、サービスの利用許可は別の問題です。
順番に切り分け、再現できる記録を残す
問題が起きても、ノードの変更、DNSの変更、モード切り替え、アプリの再インストールを同時に行わないでください。一度に変更する設定をひとつに絞り、同じリクエストを再実行すれば、どの操作が影響したかを確認できます。まず、サブスクリプションが正常に読み込まれているか、ノードが残っているか、クライアントが接続できるかを確認し、その後で通信の適用範囲と振り分けルールを調べましょう。
サブスクリプションリンクは、クライアントに設定を取得させるための入口です。読み込みが完了しても、すべての通信がその設定を使うとは限りません。ノードが表示されない場合や設定の更新に問題がある場合は、クイックスタートガイドで手順を確認してください。特定のウェブサイトに接続できない場合は、トラブルシューティングガイドを参考にしてください。
問い合わせの際は、OSとクライアントの名称、現在のモード、対象ドメイン、発生時刻、適用されたルール、個人情報を隠したスクリーンショットを共有すると、状況を把握しやすくなります。サブスクリプションリンク、アクセストークン、アカウントの認証情報は公開しないでください。第三者が設定にアクセスできるおそれがあります。
判断の目安:出口IPが想定どおりで、DNSの経路が設定と一致し、対象アプリの新しいリクエストに正しいルールとノードが適用されていれば、その使い方でVPNが有効になっている可能性が高いと判断できます。ルールによる振り分けで直接接続になっていても、必ずしも障害ではありません。ブラウザーで確認できても、端末全体の検証が済んだことにはなりません。