VPN 接続確認の方法：グローバルIP・DNS・アプリ別に検証

まず結論：接続状態と通信が経路を通ることは別

クライアントに接続済みと表示されるのは、通常、ローカルクライアントとリモートノード間でプロトコルのハンドシェイクが完了したか、システムがクライアントの作成したプロキシ、仮想NIC、VPN設定を受け入れたことを示します。ただし、それだけでブラウザー、ダウンロードツール、その他のアプリがすべてこの接続へ通信を渡しているとは限りません。

検証では、問題をいくつかの層に分けて考えます。グローバルIPが変わったかは、公開ネットワークへのリクエストがどこから出ているかを示します。DNSリクエストを誰が解決しているかは、ドメイン検索が想定経路を迂回していないかを確認する材料です。対象アプリが実際にプロキシまたはトンネルのルールに一致しているかは、経路選択が期待どおりかを判断します。これらの結果が一致して初めて、現在の通信が設定した経路を通っていると判断できます。

グローバルIPを確認する：Webリクエストの出口を確認

グローバルIPは最も分かりやすい確認項目です。VPNを切断し、信頼できるIP確認ページで現在の公開アドレスとおおまかな地域を記録します。その後、元のページを閉じて対象の経路に接続し、新しいシークレットウィンドウで同じ確認を行います。アドレスまたは出口地域が選択した経路の地域に変わっていれば、今回のブラウザーリクエストはリモート出口まで到達しています。

比較するときは、古いタブを更新するだけにしないでください。ブラウザーが既存の接続を再利用したり、サイトのキャッシュを保持したりする可能性があります。関連するタブを閉じ、クライアントで接続完了を確認してからブラウザーを新しいウィンドウで開く方が確実です。クライアントに接続ログがあれば、確認ページへアクセスした際に新しい送信記録が出るかも同時に確認できます。

IPv4とIPv6を同時に確認する

ネットワークによってはIPv4とIPv6の両方を提供していますが、クライアント設定が片方しか制御しないことがあります。確認ページでIPv4は変わっているのにIPv6がローカルネットワークを指したままだと、IPv6対応サイトが制御されていない経路を優先する可能性があります。その場合、あるサイトでは経路の地域が表示される一方、別のサイトでは元のネットワーク地域と判定されることがあります。

対処方法はクライアントの機能によって異なります。まず、デュアルスタックの通信を完全に制御できるTUNまたはシステムVPNモードを有効にしてください。現在のノード、プロトコル、クライアントがIPv6に対応できない場合は、影響を理解したうえでローカルネットワークのIPv6を一時的に無効にし、接続を再確立して確認します。ノードを何度も切り替えるだけで、プロトコルスタックの不一致を隠さないでください。

出口地域とノード名が完全に一致しないことがある理由

ノード名は通常、経路の用途や想定される出口地域を示しますが、IPデータベースはサービスごとに管理され、更新速度や帰属判定も異なります。あるアドレスが新しいデータセンターへ移転していても、確認ページには以前の地域が表示されることがあります。地域表示が一致しない場合は、公開アドレスが変わったか、対象サービスが返すコンテンツの地域、クライアントログを総合的に確認し、単一のデータベースだけに頼らないでください。

IEPL専線、中継、直結は、出口ノードへ到達するまでの転送方式を表します。IEPLは通常、国際区間を専線で運ぶ方式に重点を置き、中継ではまずリレーノードへ通信を送り、直結ではローカルネットワークからリモート入口へ直接アクセスします。これらは経路や安定性に影響しますが、最終的にWebサイトから見えるのは出口ノードの公開アドレスです。グローバルIPだけでは、前段でどの転送方式が使われたかまでは特定できません。

DNSを確認する：ドメイン検索が想定経路を迂回していないか確認

Webサイトへアクセスする前に、端末は通常、ドメインをIPアドレスへ解決します。Webページの通信がVPNを通っていても、DNSリクエストが同じ経路を通るとは限りません。システムがローカルネットワークのリゾルバーへ検索を送っていると、DNSとコンテンツ通信の経路が一致しない状態になります。これは一般にDNSリークと呼ばれます。

