VPNは接続済みと表示されていても、本当に有効とは限りません。この表示が示すのは、通常、クライアントと接続先とのセッションが確立したこと、またはシステムにプロキシや仮想NIC、ルーティング規則が作成されたことです。実際に確認すべきなのは、ウェブアクセスで使われる出口IP、ドメイン名の問い合わせ先となるDNSリゾルバー、そして各アプリの通信が想定どおり経路に入っているかどうかです。
最も確実な確認方法は、接続ボタンを何度も押すことではありません。まず未接続時のネットワーク状態を基準として記録し、目的の経路に接続したあと、出口IP、DNS、アプリ通信の順に確認します。3つの結果を照合することで、正常な分流、ブラウザだけのプロキシ接続、システムルートが切り替わっていない状態、クライアント設定の異常を切り分けられます。
まず「接続済み」が何を意味するかを理解する
クライアントに接続済みと表示されても、すべてのアプリが同じ経路を使うとは限りません。クライアントによって、システムプロキシ、ブラウザ拡張機能、仮想NIC、TUNモードなどが使われます。システムプロキシは主にプロキシ設定に従うアプリへ影響し、仮想NICやTUNモードはより広い通信を処理できる場合があります。ただし、最終的な範囲はルーティングテーブル、分流ルール、アプリ自身の動作に左右されます。
Shadowsocks、VMess、Trojan、VLESSはプロキシクライアントでよく使われます。これらはクライアントとノード間のプロトコルや転送方式を示すもので、端末全体の通信が自動的に処理されることを保証するものではありません。Hysteria2とTUICはUDPベースの転送特性を重視していますが、想定どおりの範囲を実現するには、クライアントでシステムプロキシ、TUN、ルーティング、DNSを正しく設定する必要があります。
サブスクリプションURLも「接続の証明」ではありません。サブスクリプションはノードと設定をクライアントへ配布するためのものです。インポートに成功したのは、クライアントが設定を読み込めたという意味にすぎません。ノードでセッションを確立できても、それは接続段階を通過したことを示すだけです。出口IPが変わったか、DNSが想定した経路に入ったか、アプリが分流ルールに従っているかは、別途確認する必要があります。
| 確認できた現象 | 通常そこから分かること | それだけでは証明できないこと |
|---|---|---|
| クライアントに接続済みと表示される | クライアントとノード間のセッションが確立した、またはローカルプロキシが起動した | すべてのアプリが経路を利用しているとは限らない |
| ブラウザの出口IPが変わった | 現在のブラウザが検査ページへアクセスする際、新しい出口を使っている | 他のアプリやDNSが同じ経路を使っているとは限らない |
| DNSリゾルバーが変わった | 今回の検査リクエストが別の名前解決経路に入った | ウェブやデスクトップアプリも処理されているとは単独では証明できない |
| 一部のウェブサイトにはアクセスできるが、変化しないサイトもある | ドメイン、アドレス、アプリごとの分流が設定されている可能性がある | 接続失敗とは直接判断できない |
ステップ1：接続前後の出口IPを比較する
出口IPとは、ウェブサイトへアクセスした際に相手のサーバーから見える公開ネットワークの送信元アドレスです。確認するときは、経路に接続していない状態で信頼できるIP確認ページを開き、通信事業者やネットワーク組織、国・地域、アドレス種別などを記録します。その後、目的の経路へ接続してページを再読み込みし、これらの項目が出口の変化に応じて変わるかを確認します。
地域名だけを見て判断しないでください。IPアドレスのデータベースには更新の遅れがあり、アドレス帯の都市情報も正確とは限りません。重要なのは、接続前後で公開アドレスが同じか、ネットワーク組織が変わったか、選択した経路の出口地域と大きく矛盾していないかを比較することです。アドレスが変わっていて、都市名だけが近隣地域になっていても、経路が機能していないとは限りません。
まず通常のブラウザウィンドウで確認し、別のブラウザでも再確認することをおすすめします。結果が異なる場合、片方だけに独立したプロキシ拡張機能や別の暗号化DNS設定が有効になっている、またはシステムプロキシの切り替え後にブラウザプロセスが接続を張り直していない可能性があります。その場合は、まず拡張機能を無効にし、ブラウザを完全に終了してから再起動します。
- ✅ 接続前の公開出口情報を記録し、ページに表示された地域名だけを控えない。
- ✅ 経路へ接続したら検査ページを再読み込みし、必要に応じて古いタブを閉じて開き直す。
- ✅ 別のブラウザでも確認し、特定の拡張機能やブラウザ設定の影響を除外する。
- ❌ クライアント画面に表示されたノード地域を、そのまま実際の出口結果とみなさない。
- ❌ ページの表示が速くなった、または特定のサイトを開けたという理由だけで、すべての通信が有効になったと判断しない。
IPv4とIPv6のデュアルスタックを有効にしている場合は、検査ページに2種類の公開アドレスが同時に表示されるかも確認します。一部の設定では一方のアドレスファミリーだけが処理され、アプリが未処理の経路を優先することがあります。一方の結果だけが変わり、もう一方が元のネットワークのままなら、クライアントが該当するアドレスファミリーに対応しているか、TUNが関連ルートを処理しているか、システムに優先度の高い直接接続ルールがないかを確認します。
ステップ2：DNSの名前解決経路を確認する
DNSはドメイン名をネットワークアドレスへ変換します。出口IPが変わっても、名前解決が同じ経路を通るとは限りません。システムが従来のネットワークのリゾルバーへ問い合わせ続けていると、DNSリークが起こる可能性があります。一方、クライアントで分流DNSが設定されている場合は、ドメインごとに異なるリゾルバーを使うことが設計どおりの動作である場合もあるため、ルールと合わせて判断します。
DNSを確認するときは、リゾルバーのネットワーク組織や地域を表示できる検査ページを開きます。まず経路を切断して基準を記録し、その後接続して再検査します。理想的な結果はクライアント設定によって異なります。グローバル処理では、問い合わせがクライアント指定のリモートまたは暗号化された名前解決経路へ入ることが一般的です。ルール分流では、直接接続するドメインをローカルリゾルバーに任せ、プロキシ対象のドメインを別の名前解決経路へ送ることがあります。
ブラウザ内蔵の暗号化DNSは判断を複雑にします。OSのDNSを迂回したり、ネットワーク状態に応じて名前解決サービスを自動選択したりする場合があるためです。ブラウザとシステムの検査結果が一致しなくても、すぐにクライアントの漏えいとは断定できません。まずブラウザ独自のセキュアDNSが有効か確認し、クライアントがブラウザの問い合わせを処理する設定になっているかを確認します。
DNSの確認ではキャッシュにも注意が必要です。システム、ブラウザ、アプリはいずれも、すでに解決したドメインをキャッシュしている可能性があります。同じドメインを繰り返し検査しても、端末が新しい問い合わせを送信するとは限りません。比較する前に対象アプリを終了して再起動するか、検査ページが提供する新しい検査用ホスト名を使い、今回のリクエストで実際に名前解決が行われるようにします。
- 経路を切断し、現在のリゾルバーのネットワーク組織とおおまかな地域を記録する。
- 目的の経路へ接続し、DNS検査ページを開き直して新しい問い合わせを発生させる。
- クライアントのDNSモードと照合し、グローバル処理かルール分流かを判断する。
- ブラウザとシステムの結果が異なる場合は、ブラウザ独自の暗号化DNSとプロキシ拡張機能を確認する。
- キャッシュの影響を取り除いて再度検査し、古い解決結果を現在の経路と取り違えない。
ステップ3：アプリごとに通信が経路へ入っているか確認する
出口IPとDNSの検査は通常ブラウザで行いますが、実際に使いたいのはデスクトップソフト、コマンドラインツール、ゲーム、動画・音声アプリ、開発環境かもしれません。システムプロキシへの対応はプログラムごとに異なるため、アプリ単位で確認する必要があります。1つのブラウザページだけで端末全体を判断してはいけません。
まずクライアントの現在のモードを確認します。グローバルプロキシは、処理対象となる通信をノードへまとめて送ろうとします。ルールモードでは、ドメイン、宛先アドレス、アプリ、地域などに基づいて直接接続とプロキシを振り分けます。LANをバイパスする設定では、プリンター、ルーターの管理画面、ローカルデバイスへのアクセスを維持します。モード名はクライアントによって異なりますが、核心は「この通信がどのルールに一致したか」です。
デスクトップアプリをテストするときは、まずアプリを完全に終了し、経路へ接続してから再起動します。起動時にシステムプロキシを読み込むプログラムは、実行中の設定変更に反応しないことがあります。システムプロキシに従わないアプリでは、通常のプロキシモードが機能しない場合があります。その場合はアプリ内のプロキシ設定を使うか、仮想NICやTUN、システムルートの処理に対応したクライアントモードを利用します。
ゲームやリアルタイム通信ではUDPがよく使われます。クライアントがTCPプロキシだけを設定していると、ウェブは正常でも、ゲームへのログイン、音声通信、リアルタイム接続は直接接続になったり失敗したりします。その場合は、ノードのプロトコル、クライアントモード、UDP転送が一致しているかを確認し、ブラウザ設定を何度も変えないでください。Hysteria2とTUICはこのような用途に対応できますが、有効になるかどうかはサーバー設定、クライアント実装、ルーティングルールに左右されます。
| アプリの利用場面 | 優先して確認する項目 | よくある誤判定 |
|---|---|---|
| 通常のブラウザ | システムプロキシ、ブラウザ拡張機能、セキュアDNS | ブラウザで有効なら、すべてのソフトでも有効だと判断する |
| デスクトップ業務ソフト | システムプロキシを読み込むか、プロセスの再起動が必要か | 古い接続が解放されず、ルーティングが変わっていないと誤認する |
| 開発ツール | アプリ内プロキシ、ターミナル環境、証明書、長時間接続 | コマンドラインとGUIが異なるネットワーク設定を使っている |
| ゲームとリアルタイム通信 | UDP対応、TUNによる処理、アプリ分流ルール | ウェブが正常なら、リアルタイム通信も経路を通っていると判断する |
| 動画・音声アプリ | 実際の出口地域、アプリキャッシュ、ドメイン分流 | ホーム画面の内容だけで出口地域を判断する |
接続済みなのに通信が経路を通らない主な原因
システムプロキシは有効だが、アプリが読み込まない
よくあるケースの1つです。ブラウザはシステムプロキシに従うため出口が変わりますが、一部のデスクトップアプリはネットワーク接続を直接作成し、システムプロキシを読み込まないため、ローカルネットワークを使い続けます。対処として、アプリに独自のプロキシ設定があるか確認するか、仮想NIC、TUN、システムルートの処理に対応したクライアントモードへ切り替えます。
分流ルールが対象を直接接続にしている
ルールモードでは、クライアントがドメイン、アドレス、アプリ、ルールセットに基づいて経路を選びます。対象サイトが直接接続ルールに一致すると、クライアントは接続済みと表示されても、そのリクエストはノードを通りません。クライアントの接続ログやルール一致の記録を開き、対象がプロキシ、直接接続、拒否のどれに一致したかを確認します。ノードの状態だけからリクエストの経路を推測しないでください。
ブラウザ拡張機能がシステム設定を上書きしている
プロキシ拡張機能が別のノードを指定していたり、無効にした際に直接接続へ戻ったりすることがあります。その場合、ブラウザの出口とシステムの出口が一致しません。確認時は、まずネットワーク関連の拡張機能をすべて無効にし、ブラウザプロセスを終了してから、システムプロキシまたはTUNモードで再テストします。無効化後に結果が一致するなら、問題はノードではなくブラウザ独自の設定にあります。
ルーティングの優先度または仮想NICに異常がある
TUNモードは仮想NICとルーティングに依存します。他のネットワークツール、企業向けセキュリティソフト、仮想マシン、コンテナネットワーク、古いクライアントが同時にルーティングを変更すると、対象通信がより優先度の高いインターフェースへ流れることがあります。まずネットワークを変更する他のプログラムを終了し、クライアントを再起動します。それでも解決しない場合は、ノードを何度も切り替えるより、仮想NICの設定を作り直すほうが適切です。
DNSの経路と出口の経路が一致していない
ドメインの問い合わせがローカルネットワークを通っていると、経路の想定に合わない名前解決結果が返る、別のアドレスへ誘導される、検査ページでリゾルバーの不一致が報告されるといったことがあります。クライアントのDNSモード、ブラウザの暗号化DNS、システムの名前解決設定が互いに上書きしていないかを確認します。分流DNSが正常な設計である場合は、対象ドメインが正しい名前解決ルールに一致しているかを確認します。
サブスクリプション設定が期限切れ、または更新されていない
サブスクリプションをインポートすると、クライアントは通常、ローカルに設定を保存します。サーバー側のノード情報が変わっても、古い設定が一覧に残り、接続品質や出口の動作に問題が出ることがあります。信頼できる情報源からサブスクリプションを更新し、クライアントが実際に更新を完了したか確認します。サブスクリプションの内容には接続設定が含まれることが多いため、出所の不明なページにはURLを貼り付けず、認証情報と同じように管理してください。
切断保護が再接続を妨げている
切断保護は、経路が中断した際に通信がローカルネットワークへ戻るのを防ぎます。ノードが再接続したあと、ファイアウォールやルーティングの状態が正しく復元されないと、クライアントはオンラインと表示されてもアプリがネットワークへ接続できないことがあります。まず切断保護がブロック状態のままになっていないか確認し、クライアントの案内に従って再接続またはネットワークコンポーネントを再起動します。問題を隠すために保護機能を長期的に無効にするのは避けてください。
経路の種類と実際の出口を混同している
直接接続は端末がリモートノードへ直接接続する方式です。中継では通常、まず中間入口へ接続し、そこから出口へ転送します。IEPLは入口と出口の間で使われる回線構成を示します。これらは転送経路に影響しますが、出口の確認に代わるものではありません。直接接続、中継、IEPLのいずれを使う場合も、ウェブサイトから最終的に見えるのは出口ノードのアドレスです。そのため、IPとDNSの結果で確認する必要があります。
- ✅ ルールの一致結果と接続ログを確認し、対象リクエストがどの経路に割り当てられたかを確認する。
- ✅ プロキシ、仮想NIC、ルーティングを変更する他のネットワークツールを終了する。
- ✅ サブスクリプション更新後に選択中のノードを確認し、古い設定を使い続けない。
- ✅ 切断保護、システムファイアウォール、仮想NICが正常な状態に戻っているか確認する。
- ❌ プロトコルやノードを無作為に連続して切り替えず、本当の設定問題を隠さない。
- ❌ IEPL、中継、直接接続という表示だけを、出口が有効になった証拠とみなさない。
プラットフォームごとに確認すべき点
Windowsのクライアントでは、システムプロキシとTUNという2つの動作方式が一般的です。システムプロキシはシステム設定に従うアプリに適し、TUNはより広い範囲の通信を処理したい場面に向いています。確認時は、仮想NICの状態、システムプロキシの設定が残っていないか、他のネットワークソフトがルーティングを変更していないかに注意します。モードを切り替えたあとは、対象アプリを再起動してから確認してください。
macOSでは、システムネットワーク拡張機能とプロキシ設定に明確な権限が必要です。クライアントで関連機能を初めて有効にすると、システムから確認を求められる場合があります。権限が完全に付与されていないと、画面にはノード接続済みと表示されても、一部の通信がネットワーク拡張機能に処理されないことがあります。クライアントのウィンドウだけでなく、システム設定で拡張機能の状態を確認してください。
Androidのクライアントは通常、システムVPNインターフェースを通じて通信を処理し、アプリごとの分流に対応する場合もあります。一部のアプリだけが有効にならない場合は、そのアプリが除外対象になっていないか、現在のモードに対応しないネットワーク経路を使っていないかを確認します。省電力設定によってクライアントのバックグラウンド動作が制限され、画面ロック後に経路が切断されることもあります。
iOSとiPadOSも、システムが提供するネットワーク拡張機能に依存します。オンデマンド接続、低データモード、アプリの切り替えが確認結果に影響することがあります。テスト中はクライアントを有効な接続状態に保ち、対象アプリを再起動して、ブラウザの出口とアプリ内アクセスをそれぞれ確認します。サブスクリプションから設定を取り込んでいる場合は、インポートした設定形式が現在のクライアントに対応しているか確認してください。
Linux環境では差異がさらに増えます。デスクトッププロキシ、ターミナルの環境変数、コンテナネットワーク、システムルーティングがそれぞれ独立している場合があります。グラフィカルブラウザで有効でも、コマンドラインツールが同じ設定を読み込むとは限りません。ホストで有効でも、コンテナが自動的に引き継ぐとは限りません。確認時は、テスト通信がどのネットワーク名前空間から送信され、プロキシ変数とシステムルートのどちらを参照しているかを明確にします。
繰り返し実行できる最終チェックリスト
設定を調整したあとは、決めた順序で一度再確認することをおすすめします。順序を固定すると、キャッシュや古い接続、複数の設定を同時に変更したことによる影響を抑えられます。将来ノードやクライアントを変更するときにも、この手順を再利用できます。
- 経路を切断し、現在の出口IPとDNSリゾルバーの基準情報を保存する。
- テスト対象のブラウザとアプリを終了し、ネットワーク設定を変更する他のツールを停止する。
- 目的の経路へ接続し、クライアントが再接続を繰り返したりエラーを表示したりしていないことを確認する。
- ブラウザを開き直し、公開出口アドレス、ネットワーク組織、おおまかな地域を比較する。
- 新しいDNS問い合わせを発生させ、現在のグローバルDNSまたは分流DNSの方針と照合する。
- 実際に使うアプリを1つずつ起動し、ルールの一致結果、接続ログ、アクセス結果を確認する。
- ネットワークを切り替えるか、端末を短時間スリープさせたあとに再確認し、接続の復元が想定どおりか確認する。
出口IP、DNS、目的のアプリがすべてルールに合っていれば、現在の設定どおりに接続が有効になっています。1項目だけ異常がある場合は、該当する層に戻って対処します。出口が変わらないならプロキシとルーティング、DNSが合わないなら名前解決設定とブラウザのセキュアDNS、特定のアプリだけに問題があるならアプリ内プロキシ、UDP、分流、プロセスの再起動を確認します。
確認の核心は、すべての結果を完全に同じ見た目にすることではありません。通信の種類ごとに、あらかじめ決めた経路へ入っていることが重要です。グローバルモードでは出口と名前解決の方向が比較的一貫します。ルールモードでは直接接続とプロキシが併存しても構いませんが、各経路を説明・再検証でき、ルールやログから根拠を確認できる状態にしてください。