VPNが本当に機能しているか確認するには、接続前後のグローバルIPを比較し、DNSの名前解決経路を調べ、最後に実際に使うアプリで確認します。クライアントの「接続済み」表示が示すのは接続の一部が確立したことだけで、ブラウザーやゲーム、業務ソフトの通信がすべて想定した経路を通っている証明にはなりません。

この記事でいう「機能している」とは、設定どおりの出口を経由して通信していることです。すべての通信が同じ経路を通る必要はありません。ルールベースの振り分けでは、一部のサイトが直接接続されるのは正常な場合があります。確認の前に目的を明確にしましょう。そうしないと、正常な振り分けを障害と誤認したり、ブラウザーがつながるだけで端末全体の通信がVPN経由だと思い込んだりするおそれがあります。

接続状態・出口・通信振り分けを区別する

サブスクリプションURLは、ノードや関連設定をクライアントに取り込むためのものです。クリックするだけで、すべてのアプリが自動的にVPNを使うようになるわけではありません。取り込み後は、有効な設定を選び、接続を開始して、プラットフォームで必要なネットワーク権限を許可します。サブスクリプションの更新成功と、ノードから目的のサイトにアクセスできることは、別々に確認してください。

システムプロキシの影響を受けるのは、通常、システムのプロキシ設定を参照するソフトウェアだけです。仮想ネットワークアダプターやシステムVPNモードは、より広い範囲の通信を処理できますが、ルーティング設定や除外アプリ、クライアントの実装によって対象範囲が変わります。一部クライアントの「グローバル」モードも、プロキシコアに届いたリクエストをまとめてプロキシに送るだけで、すべてのプログラムを処理するとは限りません。

確認できる情報 分かること それだけでは判断できないこと
クライアントに接続済みと表示される クライアントが接続またはトンネルの確立を報告している すべてのアプリが想定した出口を経由していること
IP確認ページでグローバルIPが変わった そのページへのリクエストのグローバルIPが変わったこと ほかのアプリやDNSリクエストも同じ経路を通ること
DNSテストに特定のリゾルバーが表示される そのテストで該当する名前解決経路が観測されたこと リゾルバーの所在地と出口の所在地が必ず一致すること
目的のアプリにアクセスできる 現在の操作に必要なリクエストが完了できること メディア、アップロード、バックグラウンド通信もすべて同じ経路を使うこと

グローバルIPチェック:接続前後を比較する

まず、未接続の状態でIP確認ページを開き、グローバルIP、ネットワークの割り当て元、おおよその地域を記録します。次に確認したいノードへ接続し、同じネットワーク環境のままページを開き直します。比較中にネットワークとノードを同時に切り替えると、結果が変わった原因を特定しにくくなります。

  1. 未接続時の結果を記録します。家庭用ルーターが割り当てるプライベートIPアドレスを、グローバルIPと取り違えないようにしてください。
  2. 目的のノードに接続し、トレイアイコンが点灯しているかだけでなく、現在の設定とノード名を確認します。
  3. 確認ページを再読み込みします。キャッシュが気になる場合は、ページを閉じて開き直すか、別のブラウザーウィンドウで確認します。
  4. IPアドレスとネットワークの割り当て元を比較し、ノードで想定される地域も確認します。必要に応じて、別の確認サービスでも照合してください。

IPアドレスの位置情報データベースは更新が遅れることがあり、特に都市名は回線品質の判断材料にはなりません。ノード名と表示される都市が異なるだけで、回線が機能していないとは判断できません。ネットワークの割り当て元、目的のサイトへのアクセス状況、サービスの説明もあわせて確認しましょう。逆に、地域が想定どおり表示されても、通信速度やプライバシー設定、ほかのアプリの動作まで確認できたことにはなりません。

ルールベースの振り分けで確認ページが直接接続に設定されている場合、接続後もローカルの出口が表示されるのは設定どおりの可能性があります。その場合は、一時的に確認用ドメインをプロキシ経由にするか、通信の対象範囲を確認してからテストモードに切り替えます。比較が済んだら通常のルールに戻してください。確認結果をよく見せるためだけに、すべてのアプリのルーティングを長期的に変更するのは避けましょう。

DNSチェック:地域だけでなく経路を見る

DNSはドメイン名をIPアドレスに変換します。Webリクエストがプロキシ経由でも、DNSリクエストまで同じ経路を通るとは限りません。名前解決は、システム、ブラウザーのセキュアDNS、クライアント内蔵リゾルバー、リモートプロキシなどが処理する場合があるため、個別に確認が必要です。

DNSテストページは通常、テスト用ドメインを使って再帰リゾルバーの出口を調べます。ネットワーク経路のすべてが見えるわけではなく、端末が直接接続しているサーバーとも限りません。パブリックDNSサービスが分散拠点を使っている場合、表示された地域と回線の出口が異なっていても、それだけでDNSリークの証拠にはなりません。

実用的な確認方法は、まず「プロキシ対象のドメインはリモートで名前解決し、直接接続するドメインはローカルで解決する」のように、想定する方針を書き出すことです。そのうえで、クライアントのDNS設定とテスト結果を照合します。プロキシ経由のリクエストでローカルネットワークを使わない想定なのに、ローカルのプロバイダーのリゾルバーが繰り返し表示される場合は、経路が迂回していないか調べましょう。