検証ではDNS確認ページを使い、リゾルバーのネットワークと地域を確認できます。ただし、「リゾルバーの地域が出口地域と完全に一致すること」を唯一の基準にしないでください。パブリックDNSは近い拠点から接続を受けることがあり、表示されるノード名も実際の物理的位置と一致するとは限りません。重要なのは、ローカルネットワークのリゾルバーが継続的に現れていないか、接続前後でDNSの経路が想定どおり変化したかを確認することです。

ブラウザーのセキュアDNSがテスト結果を変える

最新のブラウザーでは、HTTPSベースのDNS、いわゆるDoHが有効になっている場合があります。この場合、ブラウザーはシステムDNS設定を使わず、指定されたDNSサービスへ暗号化された検索を直接送信します。システムVPNがこの接続を運ぶことはありますが、リゾルバー名がクライアント設定のDNSに変わるわけではありません。ルールプロキシを使っている場合、ブラウザーのDoHリクエストがルールの違いによって直結する可能性もあります。

切り分けでは、まずブラウザーのセキュアDNS設定を確認し、次にクライアントにDNSリダイレクト、仮想DNS、リモート解決、システム解決の利用といった項目があるかを確認します。複数箇所を同時に変更すると、どの設定が効果を生んだのか分かりにくくなります。テスト後は、プライバシー、互換性、経路選択の方針に応じて、システムDNS、クライアントのリモート解決、ブラウザーのセキュアDNSのいずれを使うか決めてください。

DNSキャッシュが「変更が反映されない」ように見せる

システム、ブラウザー、アプリはいずれも、過去に解決したドメインをキャッシュすることがあります。経路を切り替えた直後に、先ほど開いたサイトへアクセスすると、アプリがキャッシュ結果を直接使い、新しいDNS検索を発生させない場合があります。このときDNS確認ログにリクエストが表示されなくても、設定が必ず無効とは限りません。ブラウザーのプロセスを終了し、システムDNSキャッシュを削除するか、これまでアクセスしていないドメインをテストして、解決結果を確認してください。

分散環境ではDNSをルールと組み合わせる

ルールモードでは、ドメイン、IP、プロセス、ルールセットに応じて直結とプロキシを決めます。ドメインを先にローカルDNSで解決すると、クライアントが解決後のIPしか認識できず、ドメインに依存するルールが一致しないことがあります。反対に、すべてのドメインをリモート解決へ渡すと、ローカルサイトに適切でないアドレスが返る可能性があります。成熟したクライアントでは、ドメインスニッフィング、仮想IP、ルールに応じたリゾルバー選択などで対応関係を保ちます。

問題が特定のドメインだけで起きる場合は、ドメインルールが広範な直結ルールの後ろに置かれていないか、ルールセットが更新済みか、そのアプリが独自に暗号化DNSを使っていないかを確認します。DNS結果が正しいのにページへアクセスできない場合は、リゾルバーを替え続けるのではなく、ルート、プロトコルのハンドシェイク、対象サービスの制限を確認してください。

アプリ別に検証する：ブラウザー以外のプログラムも経路を通るか確認

「VPNは接続済みなのにアプリでは使えない」という問題の多くは、実際にはプロキシモードの違いが原因です。システムプロキシは、システム設定に従うプログラムにだけ適用されます。TUNモードは仮想NICでより多くのシステム通信を制御し、アプリ内プロキシは設定したアプリだけに影響します。ブラウザーで対象サイトを開けても、ゲーム、コマンドラインツール、同期ソフト、ストアアプリが同じ経路を使うとは限りません。

同じテストを各アプリで実行する

1. 接続を切り、ブラウザーと対象アプリで現在確認できる出口またはアクセス結果をそれぞれ記録します。
2. 経路に接続し、クライアントにハンドシェイクエラーがないことを確認し、ネットワーク環境は変えないでください。
3. ブラウザーでグローバルIPを再確認し、対象アプリでも同じ種類のネットワークリクエストを実行します。
4. クライアントの接続ログを確認し、対象ドメイン、対象アドレス、プロセスが記録されているか、プロキシと直結のどちらのルールに一致したかを確認します。
5. ブラウザーでは変化したのに対象アプリで変化がない場合は、TUNモードへ切り替えるか、そのアプリ用にクライアントが対応する個別プロキシを設定します。

