VPNが本当に機能しているかは、クライアントの「接続済み」表示だけでは判断できません。この表示が示すのは、通常、ローカルクライアントとリモートノードのハンドシェイク完了、またはシステム上で仮想ネットワークインターフェースが確立されたことです。ブラウザ、コマンドライン、ゲームなどの各アプリが想定した出口を通っているかは、出口IP、DNSの経路、ルーティング結果を個別に確認する必要があります。
信頼できる確認では、いくつかの点を確認します。インターネット上で見えるアドレスが変わったか、選択した地域と一致しているか、ドメインの問い合わせ先はどこか、対象アプリがプロキシに入っているか、切断後に通信が元のネットワークへ戻らないか、という点です。一つだけを確認すると、「正常に見える」不完全な結論になりがちです。
何をもって本当に有効とするかを決める
「有効」とは単一の状態ではなく、アプリからリモートの出口まで、経路全体が設定どおりになっている状態です。クライアントのハンドシェイク成功は経路の入口にすぎません。システムのルーティング、プロキシモード、DNS設定、アプリ独自のネットワークスタックのどこか一つでも設定を迂回すれば、最終結果は変わる可能性があります。
| 確認レイヤー | 確認する結果 | よくある誤判定 |
|---|---|---|
| クライアント接続 | ノードのハンドシェイクが完了し、仮想インターフェースまたはローカルプロキシポートが正常に動作している | 「ハンドシェイク成功」を、すべての通信が転送されたこととそのまま解釈する |
| インターネット側の出口 | 対象アプリに、想定した出口アドレス、地域、ネットワーク事業者が表示される | 地図のラベルだけを見て、事業者やアドレスファミリーを確認しない |
| DNS解決 | ドメインへの問い合わせが、クライアントまたはシステムのルールに従って想定したリゾルバーへ送られる | 出口は変わったのに、名前解決だけはローカルネットワークが直接行っている |
| アプリ別ルーティング | プロキシ対象のアプリは回線を経由し、直結対象のアプリは直接接続を維持する | ブラウザだけをテストし、ほかのプログラムも同じ結果だと思い込む |
| 異常時のフォールバック | ノード切断後の動作が、ブロックまたはフォールバックの設定どおりになる | 切断後に自動で直接接続へ戻っているのに、保護が継続していると思い込む |
したがって、最低限必要な検証サイクルは「接続前に記録、接続後に比較、アプリごとに再確認、切断後に観察」です。出口とDNSが正しいのに特定のアプリだけ元のネットワークを表示する場合、問題は回線そのものではなく、システムプロキシの適用範囲、アプリのプロキシ設定、またはルーティングルールにあることが多いでしょう。
出口IPでインターネット上から見えるアドレスを確認する
出口IPは、最も分かりやすい確認ポイントです。接続前後に同じブラウザセッションで信頼できるIP確認ページを開き、公開アドレス、国や地域、AS番号、ネットワーク事業者を比較します。地域は想定どおりでも事業者が予想外だからといって、必ずしも異常とは限りません。データセンター、家庭向け回線、モバイル回線ではアドレスの登録方法が異なるためです。ただし、選択した回線の性質とは少なくとも一致している必要があります。
確認時は、地図上の位置だけに注目しないでください。IP位置情報データベースはリアルタイムではなく、同じアドレス帯でもデータベースによって隣接都市として表示されたり、ネットワーク事業者の登録地が表示されたりします。海外回線では、都市レベルの位置情報よりも、国や地域、AS番号、サービスへのアクセス結果のほうが参考になります。
IPv4とIPv6を同時に確認する
クライアントによってはIPv4だけを制御し、端末が元のネットワークからIPv6リクエストを直接送信できる場合があります。このとき一般的な確認ページがプロキシ経由のIPv4を使うと、切り替わったように見えます。一方、IPv6対応アプリは別の経路を通る可能性があります。確認ページに両方のアドレスファミリーが表示される場合は、それぞれ確認してください。クライアントがIPv6を処理できない場合は、必要に応じてそのアドレスファミリーを無効にするか、システム通信を完全に制御できるモードを使用します。
ブラウザのキャッシュと既存接続を切り分ける
ブラウザは、接続前に確立したセッションを再利用することがあります。ノードを切り替えてすぐに更新しても、既存接続が直ちに再構築されるとは限りません。より確実なのは、関連ページを閉じて既存セッションが終了するまで待ち、新しいプライベートウィンドウで確認する方法です。コマンドラインツールも併用すると、ブラウザ拡張機能、キャッシュ、セキュアDNS設定の影響を一部避けて検証できます。
- クライアントを切断し、現在の公開アドレス、地域、ネットワーク事業者を記録する。
- 対象ノードへ接続し、クライアントが再接続を繰り返したり、ハンドシェイクエラーを出したりしていないことを確認する。
- 確認ページを開き直し、出口アドレスとアドレスファミリーを比較する。
- ブラウザ設定を共有しない別のツールでも再確認する。
- ノードを切り替えて確認を繰り返し、出口が回線に応じて実際に変わることを確認する。
DNS解決がローカルネットワークへ戻っていないか確認する
ウェブサイトへアクセスする前に、端末は通常ドメイン名をアドレスへ解決します。ページの内容が海外回線を通っていても、ドメイン問い合わせが同じ経路を通るとは限りません。DNSリクエストが現在のネットワークのリゾルバーへ直接送られると、外部から問い合わせたドメインを観測される可能性があります。また、解決結果が出口地域と一致せず、コンテンツの地域判定を誤ったり、不適切なサービスノードへ接続したりすることもあります。
DNS確認ページには、名前解決に参加したサーバーとネットワーク事業者が表示されることが多いです。接続後もローカルネットワーク事業者のリゾルバーが表示される場合は、さらに調査が必要です。ただし、VPNの出口と異なる事業者が表示されても、必ずしも漏れとは限りません。公開DNSは分散ノードを使うため、表示されるのは実際の位置ではなく、再帰リゾルバーの出口である可能性があります。
ブラウザのセキュアDNSが確認結果を変える
最新のブラウザは暗号化DNSを独自に使用でき、システム設定に完全には従わないことがあります。そのため、同じ端末でもブラウザとコマンドラインの結果が異なる場合があります。ブラウザは独自の名前解決サービスへ問い合わせ、ほかのアプリはシステムDNSを使うためです。確認時は、ブラウザで独立したセキュアDNSが有効かを先に確認し、それが想定した設定なのか、クライアントのルールを迂回しているのかを判断します。
Fake IPとリモートDNSは表示アドレスだけで判断しない
一部のTUNクライアントはFake IP方式を使い、まずドメインに予約用途のマッピングアドレスを割り当て、クライアント内部でドメイン名を復元してリモートDNSへ渡します。アプリに見えるのはウェブサイトの実アドレスではありませんが、リクエストが正しくトンネルを通っている場合もあります。この場合、ローカルの名前解決結果だけで異常と判断せず、クライアントログのドメイン照合、DNS上流、最終ルートを確認してください。
- ✅ 接続前後にDNSチェックを実行し、リゾルバーのネットワーク事業者を記録する。
- ✅ ブラウザとシステムツールを比較し、異なる名前解決経路を使っていないか確認する。
- ✅ クライアントのDNSモード、リモートDNS設定、ルーティングルールが一致しているか確認する。
- ✅ IPv4とIPv6の問い合わせが、どちらも想定したポリシーに従っているか確認する。
- ❌ リゾルバーの地域とノードの都市が違うだけで、すぐに漏れと判断しない。
- ❌ ブラウザで独立したセキュアDNSを有効にした後、その結果をシステムDNSの状態として扱わない。
ブラウザ、コマンドライン、アプリを個別に確認する
ブラウザが通信できても、すべてのアプリが通信できるとは限りません。システムプロキシモードが主に影響するのは、システムのプロキシ設定を参照するソフトウェアです。システムプロキシを無視したり、独自にUDPセッションを確立したり、独立したネットワークスタックを使うプログラムは、直接接続する可能性があります。TUNモードは仮想ネットワークインターフェースでIP通信を制御するため、通常は適用範囲が広くなりますが、最終的にはルーティングテーブル、除外設定、システム権限の影響を受けます。
ブラウザ
まずプロキシを書き換える可能性のある拡張機能を無効にし、出口とDNSを確認します。ブラウザは正常でほかのアプリだけ異常なら、ノード自体はおそらく利用可能です。システムプロキシの適用範囲とアプリ設定を確認してください。特定のブラウザだけ異常な場合は、セキュアDNS、プロキシ拡張機能、キャッシュ接続、企業ポリシーも確認します。
コマンドラインと開発ツール
ターミナルプログラムがプロキシを継承するかどうかは、ツール本体と環境変数によって決まります。HTTPまたはSOCKSプロキシの環境変数を読むツールもあれば、システムのネットワークインターフェースを直接使うツールもあります。ローカルプロキシポートを使う場合は、HTTPプロキシとSOCKSプロキシを区別し、ドメインをローカルで解決するのか、プロキシ側で解決するのかも確認してください。ウェブ閲覧は正常なのにパッケージのダウンロードが直接接続になるのは、コマンドラインツールがシステムプロキシを読み取っていないことがよくある原因です。
メッセージアプリ、ゲーム、その他の独立したアプリ
これらのアプリは、TCP、UDP、長時間接続、独自DNSを組み合わせて使うことがあります。ログインできるかどうかだけでは、経路全体を判断できません。まずアプリを完全に終了し、ノードへ接続してから再起動します。その後、クライアント接続ログにある対象ドメイン、アドレス、適用ルールを確認します。ルールが直接接続を示すなら、ルーティングを調整してください。プロキシと表示されているのにアプリが失敗する場合は、プロトコルのUDP対応、ノードの入口、対象サービスの制限を確認します。
アプリ別プロキシには、見落としやすい方向性もあります。ルールによってローカルサービスを意図的に直接接続する場合です。このときアプリごとに異なる出口が表示されるのは設計どおりで、障害ではありません。すべてのリクエストを同じ経路に通すことが目的ではなく、各リクエストが想定したルールに一致していることを確認するのが目的です。
プロトコルとクライアントモードの範囲を理解する
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれもプロキシ通信を運べますが、「インストールすればすべてのアプリを自動的に制御する」スイッチではありません。プロトコルはクライアントとサーバー間のデータ転送方法を担い、どのローカルリクエストをその通信経路へ入れるかは、システムプロキシ、TUN、ルーティングルール、DNSモジュールが決めます。
Shadowsocksは暗号化プロキシプロトコルで、通常はクライアントがローカルのSOCKSまたはHTTPの入口を提供します。VMessとVLESSは複数のトランスポート構成に対応するクライアントでよく使われます。VLESS自体はプロトコル内蔵の暗号化に依存せず、通常はTLSなどの安全なトランスポートと組み合わせます。TrojanはTLSで通信を運びます。Hysteria2とTUICはQUICの考え方に基づいて通信を処理するため、揺らぎやパケットロスのある環境では従来のTCPプロキシと異なる挙動を示し、通常はUDP対応をより重視します。
プロトコル名だけでは、DNSが制御されていることも、アプリがプロキシに入っていることも証明できません。サブスクリプションの取り込みに成功しても、クライアントがシステムプロキシのみのモードに留まる場合があります。TUNを有効にしても、除外ルートや権限の問題で一部の通信が迂回する可能性があります。問題を判断するときは、「プロトコルが接続できるか」と「システムが正しく通信を振り分けているか」を分けて考えてください。
サブスクリプションリンクとクライアントへの取り込み
サブスクリプションリンクには通常、ノード名、サーバーの入口、ポート、認証情報、トランスポートパラメータ、TLS関連設定が含まれます。取り込みに成功したのは、クライアントが設定を読み取れたことを示すだけで、ノードへ接続できることも、現在そのノードが選択されていることも意味しません。サブスクリプションを更新した後は、現在の設定が置き換わっていないか、グループで正しい回線が選ばれているか、ローカルの上書きルールが引き続き有効かを確認します。
WindowsとmacOSのクライアントは通常、システムプロキシとTUNの両方を提供しますが、システム権限、ルート処理、DNSの制御方法は完全には同じではありません。AndroidはシステムVPNインターフェースを使ってローカルトンネルを構築し、アプリ単位で対象に含めたり除外したりできます。iOSもシステムが提供するネットワーク拡張機能に依存し、バックグラウンド動作やルール実装はクライアントによって異なります。プラットフォーム間で設定を移行する際、同じ名前のスイッチがまったく同じ効果を持つとは考えないでください。
直接接続・中継・IEPL専線で何が変わるか
回線タイプは、クライアントから出口までどのようなネットワーク経路を通るかを示すもので、プロキシプロトコルではありません。直接接続は端末から海外ノードの入口へ直接接続する方式で、経路がシンプルな一方、品質は公衆ネットワークのルーティングに左右されます。中継は近い入口へ接続してから、サービス側で最終出口へ転送する方式です。一部の不安定な公衆ネットワーク区間を避けられます。IEPL専線は通常、国境をまたぐ専用の通信経路を指し、入口から出口までの伝送方式が重視されます。
どの回線を使っていても、最終的な確認方法は変わりません。公開出口が正しいか、DNSがポリシーどおりに解決されているか、アプリが想定したアウトバウンドに一致しているかを確認します。回線名だけでは結果の確認に代えられません。中継の入口が近隣にあっても、公開IP確認で表示されるべきなのは最終出口です。入口アドレスや元のネットワークアドレスが表示される場合は、サーバー側の転送とクライアントのルーティングを確認してください。
回線には接続できても利用体験に問題がある場合、すぐにプロトコルが原因だと決めつけないでください。DNSが出口地域に適さないアドレスを返している、ルーティングルールが静的リソースを直接接続にしている、対象サイトがIPの信頼度やアカウント地域に応じて異なる対応をしている、といった可能性があります。出口、DNS、ルールの適用、アプリの応答を分けて記録すると、ノードを何度も切り替えるより原因を見つけやすくなります。
接続済みでも経由していない典型例
- ❌ クライアントのハンドシェイクは成功したが、システムプロキシが有効になっておらず、ブラウザは元のネットワークを使っている。
- ❌ ブラウザはプロキシを読み取ったが、コマンドラインツールがプロキシ環境変数を読み取らず、ダウンロードが直接接続になっている。
- ❌ IPv4はノードを経由しているが、IPv6は直接接続のままで、デュアルスタック対応アプリの出口が異なっている。
- ❌ 出口は変わったが、DNSは現在のネットワークが直接解決しており、地域判定にずれが生じている。
- ❌ ルーティングルールが対象ドメインを直接接続にしているのに、クライアントログにはノード全体がオンラインだとしか表示されていない。
- ❌ ノード切り替え後もブラウザが既存接続を再利用し、短時間は前の経路を表示している。
- ❌ TUNの権限取得に失敗し、クライアントが適用範囲の狭いシステムプロキシモードへフォールバックしている。
- ❌ ノード切断後に自動で直接接続へ戻り、アプリが動作し続けるため、トンネルがまだ有効だと思い込んでいる。
このような場合は、プロトコル、ノード、DNS、ルーティングを同時に変更しないでください。一度に一つの変数だけを変更し、同じ出口と名前解決の確認を繰り返します。そうしないと、問題が解消しても、どの設定が効いたのか分からず、次の障害でまた最初から推測することになります。
推奨する確認手順
- 接続前の出口とDNSの基準値を保存する。
- サブスクリプションが更新され、対象ノードまたはポリシーグループが選択されていることを確認する。
- 現在システムプロキシとTUNのどちらを使っているか、対応する権限が正常かを確認する。
- IPv4とIPv6の出口、およびDNSの解決経路を確認する。
- ブラウザ、コマンドライン、対象アプリを個別にテストする。
- ルールの適用結果、アウトバウンドの選択、エラーログを確認する。
- ノードを意図的に切断し、アプリがブロックされるのか直接接続へ戻るのかを確認する。
完全なセルフチェックの要点は複雑ではありません。まずインターネット上でどの出口が見えているかを確認し、次にドメインを誰が解決しているかを確認し、最後に具体的なアプリがどのルールに一致したかを確認します。接続アイコンは「クライアントが動き始めた」ことを知らせるには適していますが、ネットワーク経路全体を保証するものではありません。ネットワークも設定も、意図を読み取ってはくれません。