ブラウザーで暗号化DNSを有効にすると、システムの名前解決結果と異なる場合があります。暗号化によってDNS通信の一部は保護されますが、現在のプロキシ経由であることが自動的に証明されるわけではありません。原因を調べる際は、ブラウザーとクライアントの設定をそれぞれ確認し、一度に変更する項目は一つにします。暗号化DNSを一律に無効にして解決しようとしたり、出所の分からないDNSアドレスをそのまま設定したりしないでください。

システムコマンドの nslookup は、既定のリゾルバーやドメインの応答を確認するのに役立ちます。ただし、通常はブラウザーの暗号化DNSやクライアントのリモート名前解決を再現しません。コマンドとWebテストで結果が異なるのは珍しいことではなく、別々の経路を調べている可能性があります。どちらか一方の結果だけで端末全体を判断しないでください。

アプリごとに確認し、ブラウザーだけで全体を判断しない

ブラウザーで確認できたら、実際に使うアプリを開き、ログインやコンテンツの読み込み、実際の操作を試します。一つのアプリが複数のドメインを使う場合もあります。ログインページが開いても、ファイルのアップロード、音声、メディアのリクエストまで同じ経路を通るとは限りません。トップページが表示されるかだけでなく、実際の利用目的に沿って確認しましょう。

WindowsやmacOSのデスクトップソフトが、必ずしもシステムプロキシに従うとは限りません。特にゲームや一部のコマンドラインツールは個別に確認が必要です。Androidではアプリ別プロキシの除外リストに対象アプリが入っている場合があり、仕事用プロファイルのアプリには別のポリシーが適用されることもあります。iOSでは、現在有効なVPN構成に加え、ブラウザーのリクエスト経路を変えるほかのネットワーク機能にも注意してください。

  • ✅ 対象アプリがプロキシの適用範囲内か確認し、アプリ別の除外設定やドメインの直接接続ルールを調べる。
  • ✅ 同じノードで実際に操作し、クライアントの接続画面で対象ドメインとルーティング結果を確認する。
  • ✅ ルールを変更したら対象アプリを再起動し、既存の長時間接続が以前の経路を使い続けないようにする。
  • ❌ Webページが開くこと、ノードの遅延が表示されること、速度測定のアニメーションが終わることを、対象アプリの動作確認の代わりにしない。

接続状況の画面では、リクエストにどのルールが適用されたかを確認できます。ただし、クライアントを経由していない通信は表示されない場合があります。一時的な診断ログを有効にした場合、共有する前にアカウント情報、サブスクリプションURL全文、アクセス先などの機密情報を削除してください。サブスクリプションURLには接続情報が含まれるため、公開テストサイトやコメント欄に投稿しないでください。

接続済みなのに通信されない場合の確認方法

クライアントにエラーはないが、出口IPが変わらない

まずシステムプロキシまたはVPNの権限が有効か確認し、次に確認サイトが直接接続に設定されていないか調べます。ブラウザーのプロキシ拡張機能や独自のプロキシ設定が、システム設定より優先される場合もあります。複数のプロキシツールが同時にネットワーク設定を変更しないよう、重複する設定を一時的に無効にしてから比較してください。

一部のリクエストでは出口が変わるが、ほかはローカル経由のまま

ルールベースの振り分けに加えて、異なる種類のIPアドレスがどこまで処理されているか確認します。端末が複数種類のグローバルアドレスを同時に使い、クライアントがそのうち一方しか処理していない場合があります。確認ツールに対応するテストがあれば、それぞれの結果を照合し、クライアントがすべての通信を処理できるか、未処理の経路を明示的に遮断できるか確認してください。一つの結果だけを見て確認を終えないようにしましょう。

DNSは正常に見えるが、アプリに接続できない

名前解決の成功はIPアドレスを取得できたことを示すだけで、その先へ接続できるとは限りません。ノードとの接続、接続先サービスの制限、証明書の時刻、アプリ独自のプロキシ設定、ネットワーク通信の互換性なども原因になります。まず同じ設定で別の接続先を試し、次にノードを変えて確認しましょう。アクセスできないからといってDNSを何度も変更し、設定を複雑にしないでください。

ネットワークを切り替えた後に通信できないが、接続アイコンは表示されたまま

ネットワークが変わると既存の接続が切れても、アプリの画面に反映されないことがあります。接続を復旧したら、状態アイコンを待つだけでなく、出口IPを再確認して対象アプリを開いてください。切断時の通信保護を確認する場合は、実際に回線を切断し、リクエストが継続できるかを試します。保護機能の設定や対象範囲はクライアントごとに異なるため、既定で有効とは限りません。

再利用できる確認結果を残す

確認結果には、「現在のネットワークとノードでは、ブラウザーの出口は想定どおりで、テスト用ドメインの名前解決経路は設定に沿っており、業務アプリでも動作を確認した」のように、確認範囲を明記します。単に「VPNは正常」と書くより役立ちます。クライアントの変更、ルールの更新、ネットワークの切り替え後も、同じ手順で再確認できます。

問題を問い合わせる際は、プラットフォーム、クライアント名、ネットワーク環境、ノードの地域、再現できる操作を伝え、出口IPとDNSでそれぞれ何を確認したか説明してください。パスワードやサブスクリプションURL全文は公開しないでください。対応プラットフォームや設定の取り込み方法は使い方ガイドを、通信範囲については回線とプロトコルの説明をご覧ください。

判断の目安:出口IPが想定どおりで、DNSの名前解決が設定に沿い、対象アプリの動作も確認できて初めて、今回の利用環境で回線が機能していると判断できます。一つのテストだけではほかの確認項目を代替できず、テスト範囲を超える安全性を保証するものでもありません。