VPNが本当に効いているかをクライアントのステータスランプだけで判断する意味はありません。ランプが示すのはプロキシのプロセスが動いているということで、いま見ているサイトが本当に回線を通っているかではありません。確認できる結果は3つだけです。出口IPが回線の所在地に変わったか、DNS解決も回線側に切り替わったか、そして特定のアプリが実際にプロキシを通っているかです。
以下ではこの3つの方向に分けて解説し、それぞれ自分で実行できる手順を示します。最後に、回線を変えても、端末を変えても、ネットワーク環境を変えても使えるチェックリストを添えます。
方法1：まず出口IPが選択した地域になっているか確認する
出口IPとは、外部のサイトから見たアクセス元のアドレスです。回線に接続すると、回線の所在地のアドレスに変わるはずです。それでもローカルのアドレスのままなら、通信は回線をまったく通っていません。その状態で速度や安定性を論じても意味はありません。
- 接続を切った状態で、現在の出口IPと所在地を記録し、比較の基準にします。
- クライアントで目的の地域の回線を選んで接続し、接続成功の表示を待ちます。
- シークレットウィンドウで確認ページを開き直し、ブラウザのキャッシュが接続前の古い結果を返さないようにします。
- 出口IPと所在地が選択した回線と一致しているか比べます。地域をまたぐ回線では、所在地がノードの都市と多少ずれることがあります。
当サイトのネットワーク診断ページでは、追加のツールを入れずに出口IPと所在地を確認できます。
コマンドラインでの確認は一度きりの切り分けに向いている
ブラウザの外で確認すれば、コマンドラインの出力にはキャッシュの影響がなく、一度きりの確認に向いています。
# 現在の出口IPを確認
curl -s https://ifconfig.me
# 出口IPの所在地情報を確認
curl -s https://ipinfo.io/jsonWindowsではPowerShellで同じコマンドを実行できます。コマンドラインがローカルのアドレスを返すのに、ブラウザは回線の所在地になっている場合、コマンドラインがシステムプロキシを通っていません。TUNモードに切り替えるか、プロキシの環境変数を個別に設定する必要があります。この点は方法3でもう一度触れます。
よくある3つの誤判定
- 所在地データベースの遅れ：新しく割り当てられた、あるいは再編されたアドレス帯では、検索結果が近隣の地域を示すことがあります。1つのデータベースだけで結論は出せません。
- キャッシュの影響：ブラウザのキャッシュとシステムのDNSキャッシュのどちらも、接続前の結果を返すことがあります。シークレットウィンドウであれば大半の影響は排除できます。
- 複数の出口：同じ地域に複数の出口アドレスがあることがあり、更新するたびに結果が変わるのは正常です。何度も再接続する必要はありません。
方法2：DNSを確認し、解決がローカルに戻っていないか見る
DNSは「ドメイン名をどのアドレスに変換するか」を決めます。解決リクエストがローカルのプロバイダに送られたままだと、Webの通信が回線を通っていても、解決結果はローカルの位置に基づいて返されます。越境サイトはローカルに近いノードへ振り分けられ、地域制限はそのまま有効になり、問い合わせ内容もローカルのリゾルバに露出します。これがよく言われるDNSリークです。
リゾルバ一覧の見方
DNSリーク検出ツールは、実際に問い合わせを受け取ったリゾルバのアドレスと所属ネットワークを一覧で表示します。回線に接続した状態でもう一度測定し、次の基準で判断します。
| 検出されたリゾルバ | 意味 | 対処 |
|---|---|---|
| 回線の所在地のリゾルバだけが出る | 解決も回線側を通っており、想定どおり | 対処は不要 |
| ローカルのプロバイダのリゾルバが出る | 解決リクエストがプロキシを通っておらず、リークしている | クライアントでリモート解決を有効にし、DNSをプロキシ経由にする |
| ローカルとリモートのリゾルバが同時に出る | 一部のリクエストがOS側の暗号化DNSに横取りされている | OSのDoHを無効にし、クライアント側で一元管理する |
| 公開リゾルバのアドレスが出る | 問い合わせが回線経由で転送されているか確認が必要 | リゾルバ名だけで判断せず、出口IPと突き合わせる |
コマンドラインでも、本機が現在使っているリゾルバを確認できます。nslookup example.com の出力では、Server の行が実際に応答しているアドレスです。それがローカルのルーターやプロバイダのアドレスなら、解決は回線を通っていません。
OSレベルの暗号化DNS（DoH / DoT）は、クライアントで設定したDNSを迂回します。確認の前に、OSやブラウザでこうした機能を個別に有効にしていないか確かめてください。有効なままだと、測定結果はクライアントの設定と一致しません。
fake-ipとリモート解決の違い
一部のクライアントは既定でfake-ipモードを使います。ローカルで見える解決結果は仮のアドレスで、実際の解決はリモート側で行われます。この場合、ローカルのコマンドで引いたアドレスはリークを意味しません。判断材料はあくまでリーク検出ページに並ぶリゾルバであり、本機が返したIPではありません。リモート解決モードでは、解決リクエストは回線の出口から送られ、返るアドレスも回線の所在地に近くなります。
方法3：アプリごとに確認し、その場面が本当にプロキシを通っているか確かめる
最近のクライアントは分流（ルーティング）を備えているのが一般的で、ドメイン、地域、アプリごとに、どの通信を回線へ送り、どれを直接つなぐかを決めます。分流が有効なときの「接続済み」はプロキシのプロセスが動いていることしか示さず、いま使っているアプリが回線を通っているかは別の話です。
場面ごとに順番に確認する
| 場面 | 確認方法 | よくある漏れ |
|---|---|---|
| ブラウザで海外サイトを見る | シークレットウィンドウでネットワーク診断ページを開き、出口IPを見る | ブラウザに独自のプロキシ拡張機能が入っていて、システムプロキシを迂回している |
| デスクトップアプリ（同期ツール、開発ツール） | アプリ内でネットワーク状態やログを確認する | アプリ独自のプロキシ設定があり、既定では直接接続になっている |
| コマンドラインツール（git、curl、パッケージマネージャー） | 出口IPの問い合わせを一度実行する | システムプロキシを読まず、TUNか環境変数が必要 |
| モバイルアプリ | アプリ内でアカウントの地域やコンテンツ一覧を見る | アプリが独自の経路を使い、システムVPNを使っていない |
プラットフォームごとに通信の引き受け方が違う
- Windows：システムプロキシはシステム設定を読むプログラムにしか効きません。コマンドラインや他のアプリまでカバーするにはTUNを有効にします。
- macOS：システムのネットワーク拡張で通信を引き受けます。初回はシステム設定で拡張機能の読み込みを許可する必要があります。
- Android：システムのVPNサービスを利用し、有効にすると既定で全体を引き受けます。分流の細かい挙動はクライアント内部のルールで決まります。
- iOS：同じくシステムのネットワーク拡張で動作し、案内に沿って設定を完了して初めて通信を引き受けます。
- Linux：多くのクライアントはシステムプロキシを自動では変更しません。TUNを手動で設定するか、ターミナル用にプロキシの環境変数を個別に設定する必要があります。
コマンドラインで一時的にプロキシを設定する書き方は次のとおりです。ポート番号はクライアントに表示される実際の値に合わせてください。
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
curl -s https://ifconfig.me分流ルールが「通るかどうか」を決める
ルールモードはドメインのサフィックス、GeoIPの地域、プロセス名で照合し、直接接続に該当したドメインは回線を通りません。あるサイトを確認するときは、一時的にグローバルモードへ切り替えて再測定してみてください。グローバルでは正常でルールでは効かないなら、原因は回線ではなくルール側です。逆にグローバルでも通らない場合は、方法1と方法2に戻って切り分けます。
判定基準：3つの方法すべてを通過して初めて本当に効いていると判断できます。出口IPが変わった、リゾルバ一覧にローカルのプロバイダがいない、目的のアプリが実際にプロキシを通っている、の3点です。どれか1つだけでは、経路の一部が通ったことにしかなりません。
「接続済みに見えて実は通っていない」ケース
以下は切り分けで最もよく出てくる現象です。まず照らし合わせて、設定を直すのか回線を変えるのかを決めましょう。
| 現象 | よくある原因 | 対処 |
|---|---|---|
| ランプは緑なのに、ページが読み込み中のまま | ノードが使えない、またはサブスクリプションの期限切れ・通信量の上限 | 別の回線に切り替え、サブスクリプションの状態と残り通信量を確認する |
| ページは開けるが、アカウントの地域が変わらない | そのドメインが直接接続のルールに該当している、またはブラウザが拡張機能のプロキシを使っている | グローバルモードに切り替えて再測定し、ブラウザのプロキシ拡張機能を切る |
| 一部のアプリでしか効かない | アプリがシステムプロキシを読まない | TUNを有効にする、またはアプリ個別にプロキシを設定する |
| 解決結果がローカルのノードのまま | DNSリークで、解決が回線を通っていない | リモート解決を有効にし、OSの暗号化DNSを無効にする |
| 接続して数秒で切れる | システム時刻のずれが大きく、ハンドシェイクの検証に失敗している | システム時刻を合わせてから再接続する |
| 一部のサイトは直接接続、一部は回線経由になる | IPv4しかプロキシしておらず、IPv6の通信はローカルのまま | IPv6を無効にする、またはIPv6のプロキシを有効にする |
時刻のずれは最も見落とされやすい項目です。VMessなどのプロトコルはクライアントとサーバーの時刻差に敏感で、差が大きいとハンドシェイクがそのまま失敗し、「つながった直後に切れる」という症状になります。回線の問題に見えますが、実際にはシステム時刻を合わせるだけで解決します。
プロトコルと回線種別は判断に影響するが、方法は変わらない
確認の方法は変わりませんが、プロトコルや回線によって「つながらない」「つながっても不安定」の出方が異なります。違いを知っておくと遠回りを避けられます。
- Shadowsocks：SOCKS5ベースの軽量プロキシです。UDPはサーバー側で中継を別途有効にする必要があり、音声通話やゲーム系のアプリがUDPを使えないと「Webは正常なのに通話がつながらない」という形で現れます。
- VMess：時刻同期に敏感で、ハンドシェイクの失敗はシステム時刻やクライアントのバージョンが原因のことが大半です。
- VLESS：それ自体は暗号化を内蔵せず、外側のTLSに依存します。設定を誤ると、接続はできるのにデータが流れないという形で現れます。
- Trojan：TLSで通信を運ぶため、証明書とドメインの設定が一致しないとハンドシェイクの時点で失敗します。
- Hysteria2 / TUIC：QUICベースで、すべてUDPを使います。ネットワークがUDPを制限していると、遅いのではなくまったくつながりません。
回線の種類も判断に影響します。IEPL専用線は越境区間が専用線で、公共のインターネット出口を通らないため、夜のピーク時間帯でも安定しやすい傾向があります。中継回線は国内側の入口と越境区間で構成され、中継区間の品質に左右されます。直結回線は海外ノードに直接つなぐため、国際出口の混雑の影響を最も受けます。3つとも正常に接続できますが、差が出るのは主にピーク時間帯と長時間接続の場面です。
繰り返し使えるチェックリスト
ここまでの方法をチェックリストにまとめました。回線を変えたとき、端末を変えたとき、ネットワーク環境を変えたときに、この順で一通り確認してください。
- ✅ 接続の前後に出口IPを確認し、所在地の変化を記録する
- ✅ シークレットウィンドウで再測定し、ブラウザとDNSのキャッシュを排除する
- ✅ リゾルバ一覧を確認し、ローカルのプロバイダのアドレスがないか見る
- ✅ ランプだけでなく、目的のアプリを少なくとも1つ実際に試す
- ✅ コマンドラインでも一度確認し、必要ならTUNを有効にする
- ✅ うまくいかないときの症状を記録し、ルールかDNSかノードかの切り分けに使う
- ❌ 「トップページが開けた」を効果の証拠にする
- ❌ ルールモードのまま回線の良し悪しを判断する
3つの方法をすべて通過しても目的のアプリが快適でない場合、問題は設定ではなく回線そのものにあることがほとんどです。同じ地域の別回線に替えて再測定するか、専用線タイプの回線に切り替えてください。VPNVanは100+の国と地域、240+の回線を切り替えられ、アカウントの台数制限はなく、メールアドレスなしで登録できます。初回のお支払い後7日以内なら理由を問わず返金を申請できるため、こうした比較テストにかかる負担はごくわずかです。
最後にひとつ。サブスクリプションのURLはアカウントの資格情報に相当するので、クライアントに取り込んだ後も他人へ転送しないでください。URLが流出すると、他人がそのアカウントの通信量を消費し、確認結果の説明もつかなくなります。
確認の順番は、出口IP、DNS、アプリごとの確認、の順に固定するのがおすすめです。最初の2ステップで経路と解決を確かめ、3ステップ目で実際の通信がプロキシを通っているかを確かめます。順番を逆にすると、分流ルールのところで堂々巡りになりがちです。