クライアントの画面に「接続済み」と表示されていても、通信が本当に国際回線から出ているとは限りません。VPN が効いているかを確かめるには、次の3つを分けて見る必要があります。出口 IP がノードの所在地に変わっているか、DNS 問い合わせを誰が解決しているか、使っているアプリがルールでカバーされているか。以下ではこの3ステップの確認手順を、そのまま使える形で示し、最後に「つながっているのに通っていない」典型的な例を挙げます。

接続・引き込み・出口の切り替えは別々の話

この3つを1つの手順と捉えると、いざというときにどこから調べればよいか分からなくなります。実際には、それぞれ独立して起きることです。

  • トンネルの確立:クライアントとノードの間でハンドシェイクが完了した状態です。Shadowsocks、VMess、Trojan、VLESS は主に TCP や WebSocket などの伝送路上で動作し、Hysteria2、TUIC は QUIC ベースで、下位層は UDP です。ハンドシェイクの成功は、その経路がつながったことだけを示します。
  • 通信の引き込み:クライアントが端末の通信をトンネルに流します。TUN モードは IP 通信をすべて引き受け、システムプロキシ方式はプロキシ設定を読むアプリにしか影響しません。
  • 出口の切り替わり:アクセス先のサイトから見える送信元アドレスが、ローカル回線事業者が割り当てたアドレスではなく、ノードのアドレスになっている状態です。

この3つがずれると、「クライアントは正常なのに、ページを開くとローカルの結果のまま」という錯覚が起きやすくなります。多くの場合、クライアントが嘘をついているのではなく、引き込みの範囲や分割ルーティングのルールが、テストした対象まで届いていないだけです。

ステップ1:出口 IP を確認する

接続の前後で1回ずつ確認するのが、もっとも直接的な判断方法です。ブラウザで IP 確認ページを開けばアドレスと所在地が見えます。前後の比較にはコマンドラインのほうが向いています。出力が簡潔で、記録に残しやすいからです。

# 接続前:ベースラインを記録
curl -s https://api.ipify.org; echo

# 接続後:もう一度確認
curl -s https://api.ipify.org; echo

# 出口の地域もあわせて確認
curl -s https://www.cloudflare.com/cdn-cgi/trace | grep -E '^(ip|loc)='

正常な結果は、2回のアドレスが異なり、2回目の所在地が選択したノードと一致している状態です。2回とも同じなら、まず分割ルーティングのルールがその確認用ドメインを直接接続と判定していないか、次に現在の引き込み方式がシステムプロキシになっていないかを確認してください。

IPv6 と WebRTC という2つの抜け穴

多くのトンネルは既定で IPv4 しか引き受けません。ローカルネットワークにネイティブ IPv6 があると、IPv6 対応サイトへはローカルのアドレスのまま出ていき、IPv4 の確認結果だけを見ると問題ないように見えます。IPv6 の出口を単独で確認してください:curl -6 -s https://api64.ipify.org。ローカルのアドレスが返るなら、IPv6 は引き受けられていません。

ブラウザには独立した経路がもう1つあります。WebRTC はプロキシを通さずに端末のアドレスを取得できてしまいます。拡張機能を入れていないブラウザで1回比べる、あるいはブラウザ設定で WebRTC を制限する、という方法でここが原因かどうかを判断できます。

コマンドラインツールはシステムプロキシを読みません。curl は -x を明示するか、http_proxy / https_proxy 環境変数を設定しないとプロキシを通りません。そのためシステムプロキシ方式でターミナルから見えるアドレスがブラウザと違うのは想定どおりの動作です。TUN モードに切り替えれば、両者は一致するはずです。

ステップ2:DNS を誰が解決しているか確認する

DNS はドメイン名をアドレスに変換する役割を担います。通信はトンネルを通っているのに解決だけを回線事業者に任せると、2つの問題が起きます。アクセス先の意図がローカルのリゾルバに伝わってしまうこと、そして解決結果がローカルの位置に基づいて返るため、近い場所のノードが返ってきて「海外に切り替わった」という期待が外れることです。

確認方法は3つあります。

  • オンラインの DNS リークテストページでは、その解決に実際に使われたリゾルバが表示されます。ざっと見たいときに便利です。
  • Windows は nslookup example.com、macOS と Linux は dig example.com を実行し、返ってくる SERVER の欄がどのサーバーかを確認します。
  • macOS では scutil --dns でシステムのリゾルバの並び順を確認でき、既定でどれが使われるかを判断できます。

判断の基準は「ローカルの DNS が出たかどうか」ではなく、「気にしているドメインを誰が解決したか」です。分割ルーティングでは、地域内のドメインはローカルで解決し、海外ドメインはトンネル経由で解決するのが設計上の前提です。地域内のドメインまで無理にトンネルへ送ると、かえってそのサイトが遅くなります。

分割ルーティングでローカルのリゾルバが現れても、それ自体はリークではありません。本当に確認すべきは、海外サイトへアクセスするとき、その解決リクエストがトンネル経由で送られているかどうかです。

ステップ3:アプリ別で確認する

同じノードでも、アプリによって引き込まれ方は違います。「ブラウザで開けたから全部通っている」と判断するのが、切り分けで最も多い誤りです。

  • ブラウザは通常システムプロキシ設定を読むので、もっとも通りやすい種類です。
  • デスクトップアプリは、システムプロキシを読むものと、TUN モードでしか引き込めないものがあります。
  • コマンドラインや開発ツールの多くはシステムプロキシを読まないため、環境変数か TUN でないと引き込めません。
  • モバイルは OS の VPN 設定で引き込むため範囲は最も広くなりますが、バックグラウンドの省電力制御で接続が切られることがあります。

