VPNの有効性を確認する3ステップ：出口IP・DNS・アプリ別の検証
つながっただけでは正しく通っていない：出口IPの確認、DNSの確認、アプリ別の検証という3ステップと、「つながっているのに通っていない」よくあるパターンを挙げます。
クライアントのステータスランプは点いているのに、Webページは元のまま——「VPNが本当に効いているか」という質問で最も多いのがこの形です。答えは接続状態をもう一度見ることではなく、3つの層を順に確かめることです。出口アドレスが本当に切り替わったか、名前解決がトンネルに沿っているか、いま使っているアプリがプロキシの対象に入っているか。3つすべて通って初めて「正しく通っている」と言えます。最初の1つだけで終わらせると、残り2層のずれを見落とします。
なぜ「接続済み」は有効の証拠にならないのか
ステータスランプが示すのは1つだけです。ローカルからノードまでのトンネルが確立した、ということ。トラフィックが引き受けられたか、引き受けたあとどのルールを通ったか、名前解決が一緒に通ったかは示しません。この3つはクライアントの引き受け方式、ルーティングルール、DNS設定でそれぞれ決まり、どれか1つがずれると「接続済みなのに実際は通っていない」という症状になります。
引き受け方式は主に3つ。システムプロキシはOSのプロキシ設定を読むアプリにだけ効き、ブラウザはたいてい読みますが、デスクトップアプリの多くは読みません。TUN仮想NICはネットワーク層でIPトラフィックを引き受けるので範囲が最も広くなります。アプリ別プロキシはリストに入れたアプリだけをトンネルに通し、リスト外はそのまま直接接続です。「効いているか」の確かめ方は、いまどれを使っているかで変わります。
プロトコルはまた別の層です。Shadowsocks、VMess、VLESS、Trojan はトラフィックをカプセル化してノードへ送り、Hysteria2、TUIC は QUIC ベースで UDP 上に載せるため、電波状況が悪い環境で安定しやすい。プロトコルが決めるのは「どう運ぶか」で、「どのトラフィックを運ぶか」ではありません。だからプロトコルを変えてもルーティングの誤判定は直らず、回線品質だけが変わります。
サブスクリプションリンクはノード一覧の入れ物にすぎません。クライアントは取り込んだリンクのノード一覧から設定を生成します。サブスクリプションが切れたりリンクが失効すると一覧は更新されませんが、ローカルに保存済みのノードはハンドシェイクに成功することがあります。この場合もステータスランプは点き、実際には転送できません。
ステップ1：出口IPと所在地を突き合わせる
まず基準を記録します。接続前に、ブラウザで任意のアドレス確認ページを開くか、ターミナルでコマンドを1つ実行し、現在の出口アドレスと所在地を控えておきます。
# 接続前：出口アドレスと所在地を記録
curl -s https://ipinfo.io/json
# 接続後：ip と country の両方が変わっているはず
curl -s https://ipinfo.io/jsonノードにつないだら、シークレットウィンドウを開いてもう一度確認します。シークレットウィンドウを使うのは、キャッシュとブラウザ拡張の影響を除くためです。プロキシ系の拡張が独自にリクエストを引き受けて、クライアントとは無関係な結果に見えることがあります。
判定基準は2つだけ。アドレスが変わったか。所在地が選んだノードの地域と一致するか。両方を満たして初めて、通信が海外の出口から出ていると言えます。
いくつかは切り分けが必要です。公開されているアドレス帰属データベースは互いに違いがあり、エニーキャストアドレスや国境をまたぐブロードキャストアドレスは近隣地域として表示されることがありますが、これは異常ではありません。動画配信サービスは独自の判定データベースを使っており、公開データベースには従わないため、「アドレスの帰属は正しいのに、サービス側は国内向けの表示のまま」という結果は起こり得ます。逆に、アドレスが変わらないからといって故障とは限りません。ルーティングモードでは国内サイトへのアクセスはもともとローカル出口を通るので、測るべきは海外サイトへのリクエストです。
ルーティングモードで国内サイトを開いてローカルのアドレスが表示されるのは仕様です。出口アドレスを測るときは、必ずプロキシを通ると分かっている海外サイトを使うか、一時的にグローバルモードに切り替えてもう一度測って比べます。
ステップ2：名前解決が国内に戻っていないか確認する
DNSリークとは、 通信はトンネルに入っているのに、名前解決のリクエストだけが入らず、国内の回線事業者に送られている状態です。影響は2つ。アクセス先の一覧が国内のリゾルバに渡ること、そして解決結果が国内の位置に基づいて返るため、「出口アドレスは海外なのに、受け取る内容は国内向け」ということが起きます。
確かめ方は難しくありません。DNSリーク検査ページを開くと、実際に応答したリゾルバとその帰属が一覧で出ます。正常なのは、応答サーバーが出口の地域にあるか、サービス側が配布するDNSである場合。異常なのは、応答サーバーが国内の回線事業者である場合です。検査時もシークレットウィンドウを使い、ブラウザにキャッシュされた解決結果で判断がぶれないようにします。
ルーティングモードには例外が1つあります。国内ドメインが国内DNSを使うのは仕様どおりで、リークではありません。見るべきは海外ドメイン側の応答サーバーです。
ブラウザ内蔵の安全なDNS（DoH）は、OSとクライアントのDNS設定を迂回して第三者リゾルバに直接問い合わせます。これが「IPは合っているのに内容が国内のまま」というよくある原因です。検査の前にブラウザ設定で「安全なDNSを使用」の状態を確認し、オフにしてからもう一度測って比べます。
IPv6は同じ種類の問題の裏側です。トンネルがIPv4しか引き受けていないと、IPv6対応サイトへはローカルのIPv6出口から出てしまい、検査ページはローカルのアドレスを返します。対処は2つ。OS側でIPv6を無効にするか、クライアントにIPv6トラフィックを引き受けさせるかです。
ステップ3：アプリ別とルーティングルールを一つずつ確認する
3層目が最も飛ばされがちです。クライアントのメイン画面に出てこないからです。アプリ別プロキシの考え方は「リストに入れたアプリだけをプロキシする」というもの。リスト外のアプリはトンネルが確立していても直接接続のままです。確認はクライアントのアプリ別リストを開き、使うアプリが入っているかを一つずつ確かめ、リストを変えたら対象アプリを再起動します。多くのプログラムは起動時に一度だけプロキシ設定を読むからです。
プラットフォームごとの違い
デスクトップではシステムプロキシとTUNの2モードが一般的です。TUNはすべてのプログラムをカバーし、システムプロキシはOS設定を読むプログラムだけをカバーします。Androidクライアントはアプリ別プロキシを備えるのが普通です。iOSはOSの制約で通常はトンネル全体として動作し、同等のアプリ別スイッチはありません。Linuxではコマンドラインとシステムプロキシが中心で、http_proxy、https_proxy の環境変数を手で設定するか、TUNモードに切り替える必要があります。同じサブスクリプションがプラットフォームによって挙動が違うのは、たいていこの層のせいです。
ルーティングルールが判断にどう影響するか
ルールは通常、ドメインのサフィックス、GeoIPの地域、プロセス名でマッチし、直接接続に当たったドメインはトンネルに入りません。確かめ方は単純です。クライアントを一時的にグローバルモードにして、同じサイトを開きます。グローバルでは正常、ルーティングに戻すと不正常なら、原因はノードではなくルールです。回線タイプ（IEPL専用線、中継、直接接続）が影響するのはリンクの安定性と経路であり、「どのトラフィックをプロキシするか」は変わりません。切り分けでこの2つを混ぜないでください。
| 層 | 確認方法 | 正常な状態 | 異常のサイン |
|---|---|---|---|
| 出口アドレス | 接続前後でアドレスと所在地を確認する | アドレスが変わり、所在地がノードの地域と一致 | アドレスが変わらない、または所在地がノードと合わない |
| 名前解決 | DNSリーク検査ページ | 応答サーバーが出口の地域、またはサービス配布のDNS | 応答サーバーが国内の回線事業者 |
| ルーティングルール | グローバルモードに切り替えて同じサイトを比較 | グローバルとルーティングで結果が同じ | グローバルモードだけ正常 |
| アプリ別 | クライアントのアプリ別リストを一つずつ確認 | 対象アプリがプロキシ対象に入っている | アプリがリストになく、実際は直接接続 |
| IPv6 | IPv6対応の検査ページ | IPv4の出口と一致する、または何も返さない | ローカルのIPv6アドレスが返る |
7つのよくあるケース：表示は正常なのにトンネルを通らない
以下はいずれもステータスランプは正常なのに、実際には期待どおりに通っていないケースです。症状から照合したほうが、何度も再接続するより効きます。
| 症状 | よくある原因 | 対処 |
|---|---|---|
| 接続済みなのに、ブラウザはローカルのアドレスを表示する | クライアントがシステムプロキシモードで、そのアプリがシステムプロキシを読まない。またはドメインが直接接続ルールに当たっている | TUNモードに切り替えるか、ドメインをプロキシルールに追加して再測定 |
| 出口アドレスは正しいのに、一部のサイトが国内向け表示のまま | ブラウザの安全なDNSがクライアントを迂回している | ブラウザの安全なDNSをオフにして再測定 |
| 特定のアプリだけトンネルを通らない | そのアプリがアプリ別リストに入っていない | チェックを入れてアプリを再起動してから試す |
| 検査ページがローカルのIPv6アドレスを返す | トンネルがIPv4しか引き受けていない | OSのIPv6を無効にするか、クライアントにIPv6を引き受けさせる |
| ノードを変えても開けず、しばらくすると正常になる | DNSキャッシュと接続の再利用 | シークレットウィンドウかキャッシュ削除後に再測定 |
| 海外サイトがすべて開けない | サブスクリプションの期限切れ、通信量の超過、ノードの障害 | サブスクリプションの状態を確認し、ノードや回線タイプを変えて再測定 |
| 接続時に証明書または時刻のエラーが出る | システム時刻のずれが大きく、ハンドシェイクの段階で失敗する | システム時刻を同期してから再接続 |
セルフチェックの完全リスト
ここまでの3層を、そのまま実行できるチェックリストにまとめます。ノード、端末、ネットワークを変えるたびに1回通せば、ふつう2〜3分です。
- ✅ 接続前に本機の出口アドレスと所在地を記録し、比較の基準にする。
- ✅ 接続後はシークレットウィンドウで出口アドレスを再確認し、キャッシュと拡張の影響を除く。
- ✅ DNSリーク検査で、応答サーバーが国内の回線事業者でないことを確かめる。
- ✅ いまがグローバルかルーティングかを把握し、目的のドメインがどのルールを通るか知っておく。
- ✅ アプリ別リストで使うアプリを一つずつ確認し、変更後はアプリを再起動する。
- ✅ ブラウザ内蔵の安全なDNSはオフにするか設定を揃え、クライアントの迂回を防ぐ。
- ✅ サブスクリプションの有効期限と残り通信量を確認し、ノード一覧が最新であることを確かめる。
- ✅ システム時刻を同期し、ハンドシェイクの段階で失敗しないようにする。
- ❌ クライアントのステータスランプだけを見て有効と判断する。
- ❌ 同じタブを何度も再読み込みして結果を判断する。
- ❌ 遅延や帯域の数値で出口の正しさを判断する。両者は別物。
3ステップを習慣にする
3ステップの順序は入れ替えられません。まず出口アドレスが変わったことを確かめ、次に名前解決がついてきているかを確かめ、最後に使っているアプリがプロキシの範囲に入っているかを確かめます。順序を入れ替えると誤判定になります。最初の1つだけ見て問題なしと判断すると、残り2層のずれが日常使いに持ち込まれ、「開けるときと開けないときがある」という形で現れます。
結論：出口アドレス、名前解決、アプリ別とルーティング。3層すべてを通過して初めて有効と言えます。どれか1層でも異常があれば、まずグローバルモードで比較テストを1回行えば、問題がルール、DNS、アプリ本体のどこにあるかを切り分けられます。ノードをあれこれ切り替える必要はありません。
本サービスは現在 90+ か国 / 160+ 回線を提供し、クライアントは Windows、macOS、iOS、Android、Linux に対応、台数制限なし、ログ記録なし、7日間の無条件返金です。登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。ノードを変えたら、上の3ステップでもう一度測るほうが、感覚で判断するより時間を節約できます。