VPNの動作確認は、クライアントに表示される「接続済み」だけでは不十分です。この表示は通常、クライアントとリモートサーバーのハンドシェイク完了、またはローカルプロキシポートの起動を示すにとどまります。ブラウザ、コマンドラインツール、その他のアプリの通信がすべて目的の経路を通った証明にはなりません。出口IP、DNSの名前解決経路、IPv4とIPv6、アプリごとの実際の通信経路を確認して判断します。
最も実用的なのは、接続前の状態を基準として記録し、接続後に同じテストを繰り返す方法です。IP確認ページを1つ開くだけでは不十分な場合があります。ブラウザキャッシュ、分割トンネルのルール、システムプロキシ、アプリ独自のネットワーク処理によって結果が変わるためです。ここでは再現しやすく、問題の層を特定しやすい手順を紹介します。
まず「機能する」の定義を確認：接続アイコンだけを見ない
「機能する」には、少なくとも複数の独立した条件があります。トンネルまたはプロキシセッションが確立していること、対象アプリが通信をクライアントへ渡していること、ルーティングまたはプロキシルールが想定経路に一致していること、DNSクエリが設定経路を迂回していないこと、出口アドレスが選択した地域やサーバーと一致していることです。どれか1つでも合わなければ、「クライアントは正常なのに、ウェブサイトは通常のネットワークからアクセスしている」状態になる可能性があります。
| 確認する場所 | 確認できること | これだけでは確認できないこと |
|---|---|---|
| クライアントに接続済みと表示される | ローカルクライアントがセッションまたはプロキシサービスを起動している | すべてのアプリがそのセッションに入っていること |
| 出口IPが変わった | 現在のテストリクエストが別の出口を経由している | DNS、IPv6、その他のアプリも同じ経路を使っていること |
| DNSの名前解決サービスが変わった | 今回確認したドメインのクエリが想定した名前解決経路に入っている | すべてのプロトコルとアプリに迂回がないこと |
| 対象サイトに正常にアクセスできる | そのサイトへの現在のリクエストが完了できる | 設定全体が正しいこと、または他の対象も利用できること |
したがって、確認では単一の「成功」アイコンを目指すのではなく、互いに裏付け合う証拠を集めることが重要です。出口IPは「リクエストが最終的にどこからインターネットへ出たか」を示し、DNSテストは「ドメインを誰が名前解決したか」を示します。アプリごとのテストは「どのプログラムが実際にルールに一致したか」を明らかにします。これらを組み合わせることで、経路障害、ルールの漏れ、アプリ設定の誤りを切り分けられます。
出口IPを比較：リクエストの出口を確認する
出口IPは最も分かりやすい確認項目です。接続を切った状態で信頼できるIP確認ツールを開き、公開アドレス、ネットワークの帰属、おおよその地域を記録します。その後ページを閉じ、目的の経路に接続してから再度確認します。サイト内のネットワーク確認ページも照合に利用できます。接続前後でアドレスが完全に同じでも、必ずしも失敗とは限りません。ただし強い兆候ではあるため、分割トンネルのルール、システムプロキシ、クライアントのモードを続けて確認します。
確認時は、古いページを更新するだけにしないでください。ブラウザに保存されたキャッシュが使われたり、ページ内のスクリプトが新しい通信を開始しなかったりする場合があります。プライベートウィンドウを新しく開くか、個別のプロキシを設定していない別のブラウザで相互確認する方法が確実です。2つのブラウザで出口が異なる場合、問題は経路そのものではなく、ブラウザ拡張機能、プロキシ設定、アプリの振り分けにある可能性が高いでしょう。
- ✅ 経路を切断し、現在の出口アドレスとネットワークの帰属を記録する。
- ✅ 目的の経路に接続し、古い確認ページを閉じて検索ページを開き直す。
- ✅ アドレスが変わったか、帰属地域が選択したノードと一致するか確認する。
- ✅ 別のブラウザまたはコマンドラインのリクエストで相互確認する。
- ❌ ウェブページの言語、タイムゾーン、検索結果だけで出口の位置を判断しない。
ウェブページの言語や位置情報は、Cookie、アカウント情報、ブラウザの言語、システムのタイムゾーン、サイト側のキャッシュから決まる場合があり、IPの帰属とは一致しません。一方、IPデータベースにも更新の遅れがあります。そのため「都市名に多少のずれがある」ことと「出口がまったく変わらない」ことは別の問題です。アドレス帯、ネットワークの帰属、国または地域が大まかに想定どおりかを重視してください。
コマンドラインを使う場合は、公開されているIPエコーサービスへリクエストを送り、ブラウザの結果と比較できます。コマンドラインツールがシステムプロキシに従うかどうかは、OS、環境変数、ソフトウェアの実装によって異なります。これは、現在の設定が全体を通るトンネルなのか、システムプロキシに対応したアプリだけを対象にしているのかを判断する材料になります。
curl https://example-ip-check.invalid
curl -4 https://example-ip-check.invalid
curl -6 https://example-ip-check.invalid上記のドメインはコマンドの構成を示すための例です。実際のテストでは、信頼できるIPエコーサービスに置き換えてください。IPv4とIPv6を個別に指定するのは、デュアルスタック環境の迂回を見つけるためであり、どちらのプロトコルが速いかを比較するためではありません。
DNS経路を確認：名前解決の迂回を見つける
ドメインへアクセスする前に、システムは通常、ドメイン名をアドレスへ変換します。ウェブ通信が目的の経路を通っていても、DNSクエリがローカルネットワークの既定リゾルバーへ送られていると、確認ページでは出口IPだけが変わり、DNSサービスは元のネットワークに属したままになることがあります。これは一般にDNSリークと呼ばれます。ウェブページの本文が必ず迂回しているという意味ではありませんが、ドメインの名前解決とウェブ接続が同じ想定経路を使っていないことを示します。
確認には、複数のランダムなサブドメインを問い合わせるDNSテストツールを使います。ランダムなドメインなら、OS、ブラウザ、ローカルキャッシュの影響を抑えられます。結果を見るときは、表示されたリゾルバーの都市だけに注目しないでください。パブリックDNSは近い拠点へ振り分けることがあります。DNSサービスの提供元が設定と一致しているか、切断時と接続時で結果が妥当に変化したかを確認することが重要です。
DNSの結果が異常なときの切り分け
- ブラウザのDNSキャッシュとシステムの名前解決キャッシュを削除し、ランダムなドメインで再テストする。
- クライアントでリモートDNS、仮想ネットワークアダプターによる制御、DNSリダイレクト機能が有効になっていないか確認する。
- ウェブ接続だけをプロキシし、DNSクエリを直接接続の経路に残すルールになっていないか確認する。
- ブラウザ独自の暗号化DNSが有効になっていないか確認し、システム設定とは分けてテストする。
- 別のネットワークに切り替えて再テストし、現在のルーターがDNSを書き換えている可能性を除外する。
プロキシプロトコルそのものと、DNSの処理方法は別の問題です。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれも異なる形のプロキシ通信を運べますが、名前解決をローカルで行うかリモートで行うかは、クライアント、動作モード、ルール設定によって決まります。ノードのプロトコル名だけで、DNSが必ずリモートを経由すると判断することはできません。
ルールモードでは、クライアントがドメイン名に応じて直接接続かプロキシかを決めるのが一般的です。ルール判定の前にドメインがローカルネットワークで解決されると、名前解決の記録がローカルDNSに残る可能性があります。クライアントがDNSを制御してリモートで解決すれば、ドメイン判定とその後の接続を同じ方針で処理できます。クライアントによって用語は異なるため、他のプラットフォームの設定をそのまま再現せず、DNS、スニッフィング、仮想ネットワークアダプター、ルールモードの説明を確認してください。
IPv4とIPv6を個別に確認：デュアルスタックの迂回を除外する
現在のネットワークでは、IPv4とIPv6を同時に利用できる場合があります。クライアントがIPv4だけを制御し、システムがデュアルスタック対応サイトへIPv6を優先して接続すると、確認ページに経路側の出口が表示されたり、ローカルネットワークが表示されたりします。この問題はノードが不安定だと誤解されがちですが、実際には2種類のアドレスプロトコルが異なるルートを使っていることが原因です。
IPv4とIPv6の出口を個別にテストします。IPv4が目的の経路へ変わっているのにIPv6がローカルネットワークのままなら、クライアントがIPv6制御に対応しているか、仮想ネットワークアダプターに適切なルートがあるか、ルールがIPv6を対象にしているかを確認します。現在のサービスやクライアントがIPv6を処理しない場合は、影響を十分理解したうえでシステムのネットワーク設定を調整できます。より安全なのは、デュアルスタック通信を完全に制御できる動作モードを使うことです。
| 確認結果 | 考えられる原因 | 優先して確認する項目 |
|---|---|---|
| IPv4は変わったがIPv6は変わらない | クライアントがIPv4だけを制御している、またはIPv6ルートがない | 仮想ネットワークアダプター、デュアルスタック対応、ルーティングテーブル |
| ブラウザの結果が交互に変わる | サイトがデュアルスタック接続で異なる経路を選択している | 2種類のアドレスプロトコルを個別に強制してテストする |
| どちらも変わらない | アプリがプロキシに入っていない、またはトンネルが通信を制御していない | システムプロキシ、TUNモード、分割トンネルのルール |
| どちらも変わったがDNSは変わらない | データ通信はプロキシされているが、名前解決はローカル経路を使っている | リモートDNS、ブラウザのセキュアDNS、キャッシュ |
IPv6を無効にすることは万能な解決策ではありません。一時的に迂回をなくせる可能性がある一方、IPv6に依存するローカルネットワークへ影響することもあります。切り分け中は個別テストで問題の範囲を確認し、長期的な設定ではクライアントがデュアルスタックを正しく処理するか、制御されていない通信が端末から出ないよう明確に制限することを優先します。
アプリごとにテスト：ブラウザで機能してもシステム全体で機能するとは限らない
システムプロキシモードは通常、システムプロキシ設定を自動的に読み取るソフトウェアにだけ影響します。ブラウザは追従することが多い一方、一部のゲーム、コマンドラインプログラム、ダウンロードツール、独自のネットワーク処理を持つアプリは直接接続する場合があります。TUNまたは仮想ネットワークアダプターのモードはシステムレベルのルート制御に近いものの、除外ルール、LANの迂回、アプリごとの振り分けの影響は受けます。
そのため、複数の種類のアプリで個別に確認します。ブラウザでは出口確認ページを開き、コマンドラインツールではエコーサービスへリクエストを送り、対象アプリでは自身のサービスへアクセスします。UDP対応アプリでは接続が利用できるかを確認してください。ブラウザだけが機能する場合はシステムプロキシの適用範囲を確認し、ブラウザとコマンドラインは機能するのに特定のアプリだけが例外なら、アプリ内プロキシ、バイパスリスト、クライアントのプロセスルールを優先して確認します。
プラットフォームごとの主な違い
- Windows：システムプロキシと仮想ネットワークアダプターは別の経路です。システムプロキシを読み取らないプログラムには、TUNモードまたはアプリ側のプロキシ設定が必要です。
- macOS：ネットワークサービスごとに設定が異なります。Wi-Fiと有線ネットワークを切り替えた後は、プロキシと仮想インターフェースが現在のサービスに適用されているか確認してください。
- iOS：クライアントは通常、システムVPN拡張機能を通じて通信を制御します。ただしオンデマンド接続、アプリごとのポリシー、クライアントの一時停止状態によって実際の経路が変わることがあります。
- Android：システムVPNの権限、常時接続設定、省電力制限、許可または除外するアプリの一覧が、適用範囲に影響します。
- Linux：デスクトッププロキシ、環境変数、ルーティングテーブル、透過プロキシが同時に存在することがあります。端末上のプログラムがデスクトップ環境のプロキシ設定を読み取るとは限りません。
サブスクリプションリンクのインポートに成功しても、システム通信が制御されたとは限りません。サブスクリプションはサーバーアドレス、ポート、プロトコル、一部のパラメーターをクライアントへ渡すだけです。ユーザーはノードを選び、接続を開始し、必要に応じてルール、グローバル、TUNモードを選択する必要があります。インポート後にノード一覧しか表示されずセッションが確立していなければ、出口IPは当然変わりません。
見かけだけの接続を分解：現象から設定層へ戻って確認する
クライアントは接続済みだが、出口がまったく変わらない
まず、クライアントがローカルプロキシポートを起動しただけではないか確認します。アプリが手動プロキシモードで動作していて、ブラウザがシステムプロキシを読み取っていなければ、通信は直接送信されます。次に、システムプロキシが別のソフトウェアに上書きされていないか、TUNモードに必要な権限があるかを確認します。最後に分割トンネルのルールを確認します。対象ドメインやアドレスが誤って直接接続のルールに一致している可能性があります。
出口は変わったが、対象サイトが元の地域と判定する
サイトはIPだけで地域を判定するとは限りません。アカウントの地域、Cookie、位置情報の権限、言語、タイムゾーンを参照することもあります。まずログアウトしたプライベートウィンドウで再確認し、次に出口IPのデータベース結果を調べます。複数のIP確認ツールが目的の地域を示し、特定のサイトだけに異常があるなら、トンネルではなくサイトのキャッシュやアカウント属性が原因である可能性が高いでしょう。
接続直後は正常だが、その後ローカルの出口に戻る
クライアントのプロセスがシステムに一時停止された、仮想ネットワークアダプターの再構築に失敗した、Wi-Fiと有線の間でネットワークが切り替わった、経路切断後に自動的にフォールバックした、といった原因が考えられます。クライアントのログに再接続が記録されていないか、切断時の通信を阻止する設定やオンデマンド接続が有効かを確認し、ネットワーク切り替え後にルートを再テストしてください。画面に残った接続状態だけを見て判断しないことが重要です。
一部のサイトは正常だが、一部のサイトを開けない
これは必ずしも「VPN全体が機能していない」という意味ではありません。DNSが到達できないアドレスを返している、ルールセットが関連ドメインを異なる経路へ分けている、現在のモードがUDPを処理していない、対象サイトがその出口を拒否している、といった可能性があります。まず開けないサイトのDNS解決結果を比較し、メインドメイン、静的リソースのドメイン、APIドメインが同じポリシーに一致しているか確認します。
経路とプロトコルのラベルだけでは実際の動作確認にならない
直接接続、中継、IEPL専用線は経路の構成方法を示すものであり、ブラウザ上で機能している証明ではありません。直接接続は通常、ユーザーのネットワークからリモート入口へ直接接続する方式です。中継ではまず中間ノードに入り、そこから出口へ転送します。IEPL専用線は、専用線区間を含む国際通信方式を表すことが一般的です。どの方式でも、出口IP、DNS、アプリの経路を確認し、通信が実際にどこを通ったかを判断する必要があります。
プロトコルのラベルもテストの代わりにはなりません。Shadowsocks、VMess、Trojan、VLESSは一般的なプロキシ方式で、Hysteria2とTUICはUDPベースの転送設計を重視しています。対応プロトコルの有無、パラメーターの一致、UDPの利用可否、DNSの処理、ルールの一致状況が最終結果に影響します。プロトコルのハンドシェイク成功は、接続経路の一部が成立したことを示すだけです。
同じサブスクリプションが一方のクライアントでは正常で、別のクライアントでは異常な場合は、プロトコル対応、転送パラメーター、TLS設定、サブスクリプションの解析結果、動作モードを比較します。クライアント間で名前が似ている項目をそのままコピーしないでください。「グローバル」「ルール」「LANをバイパス」などの用語でも、具体的な実装は異なる場合があります。
最終確認リスト：結果を再テストできる記録として残す
確認が終わったら、利用したネットワーク、クライアント、動作モード、ノードの地域、出口の帰属、DNSの結果、異常があったアプリを簡潔に記録しておくと便利です。次回、ネットワーク環境やクライアントのバージョンが変わっても、接続アイコンを見て推測するのではなく、同じ手順で再テストできます。
- ✅ 切断時の出口IPとDNSの基準値を保存した。
- ✅ 接続後の出口アドレスとネットワークの帰属が、目的の経路の想定と一致している。
- ✅ IPv4とIPv6を個別に確認し、想定外の迂回がない。
- ✅ DNSの名前解決サービスがクライアント設定と一致し、ブラウザ独自のDNSも確認した。
- ✅ ブラウザ、コマンドライン、対象アプリで個別に確認した。
- ✅ ルールモードで、想定した直接接続の対象とプロキシ対象を両方テストした。
- ✅ ネットワーク切り替え後や経路の再接続後も、出口が戻っていないことを確認した。
- ❌ ウェブページの言語、タイムゾーン、単一サイトの結果を出口確認の代わりにしていない。
すべてのアプリで出口が変わらないなら、問題はシステムによる制御またはプロキシ設定の層にある可能性が高いでしょう。出口は変わったのにDNSが変わらないなら、名前解決経路を重点的に確認します。特定のアプリだけが異常なら、そのアプリがシステムプロキシを迂回していないか調べます。アドレスプロトコルによって結果が異なるなら、デュアルスタックのルーティングに戻って確認します。この順序で進めれば、「接続したのに機能しない」状態を、対応可能な具体的な設定問題へ絞り込めます。