VPNが本当に有効かを確認する際、クライアントに「接続済み」と表示されているかだけで判断してはいけません。この表示は通常、ローカルクライアントのハンドシェイクが完了したか、入口ノードとのセッションが確立されたことを示すだけです。ブラウザー、コマンドラインツール、その他のアプリが実際にその経路を利用している証拠にはなりません。確実に確認するには、接続前のネットワーク状態を記録し、その後に出口IP、DNSの名前解決経路、各アプリの実際の通信を順番に照合します。
確認前に、期待する結果を明確にしておくことも重要です。グローバルプロキシでは、インターネット上の大部分の通信が選択した出口を経由します。ルールベースの分流では、ルールに一致したリクエストだけが処理されます。アプリ別モードでは、指定したプログラムだけが対象です。正しい結果はモードごとに異なります。分流の状態をグローバル接続と誤認すると、「ブラウザーは変わったが、ほかのプログラムは変わらない」ように見えることがありますが、必ずしも障害とは限りません。
接続前後で比較できる基準を作る
確認で重要なのは、単独の結果を見ることではなく、同じデバイス、同じネットワーク、同じ検査先で接続前後の差を比べることです。開始前に古いプロキシ拡張機能を無効にし、ほかのネットワークツールを終了して、システム時刻が正しいことを確認します。次に、未接続時の公開ネットワーク出口の地域、ネットワーク事業者情報、DNSの名前解決結果を記録します。接続後は同じ検査ページで再確認してください。
VPNFeのIP検査ページで、現在のネットワーク出口を確認できます。確認時は、特定のアドレスが常に同じであることにこだわる必要はありません。ノードの割り当て、出口プールの切り替え、ネットワークの再接続によってアドレスが変わることがあるためです。重要なのは、出口の帰属が選択した地域と一致しているか、回線を切断すると元のネットワークに戻るかです。
| 確認対象 | 接続前の記録 | 接続後の期待値 | 異常の手がかり |
|---|---|---|---|
| 公開ネットワークの出口IP | 現在接続しているネットワークの出口 | 選択した経路の出口に変わる | アドレスと帰属がまったく変わらない |
| 出口の地域 | ローカル接続地域 | ノードの対象地域と一致する | 想定外の地域として表示される、または頻繁に変動する |
| DNSの名前解決経路 | ローカルネットワークの既定の解決経路 | クライアントのDNS設定と分流設定に一致する | 問い合わせが引き続きローカルネットワークで処理される |
| 各アプリ | 直接接続時の結果 | グローバル、ルールベース、またはアプリ別のポリシーに一致する | 一部のプログラムだけが変化する |
- すべての回線を切断し、現在の出口の帰属とDNSの結果を記録します。
- 判断に影響する可能性があるブラウザーのプロキシ拡張機能を整理し、検査ページの古いタブを閉じます。
- 対象の回線に接続し、クライアントの状態が安定してから検査ページを開き直します。
- ページが読み込めるかどうかだけでなく、出口、DNS、アプリの挙動を比較します。
- 回線を切断してもう一度検査し、結果が基準の状態に戻ることを確認します。
ステップ1：出口IPが実際に変わったか確認する
出口IPは、外部サービスから見えるリクエストの送信元です。回線が有効なら、検査サイトにはローカル接続ネットワークの公開出口ではなく、遠隔ノードの出口が表示されるのが通常です。アドレス、ネットワークの帰属、地域を同時に確認し、地図上のラベルだけで判断しないでください。位置情報データベースには更新の遅れがあり、同じ出口でもデータベースによって近隣都市として表示される場合があります。そのため、都市名だけでは決め手になりません。
別の検査先でも結果を確認する
ブラウザーにページのキャッシュが残っていたり、独立したプロキシ拡張機能が有効になっていたりすることがあります。結果を比較するときは新しいタブを開いて強制更新し、その後、プロキシ拡張機能を入れていない別のブラウザーでも確認します。2つのブラウザーで結果が異なる場合、原因はノードではなく、ブラウザー拡張機能、ブラウザー固有のDNS、またはシステムプロキシの継承方法にある可能性が高いでしょう。
コマンドラインのプログラムも個別に確認する価値があります。クライアントによってはシステムプロキシだけを設定し、コマンドラインツールがその設定を読み取らないことがあります。一方、TUNを有効にすると、システムのルーティング層でより広範な通信を処理できる場合があります。ブラウザーには対象の出口が表示されるのに、ターミナルのリクエストではローカルの出口が表示されるなら、まずクライアントがシステムプロキシ、TUN、ブラウザー拡張機能のどのモードを使っているか確認します。
- ✅ 接続前後で同じ検査先を使うと、結果を比較できます。
- ✅ 出口の帰属が選択した経路と一致し、切断後に元へ戻ります。
- ✅ ブラウザーと、経路を利用する必要があるアプリを個別に確認します。
- ❌ クライアントに接続済みと表示されたことだけで、すべての通信が有効だと判断する。
- ❌ 都市ラベルが異なることだけで、経路が必ず誤っていると判断する。
ステップ2：DNSが想定した経路で名前解決されているか確認する
DNSはドメイン名を接続可能なアドレスに変換します。ウェブリクエストが遠隔出口を経由していても、ドメインの問い合わせがローカルネットワークで処理される場合があります。この経路の不一致は、一般にDNSリークと呼ばれます。問い合わせ中のドメインが露出したり、コンテンツ配信ネットワークが現在の出口に適さないアドレスを返したりする可能性があり、ページの遅延、地域判定の不一致、一部リソースの読み込み失敗につながります。
ただし、解決サーバーがローカル付近に表示されたからといって、すぐにリークと判断することはできません。パブリックDNSはエニーキャストで振り分けられることがあり、検査データベースも運営主体しか記録せず、実際の問い合わせ経路を正確に反映しない場合があります。接続前後の解決サービスの帰属を比較し、クライアントのDNS設定、ブラウザーのセキュアDNS設定、分流ルールを組み合わせて確認するのが確実です。
ブラウザーのセキュアDNSがクライアント設定を迂回する場合
一部のブラウザーは暗号化DNSリクエストを独自に送信します。クライアントがシステムDNSだけを処理する設定だと、こうしたリクエストはブラウザー指定の解決サービスへ送られ続ける可能性があります。その結果、システム側の検査は正常でも、ブラウザー内のDNS結果が想定と異なることがあります。確認時はいったんブラウザーをシステム設定に従わせて再検査します。結果が一致するようになったら、ノードを何度も変更するのではなく、ブラウザーの設定を確認してください。
分流DNSではドメインルールも同時に確認する
高度なルールモードでは、直接接続するドメインとプロキシ経由のドメインで異なる名前解決経路を使うことがあります。これは意図的なDNS分流であり、リークとは限りません。判断基準は、国際経路を通す必要があるドメインが対応する経路で解決されるか、直接接続するドメインがローカルで解決されるか、解決後の接続も同じルール群に従うかです。ドメインの問い合わせはプロキシ経由なのに、実際の接続がルールによって直接接続になる場合も、経路の不一致が生じます。
- ✅ 接続前後のDNSの帰属を比較し、1回の検査結果だけに依存しない。
- ✅ ブラウザーのセキュアDNSがシステム設定を上書きしていないか確認する。
- ✅ ルールモードでは、プロキシ対象ドメインと直接接続ドメインを個別に確認する。
- ❌ 解決サーバーの都市ラベルだけを唯一の判断基準にする。
- ❌ DNSやプロキシの設定を複数変更してから一度に再検査し、原因の切り分けを難しくする。
ステップ3：ブラウザー、ターミナル、各アプリを個別に確認する
アプリによってネットワーク設定の読み取り方は異なります。ブラウザーは通常システムプロキシを継承しますが、拡張機能に上書きされることもあります。コマンドラインツールは環境変数だけを読む場合があり、ゲーム、会議アプリ、同期プログラムは直接UDP接続を確立することがあります。独自のDNSを固定したり、システムプロキシを迂回したりするプログラムもあります。したがって、「ブラウザーで有効」から「すべてのアプリで有効」とは判断できません。
確認前に、目的を明確にします。特定のアプリの通信をすべて経路に通すのか、それとも特定のドメインだけを分流するのかを決めてください。その後、ほかの条件を変えずにアプリを起動し、観測可能なネットワーク操作を1回実行します。クライアントの接続ログ、ルールの一致記録、出口検査の結果を組み合わせて判断できます。ログでは、リクエストがプロキシ、直接接続、ブロック、フォールバックのどのルールに一致したかを確認します。「ローカルポートが確立された」ことを、遠隔リクエストの成功と取り違えないようにしましょう。
システムプロキシとTUNでは対象範囲が異なる
システムプロキシは、OSのプロキシインターフェースに従うHTTP・HTTPSアプリに適しています。設定が明確で変更も少ない一方、すべてのプログラムを処理できるとは限りません。TUNモードは仮想ネットワークインターフェースを通じて、より広範なIP通信を処理します。通信を一元的に分流したい場合に適していますが、システム権限、ルーティングテーブル、DNS設定への依存度が高くなります。絶対的な優劣はないため、アプリの対象範囲に応じて選択してください。
アプリ別モードでは除外リストを確認する
モバイルプラットフォームや一部のデスクトップクライアントでは、アプリごとの選択に対応しています。対象プログラムが処理対象リストに追加されていない、または除外リストに入っている場合、その通信は直接接続されます。逆に、本来直接接続すべきローカルサービスがプロキシ対象になると、アクセスに失敗することがあります。リストを確認するときは、アプリ識別子が現在のインストールバージョンと一致することを確認し、変更後はアプリを完全に終了してから再起動します。古い接続が再利用されるのを避けるためです。
| 対象 | 一般的な処理方法 | 確認のポイント | よくある相違 |
|---|---|---|---|
| ブラウザー | システムプロキシ、拡張機能、またはTUN | 出口、ブラウザーDNS、拡張機能の優先順位 | 拡張機能がシステムプロキシを上書きする |
| コマンドラインツール | 環境変数、明示的なプロキシ、またはTUN | プロセスがプロキシ設定を読み取るか | ブラウザーは有効だがターミナルは直接接続 |
| デスクトップアプリ | システムプロキシ、アプリ内プロキシ、またはTUN | プロトコルの種類とルールの一致 | アプリがシステムプロキシを迂回する |
| モバイルアプリ | システムVPNインターフェースとアプリ別ポリシー | 処理対象リスト、バックグラウンド制限、古い接続 | 対象アプリが除外リストに入っている |
接続しているように見えて通信が経路を通らない典型的な原因
クライアントが正常に接続したことは、ローカルから入口ノードまでのセッションが確立された可能性を示すだけです。その後の通信は、サブスクリプション設定、ノードパラメータ、ルーティングルール、DNS、システム権限、アプリ自身の設定を経由します。どこか1層でも一致しなければ、「状態は正常だがアクセス経路が誤っている」ことがあります。調査は影響範囲が小さく、確認しやすい項目から始めてください。
サブスクリプションはインポート済みだが、現在の設定が最新版ではない
サブスクリプションリンクはノードとルール設定を取得するために使われます。インポートに成功しても、その後の自動更新まで完了しているとは限りません。クライアントが古いノード、古い証明書情報、古いルールを使い続ける場合があります。まずサブスクリプションを手動更新し、現在選択している設定が更新後のグループに含まれていることを確認します。更新に失敗した場合はエラー表示を確認し、同じサブスクリプションを連続してインポートしないでください。似た名前の設定が複数作られる可能性があります。
プロトコルは接続できるが、伝送パラメータが一致していない
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは伝送方式です。設定項目を相互に流用することはできません。Shadowsocksでは暗号化方式と認証情報を一致させる必要があります。VMess、Trojan、VLESSでは、伝送層、TLS、サーバー名などのパラメータが必要になる場合があります。Hysteria2とTUICは主にUDP通信を使用するため、ネットワーク環境でUDPが制限されている場合、TCPベースの方式とは異なる挙動になります。
プロトコル名だけでは、経路の品質は証明できません。確認すべきなのは、クライアントがそのプロトコルに対応しているか、設定が完全か、ハンドシェイクが成功しているか、実際のリクエストが対応する送信先に入っているかです。クライアント更新後に問題が発生した場合は、設定形式が正しく移行されたかも確認してください。
ルールの優先順位によって検査リクエストが直接接続になる
分流は通常、ドメイン、アドレス、プロセス、地域のルールを具体的なものからフォールバックの順に照合します。先にある直接接続ルールの範囲が広すぎると、後のプロキシルールは実行されません。反対に、プロキシルールの範囲が広すぎると、本来直接接続すべきサービスまで処理することがあります。ログでは、ルールファイルに「プロキシルールが存在する」ことだけでなく、対象リクエストが実際に一致したルールを確認してください。
中継、直接接続、IEPLを同じ階層の概念として混同している
直接接続は通常、クライアントが遠隔ノードへ直接接続する方式です。中継経路では、まず近い入口に接続し、リレーを通じて対象の出口へ転送します。IEPL専用線は、入口と遠隔側の間を専用線で伝送する形態を指します。これらは通信を運ぶ経路であり、ShadowsocksやVLESSなどのアプリケーション層プロキシプロトコルとは異なります。接続を確認する際は、最終的な公開出口とルールの一致を確認してください。設定名に「中継」や「専用線」と含まれているだけで、対象の出口まで通信が届いているとは限りません。
各プラットフォームで重点的に確認する場所
Windowsでは、まずシステムプロキシとTUNを区別します。システムプロキシが有効なら、システム設定に従うアプリの出口は通常切り替わりますが、一部のプログラムは直接接続を続けることがあります。TUNに問題がある場合は、仮想ネットワークインターフェース、ルーティングの競合、権限を確認します。デバイス上でほかのネットワークコンポーネントも動作している場合は、いったん終了して基準状態を作り直してください。
macOSのクライアントは、ネットワーク拡張機能またはシステムプロキシを通じて通信を処理することがよくあります。ネットワーク拡張機能を初めて有効にするとき、システム権限を許可していないと、クライアント画面に設定が残っていても通信を完全には処理できません。システムのネットワーク設定で対象の構成が有効になっていることを確認し、ブラウザーとターミナルを個別にテストします。ウィンドウを閉じるだけでは、バックグラウンドのネットワーク拡張機能は終了しません。
AndroidとiOSは、主にシステムVPNインターフェースを通じて動作します。確認すべき点は、アプリ別リスト、システムのバックグラウンド制限、自動接続ポリシー、アプリが接続前に確立されたセッションを再利用していないかです。経路を切り替えた後も特定のアプリだけ結果が変わらない場合は、ノードの問題と判断する前に、そのアプリを完全に終了して再起動してください。
Linuxは環境による差が大きいプラットフォームです。デスクトップアプリはシステムプロキシを読み取り、ターミナルのプログラムは環境変数に依存し、サービスプロセスは独立した実行環境を持つ場合があります。TUNを有効にする場合は、ルーティングテーブル、DNS管理サービス、権限も確認します。バックグラウンドタスクを検証するときは、そのタスクが実際に使うユーザーと環境を基準にします。対話型ターミナルの結果を、そのままサービスプロセスの結果とみなすことはできません。
- ✅ Windows：現在の方式がシステムプロキシかTUNかを確認し、仮想インターフェースの状態を確認する。
- ✅ macOS：ネットワーク拡張機能の権限とシステムネットワーク設定が有効になっていることを確認する。
- ✅ AndroidとiOS：アプリ別ポリシーを確認し、古い接続を再利用しているアプリを再起動する。
- ✅ Linux：デスクトップ、ターミナル、サービスプロセスのプロキシ環境を個別に確認する。
- ❌ 1つのブラウザーの結果で、デバイス全体のネットワークリクエストを判断する。
決まった順序で最終確認を行う
再現可能な調査手順では、3つの点を確認できる必要があります。外部サービスから見える出口は何か、ドメインはどの経路で名前解決されるか、対象アプリは最終的にどのルールに一致したかです。いずれかに証拠がなければ、「接続できている可能性がある」としか言えず、完全に有効とは確認できません。
- 回線を切断し、出口とDNSの基準状態を記録する。
- サブスクリプションを更新し、現在のノード、プロトコル、設定グループに誤りがないことを確認する。
- 回線に接続し、同じ検査先で公開出口を比較する。
- システムDNS、ブラウザーのセキュアDNS、分流DNSを確認する。
- ブラウザー、ターミナル、対象アプリを個別にテストする。
- クライアントのログで、ルールの一致と送信先の結果を確認する。
- 切断後に再度検査し、ネットワークが元の基準状態に戻ることを確認する。