VPNが効いているか確認する方法:初心者向け完全ガイド(IP・DNS・アプリ別検証)

なぜ「接続済み」は通信が回線を通ったことを意味しないのか

クライアントを開いてステータスが「接続済み」になっても、それは端末と回線サーバーの間にトンネルが確立したことだけを意味します。通信が実際にそのトンネルに入っているかどうかは、クライアントの動作モード、分流ルール、アプリ自身のネットワーク挙動によって決まり、この3つは「接続済み」とは別の話です。

動作モードは大きく2種類あります。システムプロキシモードはOSのプロキシ設定を書き換えるだけで、その設定を読むアプリだけがリクエストをトンネルに渡します。ブラウザは通常読みますが、デスクトップアプリの一部は読みません。TUN / 仮想NICモードはシステムに仮想ネットワークアダプターを作成してルーティングテーブルを引き継ぐため、システムプロキシを読まないアプリを含め、ほとんどのアプリの通信がトンネルに入ります。同じサブスクリプションでも、2つのモードでは検証結果がまったく変わることがあります。

第2の層は分流ルールです。ルールリストはドメインやIPを「直接接続」「プロキシ経由」「拒否」などのグループに分類します。対象ドメインが直接接続と判定されれば、トンネルが完全に正常でも、そのアクセスはローカル回線から出ていきます。ルールセットが古い、あるいはクライアントごとに内蔵の既定ルールが違うと、「同じサイトなのに、回線を通る端末と通らない端末がある」という状態になります。

第3の層はアプリ自身にあります。独自のネットワークスタックを内蔵し、システムプロキシを読まないアプリがあります。IPv6を優先するアプリもあれば、トンネルがIPv4しか引き継いでいないこともあります。UDPベースの通信(QUIC、音声通話、一部のゲーム)はTCP転送しか対応していない場合、フォールバックしたり直接接続になったりします。こうしたケースでは「クライアントは接続済みなのに、アプリはローカル回線のまま」という状態になります。

3ステップの自己点検:出口IP → DNS → アプリの実測

3つのステップは「外側から内側へ」の順に並んでいます。まず通信がトンネルに入っているかを確認し、次にトンネル内の名前解決がクリーンかを確認し、最後に目的のアプリが実際の場面で使えるかを確認します。

1. 切断時と接続時にそれぞれ出口IPを確認し、国・地域とプロバイダの帰属を比べます。
2. DNS解決がどのサーバーで行われているかを確認し、名前解決リクエストがローカルのプロバイダに届いていないことを確かめます。
3. 実際に使うアプリを1つずつ実測します。適当なWebページを開いて終わりにしないこと。

3つのステップは段階的な関係にあり、どれか1つでも通らなければ、「接続済み」がまだ「有効」に変わっていないということです。どの段階でつまずいているかを特定してから、回線の変更、モードの変更、ルールの更新のどれを行うかを決めます。

ステップ1:出口IPを確認し、地域が選択した回線と一致するかを見る

出口IPを調べるツールはたくさんありますが、ポイントは「比較」です。まず接続を切った状態で1回調べて結果を記録し、次に回線に接続してシークレットウィンドウでもう1回調べ、2つを並べて見比べます。コマンドラインの方法は、何度も検証する場面に向いています。

# 現在の出口IPを確認(Windows / macOS / Linux 共通)
curl -s https://ifconfig.me

# 地域とプロバイダ情報が必要な場合は、JSONを返す照会APIを使う
curl -s https://ipinfo.io/json

Webページのほうが分かりやすい方法です。任意のIP確認ページを開き、IPv4とIPv6の両方を見ます。片方しか変わっていなければ、もう片方はローカル回線のままです。

ステップ2:DNS解決を確認し、リークがないか確かめる

DNSリークとは、Webの通信はトンネルを通っているのに、ドメインの名前解決リクエストはローカルのプロバイダのDNSに送られ続けている状態です。これには2つの影響があります。1つは、アクセスの意図がローカルのリゾルバーに知られてしまうこと。もう1つは、解決結果がローカルに最も近いノードを指し、配信ラインナップの不一致や速度異常を招くことです。DNSリークはクライアントを切断させないため、接続状態を見ているだけでは絶対に気づけません。

