クライアントの「接続済み」表示は、ローカルでトンネルのハンドシェイクが成功したことしか示していません。データが本当に回線から出ているかは分かりません。VPNが有効かどうかは、それぞれ独立して誤りうる3つの信号で判断します。出口IP、DNSの解決位置、そしてアプリごとの実際の経路です。3つのうち2つが食い違っていれば、有効ではないものとして扱ってください。

まず整理したい3つの違い:接続状態・出口IP・DNS解決

接続状態はクライアント自身の判断で、「トンネルが確立した」ところまでしかカバーしません。トンネル確立後、どの通信をトンネルに入れるか、ドメインを誰に解決させるか、特定のアプリがシステム設定を迂回するかは、別の設定で決まります。だから検証は分けて行い、「Webページが開けるかどうか」という1つの結論で全部を片付けないようにします。

3つの検証信号と、それぞれの正常・異常な現れ方
確認項目 確認方法 正常な状態 異常なサイン
出口IP 接続前と接続後にそれぞれグローバルIPを確認 アドレスが変わり、選択した回線の接続先地域になっている 接続前とまったく同じ、または選択した地域と無関係な場所になっている
DNS解決 リゾルバのグローバル出口を調べ、解決結果と突き合わせる リゾルバの出口が回線の出口と同じ地域 解決がローカルネットワークのまま、または結果がローカルのノードを指している
アプリ別の経路 対象アプリ内で単独で出口を確認 そのアプリの出口が回線と一致 そのアプリだけローカル出口のまま、他のアプリは正常

おすすめの順序は、まず出口IP(最も分かりやすい)、次にDNS(最も見落とされやすい)、最後にアプリごとの確認(最も誤判定しやすい)です。

キャッシュは嘘をつきます。同じページを2回目に開くとローカルキャッシュやCDNのエッジノードから返ることがあり、回線が切れていても表示は変わりません。検証にはシークレットウィンドウを使うか、それまで一度も開いたことのないドメインを使ってください。

方法1:出口IPを調べて、通信がどこから出ているか確認する

出口IPとは、外部サイトから見た送信元アドレスのことです。やり方は簡単で、接続を切った状態で1回、接続後に1回調べ、2つの結果が異なり、新しいアドレスが選んだ地域に入っていればこの項目は合格です。コマンドラインで取得できるのはプレーンテキストの戻り値なので、クライアントの画面表示に依存しません。

# macOS / Linux ターミナル
curl -s https://ifconfig.me/ip