システムプロキシを無視するアプリ、UDPを使うアプリ、起動時に長時間接続を確立して再利用し続けるアプリがあります。経路を切り替えた後も、古い接続が元の経路に残ることがあります。テスト前に対象アプリを完全に終了し、経路へ接続してから再起動してください。ウィンドウを閉じるだけではバックグラウンドプロセスが終了しない場合があるため、システムのタスク管理画面で実行中か確認します。

ルールモード、グローバルモード、直結ルール

グローバルモードでは通常、クライアントが制御できる通信をまとめてノードへ送るため、問題が経路選択ルールに起因するかを素早く判断できます。ルールモードは対象アドレス、ドメイン、アプリに応じて経路を選ぶため、日常利用に適しています。グローバルモードは正常でルールモードだけ異常なら、プロトコルそのものではなく、ルールの順序、ルールセットのバージョン、プロセスの一致、DNSマッピングを重点的に確認してください。

ローカルネットワーク、プリンター、LANファイル共有、一部のローカルサービスでは通常、直結を残す必要があります。グローバル制御を有効にしてこれらのサービスが使えなくなっても、VPNが無効とは限らず、LANバイパス設定が有効になっていない可能性があります。国際アクセスの確認とローカルネットワークの接続維持は別の目的なので、分けて確認してください。

システムプロキシとTUNモードの違い

プロトコルとサブスクリプションが正常でも、システムルートが正しいとは限らない

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、クライアントからノードへ接続する際のプロトコルまたは伝送方式として利用できます。ただし、これらが解決するのはクライアントとサーバー間の接続をどう確立し、運ぶかという問題です。アプリの通信がその接続へ入るかどうかは、クライアントのシステムプロキシ、TUN、ルート、経路選択の設定で決まります。

たとえば、Shadowsocks、VMess、Trojan、VLESSのノードでクライアントログにハンドシェイク成功と表示されても、システムプロキシが有効でなく、ブラウザーにもプロキシが設定されていなければ、Web通信は直結する可能性があります。Hysteria2とTUICはUDPベースの伝送を使うことが多く、ローカルネットワークがUDPに適していないと、セッションは確立できても実際のリクエストが不安定になることがあります。その場合は他のプロトコルの経路と比較し、ログのタイムアウト、再送、ハンドシェイク失敗を確認してください。接続ボタンの色だけを見て判断するのは避けましょう。

サブスクリプションURLはノード設定を渡すためのもの

サブスクリプションURLは通常、ノードのアドレス、ポート、プロトコルパラメータ、経路名をクライアントへ取り込むために使います。インポートに成功したことは、クライアントが内容を読み取り解析できたことを示すだけで、ノードへの接続やOS通信の制御を意味しません。更新後は、ノードを選択し、対応する制御モードを有効にして、実際の出口をテストする必要があります。

サブスクリプションを更新した後、すべてのノードが突然使えなくなった場合は、まずシステム時刻が正確か、クライアントがサブスクリプション内のプロトコルに対応しているか、古い設定が新しい設定を上書きしていないか、ネットワークがノード入口を遮断していないかを確認します。同じサブスクリプションを複数のクライアントへ繰り返し取り込み、同時に接続するのは避けてください。複数のシステムプロキシや仮想NICが競合すると、ルートの結果がさらに分かりにくくなります。

プラットフォーム別の確認ポイント

Windows

Windowsでは、システムプロキシ、仮想NIC、ルートテーブルを同時に確認します。デスクトッププログラムの一部はシステムプロキシを読み込みますが、直接ネットワーク接続を確立するプログラムもあります。TUNモードでは通常、クライアントが仮想アダプターを作成してルートを書き込みます。権限不足、セキュリティポリシーによるドライバー読み込みの阻止、他のネットワークツールによるルート変更があると、画面には接続成功と表示されても通信が期待どおりトンネルへ入りません。

macOS

macOSクライアントでは、システムVPN設定、ネットワーク拡張、システムプロキシを通じて通信を制御することがあります。初回有効化時には、該当するシステム権限の許可が必要です。システム設定に古いVPN設定や他のネットワーク拡張がある場合は、同時に有効にしないでください。ブラウザーは正常なのにコマンドラインツールが直結する場合、システムプロキシを使っているのか、完全なトンネルモードなのかを確認します。