確認方法は2つあります。ブラウザでDNSリーク検出ページを開くと、今回の名前解決に使われたサーバーとその所在地が一覧で表示されます。コマンドラインでリゾルバーのアドレスを見る方法でも同じように判断できます。

# macOS / Linux:リゾルバーを確認
dig example.com | grep SERVER

# Windows:リゾルバーと解決結果を確認
nslookup example.com

判断基準はシンプルです。リゾルバーの所在地が回線の地域と一致しているか、トンネル内部のDNSアドレスとして表示されている必要があります。ローカルのプロバイダのリゾルバーが表示されているなら、名前解決リクエストはトンネルを通っていません。

DNS設定を変更したり回線を切り替えたりした後は、まずOSのDNSキャッシュをクリアしてから再確認します。そうしないと古い結果を見続けることになります。

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux(systemd-resolved)
sudo resolvectl flush-caches

ステップ3:アプリ別に検証し、ブラウザだけで判断しない

ブラウザはシステムプロキシ設定を読むため、最もプロキシを通しやすいアプリです。しかし実際の使い勝手を決めるのは、多くの場合ほかのアプリです。検証は実際の利用シーンに沿って行い、適当なWebページを開いただけで合格にしないこと。

コマンドラインと開発ツールは別途検証

gitやパッケージマネージャーなどのコマンドラインツールは、既定ではシステムプロキシを読みません。HTTP_PROXY / HTTPS_PROXY 環境変数を設定するか、TUNモードに切り替えて仮想NICに引き継がせる必要があります。確認方法はブラウザと同じで、コマンドラインで出口IPを1回調べ、ブラウザで見た結果と比べます。両者が一致しなければ、どちらかがトンネルを通っていません。

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

以下はトラブルシューティングで最もよく見られる現象です。「現象 → 原因 → 対処」に沿って当てはめてください。

クライアントを変えると結果が変わるのはなぜか

サブスクリプションのリンクが運ぶのは回線情報だけです。サーバーアドレス、ポート、プロトコルパラメータであり、「どう使うか」というポリシーは含まれません。同じサブスクリプションを別のクライアントに読み込ませても、既定のモードはグローバルだったりルールだったり直接接続だったりします。ルールセットも、クライアント内蔵のものと配布元のものが併用され、マッチングの順序が違えば結果も変わります。

プロトコルの違いも検証結果に影響します。Shadowsocks、VMess、Trojan、VLESSはTCPが中心で、実装によってはUDP転送に対応します。Hysteria2、TUICはQUICベースで本質的にUDPを使うため、UDPが制限されたネットワークでは接続できない、あるいは不安定になることがあります。出口IPとDNSの2ステップは通っているのに、特定の種類のアプリだけ異常が出る場合は、回線そのものよりプロトコルとUDP対応を疑ってください。回線タイプ(直接接続、中継、IEPL専用線)の違いについては、ノードページの説明を参照してください。

プラットフォームによっても違いがあります。デスクトップでは仮想NICを作ってすべての通信を引き継げます。モバイルはOSの制約を受け、通常は構成プロファイル単位かアプリ単位での引き継ぎになります。ルーターはネットワーク全体を引き継ぎますが、DNSも転送されているかを別途確認する必要があります。

再利用できるチェックリスト

ここまでの手順を1枚のチェックリストにまとめました。端末、回線、クライアントを変えたときは、この順番でひととおり確認してください。クライアントへの読み込み手順の詳細は使い方ガイドをご覧ください。

• ✅ 接続を切り、ローカルの出口IPとDNSリゾルバーを記録して比較用の基準にする
• ✅ 回線に接続したら、シークレットウィンドウで出口IPを再確認し、選択した回線の地域と一致するか確かめる
• ✅ IPv6アドレスも同時に確認し、トンネルをすり抜けていないか確かめる
• ✅ DNSキャッシュをクリアしてから、リゾルバーの所在地を再確認する
• ✅ 実際に使うアプリを1つずつ検証する。ブラウザだけで済ませない
• ✅ 回線、クライアント、ルールセットを変更したら、この手順をもう一度ひととおり行う

よくある質問