# Windows PowerShell
(Invoke-RestMethod https://ifconfig.me/ip)

# IPv6 の出口だけを確認
curl -s -6 https://ifconfig.me/ip

ブラウザでIP確認ページを開いてもかまいませんが、表示されているのが純粋な出口アドレスかどうかを確認してください。CDNが判定した都市名は実際の接続先と大きくずれることが多く、結論として使うと誤判定につながります。

出口IPが選択した地域と合わないとき、すぐ失敗と決めつけない

次の3つは正常なケースで、分けて考える必要があります。

  • 中継回線:入口が近く、接続先が目的の地域にある場合、見えるべきは接続先のアドレスです。入口のアドレスが見えているなら、その通信は分割ルールで直接接続と判定されています。
  • IP归属データベースの遅延:ブロードキャスト用アドレス帯や最近変更されたアドレスは、帰属情報の更新が実際より遅れることがあります。別の照会元で突き合わせると確実です。
  • デュアルスタックの片方しか通していない:IPv4は回線を通り、IPv6はローカル出口のまま。ブラウザやOSは通常IPv6を優先するため、ページは「つながらない」ように見えて、実際は別の経路を通っています。

デュアルスタックの切り分けには、上の -6 付きのコマンドを使い、続けて -6 なしでも実行してください。2つの結果は必ず一緒に見ます。片方だけ見ると誤った結論になります。

方法2:DNS解決を調べて、ドメインがどこで解決されているか確認する

DNSリークとは、通信はトンネルに入っているのに、ドメインの問い合わせはローカルネットワークのリゾルバに送ってしまうことです。その結果、解決はローカルの位置に基づいて返され、プラットフォーム側は2種類の位置情報を受け取ることになります。症状は、つながるのに読み込みが遅い、ログインで追加の本人確認を求められる、動画配信では地域不一致と判定される、などです。

# 特定のドメインが現在どう解決されているか確認
nslookup www.wikipedia.org

# リゾルバのグローバル側出口アドレスを照会(@ 引数なし、システムの現在のリゾルバを使用)
dig +short TXT o-o.myaddr.l.google.com

# Windows での同じ照会
nslookup -type=TXT o-o.myaddr.l.google.com

2つ目のコマンドが返すのは、再帰リゾルバのグローバル側出口アドレスです。これを手順1で調べた出口IPと並べて見てください。両方が同じ地域にあれば、解決も回線に沿って行われています。リゾルバがローカルのプロバイダのままであれば、DNSの引き継ぎに失敗しています。

DNSがひっそり漏れる3つの原因

  1. ブラウザ内蔵のセキュアDNSが有効になっている。システムのリゾルバを迂回するため、クライアントがDNSを引き継いでも止められません。検証時はまずブラウザ設定でセキュアDNSを切り、もう一度測って2つの結果を比べれば特定できます。
  2. クライアントがDNSをローカル処理に回している。一部のクライアントは既定で「ローカル解決+リモート接続」となっており、ドメインはローカルで解決し終えます。回線側で解決する設定に変えて再測定してください。
  3. 分割ルールがそのドメインを最初から直接接続と判定している。ルールモードではこれは想定通りの動作です。検証すべきは回線を通る側と判定されたドメインで、直接接続のドメインをサンプルにしないでください。

nslookup を使うときは、表示される「Server」の行に注目してください。そこが現在有効なリゾルバです。この行がルータのアドレスやプロバイダのアドレスのままだと、後ろの解決結果に参考価値はありません。

方法3:アプリ別に検証し、特定のアプリが回線を通っているか確認する

アプリ別プロキシはAndroidクライアントで最もよく見かけます。デスクトップ版の多くはグローバルTUNで、アプリ別に分けるにはルーティングテーブルや専用ブラウザのプロキシ、仮想マシンを使うことになります。この項目が誤判定しやすいのは、クライアントによってチェックの意味が逆になるからです。「選択したものだけをプロキシ」と「選択したものを除外」があります。

  1. まずチェックの向きを確認

    アプリ別リストを開き、画面に「選択したアプリのみプロキシ」と書かれているか、「選択したアプリを除外」と書かれているかを見ます。ここを逆に取ると後は全部狂い、どれだけ丁寧に比較しても意味がありません。

  2. チェックしたアプリ内で出口IPを確認

    アプリ内蔵ブラウザでIP確認ページを開き、結果を記録して、接続前に控えたベースラインと比べます。アドレスが変わり、選択した地域に入っていればこの項目は合格です。

  3. チェックしていないアプリ、またはシステムブラウザでもう一度確認

    2つの結果は異なるはずです。同じならアプリ別が効いておらず、通信は結局1つの経路を通っています。

  4. 結果が同じなら2か所を確認

    1つはリストの向きが逆になっていないか、もう1つはそのアプリが独自のネットワークスタックを使っていないか。内蔵プロキシ、独自プロトコル、OSレベルのダウンローダはシステム設定を迂回することがあり、こうしたケースはクライアントの設定では解決できません。

  5. ベースラインの記録を残す

    OSのメジャーアップデートやクライアントの更新後、アプリ別リストはリセットされることがあります。このベースラインで再測定しておけば、問題が起きてから原因を探すよりずっと楽です。

デスクトップ版にアプリ別の切り替えがない場合は、別の方法で判断します。同じマシンで、システムブラウザと独自のプロキシ設定を持つアプリをそれぞれ使って確認し、両者の出口が一致するかを見ます。一致すれば全体の引き継ぎが効いており、一致しなければトンネルを迂回しているアプリがあり、そのアプリ専用にプロキシを設定する必要があります。

つながっているように見えて実は通っていない:よくあるケース一覧

以下は切り分けで最も頻繁に出てくるケースです。項目ごとのチェックリストとして使えます。

  • ❌ クライアントは接続済みでも、購読リンクがとっくに期限切れで、ノード一覧が古く、すでに停止したアドレスにつないでいる。
  • ❌ システムプロキシモードでは、システムのプロキシ設定を読むアプリだけが回線を通り、この設定を読まないアプリは従来どおり直接接続になる。
  • ❌ ブラウザでセキュアDNSが有効になっており、解決がクライアントの引き継ぎを迂回。出口IPは変わったのに解決はローカルのまま。
  • ❌ IPv4しか引き継いでおらず、IPv6はローカル出口のまま。デュアルスタックのサイトはIPv6を優先するため、ページはつながっていないように見える。
  • ❌ アプリ別リストの向きが逆で、プロキシしているつもりが実際は除外されている。
  • ❌ 分割ルールが対象ドメインを直接接続と判定している、またはルールセットが長期間更新されていない。
  • ✅ 正しい状態:切断時と接続時で調べた出口IPが異なり、選択した地域に入っている。リゾルバの出口も回線と同じ地域。対象アプリ単独で調べても回線の出口になっている。

判断基準は明確にできます:3つの信号のうち2つが食い違えば、有効ではないものとして扱います。まずクライアントに戻って購読状態と分割モードを確認し、次にDNSとデュアルスタック、最後に回線そのものを疑います。順序を逆にすると、問題のない部分で延々と試行錯誤することになります。

1回の検証手順を最後まで

上の方法を1つの固定手順にまとめ、ネットワークを変えたとき、機器を変えたとき、クライアントのメジャーアップデート後に1回ずつ実行してください。数分で終わります。

  1. 接続を切り、ベースラインを記録:IPv4出口、IPv6出口、リゾルバ出口の3項目を書き留めます。
  2. いずれかの回線に接続し、同じ3項目を再度調べます。
  3. 比較:出口が変わったか、地域が選択した回線と一致するか、リゾルバも追随して変わったか。
  4. 対象アプリを開き、アプリ内で単独で出口を確認します。
  5. どれか1つでも変わっていなければ、前節のリストに沿って1項目ずつ切り分け、設定は一度に1つだけ変え、変えたらすぐ再測定します。
  6. 別の回線でもう一度実行し、単一の回線の問題を切り分けます。いきなりサービス全体が使えないと判断しないようにします。
90+ 対応国・地域
210+ 回線数
無制限 同時接続台数
7日間 理由不問の返金

回線数が多いということは、再測定のコストが低いということです。ある回線の出口が違っていれば、同じ地域の別の回線で同じ3項目を実行すれば、回線の問題かローカル設定の問題かを切り分けられます。回線一覧は地域ごとにまとまっているので、同じ地域の予備回線を選ぶのは簡単です。本サービスはログを記録せず、購読の使用量と通信パックの残量は管理画面で自分で確認できます。7日間の理由不問返金期間内に問題を見つけたら、面倒な切り分けを先にせず、そのまま返金手続きを進めてください。

検証の記録は残しておくことをおすすめします。日付、ネットワーク環境、回線の地域、3項目の結果です。いざ問題が起きたとき、この記録はどんな口頭説明よりも役に立ち、どの変更から問題が始まったかも分かります。

結論:Webページが開けるかどうかは判断基準ではありません。3つの信号が一致してこそです。出口IP、DNSの解決位置、アプリ別の経路、この3つがそろって初めて本当に有効と言えます。