iOSとAndroid

モバイルプラットフォームでは通常、システムVPNインターフェースで接続を運びますが、省電力設定、バックグラウンド制限、ネットワーク切り替えによってトンネルが中断することがあります。Wi-Fiからモバイルネットワークへ切り替えた後は、システムステータスバーのVPN表示を確認し、出口も再確認してください。Androidクライアントにはアプリ別プロキシや除外アプリのリストが用意されている場合があります。対象プログラムが除外リストに入っていると、そのまま直結します。

Linux

Linuxはネットワークスタックとデスクトップ環境の組み合わせが多いため、環境変数のプロキシ、デスクトッププロキシ、TUNデバイス、ポリシールーティングを区別する必要があります。GUIブラウザーはデスクトッププロキシに従っても、ターミナルプログラムは独自のプロキシ環境変数を読むことがあります。TUNを使う場合は、デバイスが作成されているか、デフォルトルートとポリシールールが書き込まれているか、DNS管理サービスがクライアント設定を上書きしていないかを確認します。

接続済みなのに通信が経路を通らない：順番に切り分ける

切り分けのポイントは、一度に1つの変数だけを変更することです。まず単純な接続と出口の確認から始め、次にDNS、経路選択、プロトコルの層へ進みます。ノード、プロトコル、DNS、クライアントを同時に変更すると、一時的に問題が消えても本当の原因を確認できません。

1. 基本ネットワークが使えることを確認。クライアントを切断して、普段使うWebサイトへアクセスします。基本ネットワーク自体が切断されている場合は、先にローカル接続を復旧してください。
2. クライアント接続を再構築。現在のノードを切断し、競合する可能性のあるネットワークツールを終了してから再接続し、ハンドシェイクログを確認します。
3. グローバル制御へ切り替えて比較。グローバルモードでは有効なのにルールモードでは無効なら、ルールの一致とDNS設定を確認します。
4. 対象アプリを再起動。バックグラウンドプロセスを終了し、古い接続が元の経路を再利用しないようにします。
5. IPv4、IPv6、DNSを個別に確認。一部の通信だけが経路に入り、残りが直結するデュアルスタックの問題がないか確認します。
6. システム時刻と権限を確認。時刻のずれは証明書の検証に影響し、権限不足は仮想NICやシステムVPN設定の適用を妨げることがあります。
7. 異なる経路タイプを比較。特定の入口に現在のネットワークから接続できない場合は、直結、中継、IEPLの経路を比較します。ただし、結果は出口テストで確認してください。
8. サブスクリプションを再インポート。まず無効な設定や重複設定を削除し、信頼できる提供元から取り込みます。古いパラメータや同名ノードによる混乱を避けてください。

よくある症状と確認の方向性

ログでノードのハンドシェイク成功が確認でき、グローバルIPも変わっているのに、特定のWebサイトやアプリだけ使えない場合、問題は通常、「VPNが有効か」という層にはありません。その場合は対象サービスの地域ルール、アカウント地域、キャッシュ、アプリのバージョン、対象経路との互換性を確認してください。1つのサービスへのアクセス結果を、そのまま経路全体の障害と判断しないでください。

最終チェックリスト

• 未接続時と接続時で、グローバルIPに明確な違いがある。
• IPv4とIPv6が期待どおり経路に入り、対応していないプロトコルスタックへの対処も明確になっている。
• DNSの解決経路が現在の構成に合っており、意図せずローカルリゾルバーへ戻っていない。
• ブラウザーと対象アプリを個別にテストし、結果が単一アプリの設定だけに左右されていない。
• クライアントログで対象リクエストを確認でき、想定したプロキシまたは直結ルールに一致している。
• サブスクリプションが更新され、ノードのプロトコルが現在のクライアントと互換性がある。
• プロキシ、ルート、仮想NICを同時に実行して競合する他のツールがシステム上にない。

これらを確認すれば、ノード接続、システムによる通信制御、DNS、アプリ別の経路選択の問題を明確に分けられます。グローバルIPは公開出口の確認に、DNSチェックは解決経路の確認に、アプリ別テストは実際のプログラムがルールに一致しているかの確認に使います。3つを組み合わせる方が、「接続済み」表示だけを見るよりはるかに確実です。