確認方法は単純です。同じ対象を選び、ブラウザとターミナルで1回ずつアクセスして出口アドレスを比べます。両方が一致していれば、引き込みの範囲がコマンドラインまで届いています。ブラウザだけ変わっていれば、現在はシステムプロキシ方式か、分割ルーティングのルールがターミナルからのアクセス先を直接接続と判定しています。

プラットフォームごとの違い

Windows の TUN モードは仮想ネットワークアダプターのインストールが必要で、初回接続時に権限の確認が出ます。macOS はネットワーク拡張の許可が必要で、インストール後にクライアントを再起動しないと反映されないことが多いです。Linux の TUN は root 権限、またはバイナリに CAP_NET_ADMIN 権限を付ける必要があり、それがなければシステムプロキシしか使えません。iOS と Android は OS の VPN フレームワークを使うため、初回接続時に構成の確認が入り、クライアントがバックグラウンドで終了されると接続が切れるので開き直す必要があります。サブスクリプションの読み込み方法も異なります。デスクトップクライアントはサブスクリプションリンクを貼り付けたあと、ノード一覧を手動で1回更新します。モバイルの多くはワンタップで読み込みが完了します。

3項目のチェック対照表

上の3ステップを1枚の表にまとめました。切り分けのときは行ごとに確認していけば足ります。

3項目チェックの判断基準
確認項目 確認方法 正常な結果 何が分かるか
出口 IP IP 確認ページ、curl での問い合わせ 接続後のアドレスが選択したノードと同じ地域 通信が実際にノードから出ている
DNS リゾルバ リークテストページ、nslookup または dig 海外ドメインの解決がトンネル内で行われている 解決を回線事業者に任せていない
アプリ別の引き込み ブラウザとターミナルで1回ずつアクセス 両方の出口アドレスが一致 引き込みの範囲がそのアプリまで届いている

よくある「偽接続」

以下はいずれも、クライアントの状態は「接続済み」なのに、通信が期待どおり国際回線を通っていないケースです。

  • ❌ 分割ルーティングのルールがテスト対象を直接接続と判定し、出口アドレスが最後まで変わらない。
  • ❌ システムプロキシは有効でも、テストしたアプリがプロキシ設定を読まず、ブラウザだけがトンネルを通っている。
  • ❌ IPv4 しか引き受けておらず、ローカルにネイティブ IPv6 があるため、IPv6 対応サイトへはローカルのまま出ていく。
  • ❌ 通信はトンネルに入っているが、DNS はローカルのリゾルバが処理し、解決結果がローカルの位置で返る。
  • ❌ Hysteria2、TUIC のような QUIC ベースのプロトコルは、ネットワークが UDP を制限しているとハンドシェイクの失敗や頻繁な再接続として現れ、「つながったのに、しばらくすると切れる」ように見えます。
  • ❌ サブスクリプションリンクの期限切れやノードの停止があっても、クライアントには古い回線名が残っていて、接続を押しても再試行を繰り返すだけ。
  • ✅ 出口アドレスがノードの所在地になり、海外ドメインの解決がトンネル内で行われ、ブラウザとターミナルの結果が一致する。3つすべてを満たして初めて、本当に通っていると言えます。

手順を固定する

回線やプロトコル、クライアントを変えるたびに、同じ順序で一通り確認するほうが、感覚に頼るよりはるかに確実です。

  1. 接続前に出口アドレスとリゾルバを1回記録し、ベースラインにします。
  2. ノードに接続し、選んだ地域とプロトコル名を控えます。
  3. もう一度出口アドレスを確認し、地域が選択したノードと一致するか比べます。
  4. 海外ドメインのリゾルバを確認し、解決がトンネル経由になっているかを見ます。
  5. ブラウザとターミナルで1回ずつ試し、両方の結果を比べます。
  6. 別の回線か別のプロトコルに変えて再テストし、問題が1本の回線に固有のものではないか確かめます。

結論:3項目すべてが通って初めて、VPN は本当に効いていると言えます。出口が変わり、解決がトンネル内で行われ、テストしたアプリがカバーされていること。1項目しか満たない場合は、まず分割ルーティングのルールと引き込み方式を確認し、そのうえで回線そのものを疑ってください。

検証のあとに、サービス側でも確認しておきたいこと

出口アドレスは選んだ回線によって変わります。回線を替えて再テストするコストが低いほど、切り分けは速くなります。VPNAJ は現在 120+ の国・地域、180+ の回線を用意し、量子暗号を採用、同時接続台数は無制限です。モバイル、ノート PC、デスクトップでそれぞれ上の3ステップを実行できます。登録に必要なのはユーザー名とパスワードだけで、メールアドレスは不要です。

120+ 対応国・地域
180+ 選択可能な回線
7日 理由不問の返金
無制限 同時接続台数

2〜3本の回線と2種類のプロトコルを試しても3項目が通らないなら、原因はノードよりもローカルの引き込み方式にある可能性が高いです。まず TUN モードに戻して再テストし、それでもだめならクライアントの再インストールやサブスクリプションリンクの再読み込みを検討してください。

ヒント:検証の価値は繰り返せることにあります。同じコマンド、同じ対照表なら、今日も別のマシンでも同じように使えます。切り分けをゼロから勘で始めずに済みます。