VPNが本当に有効かを確かめる最も直接的な方法は、クライアントの「接続済み」表示を見ることではなく、出口IP・DNSの帰属・アプリ別という3つの層でそれぞれ確認することです。3つすべてが通って初めて、通信が実際に回線を通ったと言えます。1つでも通らなければ「つながっているように見えて、実際は通っていない」状態です。
この記事では、3層の検証を再現可能な手順に分解します。各層について、確認すべき指標・具体的な調べ方・通らない場合の対処を示します。末尾には典型的なケースの対照表とセルフチェックリストを用意しているので、そのまま実行できます。
なぜ「接続済み」は回線を通ったことにならないのか
クライアントの接続状態は、ローカルのプロキシプロセスが起動し、入口ノードとのセッションが確立したことを示すだけです。その後の各アプリの通信がどこへ向かうかまでは確認していません。それは接続モード・分流ルール・アプリ別リストによって決まります。
見た目は「接続済み」なのに通信が漏れる、よくある3つのパターンがあります。
- ルール（分流）モードで、対象ドメインが直結と判定され、その通信が最初から回線に入っていない。
- アプリ別モードで、そのアプリが選択されていないため、通信がローカルネットワークから出ている。
- ブラウザや他のソフトが独自のプロキシ設定を持ち、システム層の上にもう1層かぶさって通信を別の場所へ誘導している。
別の言い方をすれば、「有効」とは回線を通るべき通信が実際に回線の出口から出ていて、解決と範囲の2点も一致している状態を指します。クライアントの状態ランプではなく、3層のチェックを合わせた結果です。
第1層：出口IPが本当に変わったか確認する
やり方は簡単です。まずクライアントを切断し、直結時の出口IPと帰属先を記録します。次に対象の回線に接続して、もう一度調べます。比べる点は2つ——アドレスが変わったか、帰属先が回線リストに記載された国／地域と一致するかです。
調べる際は、帰属先が表示されるIP確認サイトを使いましょう。数字の羅列だけでは地域を判断できません。コマンドラインを使う場合は、次のように直接比較できます。
# クライアントを切断した状態で先に記録しておく
curl -s https://ifconfig.me; echo
# 回線に接続してもう一度調べ、変化を比較する
curl -s https://ifconfig.me; echo
# IPv6の出口は別途確認（一部の回線はIPv4のみ対応）
curl -s -6 https://ifconfig.me; echoIPv4とIPv6は別々に確認する必要があります。一部の回線はIPv4しか扱いません。本機にIPv6の出口がある場合、IPv6のリクエストはローカルネットワークから出てしまい、「回線を通るサイトと通らないサイトがある」という症状になります。
検索結果に2つのアドレスが表示された場合は、両方の帰属を確認します。片方しか変わっていなければ、もう一方のプロトコルスタックが回線を通っていません。クライアントでIPv6の扱いを確認するか、一時的にIPv6を無効にして再テストします。
出口IPが変わっただけでは「回線を通った通信がある」ことしか証明できません。「通るべき通信がすべて通った」ことの証明にはなりません。この層を通過したら、次はDNSを確認します。
第2層：DNSの帰属も一緒に変わっているか確認する
DNSリクエストとWeb通信は別の経路です。Webの内容がすでに回線を通っていても、名前解決はローカルISPのDNSに送られていることがあります。これを一般にDNSリークと呼びます。
リークの影響は2つあります。1つは、解決結果が実際の位置に基づいて最寄りで返されるため、ローカルのCDNノードが割り当てられ、ページの言語や価格の地域が回線の所在地と食い違うこと。もう1つは、解決リクエストによって実際のネットワーク位置が露出し、回線を使う目的と矛盾することです。
確認は2段階です。まず本機が現在使っているDNSサーバーがどれかを見て、次にリゾルバに送信元アドレスを自己申告させ、帰属を逆引きします。
# 本機が現在使用しているDNSサーバーを確認する
ipconfig /all # Windows
scutil --dns # macOS
resolvectl status # Linux
# リゾルバに送信元アドレスを自己申告させ、帰属を逆引きする
dig +short TXT o-o.myaddr.l.google.com @8.8.8.8解決サーバーがまだローカルISPのものである場合は、クライアントの機能に応じて順に試します。クライアントのDNS上書き／リモートDNSオプションを有効にする。暗号化DNS（DoH / DoT）に切り替え、その通信も回線を通ることを確認する。ブラウザが独自に「セキュアDNS」を有効にしていないか確認する——ブラウザ内蔵のDoHはシステムのDNS設定を迂回し、別の経路で解決させてしまいます。
第3層：アプリ別に通信範囲を検証する
最初の2層は回線が通っているか、解決がクリーンかを検証します。第3層は範囲、つまりどのアプリ・どのドメインが回線に含まれているかを検証します。
クライアントには通常3つのモードがあります。グローバルモードはすべての通信を回線に送ります。ルール（分流）モードはドメイン・IPレンジ・GeoIPで判断します。直結モードは回線を通りません。モバイルではさらにアプリ別リストがあり、選択したアプリだけが引き受けられます。
検証方法は横並びの比較です。同じ端末で2つの異なるアプリから出口確認ページを開き、出口IPが一致するかを見ます。片方が回線の出口、もう片方がローカルの出口なら、どちらかのアプリが引き受けられていません。デスクトップでは、クライアントの接続ログやルールのヒット記録で、対象ドメインがどのルールに一致し、プロキシと直結のどちらを通ったかを確認できます。
また、ルールモードの分流判定は通常、ドメイン・IPレンジ・GeoIPデータベースに基づきます。データベースには更新周期があるため、新しく現れたドメインが誤判定されることがあります。これも「昨日は問題なかったのに、今日は急に直結になった」よくある原因の1つです。まずルールのヒット記録を確認し、それから回線の問題かどうかを判断しましょう。
アプリ別の検証の価値は「回線は問題なく、特定のアプリだけが引き受けられていない」ケースを切り分けられる点にあります。この種の状況は回線障害と誤判定されやすいので、まず設定を直し、それから回線の変更を検討します。
「つながっているように見えて、実際は通っていない」典型的なケース
次の表は、よくある症状・原因・対処をまとめたものです。症状から照合すれば、通常は数分で原因を特定できます。対処は「まず設定を直し、次に回線を変える」順に並べています。
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| 出口IPが接続前とまったく同じ | クライアントがアプリ別モードで、現在のアプリが選択されていない。またはルールが対象ドメインを直結と判定している | アプリ別リストでそのアプリにチェックを入れるか、グローバルモードに切り替えて再検証する |
| 出口IPは変わったのに、ページはローカルの言語・価格のまま | DNSリクエストが依然としてローカルISPで解決され、CDNが解決位置に応じて最寄りを割り当てている | クライアントのDNS上書き／リモートDNSを有効にするか、同じく回線を通る暗号化DNSに切り替える |
| ブラウザでは有効だが、他のアプリでは有効にならない | ブラウザ内蔵のプロキシ拡張や独自のプロキシ設定がブラウザの通信を引き受けている | ブラウザのプロキシ拡張を無効にし、クライアントに一本化して再テストする |
| サブスクリプション更新後も、回線リストが古いまま | クライアントがサブスクリプションを更新しておらず、古いノード情報を使い続けている | クライアントで手動でサブスクリプションを更新するか、サブスクリプションリンクを再インポートしてクライアントを再起動する |
| 接続済みと表示されるのに、どのサイトも開けない | ノードが利用不可、またはルールが通信を到達不能な出口に振り分けている | 別の回線に切り替えて再テストする。それでもつながらない場合はグローバルモードに切り替え、ルールが関係しているか比較する |
- ❌ クライアントのホーム画面の「接続済み」だけで判断する——アプリ層の通信が実際に回線を通ったことにはならない
- ❌ 1つのサイトだけで出口を測る——最寄りへの振り分けやキャッシュに当たり、判断を誤る
- ❌ ブラウザで別のプロキシ拡張を同時に有効にしている——測っているのは拡張の出口かもしれない
- ❌ サブスクリプション更新後にクライアントを再起動していない——古い接続が有効なままで、新しいノード情報が反映されていない
再現可能な3層の自己診断手順
ここまでの方法をつなげると、次の5ステップになります。ネットワーク環境を変えたとき（自宅・会社・公共Wi-Fiの切り替え）、サブスクリプションを更新したとき、回線を切り替えたときに1回ずつ行えば十分で、接続のたびに測る必要はありません。
- クライアントを切断し、直結時の出口IPと帰属先を記録する。IPv4とIPv6をそれぞれ1回ずつ確認する。
- 対象の回線に接続し、出口IPを再確認する。アドレスが変わり、帰属が回線の表記と一致することを確かめる。
- DNSリーク検出ページを開き、解決サーバーの帰属がローカルISPではなく回線側であることを確認する。
- 2つの異なるアプリでそれぞれ出口確認ページにアクセスし、出口が一致することを確認する。さらにクライアントのログでルールのヒットを照合する。
- 3層すべてが通ったら、速度と安定性を測る。どれか1層でも通らなければ、まず設定を直し、すぐに回線を変えない。
- ✅ 出口IPが回線の所在する国／地域になり、IPv4とIPv6の向きが一致している
- ✅ 解決サーバーの帰属が回線側で、リストにローカルISPが現れない
- ✅ 対象アプリがクライアントに引き受けられ、他のアプリと出口が一致している
- ✅ ルールのヒット記録で、対象ドメインが直結ではなくプロキシを通っている
サブスクリプションリンクはアカウントの認証情報と同じです。スクリーンショットや公開グループへの転送で流出します。流出した場合は、ユーザーパネルでサブスクリプションリンクをリセットすると古いリンクが無効になり、クライアントで再インポートすれば済みます。
3層の検証は順番を入れ替えないでください。出口IPは「通ったか」に、DNSは「クリーンに通ったか」に、アプリ別は「範囲が正しいか」に答えます。3層すべてが通って、初めて本当に有効と言えます。
よくある質問
クライアントが接続済みと表示されていても、毎回検証する必要がありますか？
いいえ。ネットワーク環境を変えたとき（自宅・会社・公共Wi-Fiの切り替え）、サブスクリプションを更新したとき、回線を切り替えたときに1回ずつ確認すれば十分です。日常的な利用なら、出口IPの層だけでほとんどのケースをカバーできます。
出口IPは変わったのに、サイトがローカル版のままなのはなぜですか？
多くの場合、DNSが依然としてローカルで解決され、CDNが解決位置に応じて最寄りのローカルノードを返しています。第2層の方法で解決サーバーの帰属を確認し、クライアントのDNS上書きまたはリモートDNSオプションを有効にしてください。
アプリ別モードでは、バックグラウンドのアプリも選択する必要がありますか？
必要に応じて。OSのアップデートやアプリストアのようなバックグラウンドの大容量通信は、直結のままにしておく方が通常は適切です。本当に回線を通したいアプリだけを個別に選択します。ルールが少ないほど、切り分けは簡単になります。
3層すべて通っているのに、アクセス速度が遅いままです。回線の問題ですか？
まず範囲を見ます。特定の1つのサイトだけ遅い場合は、相手側のCDNの振り分けやローカルネットワークの変動が原因であることが多いです。複数の回線・複数のサイトで遅い場合に、回線の変更を検討します。また、速度を測る前に3層の検証が通っていることを確認してください。そうでなければ、ローカル直結の速度を測っている可能性があります。