VPNが正しく機能しているかを確認するには、まず出口IP、次にDNS、最後に使用するアプリを調べます。クライアントの接続表示が示すのは、接続処理の一部が確立したということだけです。ブラウザーやチャットアプリなど、各アプリの通信経路までは保証しません。対象の通信が選択した経路を通っているか確認しましょう。
接続状態・出口IP・アプリの動作を分けて確認
サブスクリプションURLから経路設定を取得し、クライアントが設定を読み込んで接続します。どのリクエストを経路に通すかは、ルールによって決まります。これらは関係していますが、同じものではありません。設定をインポートできても経路が利用可能とは限らず、経路が利用可能でもすべてのアプリが使っているとは限りません。
システムプロキシは通常、システムのプロキシ設定に従うアプリの通信をローカルのプロキシ経由にします。TUNモードは仮想ネットワークインターフェースを使って通信を取り込み、より広い範囲をカバーすることがありますが、ルーティング、除外アプリ、クライアントの実装にも左右されます。モード名に「グローバル」とあっても、端末上の通信すべてが必ず取り込まれるわけではありません。実際の動作を確認してください。
| 確認項目 | 確認できること | それだけでは確認できないこと |
|---|---|---|
| クライアントの状態 | クライアントに接続済みと表示される、またはプロキシサービスが起動している | 対象アプリのリクエストがリモート側の出口を経由していること |
| 出口IP | 確認ページに表示されるリクエスト元のIPアドレス | 他のアプリやドメインも同じ経路を使っていること |
| DNSテスト | テストで使用されたリゾルバーと、そのネットワーク情報 | 端末上のすべてのDNSリクエストが同じ設定に従っていること |
| 対象アプリの確認 | 実際のリクエストに適用されたルール、接続状況、利用結果 | 今後どのネットワーク環境でも同じ動作が続くこと |
出口IPを確認する：未接続時の値を記録して比較
出口IPとは、Webサイトがリクエストを受信した際に確認できる送信元アドレスです。LAN内で端末に割り当てられたアドレスとは異なります。まずはVPNBXのIPアドレス確認ページを開き、接続前後の結果を比べましょう。国名だけでなく、IPアドレスとネットワーク事業者の情報も、通信経路が変わったか判断する手がかりになります。
- 未接続時の結果を記録します。現在のネットワークでクライアントの接続を一時停止し、確認ページを開いて出口IPとネットワークの所属情報を控えます。ほかのプロキシや企業用トンネルが端末で動作している場合は、結果への影響も確認してください。
- 確認する経路に接続します。テスト対象の経路が選択されていることを確認し、クライアントのモードも記録します。サブスクリプション設定を更新した直後は、選択中の項目が変わっていないか確認しましょう。
- もう一度確認します。ページを再読み込みし、必要であればタブを閉じてから開き直します。確認ツールに再テストのボタンがある場合は、新しいリクエストが送信されるよう操作してください。古いページの結果を最新のものと取り違えないためです。
- リクエストの経路を確認します。クライアントに接続一覧がある場合は、確認ページのドメインに適用されたルールと出口を調べます。結果が変わらないときは、経路の障害と決めつける前に、そのドメインが直接接続に設定されていないか確認しましょう。
- 別の経路でも確認します。別の出口に切り替えて、もう一度確認します。複数の経路で出口IPを共有している場合、アドレスが同じこともあります。クライアントの記録や経路の説明もあわせて判断してください。
ルールによる振り分けを使っていると、確認ページは直接接続され、海外サイトはプロキシ経由になる場合があります。この場合、出口IPが変わらなくても、VPNがまったく機能していないとは限りません。原因を調べる際は、一時的にプロキシ経由が明確なルールに切り替え、同じページで比較します。テスト後は元の振り分け設定に戻してください。
IPアドレスの位置情報データベースは、更新が遅れていることがあります。表示都市と経路名が異なっても、経路の表示が誤っているとは限りません。反対に、地域名が想定どおりでも、すべてのアプリが経路を通っている証明にはなりません。
DNSを確認する：地域だけでなく名前解決の経路を見る
DNSはドメイン名をIPアドレスに変換します。Webページへの接続はプロキシ経由でも、ドメイン名の名前解決はローカルネットワークで行われることがあります。DNSリークに当たるかどうかは、期待する動作によって異なります。関連する名前解決も指定経路に通したい場合は、ローカルでの名前解決を調べる必要があります。一方、ルール上ローカルのドメインを直接接続する設定なら、ローカルでの名前解決だけで異常とはいえません。
DNSテストページは通常、専用のテスト用ドメインを使って再帰リゾルバーを確認し、そのIPアドレスやネットワーク情報を表示します。端末上のすべてのDNSリクエストを記録するものではなく、クライアントで設定した上流DNSの名称がそのまま表示されるとも限りません。パブリックDNSサービスは分散ネットワークを利用することがあるため、リゾルバーの地域と出口の地域が異なるだけで、DNSリークと判断することはできません。
DNSを正しく比較する方法
- 未接続時と接続時の両方でテストを最後まで実行し、地域名だけでなく、リゾルバーのIPアドレスと所属情報を保存します。
- クライアントのDNS設定を確認し、リモートでの名前解決、DNSの取り込み、ルールに応じた上流DNSの選択が有効か調べます。項目名はクライアントによって異なる場合があります。
- ブラウザーのセキュアDNS設定を確認します。ブラウザーがシステムのリゾルバーを使わず、独自に暗号化DNSを利用することがあります。関連する通信がプロキシ経由か直接接続かは、実際のルーティングによって決まります。
- 設定を変更したら、テストをもう一度実行します。システムやブラウザーのキャッシュ、確立済みの接続が結果に影響することがあるため、必要に応じて対象アプリを再起動して確認してください。
暗号化DNSが保護するのは名前解決時の通信です。それだけでリクエストがVPN経由になるわけではありません。反対に、テスト結果にパブリックDNSリゾルバーが表示されても、通信が必ずVPNを通っていないとは限りません。クライアントで確認したリクエストのルール、上流DNSの設定、テスト結果が一致しているかを確かめるのが確実です。
Windows、macOS、Linuxでは、次のコマンドでシステムの名前解決状況を確認できます。システム環境を把握する手がかりにはなりますが、DNSリークを完全に検査するものではなく、ブラウザー内での確認の代わりにもなりません。
nslookup example.comこのコマンドとブラウザーでは、名前解決の経路が異なる場合があります。一部のTUNクライアントは内部マッピング用のアドレスを返すこともあり、必ずしもエラーではありません。見慣れないアドレスが表示されても、すぐにDNSを手動で変更せず、まずクライアントの名前解決モードに関する説明を確認しましょう。
アプリごとに確認する：ブラウザーで動いてもすべてのアプリで使えるとは限らない
出口IPとDNSを確認したら、実際に使うアプリで検証します。まず対象の機能を開き、クライアントの接続一覧で該当するプロセスやドメインを探します。直接接続、プロキシ、拒否のどのルールが適用されたか、接続が確立したかを確認してください。アプリのトップページを開くだけでは不十分です。ログイン、動画再生、ファイルのダウンロードで異なるドメインが使われることがあります。
デスクトップのブラウザーは通常システムプロキシを利用できますが、独立したプロキシ拡張機能、個別設定のブラウザープロファイル、セキュアDNSによって経路が変わることがあります。コマンドラインツールやゲームなどのアプリは、システムプロキシを参照しない場合があります。ブラウザーは正常でも別のアプリで失敗する場合は、まず通信を取り込む範囲を確認し、必要に応じてクライアントのドキュメントに従ってアプリプロキシやTUNを設定してください。
モバイル端末のステータスにVPNの表示があっても、示されるのはシステム上のネットワーク設定が有効になっていることだけです。Androidクライアントでは、アプリごとに通信を含める、または除外する設定がある場合があります。iOSクライアントでもルールによる振り分けが利用されることがあります。対象範囲はクライアントの機能と設定によって異なるため、ステータスバーのアイコンだけで判断しないでください。
- ✅ 対象アプリで実際の操作を行い、該当する接続を確認します。ブラウザーの確認ページだけで判断しないでください。
- ✅ 適用されたルールと選択中の出口を確認し、リクエストが直接接続または除外されていないか調べます。
- ✅ 独立したプロキシ、システムプロキシ、クライアントのモードを確認し、複数の設定が同じリクエストを同時に取り込んでいないか調べます。
- ✅ 経路を切り替えたら対象アプリを再起動し、既存の長時間接続を終了させてから、同じ操作をもう一度行います。
- ❌ Webページが開けることを、すべての通信が経路を通っている証拠にしないでください。また、再生に失敗しただけでVPNが機能していないと決めつけないでください。
動画配信やAIツールでは、アカウントの地域、出口の評価、サービスの提供地域が確認されることもあります。そのため、アクセスできないことと通信経路の誤りは別の問題です。まず通信経路を確認してから、アプリのエラーメッセージを調べましょう。詳しくはVPNBXの動画配信ガイドとAIツールの経路ガイドをご覧ください。設定を何度も切り替えて、原因を見えにくくしないようにしましょう。
「接続済みなのに経路を通らない」主な原因
クライアントは起動しているが、システムプロキシが有効になっていない
プロキシクライアントによっては、ローカルの待ち受けサービスだけを起動し、システムプロキシを変更しないことがあります。画面上では動作中でも、ブラウザーは従来のネットワーク経由でアクセスしている場合があります。システムプロキシの設定や通信の取り込みモードを確認してください。TUNを使う場合は、必要な権限と仮想インターフェースが正常に動作しているかも確認します。サブスクリプション設定の更新に成功したことが示すのは設定の取得であり、リクエストが取り込まれたことではありません。
ルールと実際のリクエストが一致していない
対象ドメインに直接接続のルールが先に適用されている場合や、ルール更新後に所属グループが変わっている場合があります。ドメインがどのカテゴリに属するはずか推測するより、実際に適用されたルールを確認しましょう。一時的にルールを変更するときは、元の設定を保存し、一度に変更する項目を一つにすると、原因がルールか経路かを特定しやすくなります。
一部のネットワーク経路が対象になっていない
端末はIPv4とIPv6の両方で接続できる場合があります。クライアントが片方の経路しか処理しないと、アプリがもう一方を選んだときに出口が異なることがあります。クライアントのデュアルスタック通信への対応と設定を確認してください。IPv6を無効にすればすべて解決するとは限りません。UDPやQUICなどの通信にも対応が必要です。Webページは正常でもリアルタイム通信に失敗する場合は、関連する転送機能を確認しましょう。
設定、プロトコル、既存の接続による誤判定
サブスクリプションURLは設定を取得するための入口であり、クライアントそのものではありません。インポート後に経路を選び、クライアントが設定内のプロトコルや通信方式に対応していることを確認します。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、自由に置き換えられる名称ではありません。対応していない場合、名前が似た別の項目を選んでも互換性の問題は解決しません。
経路の種類だけでは、アプリの通信が取り込まれるかどうかは決まりません。IEPL専線は特定のネットワーク伝送方式を指し、中継と直接接続は異なる接続経路を指します。これらは端末側のプロキシ、DNS、振り分け設定の代わりにはなりません。経路を切り替えた後も古いセッションが残ることがあるため、対象アプリから新たにリクエストを行って確認してください。
最終確認と問い合わせ時に用意する情報
VPNが機能しているかは、対象範囲を限定して判断します。対象のリクエストに想定したプロキシルールが適用され、確認ページに表示される出口が経路と一致し、DNSの名前解決が想定した方針に従い、実際のアプリ操作が完了することを確認してください。単一の接続表示、地域名、確認結果だけでは、端末の全通信を保証できません。
それでも確認できない場合は、端末のOS、クライアント名、現在のモード、経路名、操作した時刻、エラー内容をまとめます。接続前後の出口IPの変化、DNSテストの結果、対象リクエストに適用されたルールも添えてください。「接続できない」という問題を、通信の取り込み、名前解決、経路、アプリ側の制限に分けて調べやすくなります。
スクリーンショットや診断情報を共有する前に、サブスクリプションURL、アクセストークン、アカウントの認証情報を隠してください。サブスクリプションURLに有効なアクセス情報が含まれる場合があるため、公開コメント欄に貼り付けないでください。診断ログに個人用のアクセス先ドメインが含まれていないかも確認しましょう。
VPNBXの設定は初心者向けガイドから確認できます。まずクライアントとサブスクリプション設定を確認し、この記事の手順に沿ってリクエストを検証してください。関連する設定を一度に一つだけ変更し、変更前後の結果を記録すると、経路、DNS、モードを同時に切り替えるより原因を特定しやすくなります。