VPNに接続していても、クライアントの「接続済み」表示だけで判断することはできません。この表示は通常、クライアントとリモート経路のハンドシェイクが完了したことを示すだけで、ブラウザー、デスクトップアプリ、システムDNSが想定どおりプロキシを通っているとは限りません。最も確実なのは、出口IP、DNS、システムのルーティング、特定アプリを分けて確認し、接続前後の結果を比較することです。
切り分けの際は、プロトコルを頻繁に変更したり、クライアントを再インストールしたりしないでください。複数の条件を続けて変えると、原因を特定しにくくなります。現在の経路を維持し、まず外部から見える出口アドレスを確認してから、DNS、プロキシモード、分岐ルール、個別アプリの順に調べるのがおすすめです。これにより、経路が確立していないのか、システムが通信を引き継いでいないのか、特定アプリだけがプロキシを回避しているのかを区別できます。
まず出口IPで外部通信の経路変更を確認する
出口IPとは、外部サイトから見える公開ネットワークの送信元アドレスです。国際経路に接続した後、ブラウザーの通信が完全に引き継がれていれば、確認ページには現在のローカル回線事業者のアドレスではなく、経路が設置された国や地域のアドレスが表示されることが一般的です。IPアドレス、事業者またはデータセンターの情報、国や地域を同時に確認し、地図上の位置だけで判断しないでください。
位置情報データベースは常に一致するとは限りません。同じデータセンターのアドレスでも、データベースによって近隣都市に表示されたり、古い地域情報が残っていたりします。そのため、都市名のずれだけで経路の不具合を証明することはできません。重要なのは、アドレスの帰属先がローカル回線事業者から経路サービス事業者やデータセンターに変わったか、また接続前後で結果が変化したかです。
- ✅ 接続前後で同じ確認ページを使い、異なるデータベースによる帰属差を避ける。
- ✅ 地図のスクリーンショットだけでなく、出口アドレス、ネットワークの帰属先、国や地域を記録する。
- ✅ 通常のブラウザーウィンドウとプライベートウィンドウでそれぞれ確認し、キャッシュや古いセッションの結果を除外する。
- ❌ 対象サイトを開けることだけで機能していると判断しない。サイト自体が現在のネットワークから直接アクセスできる可能性があります。
- ❌ 都市の位置情報のずれをそのまま経路のエラーと見なさず、アドレスの帰属先と接続前後の変化を確認する。
| 確認結果 | 考えられる状態 | 次の手順 |
|---|---|---|
| 出口アドレスが接続前と異なり、選択した経路の地域情報と一致している | 現在のブラウザー通信はおそらく経路を通っている | DNSとほかのアプリを引き続き確認する |
| 出口アドレスがまったく変わらない | システムプロキシが引き継いでいない、ルールが直接接続になっている、またはブラウザーがプロキシを回避している | クライアントモードと分岐ルールを確認する |
| ブラウザーによって出口が異なる | ブラウザーのプロキシ設定、拡張機能、セキュアDNSの設定が異なる | ブラウザーのネットワーク設定を一つずつ確認する |
| アドレスは変わったが、地域名が想定した都市と異なる | アドレスデータベースの更新が遅れている可能性がある | まずネットワークの帰属先を確認し、別の確認元でも照合する |
ブラウザーの出口アドレスが変わっていても、「すべての通信が有効になった」とすぐに結論づけることはできません。システムがルールモードの場合、プロキシルールに一致したサイトだけが経路を変更します。デスクトップアプリが独自の接続方式を使うこともあります。出口IPの確認は最初の証拠に過ぎず、その後に名前解決のリクエストとアプリの接続も確認する必要があります。
DNSが想定どおり解決しているか確認する
サイトにアクセスすると、端末は通常、まずドメインをDNSに渡して名前解決し、その結果得られたアドレスへ接続します。ウェブ通信がプロキシを通っていても、DNSリクエストがローカルネットワークのリゾルバーに送られていれば、確認ツールにはローカルの名前解決サービスが表示されることがあります。これは一般にDNSリークと呼ばれます。ページが開けなくなるとは限りませんが、検索中のドメインが推測されたり、地域判定、コンテンツ配信、接続結果に不一致が生じたりする可能性があります。
確認時は、「通過」や「警告」の表示だけでなく、リゾルバーの運営元と地域に注目してください。リモートサーバーが名前解決する経路では、結果が出口経路の所在地に近くなることがあります。一方、クライアントが公開暗号化DNSを使う場合は、公開DNSサービスが表示されることがあります。クライアント設定で明確に採用されている解決経路であれば、リゾルバー名が出口事業者と異なるだけで失敗と判断することはできません。
ブラウザーのセキュアDNSで結果が複雑になる
最新のブラウザーでは、HTTPSを使ったセキュアDNSが有効になっている場合があります。この場合、ドメインの名前解決はブラウザーが個別に行うため、OSのDNS設定が使われるとは限りません。ブラウザーのリクエスト自体がトンネルを通っていれば、セキュアDNSの接続もブラウザー通信とともに経路へ入ることがあります。ブラウザーが直接接続に設定されている場合は、指定された名前解決サービスへ独立してアクセスする可能性があります。
そのため、「システムDNSとブラウザーの確認結果が異なる」場合は、まずブラウザーのセキュアDNS設定を確認し、調整が必要か判断してください。切り分け中は、この機能を有効にした場合と無効にした場合の結果を別々に記録できます。ただし、経路、DNS、プロキシモードを同時に変更しないでください。一度に一つの条件だけを変えることで、差異の原因を確認できます。
IPv4とIPv6も確認する
ネットワークによってはIPv4とIPv6の両方が提供されています。クライアントが一方のプロトコルしか引き継がない場合、確認ページには経路側の出口アドレスが表示される一方で、もう一方のローカル出口が見えることがあります。サイトによっては想定どおりプロキシを通るのに、IPv6を優先するサービスだけがローカルネットワークから接続される、といった状態が典型例です。
対処として、システム機能を無条件に無効にするのではなく、まずクライアントの仮想ネットワークアダプターやトンネルモードがデュアルスタックに対応しているか、ルーティングとDNSの設定がどうなっているかを確認します。現在のクライアントがIPv6を明確に処理しない場合は、ネットワーク環境を十分に理解したうえで、一時的に無効化して比較テストできます。原因を確認した後、対応するネットワークスタックを扱えるモードやクライアントを選びます。
アプリ別の確認で経路を通っていないアプリを特定する
ブラウザーの確認は正常なのに、チャットアプリ、ダウンロードツール、ゲームプラットフォーム、コマンドラインプログラムではローカルネットワークと表示される場合、プロキシが引き継ぐ範囲に原因があることが多いです。システムプロキシモードは、主にOSのプロキシ設定を読み取るアプリに影響します。仮想ネットワークアダプターやトンネルモードは、ネットワーク層でより広い範囲の通信を引き継ぎます。アプリに独自のプロキシがある、システム設定を無視する、またはクライアントが対応していない通信方式を使う場合、アプリごとの差が生じます。
確認時は、セッション情報や出口の帰属先を表示できるアプリの機能を使い、テスト内容が合法かつ再現可能であることを確認してください。まずアプリを完全に終了してから経路に接続し、再起動します。長時間接続を維持するソフトでは、クライアントで経路を切り替えても、既存のセッションが新しい出口へすぐ移行するとは限りません。
- ネットワークと経路を固定する。切り分け中は、無線ネットワーク、モバイルネットワーク、異なるノードを頻繁に切り替えない。
- 対象アプリを終了する。アプリのプロセスが終了したことを確認し、既存の長時間接続が結果に影響しないようにする。
- プロキシモードを確認する。現在の設定がグローバル、ルール、直接接続、ブラウザーのみのプロキシのどれかを確認する。クライアントによって名称は異なるが、考え方は近い。
- アプリを再起動する。確認可能な通信操作を一度行い、クライアントの接続ログに該当するドメインや宛先アドレスが表示されるか確認する。
- ブラウザーの結果と比較する。ブラウザーは経路を通っているのにアプリの記録がない場合は、まずアプリがシステムプロキシを回避していないか確認する。
- 引き継ぎ方式を切り替えて再確認する。クライアントが対応していれば、仮想ネットワークアダプターやトンネルモードで比較し、原因がシステムプロキシの適用範囲にあるか確認する。
Windowsでは、システムプロキシ設定、クライアントの仮想ネットワークアダプターの状態、ルーティングテーブルを確認します。macOSでは、ネットワークサービスのプロキシと、クライアントが要求するVPN構成の権限を同時に確認します。Androidでは通常、システムVPNインターフェースが通信を引き継ぎますが、アプリの除外リストによって指定アプリが直接接続になることがあります。iOSとiPadOSでは、システムのVPN構成が接続状態のままか確認し、クライアントのオンデマンド接続や分岐ルールも確認してください。
クライアントに接続ログがある場合は、対象アプリがアクセスしたドメイン、宛先アドレス、ルールの適用結果を探します。ログに「プロキシ」「直接接続」、または特定のポリシーグループが表示されるほうが、アプリ画面の接続アイコンより判断材料になります。ログにリクエストがないからといって、アプリが通信していないとは限りません。クライアントが記録していないプロトコルを使っているか、トンネル確立前から接続を維持している可能性もあります。
プロトコルのハンドシェイク成功とルーティングの引き継ぎは別
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルは、クライアントとリモートサーバー間でデータを転送する方式を担います。クライアントにプロトコル接続済みと表示されても、ハンドシェイクやセッションが確立したことを示すだけです。システム通信がそのセッションに入るかどうかは、システムプロキシ、仮想ネットワークアダプター、ルール、アプリの動作によって決まります。
同様に、サブスクリプションURLのインポートに成功したことは、クライアントが経路設定を取得したことを示すだけです。インポート後は、利用可能なノードを選択し、システムプロキシまたはトンネルモードを有効にして、必要なネットワーク構成の作成をクライアントに許可する必要があります。サブスクリプションの更新に成功しても引き継ぎを有効にしていないことが、「ノードの速度テストは正常なのにウェブの出口が変わらない」よくある原因です。
グローバルモード、ルールモード、直接接続を理解する
グローバルモードは通常、クライアントが引き継げる通信を選択した経路へまとめて送ります。「分岐ルールが原因か」を切り分けるのに適していますが、すべてのシステムプロセスが必ず対象になるわけではありません。ルールモードでは、ドメイン、アドレス範囲、アプリ、ルールセットに応じてプロキシと直接接続を選びます。日常利用では柔軟ですが、同じ端末でもサイトによって出口が異なる状態が起きやすくなります。
直接接続のルール自体が誤りとは限りません。LAN機器、ローカルサービス、一部の地域向けコンテンツでは直接接続が必要な場合があります。確認すべきなのは、本来経路を通したいドメインが誤って直接接続に分類されていないか、または名前解決後のアドレスがルールの想定と異なっていないかです。ログで適用されたルールを確認し、一時的にグローバルモードへ切り替えて比較します。グローバルモードで正常なら、原因は通常ルールまたは名前解決の設定にあります。
| クライアントモード | 典型的な動作 | 適した確認方法 | よくある誤判定 |
|---|---|---|---|
| グローバルモード | 引き継いだ通信を選択した経路へまとめて送る | 分岐ルールの影響を除外する | すべてのアプリが自動的にシステムプロキシを読み取ると思い込む |
| ルールモード | ドメイン、アドレス、ルールセットに応じてプロキシと直接接続を決める | 特定のリクエストがどのルールに一致したか確認する | 一部サイトのローカル出口を見て全体が機能していないと判断する |
| システムプロキシ | 主にシステムプロキシ設定に従うアプリを対象にする | ブラウザーや一般的なネットワークリクエストをすばやく確認する | システムプロキシを読み取らないデスクトップアプリを見落とす |
| 仮想ネットワークアダプターまたはトンネルモード | ネットワーク層でより広い範囲の通信を引き継ぐ | アプリがシステムプロキシを回避する問題を比較確認する | 権限、ルーティングの競合、除外ルールを見落とす |
直接接続、通常の中継、IEPL専線は同じ概念ではない
経路ページでいう「直接接続」は、端末がサービス事業者の用意した入口中継を経由せず、リモートサーバーへ直接接続することを指します。通常の中継では、まず近い入口へ接続し、サービス事業者のネットワークを通じて出口へ転送します。IEPL専線は、インターネット上の直接接続とは異なる地域間の伝送経路を重視します。これらは端末から出口までの経路を表すもので、機能しているかどうかの判定基準ではありません。
どの経路を使っていても、確認の考え方は同じです。クライアントがセッションを確立したか、システムがリクエストをクライアントへ渡しているか、DNSが設定どおりに解決しているか、外部サービスから最終的にどの出口に見えるかを確認します。専線や中継は特定のネットワーク環境で安定性を改善することがありますが、プロキシモードや分岐ルールの設定に代わるものではありません。
「接続済みなのに実際には経路を通らない」よくある原因を整理する
出口アドレスが変わらない場合は、次の順序で確認します。まず、復旧しやすく影響範囲の小さい設定から調べ、その後にシステムルーティングやソフトウェアの競合を確認することで、不要な再インストールを減らせます。
- ✅ サブスクリプションのインポートやノード更新だけでなく、具体的な経路が選択されていることを確認する。
- ✅ システムプロキシ、仮想ネットワークアダプター、トンネルのスイッチが有効で、必要なネットワーク構成の権限が与えられていることを確認する。
- ✅ ルールモードから一時的にグローバルモードへ切り替えて再確認し、直接接続ルールの誤適用か判断する。
- ✅ ブラウザーと対象アプリを完全に終了してから再起動し、再利用されている古い接続をクリアする。
- ✅ ブラウザー拡張機能、カスタムプロキシ、セキュアDNSを確認し、複数のネットワーク設定が互いに上書きしないようにする。
- ✅ ステータスアイコンだけでなく、クライアントログのリクエスト、ルール適用、接続エラーを確認する。
- ✅ 同時に動作しているほかのプロキシや企業ネットワーククライアントを切断し、ルーティングや仮想ネットワークアダプターの競合を除外する。
- ✅ サブスクリプションを更新した後に経路を選び直し、無効になった、または変更された古い設定を使い続けないようにする。
サブスクリプションURLをインポートしただけで有効化されていない
多くのクライアントでは、「サブスクリプション管理」と「現在の接続」が別ページに分かれています。サブスクリプションURLの貼り付け、ノード一覧の更新、遅延テストの完了だけでは、システムが経路を使い始めたことにはなりません。ノードを選択して接続を開始し、プラットフォームに応じてシステムプロキシを有効にするか、VPN構成の作成を許可する必要があります。クライアントの再起動後に引き継ぎが自動復元されなければ、一覧は残っていても出口はローカルネットワークに戻ります。
古い接続やキャッシュで前後の結果が混在している
ブラウザーの接続プール、デスクトップソフトの長時間接続、DNSキャッシュ、サイトのセッションは、一時的に古い経路を保持することがあります。経路を切り替えてすぐ同じページを更新すると、キャッシュされた内容や再利用された接続が表示される場合があります。確実な方法は、アプリを終了して再起動し、新しいプライベートウィンドウを使い、複数の独立した項目で照合することです。1つのページを何度も更新するだけでは不十分です。
社内ネットワークやセキュリティソフトがルーティングを書き換えている
企業ネットワーククライアント、ファイアウォール、エンドポイントセキュリティソフト、ほかの仮想ネットワークアダプターが、デフォルトルートやDNSを変更することがあります。個人用クライアントが接続成功と表示しているのに、ログに業務リクエストが一つもない場合は、ほかのネットワーク引き継ぎツールを切断して再確認できます。管理対象端末のネットワークポリシーを独自に回避せず、組織のルールに従って利用可能な接続方式を管理者に確認してください。
再現できる接続確認の手順
今後同じような問題が起きたら、同じ手順で確認してください。まず接続前の出口と名前解決の結果を記録してから経路を確立します。接続後は同じ確認環境で出口IPを再確認し、続いてDNSとデュアルスタックのアドレスを調べます。その後、対象アプリを再起動し、クライアントログでリクエストがプロキシと直接接続のどちらに一致したかを確認します。最後に、普段のルールモードへ戻します。
グローバルモードですべての確認が正常で、ルールモードに戻すと特定のサービスだけが不安定になる場合は、分岐ルールとDNSを重点的に確認します。グローバルモードでも出口が変わらない場合は、システムによる引き継ぎ、権限、ソフトウェアの競合を確認します。特定のアプリだけに問題がある場合は、そのアプリ独自のプロキシ、除外設定、古い接続を調べます。このように分類すれば、プロトコルの変更やシステムの再インストールを繰り返す必要は通常ありません。
経路の種類も、適切な段階で確認してください。直接接続、中継、IEPL専線は主に端末から出口までの経路に影響します。Shadowsocks、Trojan、VLESSなどのプロトコルは、クライアントとサーバーがデータを転送する方法を決めます。いずれも、システムプロキシ、ルーティング、DNS、アプリごとのルール確認の代わりにはなりません。まず通信が経路に入っているかを確認してから、現在のネットワークに適した経路を検討すると、切り分けが効率的です。