VPNの接続状況を確認する際は、クライアントの接続アイコンを見るだけでなく、接続前後の出口IPを比較し、DNSリクエストを確認したうえで、実際に使うアプリを一つずつ調べるのが確実です。接続状態が示すのは、クライアントがトンネルの確立を試みていることです。ブラウザーやデスクトップアプリ、システムサービスがその経路を使うかどうかは、プロキシモードやルール設定、アプリ独自のネットワーク設定にも左右されます。
自分のグローバルIPアドレスを覚えておく必要はありません。まず切断時のネットワーク情報を記録し、同じ端末・同じネットワークで目的のノードに接続してから、もう一度測定します。結果を比較するときは、テストツールがブラウザーの通信を測っているのか、端末全体の通信を測っているのかも確認してください。この違いを混同すると、「接続済みなのに元のネットワークを使っている」と誤解しやすくなります。
まず出口IPを確認：接続前後を比較する
出口IPは、アクセス先のウェブサイトから見える接続元のIPアドレスです。VPNを切断した状態で、ブラウザーから信頼できるIP確認ページを開き、表示されたグローバルIPとおおよその地域を記録します。本サイトのIPアドレス確認ページでも、現在のブラウザーの出口情報を確認できます。次に使用するノードへ接続し、確認ページを再読み込みして結果を比較してください。後から別のツールやネットワークの結果と混同しないよう、確認ページのURLとテスト時に選択したノードを控えておくと便利です。
- クライアントを切断し、起動中のほかのプロキシやネットワーク高速化ツールを終了してから、ブラウザーの出口IPを確認して記録します。
- 目的のノードに接続し、クライアントで選択中のモードを確認します。確認ページを再読み込みし、切断時に開いたままのページ表示だけで判断しないでください。
- IPアドレスが変わったかを比較し、おおよその地域が選択した出口と合っているかを確認します。地域データベースの更新には時間がかかることがあるため、都市名だけで接続失敗と判断しないでください。
- 別のアプリも確認する場合は、そのアプリ内でネットワーク結果を確認できる操作を行います。ブラウザーのテスト結果をそのまま当てはめないでください。
IPアドレスが変われば、今回のブラウザーのリクエストは、少なくとも異なる出口から確認サイトに到達したといえます。ただし、DNSやほかのアプリも同じ経路を通った証明にはなりません。IPが変わらない場合も、すぐに結論を出さないでください。ルールモードによって確認サイトが直接接続されている、ブラウザー拡張機能がシステムプロキシの設定を上書きしている、またはページにキャッシュが表示されている可能性があります。別の信頼できる確認サイトを使い、ページを強制再読み込みすると、特定のサイトでの表示問題を切り分けやすくなります。
次にDNSを確認：名前解決の経路とウェブの出口を分けて考える
DNSはドメイン名を接続先のアドレスに変換します。ウェブのリクエストが目的のノードを経由していても、ドメイン名の問い合わせが同じ経路を通るとは限りません。実際のDNS応答を表示できるテストツールを使い、接続前後に未アクセスのドメインをそれぞれ調べて、名前解決に使われたサービスがクライアントの想定と一致するか確認します。キャッシュの削除やテスト用ドメインの再生成を求められた場合は、ツールの案内に従ってください。すでに名前解決済みのページを何度も開いても、新たなDNSリクエストが発生しないことがあります。
DNSリークを判断する前に、設定上の想定を確認しましょう。関連する問い合わせをすべて回線経由にする設定なのに、ローカルネットワーク指定のDNSサービスが繰り返し表示される場合は、DNS設定を確認してください。一方、ルールによってローカルのドメインはローカルDNSで、海外のドメインは別の経路で処理する設定なら、想定どおりの動作かもしれません。DNSサービスの所在国と出口の地域が異なることだけを根拠に、リークと判断することもできません。パブリックDNSの接続拠点と表示上の所在地が一致しない場合があります。
ブラウザーのセキュアDNS設定にも注意してください。ブラウザーによっては、システム設定のDNSサービスではなく、独自に暗号化DNSを使用します。その場合、テスト結果に反映されるのはクライアントのシステム全体のDNS動作ではなく、ブラウザーの設定です。確認する際は、まずブラウザーでこの機能が有効か記録し、ブラウザーとほかのアプリを分けてテストしてください。見栄えのよい結果を得るためだけに、影響を理解せずシステムDNSを変更するのは避けましょう。
アプリごとに確認：ブラウザーで通っても端末全体で通るとは限らない
クライアントの動作範囲には、ブラウザー拡張機能によるプロキシ、システムプロキシ、さらに多くの端末通信を取り込む仮想ネットワークインターフェース方式などがあります。ブラウザー拡張機能の影響は通常、そのブラウザーに限られます。システムプロキシは、アプリがシステム設定に従う場合に有効です。仮想ネットワークインターフェースを使う場合は、ルーティングやルール設定も確認してください。「グローバル」や「ルール」といった似た名称の項目でも、クライアントによって動作が異なることがあります。実際の設定説明とテスト結果を基準に判断しましょう。
| 確認する対象 | 確認方法 | 結果の見方 |
|---|---|---|
| ブラウザーのウェブページ | 接続前後に出口IPを確認し、新しいDNSテストも実行する | そのブラウザーで行ったテストリクエストの経路だけがわかる |
| 別のブラウザー | そのブラウザーで同じ確認ページを個別に開く | 結果が異なる場合は、拡張機能、プロキシ、セキュアDNSの設定を確認する |
| デスクトップアプリ | アプリ独自のプロキシ設定を確認し、実際のネットワーク機能をテストする | ウェブの出口が変わっても、そのアプリが同じ経路に接続したとは限らない |
| モバイルアプリ | 同じネットワークでブラウザーと対象アプリをそれぞれテストする | アプリ独自の接続方式とクライアントのルール設定を確認する |
デスクトップアプリやモバイルアプリをテストするときは、アプリ内のネットワーク診断、サービスの地域表示、接続ログなど、リクエストの結果を直接確認できる機能を使いましょう。アプリ自体に出口情報が表示されない場合、「コンテンツを開けた」ことを経路の証明にしないでください。直接接続でも開けることがあります。より確実に確認するには、クライアントの接続履歴やルールの適用情報を見て、アプリがリクエストを送信した時刻と照合します。これらの記録は通信経路の確認に使い、アカウント情報やアクセス先を含むスクリーンショットを不用意に公開しないでください。
「接続済みなのに回線を経由しない」ときによくある原因
テスト結果が想定と異なる場合は、まず条件をそろえます。同じネットワーク、同じ端末、同じ対象アプリを使い、クライアントの設定を一度に一つだけ変更してください。どの設定が結果に影響したかを特定できます。以下は確認しやすい順に並んでいます。一つ確認するたびに再テストし、ノード、ルール、ブラウザー設定を同時に切り替えないでください。
- ✅ 現在のモードを確認する。ルールモードでは、IP確認サイトが直接接続されることがあります。回線自体を確認する必要がある場合は、影響を理解したうえでテストに適したモードを一時的に選び、確認後に元の設定へ戻してください。
- ✅ プロキシの適用範囲を確認する。ブラウザー拡張機能だけが有効な場合、ほかのブラウザーやデスクトップアプリは自動的に同じ出口を使いません。
- ✅ アプリの設定を確認する。アプリ独自のプロキシやDNS設定、以前からのネットワーク接続が、システムで使っていると思っていた経路を上書きすることがあります。
- ✅ IPv6を確認する。ローカルネットワークでIPv6が利用できても、使用中のモードが該当する通信を処理しない場合、IPv6対応サイトは別の経路を使う可能性があります。IPv4とIPv6の検索結果をそれぞれ確認してください。
- ✅ DNSとルールの適用状況を確認する。出口IPが変わっても名前解決が想定どおりでない場合は、ノードを何度も変更するのではなく、DNS設定を分けて確認します。
IPv6の確認は特に見落とされやすい項目です。ある確認ページはIPv4だけを表示し、別のサイトはIPv6を優先して使うことがあります。ツールで両方のアドレスを個別に表示できる場合は、接続前後の結果をそれぞれ比較してください。差が見つかったら、まずクライアントが選択中のモードでIPv6ルーティングに対応しているか、現在のルールが対象リクエストをカバーしているかを確認します。経路の問題を解明しないまま、端末のIPv6機能を無効にして済ませないでください。
接続は確立していても、ノードが目的のリクエストを正常に転送できていないこともあります。まず一般的なウェブページをテストし、クライアントにハンドシェイク、認証、サブスクリプション更新のエラーが表示されていないか確認してください。読み込みに失敗したからといって、すべてを「回線が有効になっていない」と判断するのは避けましょう。接続先サービスの障害、アプリのキャッシュ、ドメイン名の名前解決エラーでも似た症状が起こります。接続ボタンを何度も押すより、出口IP、DNS、アプリの3つの結果を照らし合わせるほうが効果的です。
サブスクリプションやプロトコル名だけでは確認にならない
サブスクリプションリンクは通常、対応クライアントにノードや設定情報を提供するために使います。インポートに成功したのは、クライアントが認識できる設定を取得したことを示すだけです。ノードに接続できるか、ルールが想定どおり動作するかは、別途確認が必要です。サブスクリプション更新後にテスト結果が大きく変わった場合は、一覧に新しい項目が表示されているかだけでなく、現在選択中のノードとモードを確認してください。プラットフォームごとにクライアントの設定場所は異なり、同じ名称の項目が同じ通信を制御するとは限りません。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なる接続プロトコルまたは方式の名称であり、「検査済み」を示すものではありません。プロトコルが関係するのは、クライアントとノードが接続を確立する方法です。出口IP、DNS、アプリごとの振り分けを確認すれば、通信が実際にどこへ向かったかがわかります。IEPL専用線、中継、直接接続も、回線の構成方法を表すもので、端末側の確認に代わるものではありません。ノードが利用可能でも、アプリの通信がプロキシルールの対象になっていなければ、アクセスはローカル経路を通る場合があります。
サポート窓口に状況を伝える場合は、クライアントのプラットフォーム、使用モード、アクセスしたいアプリ、接続前後の出口IPとDNSの違いを伝えれば十分です。サブスクリプションリンクには接続情報が含まれることがあるため、公開の場にリンク全体を貼らないでください。スクリーンショットを共有する際も、確認に不要なアカウント情報は隠してください。
今回の確認結果をどう判断するか
結論は、実際にテストした範囲に限ってください。ブラウザーの出口が選択したノードと一致し、DNSの名前解決もモードの想定どおりで、対象アプリでも該当ルールの適用や観測可能なネットワーク結果を確認できれば、テストしたリクエストは想定どおりに動作したといえます。反対に、クライアントに「接続済み」と表示されただけ、またはブラウザーの出口が変わっただけでは、端末上のすべての通信が同じ経路を使っているとは判断できません。
ネットワーク環境やクライアント設定が変わると、以前のテスト結果が当てはまらなくなることがあります。ネットワークの変更、ノードの切り替え、サブスクリプションの更新後は、同じ順番で改めて確認しましょう。記録するのは、その時点での端末とアプリの結果であり、今後のすべての接続を保証するものではありません。