VPNが有効かどうかを判断する際、クライアントに「接続済み」と表示されているかだけでは不十分です。より確実なのは、グローバルIP、DNSの名前解決経路、実際のアプリの通信先を同時に確認する方法です。接続状態はクライアントが特定のネットワークセッションを確立したことを示すだけで、システムプロキシ、仮想NIC、分割ルーティング、アプリ独自の設定によって一部のリクエストが元のネットワークから送信される可能性は残ります。
完全な確認では、いくつかの異なる点を確認します。パブリック通信がどの出口を使っているか、ドメイン名の問い合わせ先がどのリゾルバーか、ブラウザとコマンドラインが同じ経路を通っているか、対象アプリがシステムプロキシを迂回していないかです。これらを総合すれば、「経路が確立していない」「一部の通信だけが処理されている」「経路は正常だがサイト側の判定に問題がある」を切り分けられます。
クライアントが接続済みでも、すべての通信が処理されるとは限りません
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルは通信トンネルを確立しますが、そのトンネルにどのシステム通信を流すかはクライアント側で決まります。よくある処理方式には、システムプロキシ、仮想NICモード、アプリ内プロキシがあります。プロトコルのハンドシェイクが成功しても、ローカルクライアントとリモートノードの間で通信できる状態を示すだけで、すべてのプログラムが同じ経路を使うことを単独で証明するものではありません。
システムプロキシは通常、OSのプロキシ設定に従うアプリにだけ影響します。ブラウザの多くはこの設定を読み込みますが、一部のコマンドラインツール、ゲーム、ダウンロードソフト、独自のネットワークスタックを持つアプリは直接接続する場合があります。仮想NICモードはより低いネットワーク層で通信を処理するため、対象範囲は一般に広くなりますが、ルーティングテーブル、除外リスト、LANルールの影響は受けます。アプリ内プロキシは、設定したプログラムにのみ適用されます。
そのため、テストでは「ブラウザにアクセスできる」ことを「端末全体が経路を使っている」ことと同一視しないでください。逆に、特定のアプリが接続できなくても、ノードが停止しているとは限りません。システムプロキシを読み込んでいない、または使用プロトコルが現在のルールで直接接続に設定されている可能性があります。
| 確認結果 | 考えられる原因 | 次に確認すること |
|---|---|---|
| ブラウザの出口は変わるが、ターミナルは変わらない | システムプロキシのみ有効 | ターミナルのプロキシ変数または仮想NICモードを確認 |
| 出口は変わるが、DNSはローカルネットワークを通る | DNS問い合わせが経路で処理されていない | クライアントのDNSと暗号化DNSの設定を確認 |
| 経路を通るサイトと直接接続するサイトがある | 分割ルーティングが有効 | ドメイン、IP、ルールセットの一致記録を確認 |
| どのテストでも変化がない | プロキシが適用されていない、またはルートが確立していない | システムプロキシ、仮想NIC、デフォルトルートを確認 |
まずグローバルIPでパブリック通信の経路を確認
グローバルIPは、対象サイトから見えるパブリックな送信元アドレスです。経路に接続していない場合は、通常、現在のネットワークのパブリックな出口に対応します。接続後、テストリクエストがリモートノードを経由していれば、ページやAPIに表示されるアドレスは出口の位置に応じて変化します。ここでは接続前後の結果を比較し、アドレスの国や通信事業者名だけで品質を判断しないでください。
テスト前にブラウザキャッシュの影響を一時的に避け、検査ページが新しいネットワークリクエストを送るようにします。プロキシ拡張機能がシステム設定を上書きする可能性があるため、通常のウィンドウと拡張機能の影響を受けないウィンドウでそれぞれ確認するのがおすすめです。端末がIPv4とIPv6の両方に対応している場合は、両方のアドレスを個別に確認してください。一方だけを調べると、もう一方の通信が元のネットワークから送信されていることを見落とす可能性があります。
コマンドラインは、ブラウザとは別の基準として利用できます。次のコマンドで公開されている出口確認APIにリクエストを送ります。
curl https://api.ipify.orgブラウザの結果は変わったのに、コマンドラインが接続前の出口を返す場合、通常はブラウザまたはシステムプロキシだけが設定され、コマンドラインツールがプロキシ設定を読み込んでいません。仮想NICモードを有効にして再実行すれば、OSのルーティングが処理されているかをさらに確認できます。アプリ内プロキシを使う場合は、コマンドでプロキシを明示的に指定して比較することもできます。
グローバルIPの所在地データベースには更新の遅れがある場合があり、検索サービスによって都市名やネットワーク名が異なることもあります。有効性を判断する際は、「アドレスが変わったか」と「異なるアプリで結果が一致するか」を重視し、すべてのデータベースがまったく同じ場所を示すことを求めないでください。
DNSの確認では、名前解決リクエストの行き先を確認する
ドメインにアクセスする前に、端末は通常DNSで対象アドレスを問い合わせます。Web通信が経路に入っていても、DNSリクエストがローカルネットワークのリゾルバーへ直接送られると、名前解決経路とアクセス経路が一致しない場合があります。想定した経路を意図せず迂回する名前解決リクエストは、一般にDNSリークと呼ばれます。
ただし、検査ページにローカルのリゾルバーが表示されても、それだけでクライアントの障害とは限りません。最新のブラウザは暗号化DNSを有効にしていることがあり、OSはキャッシュを使う場合があります。クライアントがリモートDNS、マッピングアドレス、内蔵DNSモジュールを利用することもあります。企業ネットワーク、ホームゲートウェイ、セキュリティソフトが名前解決経路を書き換える可能性もあるため、クライアント設定とシステム状態を合わせて判断してください。
Windowsでは、次のコマンドでドメインの名前解決結果を確認できます。
nslookup example.com
Resolve-DnsName example.commacOSでは、システムが管理するリゾルバー設定を確認できます。
scutil --dnssystemd-resolvedを採用しているLinux環境では、現在のインターフェースとリゾルバーの状態を確認できます。
resolvectl status
resolvectl query example.comこれらのコマンドが示すのはシステム層の情報であり、ブラウザの暗号化DNSはシステムのリゾルバーを迂回する場合があります。コマンドラインとブラウザの検査結果が異なる場合は、ブラウザのセキュアDNS設定を確認してください。クライアントに名前解決を一元管理させる場合は、クライアントのDNSモジュールが有効になっていることを確認し、分割ルーティングによってDNSサーバー自体が誤って直接接続に設定されていないか確認します。
アプリごとのテストで経路を迂回するプログラムを特定する
同じ端末上でも、アプリによって異なるネットワークスタックが使われる場合があります。ブラウザは通常システムプロキシに従いますが、コマンドラインツールが従うかどうかは環境変数と独自のオプションによって決まります。一部のゲームやリアルタイム通信アプリはUDPを使用し、TCP転送にしか対応しないプロキシ方式を無視することがあります。アプリ内蔵プロキシ、暗号化DNS、接続の多重化機能などにより、システム設定とは異なる動作をするアプリもあります。
切り分けでは、ブラウザ、ターミナル、実際の対象アプリでそれぞれ通信を行い、クライアントの接続ログを確認します。クライアントがプロセスや対象ドメインごとのログに対応している場合は、リクエストが最終的にプロキシ、直接接続、拒否のどのルールに一致したかを重点的に確認してください。ログにドメインが出ているかだけでなく、その記録の送信ポリシーも確認する必要があります。
- ブラウザで出口確認ページを更新し、アドレスが変わったかを記録します。
- ターミナルで出口確認コマンドを実行し、ブラウザの結果と比較します。
- ブラウザ内蔵の暗号化DNSを無効にして再テストし、必要に応じて設定を元に戻します。
- 対象アプリを開いて実際のリクエストを実行し、同時にクライアントの接続ログを確認します。
- ルールに一致しない通信のデフォルトポリシーが、プロキシか直接接続かを確認します。
- アプリがUDPを使用する場合は、現在の処理モードと経路設定が対応する通信をサポートしているか確認します。
対象アプリだけが経路を通らない場合は、ノードを何度も変更する前に、アプリのプロキシ設定、プロセス単位の分割ルーティング、UDP処理を確認してください。すべてのアプリで変化がない場合は、システムプロキシ、仮想NICの権限、ルーティングテーブルに戻って確認します。アプリごとのテストは問題の範囲を絞り込み、ルールの問題を経路の問題と誤認しないために役立ちます。
分割ルーティングでは「一部だけ有効」が正常な結果になる
分割ルーティングの目的は、すべてのリクエストを同じ出口から送ることではなく、ドメイン、IP、アプリ、ネットワークの種類に応じてプロキシと直接接続を選ぶことです。たとえば、ローカルサービスは直接接続し、国際アクセスのリクエストはグローバル経路を通し、LANアドレスはローカルネットワークに留めます。この場合、サイトによって異なる出口が表示されるのは、ルール設計の結果である可能性があります。
ルールの照合には通常、優先順位があります。ドメインルールがIPルールより先に適用され、どのルールにも一致しないリクエストは最終ルールで処理されることがあります。サブスクリプションのルールセットを有効にすると、古いルール、ユーザー定義ルール、クライアントのデフォルトルールが同時に存在する場合もあります。切り分けでは、ルールファイルの文面だけで推測せず、実際の接続ログから一致した項目を確認してください。
DNSポリシーも分割ルーティングの精度に影響します。クライアントがドメイン名で経路を判断していても、アプリが先にドメインをIPへ解決して直接接続すると、クライアントにはアドレスしか見えず、元のドメインルールを適用できない場合があります。仮想NICモードのDNSリダイレクトやアドレスマッピングで可視性を改善できることがありますが、設定が一致しないと名前解決は成功しても接続に失敗する可能性があります。
プラットフォーム別の確認ポイント
Windows
Windowsでは、システムプロキシ、仮想NICの状態、DNSインターフェースの優先順位を同時に確認します。デスクトップアプリの一部はシステムプロキシを読み込まないため、ブラウザは正常でも他のアプリが直接接続することは珍しくありません。処理モードを切り替えた後は、既存の接続が古い経路を再利用しないよう、対象アプリを再起動して確認してください。
macOSとiOS
macOSのクライアントはシステムプロキシを使う場合と、ネットワーク拡張を作成する場合があります。両者では処理範囲が異なります。iOSのクライアントは通常、システムが提供するVPNネットワーク拡張を通じて通信を処理しますが、アプリ独自の暗号化DNS、LANアクセスのポリシー、オンデマンド接続も検査結果に影響します。設定を切り替えた後は、検査ページで接続を再確立してください。
Android
Androidのクライアントは一般にシステムVPNインターフェースで通信を処理し、アプリごとのプロキシや迂回リストを提供することがあります。特定のアプリだけ出口が変わらない場合は、まずそのアプリが除外されていないか確認してください。システムのプライベートDNSはクライアントのDNSポリシーとは独立して動作することもあるため、クライアントのドキュメントを確認し、維持するか経路側に任せるかを判断します。
Linux
Linux環境では、デスクトッププロキシ、環境変数、ルーティングテーブル、DNS管理コンポーネントの違いが主な要因です。GUIで設定した内容がターミナルのプロセスに影響するとは限らず、ターミナルのプロキシ変数がシステムサービスに影響するとも限りません。切り分けでは、現在のシェル、サービスプロセス、仮想NICのルートを個別に確認し、同じ設定を共有していると決めつけないでください。
接続済みなのに検査に失敗する場合の確認手順
接続状態は正常なのに出口が変わらない場合は、クライアントを何度も再インストールするより、ネットワーク層に沿って段階的に確認する方が効果的です。まずリクエストがクライアントに入っているか、次にクライアントがどの送信先へ渡しているか、最後にリモート経路と名前解決結果を確認します。
- 経路を切断し、現在のグローバルIPとDNSの状態を記録して比較用の基準を作ります。
- 再接続後、クライアントにハンドシェイク、権限、設定の解析エラーがないことを確認します。
- システムプロキシが書き込まれているか、または仮想NICが正常に作成され、ルートを取得しているか確認します。
- テストリクエストの接続ログを確認し、直接接続ではなくプロキシルールに一致していることを確認します。
- ブラウザ、ターミナル、対象アプリを個別にテストし、問題が特定のプログラムに限られるか判断します。
- ブラウザの暗号化DNS、システムDNS、クライアントDNSが互いに上書きしていないか確認します。
- IPv4とIPv6の通信がどちらも想定どおりか確認し、一方のプロトコルスタックだけが処理される状態を避けます。
- 経路を変更して再テストし、ローカル設定の問題と特定ノードの接続問題を切り分けます。
接続ログにテストリクエストがまったく表示されない場合、問題は通常、アプリとクライアントの間にあります。プロキシ設定、仮想NICの権限、アプリの除外リストを確認してください。ログに直接接続と表示される場合は、分割ルーティングを重点的に確認します。プロキシと表示されているのに出口が変わらない場合は、検査ページがキャッシュを使っていないことを確認し、クライアントが実際に選択したリモートノードと送信経路を調べます。
IEPL専線、中継経路、直接接続は、それぞれ異なる通信経路を指します。直接接続では端末がリモートノードへ直接接続し、中継では入口に接続してから中継ネットワークを通じて出口へ送ります。IEPL専線は通常、入口と出口の間を専用経路で転送するために使われます。どの経路でも、サイトから最終的に見えるのは設定に対応した出口であり、入口ノードではありません。出口確認で最終的な送信元アドレスは検証できますが、検査ページだけで通信全体の経路を判断することはできません。
信頼できる最終判断の出し方
信頼できる判断は、複数の結果が互いに一致することで得られます。ブラウザとコマンドラインの出口が想定どおりで、DNS問い合わせが設定したポリシーに従い、対象アプリの接続ログが正しい送信先を示し、分割ルーティング時の直接接続とプロキシの結果もルールと一致していることが重要です。特定の検査サイトだけが異常を報告する場合は、別の方法でも確認し、データベース上の所在地、キャッシュ、ブラウザのネットワーク機能による違いを考慮してください。
テストが終わったら、日常利用に必要な暗号化DNS、分割ルーティング、アプリの除外設定を元に戻せます。確認の目的は、すべての通信を長期間同じ出口から送ることではなく、各種の通信が設定どおりに処理されているかを確かめることです。クライアントの接続成功表示は出発点にすぎません。グローバルIP、DNS経路、アプリごとの接続記録を組み合わせることで、より完全な検証ができます。