VPN接続後に有効か確認する際、「接続済み」というクライアント表示だけを見てはいけません。この表示は通常、クライアントとノードのハンドシェイクが完了したか、ローカルプロキシのポートが起動したことを示すだけです。ブラウザ、デスクトップアプリ、IPv6通信、DNSクエリまで想定した経路を通っている証明にはなりません。信頼できる確認方法は、未接続時のネットワーク状態を基準として記録し、グローバルIP、DNSの解決経路、各アプリの実際の通信を順に照合することです。
確認時は、「トンネルの確立」と「実際の通信がトンネルに入ること」を分けて考える必要があります。前者はクライアントの状態で判断できますが、後者は外部からの確認と端末のルーティング情報を合わせて検証します。システムプロキシ、TUNモード、ルール分岐、アプリ固有のネットワーク設定によって最終結果は変わるため、同じ端末でもブラウザは経路を通り、コマンドラインツールは直接接続する場合があります。
まずグローバルIPを確認：ウェブ通信の出口を確かめる
グローバルIPは、最も分かりやすい確認項目です。サイト内の IPチェックページを開き、切断時と接続時の公開アドレス、地域、ネットワーク事業者をそれぞれ確認します。接続後に表示される公開アドレスと地域が、選択したノードに対応する場所へ変わっていれば、チェックページを開いたブラウザのリクエストは経路を通っています。
ただし、「IPが変わった」ことから分かるのは、確認したリクエストの経路が変化したという点だけです。端末上のすべてのアプリが対象になるわけではありません。ブラウザはシステムプロキシに従っていても、特定のデスクトップアプリは独自に直接接続することがあります。また、IPv4だけがプロキシを通り、IPv6はローカルネットワークから出ている可能性もあります。確認結果はクライアントの動作モードと合わせて解釈してください。
- ✅ 回線を切断した状態で、現在の公開アドレスとネットワーク事業者を記録し、比較用の基準にする。
- ✅ 対象ノードへ接続してチェックページを再読み込みし、公開アドレスと地域が想定どおり変わったか確認する。
- ✅ IPv4とIPv6を同時に確認する。ローカル環境でIPv6が利用でき、クライアントが制御していない場合は、引き続きルーティングを確認する。
- ✅ シークレットウィンドウを使うか、チェックページのキャッシュを削除して再確認し、ブラウザが古いページ内容を再利用しないようにする。
- ❌ ウェブページの言語、タイムゾーン、検索結果の地域だけで判断しない。これらはアカウント設定やキャッシュの影響を受ける場合がある。
接続後もIPが変わらない理由
よくある原因は、クライアントがローカルプロキシだけを起動し、システムプロキシが有効になっていないことです。ブラウザにも、そのプロキシを使う設定が明示されていない可能性があります。別のケースでは、ルールモードがチェックサイトを直接接続と判定し、クライアントはオンラインでも、チェックリクエストは分岐ルールに従ってノードを迂回します。一時的にグローバル制御モードへ切り替えて再確認してください。グローバルモードでアドレスが変わるなら、問題は通常、ノードのハンドシェイクではなくルールのマッチングにあります。
クライアントが待ち受けているプロキシの種類と、アプリ側の設定が一致しているかも確認します。たとえばアプリがHTTPプロキシに設定されているのに、クライアントがSOCKSインターフェースしか開いていない場合や、プロキシのアドレス・ポートが実際の待ち受け設定と異なる場合、アプリが気付かないまま直接接続へ戻ることがあります。推測でノードを何度も切り替えるのではなく、まずクライアントのログに対象ドメインや接続記録が出ているか確認してください。
次にDNSを確認：ドメインの問い合わせが想定どおり処理されているか
ウェブサイトへアクセスする前に、端末は通常、ドメイン名を接続可能なアドレスへ解決します。DNSクエリがローカルネットワークの既定リゾルバーへ送られたままだと、問い合わせたドメインが知られる可能性があり、ノードの地域と異なる解決結果によってアクセスに影響することもあります。DNSリークの要点は、チェックページに見慣れないリゾルバーが表示されるかどうかではなく、問い合わせが想定した暗号化・プロキシ・リモート解決経路を迂回していないかです。
回線接続後にDNSチェックを実行し、リゾルバーの所属ネットワークと地域がクライアント設定に合っているか確認します。リモート解決を設定している場合、結果は通常、回線側の解決方針と一致します。ローカルの暗号化DNSを使っている場合、選択した公開DNSサービスがチェックページに表示されることがありますが、必ずしもリークを意味しません。判断は実際の設定に基づいて行い、DNSの地域とグローバルIPが完全に一致することを機械的に求めないでください。
| 確認項目 | 正常と考えられる手がかり | 確認が必要な現象 | 優先して確認する場所 |
|---|---|---|---|
| グローバルIP | 選択したノードの地域とネットワーク事業者に一致する | 接続前後でまったく同じ、またはローカルとノードのアドレスを頻繁に行き来する | システムプロキシ、TUN制御、ルール分岐 |
| DNS | リゾルバーがクライアント設定のローカルまたはリモート方針に合っている | リモート解決の設定なのに、ローカルネットワークの既定リゾルバーが継続して表示される | DNSモード、ブラウザのセキュアDNS、システムのネットワーク設定 |
| IPv6 | トンネルで制御されている、またはクライアントの方針に沿って適切に処理される | IPv4はノードのアドレスだが、IPv6はローカルの出口を表示する | 仮想ネットワークアダプターのルーティング、クライアントのIPv6設定 |
| 特定のアプリ | 対象リクエストがクライアントの接続ログに表示される | ブラウザは正常だが、デスクトップアプリではローカル向けの内容が表示され続ける | アプリのプロキシ、バイパスリスト、独立したネットワークスタック |
ブラウザのセキュアDNSによって確認結果が変わる
一部のブラウザでは、セキュアDNSを独立して有効にできます。有効にすると、ドメインの問い合わせがOSやクライアントではなく、ブラウザから指定したDNSサービスへ直接送信されることがあります。その場合、グローバルIPの確認は正常でも、DNSチェックには別のリゾルバーが表示されます。これは必ずしもローカルネットワークから通信が平文で出ていることを意味しませんが、ブラウザの解決経路がクライアントの統一DNS方針と異なることを示しています。
確認時は、ブラウザ独自の名前解決を一時的に無効にしてシステム設定に従わせ、結果を比較できます。結果が変わるなら、ブラウザのセキュアDNSを維持するのか、クライアントで集中管理するのかを決めてください。重要なのは、互いに上書きし合う複数の解決層を同時に有効にするのではなく、設定と期待する動作を一致させることです。
IPv6とアプリ別通信を確認：一部だけがプロキシを通る状態を避ける
「チェックページは正常なのに、アプリは正常に動作しない」ケースの多くは、制御範囲が不完全なことが原因です。端末がIPv4とIPv6の両方に対応していると、アプリはシステムから返された情報に応じて接続経路を選びます。クライアントがIPv4のルートしか設定していない場合、IPv6対応アプリがローカルのIPv6出口を直接使うことがあります。その結果、同じブラウザ内でも一部の接続はノードを通り、別の接続はローカルネットワークから出ていきます。
確認するには、2種類の公開アドレスを同時に確認し、クライアントの仮想ネットワークアダプター、ルーティングテーブル、IPv6処理設定を調べます。クライアントがIPv6を明確に制御しない場合は、利用状況に応じてシステムまたはクライアントの設定を調整してください。「ウェブページの主要アドレスが変わった」ことだけで、すべてのプロトコルスタックが制御されたと判断しないようにします。
システムプロキシとTUNモードの制御範囲
システムプロキシは、OSのプロキシ設定を読み取るアプリに主な影響を与えます。一般的なブラウザは通常この設定に従いますが、コマンドラインプログラム、ゲーム、一部のストアアプリ、独自のネットワークスタックを実装したソフトウェアは無視することがあります。TUNモードは仮想ネットワークインターフェースとルーティングを使って、より広いIP通信を制御します。従来のプロキシ設定に対応しないプログラムの確認に適していますが、除外ルール、ローカルネットワークのルール、アプリがバインドするインターフェースの影響を受ける場合があります。
アプリ別通信を確認する際は、同じウェブページを繰り返し更新するだけでは不十分です。実際に使うソフトウェアを選び、その操作中にクライアントの接続ログを確認します。対象ドメイン、対象アドレス、接続項目が表示されているか、最終的にプロキシルールと直接接続ルールのどちらに一致したかを確認してください。ログの「ルール一致結果」は、アプリ画面に表示される地域情報より信頼できます。
- 対象ノードへの接続を維持し、まずクライアントの接続ログまたはリアルタイム接続一覧を開きます。
- 確認対象のアプリを完全に終了して再起動し、接続前に作られた長時間接続を再利用しないようにします。
- アプリ内でコンテンツの更新やページの再読み込みなど、明確な通信操作を1回実行します。
- クライアントに戻り、該当するリクエストが表示されているか、プロキシ・直接接続・拒否のどのルールに一致したかを確認します。
- 記録がまったくない場合は、アプリがシステムプロキシを迂回していないか、制御対象外のネットワークインターフェースにバインドされていないかを確認します。
ルール分岐を確認：直接接続は必ずしも障害ではない
ルールモードでは、すべてのリクエストを同じ経路へ送ることはありません。クライアントはドメイン、対象アドレス、プロセス、ルールセットに基づき、プロキシ、直接接続、拒否を決定します。日本国内向けサービス、ローカル端末のアドレス、LANリソースは直接接続に設定され、海外サイトはルールに従ってノードへ送られることがあります。そのため、同じ時点でローカルの出口とノードの出口が確認されても、必ずしも接続失敗を意味しません。重要なのは、各リクエストが既定の方針に沿って処理されているかです。
分岐が正しく動作しているかは、「この対象は本来どの経路を通るべきか」を基準に判断します。チェックサイトが誤って直接接続ルールに入っていれば、グローバルIPは変わりません。逆に、直接接続すべきサービスがノードへ送られると、ログイン地域が変わったり、アクセスが遅くなったりすることがあります。一時的にグローバルモードを使うとルールの問題を切り分けられますが、グローバルモードの結果を日常のルールモードの動作とそのまま同一視しないでください。
ルールの一致順が結果を左右する
多くのクライアントは、上から順に、またはあらかじめ設定された優先順位でルールを照合します。範囲の広い直接接続ルールが、より具体的なプロキシルールより前にあると、後者がまったく一致しないことがあります。ルールを変更した後は設定が再読み込みされたか確認し、古い接続も閉じてから再テストします。テキストを保存しただけでコアを再読み込みしていなければ、実際に動作しているのは古いルールのままかもしれません。
診断時は、まずログに表示されたルール名を確認し、そのルールがローカル設定、リモートルールセット、クライアントの既定項目のどれに由来するかを特定します。複数のスイッチを一度に変更しないでください。現象が解消しても、DNS、ルーティング、ルール変更のどれが原因だったか分からなくなるためです。
- ✅ チェックサイトは想定したプロキシルールに一致し、汎用の直接接続ルールに先に処理されないようにする。
- ✅ ルールを変更したら設定を再読み込みし、テストするアプリの古い接続を閉じる。
- ✅ LANリソースはローカルルールでアクセスし、グローバルIPの変化だけで正常性を判断しない。
- ❌ ノード、DNS、TUN、ルールモードを同時に切り替えない。切り分けの条件が崩れてしまう。
- ❌ すべての直接接続記録をリークとみなさない。ルールモードで想定された直接接続は、正常な振り分けの一部です。
サブスクリプションURL、ノード、プロトコル互換性を確認
サブスクリプションの読み込みに成功しても、利用可能なノードが現在選択されているとは限りません。クライアントが購読内容を正常に読み取っていても、古い設定、自動選択グループ、直接接続方針のまま動作していることがあります。確認時は、サブスクリプションの更新時刻、現在のノード名、プロキシグループの選択、実行中のコアが実際に読み込んだ設定が一致しているかを確認してください。サブスクリプションURLはアカウントの認証情報にあたるため、適切に管理し、公開チェックサイト、スクリーンショット、ログ共有ページに貼り付けないでください。
Shadowsocks、VMess、Trojan、VLESSは、一般的なプロキシプロトコルまたはその体系です。対応するクライアントコアの範囲はそれぞれ異なります。Hysteria2とTUICは、UDPの到達性とクライアント実装への依存度が高くなります。あるクライアントでノードを読み込めても、別のクライアントがすべてのパラメータを完全に認識できるとは限りません。「エラーなしで読み込めた」ことも、ハンドシェイク、認証、通信転送がすべて完了したことを意味しません。
ログにプロトコル項目を認識できない、転送パラメータが不足している、コアのバージョンが対応していないといった表示がある場合は、ウェブキャッシュを調べ続ける前にクライアントの互換性を確認します。一方、ハンドシェイクが完了しているのに通信リクエストがログに出ない場合は、システムプロキシ、TUN制御、ルール分岐に問題がある可能性が高くなります。
IEPL・中継・直接接続が確認結果に与える影響
直接接続の回線では、端末が遠隔入口へ直接接続するため、ローカルネットワークや国際回線の影響を受けやすくなります。中継回線では、まず近い入口へ接続し、その後、中継ネットワークを経由して出口へ送ります。IEPL専線は、特定区間で専用の国際イーサネット接続を使うことを示しますが、ユーザー端末から入口までにはローカルのアクセス経路が残ります。どのトポロジーでも、最終的にはグローバルIP、DNS、アプリログで確認してください。ノード名だけで、通信が想定どおり転送されたと判断することはできません。
回線トポロジーは、ログに表示されるアドレスにも影響します。クライアントが接続する入口アドレスと、ウェブサイトから見える出口アドレスが異なることは、中継構成では異常ではありません。確認時は、公開される出口がノードの説明に合っているか、通信リクエストが正しいプロキシグループに入っているかを見ます。入口と出口が必ず同じアドレスになる必要はありません。
「接続済みなのに、実際には経由していない」典型例
ここまでの確認項目を組み合わせれば、見かけ上の接続や一部だけが制御される問題の多くをすばやく特定できます。クライアントが接続済みと表示している間にも、次の現象は起こり得ます。証拠を確認しながら一つずつ切り分けてください。
| 表面上の現象 | 考えられる原因 | 確認方法 | 対処の方向性 |
|---|---|---|---|
| クライアントは接続済みだが、グローバルIPが変わらない | システムプロキシが有効でない、またはチェックサイトが直接接続ルールに一致している | チェックリクエストが接続ログに表示されるか確認する | プロキシの有効設定、ルール一致、アプリのプロキシ設定を確認する |
| グローバルIPは変わったが、DNSはローカルネットワークのまま | DNSがクライアントに制御されていない、またはブラウザが独自の解決設定を使っている | システムとブラウザのDNS設定を比較する | 解決方針を統一して再テストする |
| ブラウザは正常だが、デスクトップアプリに変化がない | アプリがシステムプロキシを無視している、または既存の長時間接続が再構築されていない | アプリを再起動し、クライアントのリアルタイムログを確認する | アプリプロキシ、または適切なTUN制御方式を使う |
| IPv4は正常だが、IPv6はローカルの出口を表示する | 仮想ネットワークアダプターがIPv6ルートを制御していない | 2種類の公開アドレスを個別に確認する | クライアントとシステムのIPv6方針を確認する |
| ノードは読み込めるがアクセスできない | プロトコルパラメータの互換性がない、サブスクリプションが再読み込みされていない、またはノードが選択されていない | コアのエラーと現在のプロキシグループを確認する | 互換性のあるクライアントへ更新し、サブスクリプションを再読み込みする |
| ノードを切り替えても結果が変わらない | 古い接続、ブラウザキャッシュ、またはプロキシグループが元のノードを参照し続けている | 古い接続を閉じ、現在有効なノードを確認する | 確認対象のアプリを再起動し、基準状態と比較する |
推奨する完全な再確認手順
- 回線を切断し、グローバルIP、DNS解決事業者、IPv6の状態を記録する。
- 対象ノードへ接続し、クライアントログでハンドシェイクと設定の読み込みにエラーがないことを確認する。
- グローバルIPを再確認し、切断時の状態およびノードの地域と比較する。
- DNSチェックを実行し、解決経路がクライアントの設定どおりか判断する。
- IPv4とIPv6を個別に確認し、重要なアプリのリクエストが接続ログに表示されることを確認する。
- 結果が想定と異なる場合は、グローバルモードとルールモードを一時的に比較し、具体的な分岐ルールを特定する。
- 設定を修正したら古い接続を閉じ、基準状態から再確認する。キャッシュの影響を避けるためです。
グローバルIPが変わっても、DNS、IPv6、または特定のアプリが想定どおりでない場合は、クライアントログに残る時刻、対象ドメイン、一致したルール、エラー情報を保存し、一つずつ調整してください。変数を一つに絞って再テストする方が、ノードを何度も切り替えるより問題を特定しやすく、ルールによる直接接続、ブラウザ独自のDNS、古い接続を回線障害と誤認することも避けられます。