結論から言うと、VPNが効いているかどうかを確かめるのに専門ツールは不要です。順番に次の3つを確認するだけです。外部サイトから見える出口IPが変わったか、名前解決を誰が行っているか、目的のアプリの通信が実際にどの経路を通っているか。3つのうちどれか1つでも回線を通っていなければ、クライアントの画面に「接続済み」と表示され続けていても、効いているとは言えません。
クライアントの「接続済み」表示は端末側の状態にすぎない
接続ボタンを押すと、クライアントの画面はすぐに「接続済み」に変わります。この状態が示しているのは、端末上のプロセスが設定を読み込み、回線の対向側とセッションを確立したことだけです。通信が本当にその回線から出ているかどうかは別問題です。その間にはまだ2つの段階があります。OSが通信をトンネルに渡しているか、そして名前解決も同じ経路を通っているかです。
「効いている」状態を3つの層に分けて考えると、問題はぐっと整理しやすくなります。
- 端末側の状態：プロセスが動作していて、画面に接続済みと表示され、エラーも出ていない。
- トンネルへの取り込み：仮想NICまたはシステムプロキシの設定によって、対象の通信がトンネルへ送られ、ローカルのNICから直接出ていかない。
- 出口と名前解決：外部サイトから見える送信元アドレスが回線の出口になっており、名前解決もトンネル側で行われる。
3つの層のどれか1つでもつながっていなければ、「クライアントは接続済みなのに実際には回線を通っていない」という状態になります。どこまでを取り込むかはクライアントの動作モードで決まります。システムプロキシモードは、システムプロキシ設定を読み取るプログラムにしか効きません。多くのブラウザは該当しますが、コマンドラインツールや独自のネットワークスタックを持つアプリは該当しないことがあります。仮想NICモードは端末全体の通信を取り込み、あるいは振り分けルールに従って指定した通信を取り込むため、カバー範囲が広く、後述する3ステップの検証結果が一致する前提にもなります。
| 検証の層 | 確認する項目 | 合格ライン | よくある誤解 |
|---|---|---|---|
| 端末側の状態 | クライアントのプロセスと接続インジケーター | 接続済みと表示され、エラーがない | 「接続済み」を経路全体が正常だと誤解する |
| トンネルへの取り込み | ルーティングテーブルと仮想NIC | トンネルを指すデフォルトルートがある、またはルールが対象の通信に一致している | システムプロキシモードではブラウザだけがプロキシ経由になる |
| 出口IP | 外部から返ってくるアドレスとその所在地 | 選択した回線の地域と一致している | ブラウザしか確認せず、他のアプリを試していない |
| DNS解決 | 解決リクエストを誰が送っているか | リゾルバの所在地が出口の地域と一致している | 出口は変わったのに、解決はローカルの再帰リゾルバのまま |
| アプリ別 | 対象アプリの実際の出口 | 回線を通すべきアプリが実際に回線を通っている | 振り分けルールがドメインだけに一致し、プロセスやUDP通信が漏れている |
ステップ1：出口IPを確認し、通信がどこから出ているか突き止める
出口IPは最も直接的で、ごまかしが効きにくい項目です。外部サイトから見える送信元アドレスは、自分のローカルネットワークか回線の出口のどちらかであり、曖昧にはなりません。確認する前にまず接続を切り、ベースラインを1回記録してから、回線に接続してもう一度確認し、2回の結果を比べるだけで済みます。
ブラウザで確認用ページを開けば結果はすぐに見られますが、ブラウザにはプロキシ系の拡張機能が入っていることがあり、前回の応答がキャッシュされている可能性もあります。より確実に調べるなら、ブラウザの設定に影響されないコマンドラインで確認します。
# macOS / Linux
curl -4 https://api.ipify.org
curl -6 https://api64.ipify.org
# Windows PowerShell
Invoke-RestMethod -Uri "https://api.ipify.org?format=json"手順の全体は次のとおりです。
- 接続を切り、ローカルの出口IP・所在地・事業者（ASN）をベースラインとして記録します。
- 回線に接続して再確認し、アドレスと所在地の両方が変わったことを確かめます。
- IPv4とIPv6をそれぞれ確認します。片方だけ回線を通り、もう片方が直結になっていないか、両方とも回線の出口を指している必要があります。
- 別の確認用サイトでもう一度試し、1つのサイトだけの判定の偏りを排除します。
出口IPの所在地は、実際にどの回線を選んでいるかによって決まります。同じ国でも複数の回線があり、都市や事業者が異なれば、返ってくるASNも変わります。所在地が想定と違う場合は、まずクライアントで選択中のノードを確認し、それから検証方法に問題がないかを判断します。
ステップ2：DNSリークと解決の所在地を確認する
出口IPが変わっても、名前解決はローカルのままということがあります。解決リクエストがトンネルに入らず、ローカルネットワークの再帰リゾルバが処理してしまうケースです。その結果、外部サイトから見たアドレスは海外なのに、ドメインから位置を判定されるとローカルの答えが返り、コンテンツの地域が合わない、一部のサービスで追加認証を求められる、特定のサイトが開けないといった症状が出ます。
名前解決がどこを通っているか調べる方法
まず任意のDNSチェックページにアクセスし、返ってくるリゾルバのアドレスと所在地を確認します。次にコマンドラインでクロスチェックします。以下の2つのコマンドはいずれも、そのクエリを処理したリゾルバのアドレスを返すので、出口IPと比べてみてください。
# macOS / Linux
dig +short TXT whoami.ds.akahelp.net
# Windows
nslookup -type=TXT whoami.ds.akahelp.net名前解決がトンネルを通らない3つのよくある原因
- OSまたはブラウザで暗号化DNSが有効になっている：DoH / DoTを有効にすると、解決リクエストは指定したパブリックリゾルバへ直接送られ、トンネルから配布されたDNS設定を迂回します。
- トンネルがTCPの通信しか取り込んでいない：DNSクエリは既定でポート53のUDPを使います。ルールがTCP 80 / 443しか対象にしていなければ、解決はローカルから出ていきます。
- 振り分けルールが解決を直結と判定している：ルールがドメインやIPで照合するとき、解決リクエストが直結の分岐に一致してしまいます。
ブラウザの「セキュアDNS / 暗号化DNS」や、OSにインストールしたサードパーティのDNSツールは、解決結果をトンネルの実際の動作と食い違わせます。まずこれらをオフにしてから確認しないと、得られた結論に意味がありません。
対処法はプラットフォームによって少し異なります。デスクトップではクライアントで「DNSをトンネル経由にする」を有効にするか、トンネル内蔵のリゾルバを使い、それから再確認します。Androidでシステムの「プライベートDNS」を有効にしている場合、解決は指定した暗号化リゾルバが行うため、トンネルから配布されたリゾルバと結果が異なることがあります。確認する前に「自動」に設定してください。iOSでDNS設定を含む構成プロファイルをインストールしている場合は、クライアントの解決設定を上書きしていないか確認します。
ステップ3：アプリ別に検証し、通すべきものだけを通す
最初の2ステップが問題なくても、「ブラウザは正常なのに、特定のアプリだけ回線を通らない」ことはあります。原因は振り分けルールです。ルールはドメイン、IPレンジ、プロセス名でどの通信をトンネルに入れるか決めますが、ルールが正しく書かれていても対象アプリが一致するとは限りません。アプリ別の検証は、この部分だけを取り出して確かめるためのものです。
- 一時的にクライアントをグローバルモード（すべての通信が回線を通る）に切り替え、対象アプリを開いて正常に使えるか確認します。
- グローバルでは正常で、ルールモードでは異常なら、問題は回線そのものではなくルールにあります。
- ルールモードに戻り、対象ドメイン、必要なIPレンジ、プロセス名を順に追加していきます。
- 音声通話、オンライン対戦、ライブ配信系のアプリでは、ルールがUDPを対象にしているか確認します。そうでないと「Webページは開けるのに音声がつながらない」という状態になります。
- 確認が終わったら、モードは普段使う設定に戻します。グローバルのままにしないでください。
ここでつまずきやすいのがプロトコルとUDPです。Shadowsocks、VMess、Trojan、VLESSがUDPを転送できるかどうかは、サーバー側とクライアント側の実装によります。Hysteria2とTUICはQUICベースで、もともとUDP上で動作するため、UDP通信の転送に向いています。ルールがTCPしかプロキシしない場合、ブラウザのQUICベースのリクエスト（UDP 443）はTCPにフォールバックするか、そのまま直結になり、「接続はできているのに、特定のサイトだけ回線を通っていないような挙動」になります。
接続済みに見えて実は回線を通っていない：6つの典型的なケース
3ステップの検証で問題が起きやすい症状を一覧表にまとめました。異常が出たら行ごとに確認してください。
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| クライアントは接続済みと表示しているのに、出口IPが切断時とまったく同じ | システムプロキシモードでブラウザしか取り込めていない、またはルールが現在のアプリに一致していない | グローバルモードに切り替えて再確認し、取り込み範囲を確かめてからルールモードに戻す |
| Webページは開けるのに、音声通話・オンライン対戦・ライブ配信がつながらない | UDP通信がトンネルに入っていない。QUICも音声通話もUDPを使う | プロトコルとルールがUDPを対象にしているか確認し、必要ならブラウザのQUICを無効にしてから再確認する |
| 出口IPは変わったのに、一部のサイトでローカルのコンテンツが表示される | DNS解決がトンネルを通っていない | OSとブラウザの暗号化DNSをオフにし、トンネル内の解決に切り替えて再確認する |
| クライアントを再起動するとローカルの出口に戻ってしまう | ルーティングが他の仮想NIC、ファイアウォール、セキュリティソフトによって書き換えられている | 競合するソフトを終了し、再接続してからルーティングテーブルを再確認する |
| 特定の1つのアプリだけ回線を通らない | 振り分けルールがドメインやプロセスで照合され、そのアプリが漏れている | ルールに対応するドメインやプロセスを追加するか、一時的にグローバルモードで確認する |
| IPv6のサイトでローカルのアドレスが表示される | トンネルがIPv4しか取り込んでおらず、IPv6がローカルから直結で出ていく | IPv6を無効にするか、デュアルスタック対応の回線に切り替える |
6つのケースをすべて除外したら、このチェックリストで最終確認します。すべて合格して初めて、本当に効いていると言えます。
- ✅ 切断時と接続時で出口IPが異なり、所在地が選択した回線と一致している
- ✅ IPv4とIPv6の確認結果が同じ方向の出口を返す
- ✅ DNSリゾルバの所在地が出口の地域と一致している
- ✅ 対象アプリがグローバルモードで正常に使える
- ✅ ルールモードに戻しても、対象アプリが回線を通っている
- ❌ ブラウザだけを確認して結論を出す
- ❌ トンネルを有効にしているのに、IPv6のサイトでローカルのアドレスが表示される
各プラットフォームでの確認方法の違い
3ステップの確認順序はどのプラットフォームでも同じです。違いは、取得できるシステム情報の量にあります。デスクトップOSではルーティングと解決の状態を調べられますが、モバイルでは主に外部の確認用ページとクライアント内の接続診断に頼ることになります。
Windows
システムプロキシモードと仮想NICモードの違いは、Windowsで最もはっきり現れます。前者はシステムプロキシ設定を読み取るプログラムにしか影響しません。route printでデフォルトルートがトンネルのNICを指しているか確認でき、ipconfig /allで仮想NICの状態を確かめられます。ブラウザでQUICが有効になっている場合は、別途無効にしてからUDP関連のケースを確認してください。
macOS
scutil --dnsで現在有効なリゾルバの順序を確認し、networksetup -getwebproxy Wi-Fiでシステムプロキシが取り込まれているかを確かめます。さらにcurl -4とcurl -6を組み合わせれば、出口の確認は完了です。
iOSとAndroid
モバイルにはコマンドラインがないため、確認はブラウザの確認用ページとクライアント内の接続状態に頼ります。Androidで「プライベートDNS」を有効にしている場合は、先に「自動」に設定してから確認してください。iOSでDNS設定を含む構成プロファイルをインストールしている場合は、クライアントの解決設定を上書きしていないか確認します。
Linux
ip routeでデフォルトルート、resolvectl statusでリゾルバ、curlで出口を確認。この3つのコマンドで3ステップの検証をすべてカバーできます。
各プラットフォームのクライアントは画面が異なりますが、いずれもサブスクリプションリンクで回線をインポートします。ログイン後にパネルでサブスクリプションURLを取得してクライアントにインポートし、出口IP → DNS → アプリ別の順に確認します。サブスクリプションリンクはアカウントの認証情報と同じです。スクリーンショットを送ったり、公開の場に貼り付けたりしないでください。
確認完了後にやるべきこと
確認自体は数分で終わりますが、結果を残しておけば、次に問題が起きたときに大幅に時間を節約できます。
- ベースラインを記録する：切断時の出口IP、接続後の出口IPとリゾルバの所在地をそれぞれ1行ずつ記録します。異常時に対照すれば、どの層で問題が起きているかすぐに判断できます。
- 環境が変わったら再確認する：ネットワークの変更、OSの大型アップデート、新しいセキュリティソフトのインストール後は、3ステップの確認をもう一度行います。
- 地域が合わないときはまずノードを切り替える：回線ごとに出口の所在地は異なります。まずノードを切り替え、それからクライアント設定の問題かどうかを判断します。
- サブスクリプションリンクを厳重に管理する：アカウントの認証情報と同じなので、漏えいした場合はパネルで再発行してください。
本サービスは120+の国・地域、180+の回線を提供し、台数制限なし、30日間の理由不問返金に対応しています。回線の状態はサーバーページで確認できます。3ステップのどこかでどうしても先に進めない場合は、トラブルシューティングのドキュメントと照らし合わせて項目ごとに確認してください。