VPNが機能しているかを確認するには、接続前後のグローバルIPを比べ、DNSの経路を調べ、最後に実際に使うアプリで通信を確認します。クライアントに「接続済み」と表示されても、それは接続やローカルプロキシが確立したことを示すだけの場合があります。ブラウザーや業務アプリなど、すべての通信が想定した経路を通っているとは限りません。
確認したいのは「すべての通信が変わること」ではなく、プロキシを使う通信は実際にプロキシ経由になり、直接接続する通信はルールどおりに直結することです。そのため、検査を始める前に、クライアントがシステムプロキシ、ルールによる振り分け、仮想ネットワークアダプターによる通信制御のどれを使っているか確認しましょう。以下では、検証し直せる手順に沿って進めます。検査画面のスクリーンショットだけで判断することはありません。
制御範囲を確認する：接続状態だけでは通信経路はわからない
システムプロキシは通常、システム設定に従うソフトにプロキシの接続先を提供するもので、すべての通信を制御するわけではありません。独自のネットワーク機能を使うアプリは、システムプロキシを無視することがあります。ブラウザー拡張機能の対象はさらに限られ、多くの場合そのブラウザーだけに適用されます。デスクトップアプリの出口も変わったとは限りません。
仮想ネットワークアダプターモードではルーティングによって、より多くの通信を制御します。TUNやVPNモードと呼ばれることがありますが、除外リスト、プロセスごとのルール、対応プロトコルの範囲によって対象外になる通信もあります。モバイル端末では、ステータスバーにVPNの表示があっても、アプリごとの除外やオンデマンド接続が設定されている場合があります。実際のクライアント設定を確認してください。
- ✅ 現在の接続先、プロキシモード、ルールセット、仮想ネットワークアダプターの有効・無効を記録し、テスト中に条件を変えないようにします。
- ✅ ほかのプロキシ拡張機能や同種のクライアントを一時停止し、多重プロキシやルーティングの競合を減らします。
- ✅ バックグラウンドでのダウンロードや同期を停止し、速度を調べる前に通信経路を確認します。
- ✅ 確認するブラウザー、業務アプリなどをリストアップし、ブラウザーの結果を端末全体に当てはめないようにします。
サブスクリプションURLはクライアントに設定を渡すためのもので、Webプロキシのアドレスではありません。インポート後は、サブスクリプションが正常に更新されていること、接続先が選択されていること、該当する通信制御が有効であることも確認してください。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコル名だけでは、現在使っているアプリがプロキシ経由かどうかはわかりません。クライアントのルーティングと通信制御の設定も重要です。
グローバルIPを確認する：接続前後を比較する
まず接続を切り、同じブラウザーでIPアドレス確認ページを開きます。表示されたグローバルIPアドレス、通信事業者、アドレスの割り当て先ネットワークを記録してください。次に接続先を選んで接続し、ページを再読み込みして結果を比べます。テスト中にネットワークも切り替えると、変化がプロキシによるものかローカルネットワークによるものか判断できません。
グローバルIPが変わった場合、その検査リクエストの経路が変わったことはわかりますが、端末上のすべての通信が制御された証拠にはなりません。一方、ルールモードでは検査用ドメインが直結に振り分けられることがあります。IPが変わらなくても、接続先全体の不具合とは限りません。その場合は、該当ドメインに適用されたルールと実際の出口を確認しましょう。
IPアドレスからわかる国や地域も、正確な位置情報ではありません。データベースの更新には遅れがあり、接続先の名称、データセンターの所在地、IPアドレスの登録地域が一致しないこともあります。まず実際のIPアドレスとクライアントの接続ログを確認し、地域表示は参考情報として扱いましょう。地図上の位置だけで成否を判断しないでください。
IPv4とIPv6の両方を確認します。検査ツールが個別に対応している場合は、どちらのリクエストも想定した経路になっているか確認してください。一方のアドレスだけが変わっても、もう一方が直結している可能性があります。IPv6を無効にすればよいと決めつけず、まずクライアントの対応状況とルーティング設定を確認しましょう。
ブラウザーに残った古いページや、アプリの既存の接続も比較を妨げることがあります。接続先を切り替えたら、新しいリクエストを送信し、必要に応じて対象アプリを再起動してください。シークレットウィンドウでキャッシュや拡張機能の影響を減らせる場合はありますが、システムのルーティングが自動で変わるわけではなく、DNSの確認にも代わりません。
DNSリークを確認する：名前解決と通信の出口を区別する
DNSはドメイン名をネットワーク上のアドレスに変換します。名前解決のリクエストとWebサイトへの接続は、別々の経路を通る場合があります。DNSリークとは、プロキシやトンネルの設定で保護されるはずの名前解決リクエストが、想定外のローカルネットワーク経由で送信される状態を指します。見慣れないDNSサービス名が表示されたからといって、すぐにリークと判断することはできません。
新しいテスト用ドメインを発行するDNS検査ツールを使い、切断時と接続時の両方で検査して、リゾルバーのネットワーク上の所属を記録します。DNSも制御するモードを有効にしているのに、接続後もローカルネットワークのリゾルバーが継続して表示される場合は、さらに確認が必要です。ただし、検査結果によっては端末が直接接続したサーバーではなく、再帰リゾルバーの上流側の出口を表示します。所属情報は設定と合わせて解釈してください。
ブラウザーのセキュアDNSで検査結果が変わる理由
ブラウザーのセキュアDNSは、暗号化された名前解決サービスを使い、システム側のリゾルバー選択を経由しないことがあります。その通信がプロキシを通るかどうかは、ブラウザーのリクエストがどのようにルーティングされるかによって決まります。「暗号化DNSを使っていること」と「DNSリクエストがプロキシ経由であること」は別の問題であり、互いの代わりにはなりません。
まずブラウザーのセキュアDNS設定を記録し、クライアントのDNSモードや接続ログと照らし合わせます。要因を切り分ける場合は、一時的に設定を変更して比較し、テスト後に必要な設定へ戻してください。変更を記録せずにシステム、ブラウザー、クライアントのDNS設定を何度も変えると、どの変更が効果をもたらしたのか判断しにくくなります。
キャッシュや仮想アドレスが原因とは限らない
システムやアプリは名前解決の結果をキャッシュするため、接続先を切り替えた直後に新しいDNSリクエストが発生しなくても異常とは限りません。クライアントによってはFake-IP方式を使い、内部用の仮想アドレスを返してから、クライアント側で対象ドメインに対応付けます。このアドレスはWebサイトの実際のグローバルIPではなく、表示されたことだけでリークと判断することもできません。
アプリごとに検証する：実際に適用されたルールを確認
ブラウザーでの確認後、実際に使うアプリを開き、リモート文書の更新、リソースの再読み込み、同期の開始など、明確な新規リクエストを発生させます。同時にクライアントの接続パネルで該当するプロセスやドメインを探し、適用されたルール、出口、接続エラーの有無を確認してください。
アプリのリクエストに想定した出口が適用されたことは、ログからわかる重要な情報です。ただし、アプリからの応答も合わせて確認しましょう。ログイン、コンテンツ表示、リソースのダウンロードなど、アプリは複数のドメインに接続し、それぞれ別の経路を使う場合があります。トップページが開くだけでは、ログインやファイル転送まで正常とは限りません。
| 通信制御方式 | 優先して確認する項目 | よくある誤判定 |
|---|---|---|
| ブラウザーのプロキシ拡張機能 | 拡張機能の適用範囲、除外ドメイン、ブラウザーの出口 | ブラウザーの結果をデスクトップアプリにも当てはめる |
| システムプロキシ | アプリがシステム設定に従うか、独自のプロキシ設定があるか | システムプロキシを有効にすれば、すべてのアプリが対象になると思い込む |
| 仮想ネットワークアダプターモード | ルーティング、DNSの制御、除外リスト、プロトコル対応状況 | 除外されたプロセスや、もう一方のアドレス種別の通信を見落とす |
| アプリ別またはルールによる振り分け | 対象プロセス、ドメインルール、実際の出口 | 想定どおりの直結リクエストを接続先の不具合と誤認する |
WindowsとmacOSでは、システムプロキシと仮想ネットワークアダプターの設定を区別してください。Linuxでは、デスクトップのプロキシ設定とターミナルアプリのプロキシ環境変数が一致するとは限りません。iOSとAndroidでは、アプリの除外やオンデマンド接続に対応しているかを確認します。利用できる機能はOSやクライアントによって異なるため、ほかのプラットフォーム向けの手順をそのまま適用しないでください。
UDPを使うアプリでは、クライアント、選択中の設定、接続先が該当する転送に対応していることも確認してください。Webページは正常でも音声通話やゲームで問題が起きる場合、プロトコルやルーティングの対応範囲が異なる可能性があり、接続全体が機能していないとは限りません。
接続済みなのに経路が変わらない場合の確認手順
- 設定が有効か確認。サブスクリプションが正常に更新され、想定した設定が選択されていることを確認します。有効になっていないルールセットを変更していないかも確認してください。
- 通信制御の設定を確認。「接続先への接続」と「システムプロキシの設定」を区別し、仮想ネットワークアダプターに必要な権限が許可されているか確認します。
- 適用されたルールを確認。検査用ドメインや対象アプリが直結に設定されていないか、優先度の高い除外ルールがないかを確認します。
- ほかのネットワークツールを切り分ける。ブラウザー拡張機能、ほかのプロキシクライアント、ルーティングを書き換える可能性のあるソフトを一時停止し、再度比較します。
- アプリの接続を作り直す。既存の接続を終了してアプリを開き直します。必要に応じて、DNSキャッシュやセキュアDNSの設定も確認してください。
- 情報を整理して問い合わせる。OS、クライアント、モード、エラーの内容、個人情報などを伏せたログを用意します。サブスクリプションURL全体は送らないでください。
診断のため、一時的にクライアントのグローバルルールへ切り替え、対象の通信の出口が変わるか確認できます。ここでいう「グローバル」は通常、適用するルールの選択を示すもので、通信制御の範囲が必ず広がるわけではありません。システムプロキシを使わないアプリには影響しない場合があります。比較後は、実際の用途に合うルールへ戻してください。
サブスクリプションURLにはアクセス情報が含まれる場合があり、ログからはアクセス先のドメインやアドレスがわかることがあります。資料をサポートに送る前に、必要な箇所だけを残して個人情報などを伏せてください。提供元のわからないオンライン検査ページに設定全体をアップロードしないでください。
検証結果の見方：経路が正しくても、すべてのサービスが使えるとは限らない
グローバルIPの変化、設定どおりのDNS経路、対象アプリに適用された想定の接続先を合わせて確認することで、接続が機能しているかをより正確に判断できます。Webサイトにアクセスできるかどうかは、アカウントの地域、権限、サービスの稼働状況、Cookie、出口IPに対する制限にも左右されます。接続が機能していることと、サービスを利用できることは別の問題です。
同様に、速度測定の結果だけでは接続の有効性は判断できません。回線の種類は通信経路を表すもので、端末での検証に代わるものではありません。IEPL専線、中継、直結といった名称だけでは、端末のDNSや通信の振り分けが正しく設定されている証拠にはなりません。まず経路を確認し、その後で速度、安定性、アプリとの互換性を個別に調べましょう。
判断の基準：接続前後の比較で検査リクエストの変化を確認し、DNS検査で名前解決が想定どおりかを調べます。さらに、アプリのリクエストとクライアントのログで通信の振り分けを確認してください。結論は検証できたアプリとリクエストに限り、「接続済み」を端末全体の通信が通る証明として扱わないようにしましょう。
VPNCBはWindows、macOS、iOS、Android、Linuxに対応しています。クライアントとサブスクリプションは、ログイン後にパネルから取得できます。設定のインポートから接続までの手順はクイックスタートをご覧ください。アカウント作成にメールアドレスは不要で、ユーザー名とパスワードを使用します。接続の状態は、この記事の方法でご利用のネットワーク環境にて確認してください。