VPNが本当に機能しているかを確認する際、クライアントの「接続済み」表示だけを見るのは不十分です。この状態は通常、クライアントとリモート回線のハンドシェイク完了を示すだけで、ブラウザー、デスクトップアプリ、コマンドラインツール、DNSクエリまで想定した経路を通っていることは保証しません。信頼できる確認方法は、出口IP、DNS解決、ルーティングモード、使用するアプリを順番に確認し、接続前後の結果を比較することです。
出口アドレスが変わったのに、特定のアプリが以前のネットワーク位置を表示し続ける場合、問題は回線のハンドシェイクではなく、システムプロキシ、TUNモード、ルール分岐、キャッシュ接続、またはアプリ独自のネットワーク処理にあることが多いです。逆に、ページが正常に開けても、すべてのリクエストが回線を通っているとは限りません。ルールモードでは特定のドメインだけを転送し、その他の通信はローカルネットワークへ直接接続する場合があります。
まず「機能している」とは何を含むかを理解する
VPNが機能しているかどうかは、単一のスイッチだけで決まるものではありません。完全な接続には、少なくとも回線のハンドシェイク、システムルーティング、名前解決、アプリ通信が関係します。どれか一つでも想定どおりに動作しなければ、画面上は正常でも実際の経路が異なることがあります。
| 確認対象 | 確認したい状態 | よくある異常 |
|---|---|---|
| クライアントの状態 | 設定が読み込まれ、回線のハンドシェイクが完了し、再接続を繰り返していない | サブスクリプションの期限切れ、ノードに到達できない、システム時刻の異常、プロトコルパラメーターの不一致 |
| 出口IP | 接続後のパブリックな出口が接続前と異なり、選択した地域と一致している | アプリがプロキシを迂回している、ルールが直接接続に一致している、古い接続が解放されていない |
| DNS解決 | 解決リクエストが、クライアントに設定したローカル・リモート・暗号化DNSの方針に沿っている | システムキャッシュ、ブラウザー独自の名前解決、LAN内のリゾルバーが引き続き処理している |
| 特定のアプリ | 回線を通す必要があるアプリが、対応する出口を実際に使用している | アプリがシステムプロキシを読み取らない、一部のプロトコルだけが処理対象、アプリ別ルールの設定ミス |
| プロトコルとアドレスファミリー | TCP、UDP、IPv4、IPv6が現在の設定に従って処理されている | 一方の通信だけが処理され、もう一方がローカルネットワークから送信されている |
これらの層を制御できる範囲は、クライアントによって異なります。デスクトップでよく使われる「システムプロキシ」は、主にOSのプロキシ設定を変更する機能です。その設定を読み取るアプリだけが従います。一方、TUNモードは仮想ネットワークインターフェースを作成し、ルーティングテーブルを通じてより広い範囲の通信を処理します。プロキシ設定に対応していないソフトウェアに適していますが、通常はシステム権限が必要です。
モバイルクライアントは通常、システムが提供するVPNインターフェースを使って通信をまとめて処理します。ただし、アプリ別の除外、オンデマンド接続、プライベートDNS、アプリ内の暗号化DNSの影響を受ける場合があります。そのため、同じShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICの設定でも、プラットフォームが違えば「接続済み」と表示された場合の処理範囲が完全に同じとは限りません。
出口IPを確認する正しい手順
出口IPは最も分かりやすい確認方法ですが、信頼できる比較を行うには、まず未接続時の状態を記録する必要があります。接続後に確認ページを開き、見慣れないアドレスが表示されただけでは、現在の回線による結果だとは断定できません。企業ネットワーク、共有ネットワーク、上位プロキシ自体によっても、パブリックIPと端末のLANアドレスは異なることがあります。
- クライアントを切断する。既存の接続を完全に終了し、自動再接続するオンデマンドルールを無効にします。
- 基準値を記録する。現在のパブリックな出口、ネットワーク事業者、おおまかな地域を確認します。公開スクリーンショットに完全なアドレスを載せないでください。
- 再接続する。判別しやすい地域の回線を選び、クライアントの状態が安定するまで待ちます。
- 新しいセッションを開く。新しいブラウザーのプライベートウィンドウを使い、古いページ、キャッシュ、長時間接続による影響を避けます。
- もう一度確認する。出口アドレス、地域、ネットワークの帰属先が回線の変更に応じて変わったか比較します。
- 回線を切り替えて再確認する。別の回線グループに変更してから再読み込みし、結果が確認ページのキャッシュによるものではないことを確かめます。
- ✅ 接続前後で出口アドレスが異なり、地域も選択した回線と一致している場合は、DNSとアプリ通信の確認に進めます。
- ✅ ブラウザーとシステムのネットワークツールが同じ出口を取得するなら、処理範囲はおおむね一致しています。
- ❌ アドレスがまったく変わらない場合は、現在のルールで確認先のドメインが直接接続に設定されていないか確認します。
- ❌ ブラウザーだけアドレスが変わり、他のソフトウェアが変わらない場合、システムプロキシを使っていて、通信全体を処理していない可能性があります。
- ❌ 回線を切り替えても以前の地域が表示される場合は、ページキャッシュ、接続の再利用、古いプロセスが終了していないことが考えられます。
IPv4とIPv6も分けて確認してください。ローカルネットワークによっては両方のアドレスが提供されますが、クライアントがIPv4だけを処理する場合があります。その場合、一般的な確認では出口が切り替わったように見えても、IPv6対応アプリはローカル経路を優先する可能性があります。単純にすべてのネットワーク機能を無効にするのではなく、まずクライアントがIPv6の処理に対応しているか確認してください。非対応の場合は、クライアントのドキュメントに従って無効化、ブロック、ルール処理のいずれかを選びます。
DNS解決が想定どおり処理されているか
ブラウザーがドメインへアクセスする前に、通常はドメイン名をIPアドレスへ解決する必要があります。DNSリークとは一般に、本来は回線内のリゾルバーや指定した暗号化リゾルバーへ送るべきリクエストが、ローカルネットワークのDNSサービスへ送信され続ける状態を指します。必ずしもウェブページが開けなくなるわけではありませんが、検索したドメインの範囲が露出し、解決結果と回線の地域が一致しなくなる可能性があります。
DNSの異常を判断する際、検査ページに表示されたリゾルバー名だけを見てはいけません。現在のクライアントは、パブリックDNS、DoH、DoT、リモート解決、ドメイン別の分岐を使うことがあります。ブラウザーが独自のセキュアDNSを有効にしている場合もあります。これらの結果が出口回線と同じネットワーク事業者になるとは限りません。本当に確認すべきなのは、検査結果が現在の設定と一致しているかどうかであり、リゾルバー名が出口IPと完全に同じかどうかではありません。
説明可能なDNS結果を作る
まずクライアントのDNS設定を開き、現在の方針がどれに該当するか確認します。システムで解決するのか、リモート回線経由で解決するのか、指定した暗号化DNSを使うのか、ドメインルールに応じて個別に処理するのかを確認してください。その後、古いキャッシュを削除して、もう一度解決を実行します。デスクトップOSごとに、対応するキャッシュ更新コマンドを使用できます。
Windows:
ipconfig /flushdns
macOS:
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
Linux with systemd-resolved:
resolvectl flush-cachesシステムキャッシュを更新した後は、ブラウザーも終了して再起動してください。ブラウザーが独自のキャッシュや接続プールを保持している可能性があるためです。ブラウザー独自の暗号化DNSが有効な場合、システムのコマンドだけではすべての状態を消去できません。ブラウザーのネットワーク設定で、解決方針を確認してください。
- ✅ リゾルバーがクライアントの設定と一致し、設定を切り替えると検索結果も変化する。
- ✅ ローカルドメインはローカルルールで解決し、国際ドメインはリモートルールで解決され、結果が分岐設計と一致している。
- ❌ クライアントがリモート解決に設定されているのに、検査結果が常にローカルネットワークのリゾルバーだけになる。
- ❌ ブラウザーとコマンドラインで解決結果が長期間異なる場合は、ブラウザー独自のDNS設定を確認する。
- ❌ 回線を切り替えてもドメインが明らかに古いアドレスを返す場合は、システム、ブラウザー、アプリのキャッシュを削除する。
DNSの分岐は、単一の解決経路より複雑です。たとえば、ローカルドメインはローカルリゾルバーで処理して直接アクセスし、それ以外のドメインはリモートで解決して回線を通す構成があります。この場合、検査ページに異なる送信元の解決リクエストが表示されても、必ずしもリークを意味しません。ルールが想定どおりか、リモート解決が必要なドメインが誤ってローカルへ送られていないかを確認することが重要です。
アプリごとに通信経路を検証する
出口IPとDNSが正常なら、次は実際に使用するソフトウェアを一つずつ検証します。ブラウザーが回線を通っていても、ゲーム、ダウンローダー、ターミナル、同期ツール、デスクトップクライアントが同じプロキシ設定を読み取るとは限りません。特にシステムプロキシモードでは、一部のアプリが直接接続を確立し、OSのプロキシを完全に無視することがあります。
ブラウザー
ブラウザーは通常、最も確認しやすい一方で、拡張機能、独自プロキシ設定、セキュアDNS、接続の再利用の影響も受けやすいアプリです。切り分ける際は、まずネットワーク経路を変更する拡張機能を無効にし、新しいプライベートウィンドウでテストします。一方のブラウザーは正常で、別のブラウザーだけ異常な場合は、すぐにノードを変更するのではなく、両者のプロキシ設定とDNS設定を比較してください。
コマンドラインと開発ツール
コマンドラインツールがプロキシを通るかどうかは、ツール自体、環境変数、システムの実装に左右されます。プロキシ環境変数を読み取るツールもあれば、明示的なプロキシ指定が必要なツールもあります。また、TUNモードで初めて透過的に処理されるツールもあります。テスト時はクライアントの接続ログも確認し、リクエストがプロキシルール、直接接続ルール、拒否ルールのどれに一致したかを確かめてください。
デスクトップソフトウェアとモバイルアプリ
デスクトップソフトウェアは独自のネットワークスタックを使う場合があり、モバイルアプリも独立したQUICなどのUDPセッションを確立することがあります。現在のノードプロトコルやクライアントモードがTCPだけを処理する場合、関連するリクエストは直接接続を続けるか、失敗する可能性があります。Hysteria2とTUICはUDPを基盤とするプロトコルですが、これらを有効にしたからといって、すべてのアプリのUDP通信が必ず処理されるわけではありません。アプリ通信がトンネルに入るかどうかは、クライアントのルーティングとTUN設定によって決まります。
アプリ別設定と迂回ルール
一部のクライアントでは、どのアプリを回線経由にし、どのアプリを直接接続にするか指定できます。確認時は「含める」リストと「除外」リストの両方を確認してください。アプリの更新後は、実行ファイルのパスやパッケージ識別子が変わることがあります。ルールが古いパスを参照したままだと、新しいバージョンのプログラムが従来のポリシーに一致しない可能性があります。
| 現象 | 優先して確認する項目 | 対処の方向性 |
|---|---|---|
| ブラウザーは正常だが、ターミナルは直接接続 | システムプロキシ、プロキシ環境変数、TUNモード | ツールにプロキシを設定するか、その通信を処理できるモードに変更する |
| ウェブページは正常だが、アプリ内のリクエストが失敗 | UDP、QUIC、証明書検証、アプリ別ルール | プロトコルの対応状況と、アプリが除外されていないか確認する |
| 一部のウェブサイトは回線経由だが、一部は直接接続 | ルールモード、ドメイン分類、プロセスルール | ルールの一致ログを確認し、想定した分岐かどうか確かめる |
| ノードを切り替えてもアプリに古い出口が表示される | 長時間接続、バックグラウンドプロセス、接続プール | アプリを完全に終了して再起動し、必要ならネットワークを切断して再接続する |
| IPv4は正常だが、IPv6はローカル出口のまま | クライアントのアドレスファミリー対応、システムルーティング | 対応する処理機能を有効にするか、設定に従って保護されていない経路をブロックする |
接続済みと表示されるのに通信が回線を通らない理由
最もよくある原因は、クライアントがノードへの接続を確立しただけで、システムプロキシやルーティングの変更に成功していないことです。権限不足、仮想ネットワークアダプターの初期化失敗、別のネットワークツールによる設定の上書きなどにより、制御層はオンラインでもデータ層が処理されないことがあります。この場合は、接続ボタンを何度も押すのではなく、まずクライアントログを確認してください。
システムプロキシとTUNモードの選択ミス
ブラウザーやプロキシ対応ソフトだけを使う場合は、システムプロキシのほうが簡単です。プロキシ設定を読み取らないアプリまで処理する必要がある場合は、TUNモードが適しています。両者は速度の段階ではなく、通信を取り込む入口の違いです。TUNを有効にした後も、仮想インターフェースが作成され、デフォルトルートまたはポリシールートが書き込まれていることを確認してください。
ルール分岐が直接接続に一致している
ルールモードでは、ドメイン、IP、プロセス、ルールセットに基づいて経路を決定します。出口を確認するウェブサイトが直接接続に分類されていれば、結果が変わらないのは当然です。切り分けのために一時的にグローバルプロキシへ切り替える方法は比較手段として有効です。グローバルモードで正常なら、回線自体は利用でき、問題は主にルールにある可能性が高いと考えられます。確認後は、必要な分岐モードへ戻してください。
古い接続が解放されていない
ブラウザー、チャットアプリ、同期ツールは長時間接続を維持することがあります。回線を切り替えても、これらの接続が直ちに再作成されるとは限らないため、アプリが一時的に古い経路を使い続ける場合があります。ページを更新するだけでなく、アプリを完全に終了して再起動するほうが確実です。バックグラウンドで常駐するプロセスについては、実際に終了していることも確認してください。
複数のネットワークツールが設定を奪い合っている
企業VPN、デバッグプロキシ、ネットワークフィルタリングソフト、別の回線クライアントを同時に実行すると、後から書き込まれたルートやプロキシ設定が以前の設定を上書きすることがあります。切り分け中は必要なツールだけを残し、ネットワーク経路を変更する他のプログラムを停止してください。その後、一つずつ戻して競合元を特定します。
サブスクリプション設定が更新されていない
サブスクリプションURLは、ノードとルールの情報をクライアントへ提供します。サーバー側の設定が変更されても、ローカルクライアントが古いコピーを保持している場合があります。クライアント内でサブスクリプションを更新し、更新が成功したことを確認してから回線を選び直してください。サブスクリプションURLはアクセス認証情報にあたるため、公開検査サイトや問題のスクリーンショットに貼り付けないでください。
回線の種類が検証結果に与える影響
直接接続、中継、IEPL専線は、回線の入口から出口までのネットワーク経路を表すもので、クライアントが通信を処理する方式とは別の概念です。直接接続回線では端末がリモートノードへ直接接続するため経路は単純ですが、ローカルネットワークから対象地域までのパブリックネットワーク品質に左右されます。中継回線ではまず近い入口へ接続し、そこから中間ネットワークを経由して出口へ送ります。ネットワーク環境によっては、経路の安定性が改善することがあります。
IEPL専線は通常、入口と出口の間に専用の伝送路や管理されたリンクを使う構成を指し、地域をまたぐ伝送経路に重点があります。どの回線を使う場合でも、端末側でシステムプロキシ、TUN、DNS、分岐を正しく設定する必要があります。専線だからといって、アプリによるプロキシ迂回が自動的に解消されるわけではなく、出口IPやDNSの検証の代わりにもなりません。
プロトコルだけで機能の有無が決まるわけでもありません。Shadowsocks、VMess、Trojan、VLESSは異なる伝送方式と認証方式を提供し、Hysteria2とTUICはUDPベースの伝送機構を重視しています。実際にアプリのリクエストが回線へ入るかどうかを決めるのは、クライアントがローカルの入口をどのように作り、ルーティングルールを適用するかです。ノードのハンドシェイクは成功しているのにアプリが直接接続する場合は、まずローカル側の通信処理を確認し、すぐにリモートノードの障害と判断しないでください。
再現可能な完全検証フロー
一時的に確認ページを開くだけでは、その瞬間の結果しか分かりません。より確実なのは、固定した確認手順を作り、クライアントの変更、サブスクリプションの読み込み、DNSの調整、分岐ルールの変更後に毎回同じ順番で実行することです。これにより、どの層で変化が起きたのかを素早く判断できます。
- 設定を更新する。信頼できるクライアント内でサブスクリプションを更新し、回線とルールが正常に読み込まれたことを確認します。
- 未接続時の基準値を記録する。出口の地域、アドレスファミリー、現在のDNS方針を保存し、完全なネットワーク識別情報は公開しません。
- 接続を確立する。ログでハンドシェイクが完了したか、再試行が続いていないか、仮想インターフェースのエラーがないか確認します。
- 出口を確認する。新しいセッションで接続前後のIPを比較し、IPv4とIPv6をそれぞれ確認します。
- DNSを確認する。リゾルバーがクライアントの方針と一致していることを確認し、システムとブラウザーのキャッシュを除外します。
- ルールの一致を確認する。テストしたドメインとアプリがプロキシと直接接続のどちらに判定されたかを確認します。
- アプリごとに検証する。ブラウザー、ターミナル、デスクトップソフトウェア、使用するモバイルアプリを確認します。
- 回線を切り替えて再確認する。アプリが新しい接続を作成し、出口の結果が回線の変更に応じて変化することを確認します。
- 通常モードへ戻す。切り分けのため一時的にグローバルプロキシを使用した場合は、完了後に必要な分岐設定へ戻します。
- ✅ クライアントのハンドシェイクが安定し、ログに再接続のループがない。
- ✅ 出口の結果が選択した回線と一致し、アドレスファミリーによる想定外の迂回がない。
- ✅ DNSクエリがローカル、リモート、暗号化のいずれかの解決方針に沿っている。
- ✅ 回線を通す必要があるすべてのアプリがプロキシルールに一致している。
- ✅ 直接接続すべきローカルサービスが、ルールどおりにアクセスできている。
- ❌ 接続アイコンだけを見て、実際の出口とルールログを確認していない。
完全な手順で特定のアプリだけが失敗した場合は、まずアプリ名、OS、クライアントモード、ノードプロトコル、ルールの一致結果、エラーログを集めてください。すべてのアプリで出口を切り替えられない場合は、システムプロキシ、TUNインターフェース、ルーティングの競合、サブスクリプション設定を優先して確認します。問題を具体的な層に絞り込むほうが、ノードを何度も変更するより効率的です。