VPNに接続したら、本当に有効になっているかをクライアントの「接続済み」表示だけで判断してはいけません。この表示は通常、クライアントのハンドシェイクが完了した、プロキシポートが開いた、または仮想ネットワークインターフェースが作成されたことを示すだけです。ブラウザー、ダウンロードツール、その他のアプリの通信すべてが選択した経路を通っているとは限りません。最も確実なのは、出口IP、DNS解決、システムルート、各アプリの実際のアクセス結果を順に確認する方法です。
確認する前に、「有効」の意味を明確にしましょう。全トンネルモードでは、インターネット上の通信の大部分がリモートの出口から出る状態を想定します。ルールベースの分割通信では、中国本土のアドレス、ローカルネットワークのリソース、指定したアプリが直接接続されることは正常な場合があります。プロキシモードのみの場合は、そのプロキシを明示的に使うアプリだけが対象です。モードによって正しい結果は異なります。現在の設定を確認せず、1つのIP確認ページだけを見ると、正常な分割通信を接続失敗と誤判定しやすくなります。
まずクライアントが確立した接続の種類を確認する
一般的なクライアントには、システムプロキシ、仮想ネットワークアダプター、アプリプロキシ、ルールベースの分割通信などのモードがあります。システムプロキシは、OSのプロキシ設定に従うソフトに主に影響します。ブラウザーは通常これに従いますが、一部のゲーム、コマンドラインツール、独自のネットワーク処理を持つプログラムは迂回することがあります。仮想ネットワークアダプターのモードは、システムのルーティング層でより多くの通信を処理します。対象範囲は広い一方、ローカルネットワークの許可、ルートの優先順位、セキュリティソフトによって最終的な経路が変わることがあります。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるトランスポートまたはプロキシプロトコルです。プロトコル名だけでは、システム全体の通信が処理されているかどうかは分かりません。同じプロトコルでも、クライアントによってシステムプロキシとして動作する場合もあれば、仮想ネットワークアダプターと組み合わせて動作する場合もあります。確認時は、クライアントの現在のモード、分割通信ルール、ログに記録された接続先を確認し、プロトコル名だけで判断しないでください。
もう1つよくあるのが、クライアントはローカルのプロキシコアへの接続に成功していても、そのコアからリモートノードへのリクエストが正常に転送されていないケースです。この場合、画面上は接続状態のままでも、実際のアクセスはタイムアウトしたり元のネットワークに戻ったりします。したがって、ハンドシェイクの成功は出発点にすぎず、その後にエンドツーエンドの確認が必要です。
| 確認対象 | 正常な状態 | 考えられる異常 | 優先して確認すること |
|---|---|---|---|
| クライアントの状態 | ノードに接続され、ログに正常な転送記録が継続して表示される | 接続表示だけで、アプリのリクエストがまったくない | システムプロキシまたは仮想ネットワークアダプターのモードが有効か確認する |
| 公開ネットワークの出口 | 接続前後で出口の帰属が想定どおりに変化する | 常に元のネットワークの出口が表示される | ルート、分割通信ルール、ブラウザーのプロキシを確認する |
| DNS解決 | 解決経路が現在のモードと設定に一致している | ドメインリクエストが想定外のローカルリゾルバーで処理され続ける | システムDNS、クライアントDNS、ブラウザーのセキュアDNSを確認する |
| 個別のアプリ | 対象リクエストがクライアントの接続ログに記録される | ブラウザーは正常だが、他のプログラムは直接接続している | アプリがシステムプロキシに従うか確認し、プロセス単位の分割設定を確認する |
出口IPを接続前後で比較する
出口IPは最も分かりやすい確認項目です。まずクライアントを切断し、信頼できる公開IP確認ページを開いて、現在のアドレスの通信事業者とおおまかな地域を記録します。次に対象の経路へ接続し、同じページを更新します。その経路がブラウザーのリクエストを転送していれば、ページには元のネットワークではなくリモート側の出口が表示されるはずです。
アドレスの文字列が変わったかどうかだけを比較しても十分ではありません。アクセスネットワークによってはアドレスが動的に割り当てられるため、プロキシに接続していなくても再接続後に変わることがあります。より重要なのは、通信事業者の帰属と出口地域が選択したノードに合っているかです。一方、地域データベースの更新が遅れることもあるため、地域名の不一致だけで経路の不具合を証明することはできません。アドレスの帰属、クライアントログ、実際のアクセス経路を合わせて判断してください。
接続前後では、同じブラウザーの同じウィンドウと同じ確認ページを使うのがおすすめです。サイトごとに異なるアドレスデータベースを使うことによる影響を避けられます。ページにキャッシュがある場合は、強制更新するかプライベートウィンドウで再確認します。確認ページに表示された公開IPを公開の掲示板へそのまま投稿しないでください。トラブルシューティングでは、帰属が変わったかどうかを伝えるだけで十分で、完全なアドレスを公開する必要はありません。
- ✅ 経路を切断した後、元のネットワークの出口の帰属を記録し、基準にする。
- ✅ 対象ノードに接続して同じ確認ページを更新し、出口が切り替わったか確認する。
- ✅ クライアントログで、ブラウザーのリクエストが実際にプロキシ接続へ入ったことを確認する。
- ✅ 元のネットワークに戻して再確認し、ページキャッシュやアドレスデータベースの誤差を除外する。
- ❌ 「接続成功」と表示された時点で確認を終え、実際の出口を検証しない。
- ❌ ページに表示された地域名だけを見て、通信事業者の帰属やリクエストログを確認しない。
DNSが想定どおりに解決されているか確認する
DNSはドメイン名を接続可能なネットワークアドレスに変換します。ウェブページの内容がリモート出口を経由していても、DNS解決まで同じ経路を通るとは限りません。システムが元のネットワークのリゾルバーへ問い合わせを送っていると、ローカルネットワークで使われている解決経路が露出したり、返される結果の違いによってアクセスに問題が起きたりすることがあります。一般にDNSリークとは、解決リクエストが想定したトンネルやプロキシのルールを迂回することを指し、「リゾルバーの地域とノードの地域が違う」という単純な話ではありません。
確認方法は出口IPの場合と似ています。経路を切断した状態で現在のリゾルバーの帰属を確認し、接続後に同じテストを実行します。結果は設定と合わせて読み取ってください。クライアントがリモートDNSを明示的に使う、またはプロキシ経由でDNSを送る設定なら、リクエストが元のネットワークのリゾルバーで処理され続けることは通常ありません。もともと独立した暗号化DNSを指定している場合は、リゾルバーが別のネットワークに属していてもまったく問題ないことがあります。
ブラウザーのセキュアDNSも結果を変えることがあります。一部のブラウザーはシステムDNSを迂回し、ユーザーが選択した解決サービスへ直接接続します。そのため、テストページに表示されるリゾルバーはクライアントの設定ではなく、ブラウザーの設定に由来する場合があります。確認時は一時的にブラウザーをシステム設定に従わせ、比較が終わったら元のセキュアDNS設定に戻せます。
キャッシュも判断を妨げます。一度アクセスしたドメインは、ブラウザーやOSのキャッシュから結果を取得し、新しい問い合わせを送らないことがあります。以前アクセスしていないテスト用ドメインを使うか、システムとブラウザーのDNSキャッシュを消去してから確認してください。Windowsではネットワーク設定から現在のリゾルバーを確認でき、macOSではシステムDNSの状態を確認できます。Linuxでは、システムの名前解決サービスとネットワーク管理ツールが生成した設定の両方に注意が必要です。
アプリごとに通信経路を確認する
ブラウザーで確認できても、そのブラウザーのリクエストが経路に入ったことしか証明できません。デスクトップアプリ、ゲームプラットフォーム、ダウンロードツール、コマンドラインプログラムは、異なるプロキシ方式を使うことがあります。システムプロキシモードでは、システム設定に従うソフトは通常処理対象になりますが、システムプロキシを無視するソフトは直接接続を続ける可能性があります。仮想ネットワークアダプターの対象範囲は広いものの、除外リスト、ローカルネットワークの許可、プロセス単位の分割設定が残る場合があります。
アプリごとに確認するときは、関係のないプログラムを終了し、クライアントのリアルタイム接続ログを開いてから、対象アプリを起動し、明確な通信操作を1つ実行します。ログにそのアプリがアクセスしたドメインやアドレスが表示されれば、通常はリクエストがプロキシコアに入ったことを示します。アプリは通信できるのにクライアントログに対応する記録がない場合は、直接接続していないか、独自のプロキシ設定を使っていないか、分割通信ルールから除外されていないかを確認します。
AndroidとiOSでは、アプリ単位のプロキシ、常時接続、ローカルネットワーク権限にも注意が必要です。デスクトップでは、ブラウザー拡張機能がシステム設定を上書きする、別のプロキシソフトがポートを取り合う、セキュリティソフトがネットワークフィルタールールを書き換えるといったケースがよくあります。複数のネットワークツールを同時に使っている場合は、まず現在のクライアントだけを残し、プロキシチェーンやルートの競合を除外してから、1つずつ元に戻すのがおすすめです。
- クライアントが現在、システムプロキシ、仮想ネットワークアダプター、アプリ専用プロキシのどれを使っているか確認する。
- リアルタイムログを開き、既存の記録を消去するか、現在の末尾位置を覚えておく。
- 対象アプリを起動し、新しいネットワークリクエストが発生する操作を1回実行する。
- ログで対象ドメイン、接続方式、適用された分割通信ルールを確認する。
- 経路を切り替えるか接続を切断し、同じ操作を繰り返して比較する。
クライアントがルールログに対応している場合は、リクエストがプロキシ、直接接続、拒否のどれとして記録されたかを確認します。ルールベースの分割通信では、直接接続が必ずしも誤りとは限りません。ローカルネットワーク機器、内部ドメイン、明示的に指定されたローカルリソースは、通常そのまま直接接続します。本当に確認すべきなのは、「プロキシを想定していたのに直接接続になった」場合や、「アプリがクライアントにまったく入っていない」場合です。
直接接続・中継・IEPLの確認範囲を理解する
経路の伝送トポロジーと最終出口は別のレイヤーです。直接接続は通常、ユーザーのネットワークからリモートの出口ノードへ直接接続することを指します。中継では、まず中継地点に入り、そこから出口へ通信を送ります。IEPLは、アクセス区間やバックボーンの伝送方式を表すために使われることがあります。途中でどの経路を通っても、対象サイトに通常見えるのは最終出口のアドレスであり、中継地点の内部アドレスではありません。
そのため、公開IPの確認だけで直接接続、中継、IEPLを区別することはできません。最終出口は確認できますが、途中の伝送経路全体が表示されるわけではありません。トポロジーの判断には、クライアントのノード説明、サーバー設定、運営側が提供する経路情報のほうが適しています。ネットワークの経路追跡は手がかりになりますが、中継地点が応答を隠すことや、通信事業者のネットワークが探査データをフィルタリングすることがあります。不完全な経路結果を確定的な結論にしないでください。
経路の伝送方式をプロキシプロトコルと混同してはいけません。TrojanやVLESSは異なる伝送経路上で動作でき、Hysteria2やTUICも異なるアクセス方式を経由する場合があります。プロトコルは接続と伝送の動作を担い、直接接続、中継、専用線はより下位の経路構成を表します。有効性を確認するときは、まずアプリが処理対象になっているか、出口が変わったか、DNSがルールに合っているかを確認します。経路の種類を判断するには、別途設定の説明を確認してください。
接続済みなのに有効にならない代表的なケース
ブラウザー拡張機能がシステムプロキシを上書きする
ブラウザーにプロキシ拡張機能をインストールしていると、拡張機能が独自のノードを使ったり、直接接続したりして、OSのプロキシ設定を上書きすることがあります。確認時は関連する拡張機能を一時的に無効にし、システムプロキシまたは仮想ネットワークアダプターのモードでテストしてください。無効化後に出口が正常になったなら、問題はリモート経路ではなくブラウザー内部の設定にあります。
分割通信ルールが対象を直接接続と判定する
ルールは、ドメイン、アドレス、プロセス、ルールセットなどに基づいて経路を決めます。ルールが古い、またはドメインのマッチ範囲が広すぎると、本来プロキシを通すはずのリクエストが直接接続になることがあります。むやみにノードを切り替えるより、リアルタイムログで適用されたルールを確認するほうが効果的です。修正後は、既存の接続が元の経路を再利用する可能性があるため、リクエストを新しく送信してください。
サブスクリプションを更新したが、実行中の設定が更新されていない
サブスクリプションURLは、ノードと設定を取得するために使われます。クライアントで更新が完了しても、現在のノードへ自動的に切り替わるとは限らず、実行中のプロキシコアがすぐに再読み込みされるとも限りません。設定と画面表示が一致しない場合は、現在の設定を保存し、ノードを選び直して接続を再起動してください。サブスクリプションURLは機密性の高い認証情報なので、公開の確認ページや公開ログに貼り付けないでください。
システムに別のプロキシや残ったルートがある
別のクライアント、デバッグ用プロキシ、企業ネットワークソフト、セキュリティツールが、システムプロキシやルートを同時に変更している可能性があります。現在のクライアントが接続済みと表示していても、優先度の高いルールが通信を処理していることがあります。競合するソフトを終了したら、ブラウザーを再起動するだけでなく、システムプロキシ、デフォルトルート、仮想ネットワークインターフェースを再確認してください。
古い接続が再確立されていない
ノードを切り替えた後も、一部のアプリは確立済みの長時間接続を使い続けることがあります。確認ページが新しいリクエストを送らなければ、結果が元の出口のまま残る場合もあります。関連するタブやアプリのセッションを閉じてから、再度開いて更新すると、古い接続による誤判定を減らせます。
繰り返し実行できる完全な確認手順
接続に問題があるときは、テスト条件を安定させ、ノード、プロトコル、ブラウザー、DNSを同時に変更しないでください。一度に1つの変数だけを変更すれば、どの設定が影響したのか判断できます。以下の手順は、初回接続、クライアントの切り替え、分割通信ルールの変更後に適しています。
- ✅ クライアントを切断し、元のネットワークの公開出口とDNSの帰属を記録する。
- ✅ 対象ノードに接続し、クライアントログでエラーが継続していないことを確認する。
- ✅ 同じブラウザーで公開出口を再確認し、通信事業者の帰属を確認する。
- ✅ 新しいドメイン解決テストを実行し、キャッシュとブラウザー独自のDNSの影響を除外する。
- ✅ リアルタイムログを開き、実際に使うアプリを1つずつテストする。
- ✅ リクエストに適用されたプロキシ、直接接続、拒否のルールが想定どおりか確認する。
- ✅ 元のネットワークに戻して比較を繰り返し、結果がページキャッシュによるものではないと確認する。
- ❌ 複数の設定を同時に変更し、異常の原因を判断できなくする。
出口が変わらない場合は、まずプロキシモード、仮想ネットワークアダプターの状態、ルートを確認します。出口は変わったのにDNSが想定と異なる場合は、クライアントDNS、システムのリゾルバー、ブラウザーのセキュアDNSを確認します。ブラウザーは正常で他のアプリに問題がある場合は、アプリがシステムプロキシに従っているか、プロセス単位の分割設定を確認します。すべてのリクエストがクライアントに入っているのにアクセスできない場合は、ノードの状態、プロトコルの互換性、上流ネットワークの制限を検討します。
有効になったことを確認しても、プライバシーや安全性に関する設定がすべて完了したわけではありません。利用場面に応じて、切断保護を有効にするか、ローカルネットワークへのアクセスを許可するか、どのドメインを直接接続にするか、DNSをシステムに従わせるかプロキシ経由で解決するかを決める必要があります。すべてのリクエストを無条件に同じ経路へ通すのではなく、通信の種類ごとに明確で確認可能なルールで動かすことが適切な目標です。