VPN が本当に機能しているかを確認する際、クライアントに「接続済み」と表示されているだけでは不十分です。この表示は通常、ローカルのプロキシコアが起動したか、クライアントと選択した経路のハンドシェイクが完了したことを示すにとどまります。ブラウザ、デスクトップアプリ、コマンドラインプログラムの通信がすべて目的の出口を経由していることを単独で証明するものではありません。確実に判断するには、出口IP、DNSの解決経路、各アプリの実際の通信を同時に確認します。
確認する前に、接続モードを明確にしましょう。TUNを有効にしたクライアントは通常、仮想ネットワークインターフェースを作成してシステムのルーティングを引き受けます。システムプロキシモードは、OSのプロキシ設定に従うアプリに主に影響します。ブラウザ拡張機能は、そのブラウザ内のリクエストだけを処理します。スプリットトンネルでは、一部の宛先がプロキシを経由し、他は直接接続になります。モードによって「有効」の範囲は異なるため、1つの結果だけで端末全体を判断することはできません。
まずクライアントが実際に引き受けている範囲を確認する
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれもプロキシ通信を運べますが、プロトコル名だけでシステム通信がトンネルに入る方法まで決まるわけではありません。適用範囲を左右するのは、システムプロキシ、TUN仮想インターフェース、アプリ内プロキシ、手動設定したローカルポートなど、クライアントが採用する入口です。ノードが正常に接続していても、プロキシ入口に取り込まれていないアプリは直接ネットワークへアクセスします。
| 接続方式 | 通常カバーされる範囲 | 「接続済み」が通常意味すること | 追加で確認する項目 |
|---|---|---|---|
| TUNモード | システムルートによって仮想インターフェースへ送られる通信 | 仮想インターフェースとプロキシコアが稼働している | デフォルトルート、除外ルール、IPv6経路 |
| システムプロキシ | システムプロキシ設定に従うアプリ | ローカルプロキシポートが起動し、システム設定に反映されている | アプリがプロキシを無視していないか、設定が上書きされていないか |
| ブラウザプロキシ | 指定したブラウザまたは指定したプロファイル | 拡張機能またはブラウザのプロキシ設定が有効になっている | 他のアプリは直接接続のままの場合があり、ブラウザのDNSも個別に確認が必要 |
| スプリットトンネルモード | ルールに一致したドメイン、アドレス、アプリのみ | ルールエンジンと経路が利用可能である | 対象リクエストがプロキシルールと直接接続ルールのどちらに一致したか |
サブスクリプションURLは設定を取り込むための入口にすぎません。クライアントにサブスクリプションをインポートすると、経路、プロトコルパラメータ、場合によってはスプリットトンネルルールを取得できますが、インポートに成功したからといってシステムプロキシが有効になったとは限りません。デスクトップクライアントの中には、「ノードを選択」「コアを起動」「システムプロキシを設定」が別々の操作になっているものがあります。モバイル端末では、システムのVPNインターフェースを通じて通信を引き受けることが一般的です。確認時はまず現在のモードを確認し、そのうえでテスト結果が妥当か判断してください。
- ✅ 現在選択しているのが自動選択や前回の経路ではなく、想定した経路であることを確認した
- ✅ システムプロキシ、TUN、アプリ内プロキシの少なくとも1つが有効になっていることを確認した
- ✅ スプリットトンネルモードの名称を確認し、テスト対象のドメインがプロキシと直接接続のどちらを通る想定か把握した
- ❌ クライアントのタイマーやステータスの色が変わっただけで、すべてのアプリが引き受けられたと判断する
- ❌ サブスクリプションをインポートしただけで経路を起動せず、通信をローカルプロキシインターフェースへ送っていない
出口IPを接続前後で比較する
出口IPは最も直接的な確認項目です。接続後に検索ページを1つ開くだけではなく、まずVPNを切断して現在の公開出口IP、ネットワーク事業者、大まかな地域を記録します。その後、テストページを閉じ、目的の経路に接続してから再度検索します。IPアドレスとネットワークの帰属先が想定どおり変われば、そのテスト通信はおそらくプロキシの出口を経由しています。
- クライアントを一時的に切断し、個別にプロキシを設定している可能性のあるブラウザ拡張機能も無効にします。
- ブラウザで公開IPを検索し、直接接続時の基準としてアドレス、ネットワークの帰属先、地域情報を記録します。
- 確認したい経路に接続し、システムプロキシまたはTUNモードが有効になっていることを確認します。
- 古いページのキャッシュや長時間接続の影響を避けるため、新しいプライベートウィンドウで再度検索します。
- 別のアプリからもリクエストを送信し、同じプロキシ出口になるか確認します。
接続前後でアドレスがまったく変わらなくても、すぐにノードの故障と判断しないでください。ブラウザで独立したプロキシ拡張機能が有効になっていたり、システムプロキシの反映に失敗していたり、対象サイトが接続前に確立した長時間接続を再利用していたりする可能性があります。関連ページを閉じて開き直すか、拡張機能のない別のブラウザで試すと、こうした要因を切り分けられます。
スプリットトンネルのルールにも注意が必要です。ルールモードでは、日本国内向けのサイト、ローカルネットワークのアドレス、指定サービスなどが直接接続になるよう設計されている場合があります。そのため、直接接続の対象を検索して元のネットワーク出口が表示されても矛盾ではありません。プロキシルールに明確に一致する対象を選ぶか、一時的にグローバルプロキシへ切り替えて比較してください。テスト後は元のスプリットトンネルモードに戻し、プロキシ不要の通信を長期間迂回させないようにします。
ブラウザの結果は変わるのに、他のソフトは変わらない
この場合、プロキシの適用範囲がブラウザだけになっている可能性が高いです。ブラウザ拡張機能が有効になっている、またはデスクトップクライアントがシステムプロキシだけを設定し、対象ソフトがシステムプロキシを無視していることが主な原因です。ゲームランチャー、同期ツール、コマンドラインプログラム、独自のネットワークスタックを使う一部のソフトは、システムプロキシ設定を読み取らない場合があります。アプリごとにプロキシを設定するか、通信を引き受けられるTUNモードへ切り替えてください。
DNSリクエストが想定した経路で解決されているか確認する
出口IPが変わった後も、DNSを確認する必要があります。DNSはドメイン名をネットワークアドレスへ変換します。ウェブリクエストがプロキシ経路を通っていても、ドメインがローカルネットワークのリゾルバーで解決されていれば、アクセス先と名前解決の経路が分離しています。これは一般にDNSリークと呼ばれます。ただし、明確に設計されたスプリットトンネルでは、直接接続のドメインにローカルDNS、プロキシ対象のドメインにリモートDNSを使うことも正常な動作です。判断にはルールの想定を合わせて確認してください。
ブラウザのDNS検査ページでは、解決に参加したサーバーとそのネットワークの帰属先を確認できます。経路に接続した後もプロキシ対象のドメインがローカルネットワークのリゾルバーで解決され続ける場合は、クライアントのDNSモード、リモート解決オプション、ブラウザ独自の暗号化DNS設定を確認してください。ブラウザがOSのリゾルバーを迂回したり、クライアントが仮想DNSやドメインスニッフィングでスプリットトンネルを補助したりすることがあります。両者の設定が衝突すると、結果の解釈が難しくなります。
システム側では、まず現在のDNS設定を確認できます。以下のコマンドは確認専用で、ネットワーク設定は変更しません。
Windows
ipconfig /all
nslookup example.com
macOS
scutil --dns
nslookup example.com
Linux
resolvectl status
nslookup example.comnslookup に表示されるのは、そのクエリで使用されたリゾルバーですが、ブラウザの解決経路を完全に示すとは限りません。ブラウザ独自のセキュアDNSが有効な場合、システムコマンドとブラウザの検査結果が異なることがあります。そのため、システムとブラウザの両方で確認し、クライアントのログに対象ドメインが現れているかも合わせて判断してください。
IPv6によって結果が矛盾して見える理由
端末がIPv4とIPv6の両方に対応している場合があります。クライアントが一方のプロトコルだけを引き受け、ブラウザがもう一方の利用可能な経路を優先すると、一部のリクエストは経路を通り、別のリクエストは直接接続になることがあります。このとき、IP検索ページに想定と異なる出口が表示されたり、DNSが返すアドレスの種類によって最終経路が変わったりします。
切り分けでは、クライアントがIPv6対応を明示しているか、TUNインターフェースが対応するルートを取得しているか、スプリットトンネルのルールが両方のアドレス種別を処理しているかを確認します。IPv6を無効にすることを、恒久的で汎用的な解決策と考えないでください。クライアントが正しく通信を引き受けられることを確認するか、管理されていない経路を対象アプリに提供しないようシステム側で明確に制御する方が確実です。
アプリごとに確認し、ブラウザだけで端末全体を判断しない
ブラウザのテストに成功しても、現在のブラウザのリクエストがおそらく想定した出口を通ったことしか証明できません。会議アプリ、クラウドストレージ、開発ツール、デスクトップクライアント、ターミナルプログラムを使う場合は、それぞれ確認が必要です。アプリによってプロキシ設定の読み取り方が異なり、システム設定を迂回して直接接続することもあります。
- 対象の経路への接続を維持し、ブラウザの出口が変わったことを確認します。
- 接続前に確立したセッションを引き継がないよう、確認するアプリを完全に終了してから再起動します。
- クライアントの接続ログを確認し、そのアプリが対象へアクセスした際に新しいリクエストが発生しているかを見ます。
- クライアントがプロセス別またはルール別の一致結果を表示できる場合は、リクエストがプロキシルールに入っていることを確認します。
- 直接接続に切り替えて同じ操作を繰り返し、アプリの動作とログに変化があるか比較します。
ログは「開けるかどうか」よりも判断材料として有用です。あるサービスが直接接続でもプロキシ環境でも正常に使える場合、ページが表示できるだけでは経路を確認できません。クライアントログに対象ドメイン、対象アドレス、ルール名、選択した経路が記録されていれば、アプリの動作と実際の転送経路を対応付けられます。ログを共有する前に、サブスクリプションURL、認証情報、完全な設定内容を削除してください。
コマンドラインツールも個別設定になっていることがよくあります。ターミナルの環境変数、ツール固有のプロキシパラメータ、システムプロキシは互いに異なる場合があります。ブラウザの出口が変わったのにターミナルのリクエストが直接接続のままなら、現在のターミナルセッションが古いプロキシ環境を引き継いでいないか、使用中のツールがシステムプロキシを明示的に無視していないか確認します。変更後はターミナルを開き直す方が、古いセッションで何度も試すより安定した結果を得やすくなります。
接続済みなのに通信が経路を通らない主な原因
システムプロキシの反映に失敗している
クライアントのコアはノードへ正常に接続できても、OSに古いプロキシ、手動プロキシ、自動設定スクリプトが残っていることがあります。この場合、クライアントには接続済みと表示されますが、アプリのリクエストはローカルプロキシポートへ送られません。他のプロキシツールを終了し、システムのネットワーク設定を確認してから、クライアントでシステムプロキシを再度有効にしてください。
TUNルートが他のネットワークツールに上書きされている
仮想マシン、コンテナ、企業ネットワーククライアント、その他の仮想ネットワークインターフェースがルートの優先順位を変更することがあります。TUNインターフェースが存在していても、デフォルト通信がより優先度の高いルートへ送られる場合があります。切り分けでは、ネットワーク経路を変更するプログラムを一時的に終了し、経路へ再接続してから1つずつ戻すと、競合元を特定できます。
ルールによってテスト対象が直接接続と判定されている
ドメインルール、アドレスルール、地域ルールによって結果が異なることがあります。対象ドメインがDNSでアドレスに変換された後、別のアドレスルールで上書きされる場合もあります。ルール一覧を読むだけでなく、クライアントログに記録された最終的な一致ルールを確認する方が確実です。グローバルモードでは正常でルールモードだけ異常なら、問題は通常、経路のハンドシェイクではなくルールとDNSの連携にあります。
ブラウザが古い接続や独自のDNS設定を保持している
最新のブラウザは接続を再利用し、独自の暗号化DNSを有効にしている場合もあります。VPN接続後に古いページを更新するだけでは、新しいネットワークセッションが確立されないことがあります。ブラウザを完全に終了して開き直し、新しいプライベートウィンドウを使って、システムDNSとブラウザDNSの結果を比較すると誤判定を減らせます。
サブスクリプション更新後も古い設定を使っている
サブスクリプションの更新で経路パラメータやルールが変わっても、一部のクライアントでは新しいノードへ手動で切り替えるか、設定を再読み込みしなければ反映されません。現在有効な設定の名前、更新時刻、選択中の経路を確認し、サブスクリプション一覧に新しい内容が表示されているかだけで判断しないでください。サブスクリプションURL自体が機密性の高い認証情報にあたるため、公開の検査サイトやスクリーンショットに貼り付けないでください。
決めた順番で最終確認を行う
「クライアントには接続済みと表示されるのに、アクセス経路が変わらない」場合は、プロトコルやノードを頻繁に変えるのではなく、入口から出口まで段階的に確認するのが最も効果的です。一度に変更する条件を1つに絞ることで、どの設定が結果を変えたのか把握できます。
- ✅ 現在の設定、経路、接続モードが想定どおりか確認する
- ✅ 経路を切断して直接接続時の出口を記録し、接続後に新しいウィンドウで再比較する
- ✅ プロキシ対象のDNSリゾルバーとクライアントのDNS設定を確認する
- ✅ ブラウザ、デスクトップアプリ、コマンドラインプログラムを個別にテストする
- ✅ ログで最終ルール、対象アドレス、実際に選択された経路を確認する
- ✅ IPv6、仮想ネットワークインターフェース、他のネットワークツールによる迂回を確認する
- ❌ ノード、プロトコル、DNS、スプリットトンネルルールを同時に変更し、原因を特定できなくする
- ❌ 地域ラベルが正確でないことだけを、接続が有効でない証拠とみなす
出口IPが変わらない場合は、まず通信の入口とシステムプロキシを確認します。出口は変わったのにDNS経路が異常なら、リモート解決、ブラウザDNS、スプリットトンネルの方針を確認します。ブラウザは正常で特定のアプリだけ異常なら、そのアプリがシステムプロキシを読み取るか、TUNによる引き受けが必要かを確認します。一部の対象だけ異常なら、ルールの一致状況とアドレス種別を重点的に見ます。この順番で、クライアントの入口、DNS、ルーティング、アプリ設定のどの層に問題があるか絞り込めます。