VPNが接続済みかどうかは、クライアントのアイコンだけでは判断できません。グローバルIP、DNS、アプリ別の確認では、それぞれ「WebサイトにどのIPアドレスが見えているか」「どのDNSサーバーがドメインを解決しているか」「対象アプリの通信がプロキシを経由しているか」を調べます。設定したルーティングルールと照らし合わせて判断しましょう。Webページを一つ開いただけでは、十分な確認になりません。
「接続済み」でも通信経路は別
クライアントに「接続済み」と表示されるのは、システムの仮想ネットワークインターフェースが確立された、またはプロキシコアが起動したなど、接続処理の一段階が完了したことを示す場合があります。ただし、すべてのアプリの通信がリモートの経路を通っているとは限りません。表示の意味はクライアントによって異なるため、実際の通信を確認する必要があります。
システムプロキシは、通常、システム設定に従うアプリにプロキシの接続先を提供します。一部のアプリは設定を無視したり、独自のプロキシ設定を使ったりします。トンネルモードでは仮想ネットワークインターフェースを通じて、より広範な通信を処理するのが一般的ですが、対象外アプリ、ルーティングルール、IPv6対応、DNS設定の影響を受けることがあります。「グローバルプロキシ」も、プロキシコアに届いた通信を選択した経路へ送るだけの場合があり、すべてのアプリの通信を自動的に処理するとは限りません。
サブスクリプションURLは、ノードや関連設定を更新するためのものです。URLを正常にインポートまたは更新できても、クライアントが設定を取得できたと分かるだけで、現在のノードに接続できることやシステムの通信がVPN経由になっていることの証明にはなりません。Shadowsocks、VMess、Trojan、VLESSなどのプロトコル名だけでは、現在の通信経路を確認できません。
| 確認項目 | 主に確認できること | 単独では確認できないこと |
|---|---|---|
| クライアントの状態 | インターフェース、プロキシコア、または経路の接続状態 | すべてのアプリが選択した経路を使っていること |
| グローバルIP | 今回のWebリクエストをサイト側が認識したグローバルIPアドレス | ほかのアプリやDNSも同じ経路を使っていること |
| DNSの確認 | テスト用ドメインの問い合わせに応答した再帰DNSサーバー | 端末上のすべてのDNS問い合わせがVPN経由になっていること |
| アプリの接続ログ | 対象の通信に適用されたルール、出口、エラー | ログに記録されていないアプリが直通またはVPN経由になっていること |
まずグローバルIPを比較する
グローバルIPを確認する前に、テスト対象のサイトにどの経路を使う設定なのか確認しましょう。そのサイトが直通するルールなら、IPアドレスが変わらなくても想定どおりです。IPv4とIPv6を個別に表示できる確認サイトを選び、接続前後で同じサイトを使ってください。サイトによるデータベースの違いを、経路の変化と誤認しにくくなります。
- クライアントの接続を切り、ブラウザーで独立して動作するプロキシ拡張機能も無効にします。現在のグローバルIP、ネットワークの種類、確認した時刻を記録してください。ほかのプロキシを使っている場合は、それがまだ有効かどうかも確認します。
- 確認したい経路に接続し、プロキシまたはトンネルモードが有効で、確認サイトへの通信にその経路が適用されていることを確かめます。もう一度アクセスし、必要であれば古いタブを閉じてから開き直してください。
- 接続前後のアドレスを比較します。ページに表示される国名だけでなく、通信の出口が想定どおりかを確認しましょう。IPアドレスの位置情報データベースには、反映の遅れや誤差がある場合があります。
- 接続を切ってからもう一度確認し、アドレスが現在のローカルネットワークの出口に戻るかを見ます。動的IPや共有出口ではアドレスが変わるため、文字列が完全に一致する必要はありません。
IPv4は変わったのにIPv6がローカルネットワークの出口を示す場合は、クライアントがIPv6を処理しているか、確認時の通信でどちらのアドレスファミリーが使われたかを調べます。クライアントのドキュメントに従って対応状況とルーティング設定を見直し、再確認してください。IPv6を無効にする方法が、すべての端末に適した恒久対策とは限りません。
確認結果が示すのは、そのときのリクエストだけです。ブラウザーでVPN経由の出口を確認できても、ダウンロードツール、ゲーム、コマンドラインのプログラムが同じ出口を使うとは限りません。Webサイトが開けるのも、もともとローカルネットワークからアクセスできるためかもしれません。
DNSリークの確認方法
DNSはドメイン名をIPアドレスに変換しますが、Webサイトへの接続とDNS問い合わせが同じ経路を通るとは限りません。ブラウザーでセキュアDNSが有効だと、選択したDNSサービスにHTTPSで問い合わせることがあります。一方、システムやほかのアプリは別の設定を使う場合があります。そのため、ブラウザーのDNSテストは手掛かりにはなりますが、端末全体の状態を示すものではありません。
一般的なDNSチェックサイトはテスト用ドメインを生成し、どの再帰DNSサーバーから問い合わせが届いたかを確認します。結果に表示される運営者や地域は記録しておくとよいでしょう。ただし、DNSサーバーの所在地とVPNの出口が一致するとは限りません。パブリックDNS、転送経路、位置情報データベースの誤差によって、異なって見えることもあります。
より明確な異常と考えられるのは、対象のDNS問い合わせがすべてトンネルまたは指定したDNSサーバーを通る設定なのに、テストでローカルネットワークのDNSサーバーが継続して表示され、さらにクライアントのログから想定した経路を通っていないと分かる場合です。システムDNS、クライアントのDNS処理、セキュアDNS、ルール設定で直通になっているドメインを確認してください。
ブラウザーとシステムの設定を分けて再確認する
まずブラウザーのセキュアDNSの現在の設定を記録し、クライアントのドキュメントで推奨されている設定と比較します。一度に変更する項目は一つだけにしてください。システムの nslookup などのツールは、一部のDNS解決動作を調べるのに役立ちます。ただし、ブラウザーとは異なる方法で問い合わせる場合があり、表示されたサーバーアドレスだけで端末全体にリークがないとは判断できません。
DNSキャッシュにより、変更前の結果が引き続き使われることもあります。設定を変更したら、システムまたはクライアントのドキュメントに従って関連するキャッシュをクリアし、再度問い合わせてください。DNSの暗号化と通信経路の制御は別の問題です。暗号化DNSを使っていても、問い合わせが選択した国際経路を通るとは限りません。
アプリごとにルールの適用を確認する
先に期待する動作を明確にしてから結果を判断しましょう。たとえば、海外のWebサイトにはVPNを使い、ローカルネットワークには直通でアクセスしたいなら、それぞれを分けて確認します。すべての通信が同じ出口に見えることだけが、ルール設定の正解ではありません。種類ごとの通信が、あらかじめ決めたルーティングに従っているかが重要です。
- ✅ ブラウザー：プロキシ拡張機能、独自のプロキシ、セキュアDNSの設定を確認します。ブラウザーとシステム上のアプリで設定が異ならないようにしましょう。
- ✅ 対象アプリ：クライアントの接続ログで該当するプロセスやドメインを探し、VPN経由、直通、拒否のどのルールが適用されたかを確認します。
- ✅ バックグラウンド通信：対象アプリを再起動してから確認します。既存の接続は以前の経路を使い続ける場合があり、画面を更新するだけでは新しい接続が作られないことがあります。
- ✅ アプリ別のリスト：対象アプリが含まれていて、誤って除外リストに入っていないことを確認します。ランチャーと実際に動作するプログラムが別プロセスの場合もあります。
- ❌ ブラウザーで成功したからといって、すべてのアプリでも成功したとは限りません。接続ログに記録がないことを、そのままネットワークが正常だと解釈しないでください。
WindowsとmacOSでは、ブラウザーがシステムプロキシに従う一方、コマンドラインのプログラムには個別の設定やプロキシ環境変数が必要な場合があります。トンネルモードでは通信を処理する範囲も異なります。AndroidではVPNの許可、アプリ別のリスト、バックグラウンド制限が接続の維持に影響します。iOSでは、他のプラットフォームの設定名をそのまま当てはめず、実際に使うクライアントが対応するルールとシステムのVPN状態を確認してください。
Linuxでは、デスクトップ環境のプロキシ設定がバックグラウンドサービスにも適用されるとは限りません。対象プロセスが使う設定と、クライアントで想定したルートが作成されているかを確認してください。アプリがUDPを使う場合は、使用中のクライアントと経路の設定がその通信に対応しているかも確認しましょう。ブラウザーのWebリクエストだけでは代わりになりません。
接続済みに見えてもVPNを経由しないケース
ブラウザーだけがプロキシを経由している
ブラウザーの拡張機能は接続できているのに、ほかのアプリの通信が変わらない場合は、通信を処理する範囲が異なる可能性があります。使っているのが拡張機能のプロキシ、システムプロキシ、トンネルモードのどれかを確認してください。まず処理範囲の問題を解決し、原因が変わらないまま経路を何度も切り替える前に、対象を絞り込みましょう。
ノードには接続できるが、対象の通信は直通している
クライアントの遅延テストが成功しても、該当のテストに応答があったことしか分かりません。実際の通信が同じ出口を使うとは限りません。接続ログで対象のドメインを探し、適用されたルールを確認してください。ルールの順序にも注意が必要です。先に一致したルールが、後ろにあるより広範な設定より優先されることがあります。
Webサイト上の地域表示が変わらない
サイトに表示される地域は、現在のIPアドレスだけでなく、アカウント情報、過去のセッション、位置情報の許可、コンテンツの設定などに基づく場合があります。ネットワーク経路の判断には、出口の確認と通信ログを優先してください。トップページの言語やおすすめ内容だけで、接続の失敗を判断しないようにしましょう。反対に、ページの言語が変わっただけでも、プロキシが有効だとは証明できません。
ネットワークを切り替えても接続表示が変わらない
Wi-Fiからモバイルデータ通信に切り替えたときや、端末がスリープから復帰したときは、画面上の状態と実際の接続が一時的に同期しないことがあります。まずリクエストを再実行し、クライアントのログとシステムのVPN状態を確認してください。再接続する場合は、アイコンが再表示されたことだけで済ませず、再接続後に一通り確認しましょう。
切り分けの手順と判断できること
問題が起きたら、「通信を処理する範囲」「適用されたルール」「出口IPアドレス」「DNS」「対象アプリ」の順に確認範囲を絞ります。一度に変更する設定は一つだけにし、変更前後の結果を記録してください。ルールの問題を切り分けるために一時的にグローバルルールへ切り替える場合も、システムの通信が実際にプロキシコアへ届いているか先に確認します。テスト後は元のルール設定に戻してください。
VPNJazzはユーザー名とパスワードだけで利用を開始でき、メールアドレスは不要です。クライアントはユーザーパネルのダウンロードページから入手できます。サブスクリプションの追加方法や各プラットフォームの設定は使い方ガイドをご覧ください。サブスクリプションURLには通常、アクセス認証情報が含まれます。公開のチェックサイトに貼り付けたり、設定全体を知らない人に渡して確認を依頼したりしないでください。
サポートが必要な場合は、パネルのチケットから、端末のOS、クライアントのモード、問題が発生したときのネットワーク、対象アプリ、適用されたルールをお知らせください。スクリーンショットを送る前に、サブスクリプションURL、パスワード、不要な個人情報を隠してください。診断ログに含まれるドメインから、アクセス状況が分かる場合もあります。
判断の目安：対象の通信の出口が想定どおりで、DNSの動作が設定と一致し、VPNを使う必要があるアプリに適切な経路が適用されていれば、確認した範囲ではVPNが機能していると判断できます。この結果を、すべてのアプリ、ネットワーク、今後の接続まで確認済みという意味に広げないでください。
VPNJazzは匿名・ノーログをプライバシー方針として掲げていますが、これは端末側の通信経路の確認に代わるものではありません。アカウントのログイン状態、ブラウザーの権限、アクセス先サイトによるデータの取り扱いは、それぞれ別に管理してください。「接続済み」という表示だけに頼らず、接続前後を比較する手順を用意しておくと、現在の状態を継続的に確認しやすくなります。