本文へスキップ
check-vpn-working.md

VPN 接続の確認方法|IPアドレスとDNSを初心者向けに解説

IPアドレスの確認、DNSリークのチェック、アプリごとの通信経路の調べ方を解説。接続済みでも通信がVPNを経由しない主な原因も紹介します。

VPNが機能しているか確認するには、接続アイコンだけでなく通信をチェック

VPNは本当に機能しているのでしょうか。接続元のIPアドレスやDNSは確認の出発点ですが、検査サイトを一つ見るだけでは不十分です。クライアントに「接続済み」と表示されていれば、通常はローカル接続またはトンネルが確立されています。しかし、ブラウザーやチャットアプリ、コマンドラインの通信がその接続を使うかどうかは、システムプロキシ、トンネルのルーティング、アプリの設定、振り分けルールによって異なります。

まず、目的を明確にしましょう。特定のサイトだけをプロキシ経由にしたいのか、端末の大部分の通信をトンネルに通したいのかを確認します。ルールモードでは、一部のサイトが直接接続になる場合があり、それが意図した動作のこともあります。すべての通信で出口を変えることだけを基準にすると、正常な振り分けを不具合と誤認しかねません。

正しく確認するには、対象の通信がどこから出ているか、ドメインをどのDNSが名前解決しているか、実際に使うアプリが同じ経路を利用しているかをそれぞれ調べます。以下では、接続前の記録、接続後の比較、項目ごとの切り分けの順に説明します。ダウンロード速度から推測する必要はありません。

確認項目 確認できること それだけでは確認できないこと
出口IPアドレス 今回の確認リクエストを受け取ったサイトから見える送信元のグローバルIPアドレス ほかのアプリやサイトもプロキシ経由で通信していること
DNSテスト 今回テストしたドメインの再帰DNS問い合わせが外部へ出る経路 端末上のすべてのドメイン問い合わせが同じ経路を使うこと
クライアントの接続ログ アプリのリクエストに適用されたルールと選択されたアウトバウンド リモートサービスが正常に応答し、コンテンツをすべて返したこと
実際のアプリでのアクセス 現在の設定で目的の機能を使えるかどうか アクセスに成功すれば、すべてのプライバシー保護が有効になっていること

出口IPアドレス:接続前の状態を記録して比較する

信頼できるグローバルIPアドレス確認サイトを選び、表示内容がサイトのサーバーアドレスではなく、アクセス元のアドレスであることを確認します。検査サイトにはアクセス情報が送信されるため、サブスクリプションURL、アカウント情報、クライアント設定を入力しないでください。IPアドレスの位置情報データベースは更新が遅れることがあり、特に都市名は回線の物理的な所在地を正確に示すものではありません。

  1. 直接接続時の状態を記録します。短時間の直接接続が許容されるテスト環境でクライアントを切断し、確認サイトを開きます。グローバルIPアドレス、ネットワーク事業者、異なるアドレスファミリーの結果がそれぞれ表示されるかを記録してください。
  2. プロキシ設定を記録します。接続先ノードに接続し、ルールモードとグローバルモードのどちらを使っているか、システムプロキシまたはTUNが有効かを記録します。基準となる状態が変わらないよう、テスト中は同じネットワークを使い、Wi-Fiを切り替えないでください。
  3. もう一度確認します。検査結果を更新し、必要であればページを開き直します。表示されたアドレスを接続前の記録と比較し、今回のアクセスがクライアントの接続ログに記録されているかも確認してください。
  4. 別の方法でも確認します。信頼できる別の確認サイトでも同じ手順を繰り返します。結果が異なる場合は、どちらかが間違いだとすぐに決めつけず、二つの検査ドメインに異なるルールが適用されていないか確認してください。

接続後にアドレスが変わった場合、今回の確認リクエストの出口が変わったことを示します。変わらない場合は、検査ドメインが直接接続になっていないか、ブラウザーがシステムプロキシを迂回していないか、クライアントがノードには接続したものの通信を取り込めていないのではないかを確認してください。アドレスが変わっただけではサービスがログを記録するかどうかは判断できません。また、ページに表示された地域がすべてのアプリから見える地域と同じとは限りません。

DNSリーク:名前解決の場所と通信経路を見分ける

DNSはドメイン名を接続先のアドレスに変換します。DNSテストサイトは通常、テスト用ドメインを生成し、どの再帰DNSサービスから問い合わせが届くかを調べます。表示されるのはパブリックDNS事業者やその出口の位置情報である場合があり、端末が直接接続しているサーバーとは限りません。また、プロキシノードと同じ地域にあるとも限りません。

そのため、DNSの所在地と出口IPアドレスが異なるだけでは、DNSリークとは判断できません。確認すべきなのは、現在の設定で保護された経路を通るはずの問い合わせが、意図せずローカルネットワークや通信事業者のDNSサービスへ送られていないかです。ルールモードでは、直接接続するドメインをローカルで名前解決する設定もあります。適用されるルールを踏まえて判断してください。

  1. 信頼できるDNSテストを接続前後に実行し、地図上の国や地域だけでなく、DNSサービス名とネットワーク上の所属を記録します。
  2. クライアントのDNS設定を確認します。直接接続するドメインとプロキシ経由のドメインで、どの名前解決方法を使うか、DNSの取り込みが有効かを確認してください。
  3. ブラウザーの「セキュアDNS」などの設定も確認しましょう。ブラウザーが暗号化DNSを使って独自に名前解決し、OSの設定を経由しない場合があります。暗号化された問い合わせがトンネルを通るかどうかは、ルーティング設定によって異なります。
  4. 接続ログと照らし合わせ、DNSサービスへの通信経路を確認します。意図しないローカルDNSが見つかった場合は設定を調整し、新しい問い合わせで再テストしてください。キャッシュされた結果だけで判断しないようにしましょう。

Windowsでは、次のコマンドでコマンドラインの名前解決時に既定で問い合わせるサーバーを確認できます。これは原因を探る手がかりであり、DNSリークを完全に検査するものではありません。ブラウザーが独自のDNSを使うことも、プロキシがリモート側でドメインを解決することもあります。

nslookup example.com

クライアントによってはFake-IP方式を採用しています。アプリには合成アドレスを返し、その後クライアントが元のドメインと関連付けてアウトバウンドを決定します。そのため、システムツールに表示されるアドレスが接続先サイトの実際のアドレスとは限りません。合成アドレスが表示されたからといって、DNSを手動で変更しないでください。まず、利用しているクライアントの設定説明を確認しましょう。

ブラウザーは使えるのに、ほかのアプリが直接接続するのはなぜ?

「システムプロキシ」は通常、その設定に従うアプリにローカルのプロキシポートを使うよう通知するだけで、端末のすべての通信を強制的に取り込むものではありません。ブラウザーは設定に従っても、ゲームやコマンドラインツール、独自のネットワーク機能を持つソフトは従わない場合があります。ブラウザー拡張機能も、ブラウザー内だけに作用することがあり、システム全体の接続状態を示すものではありません。

TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。一般に対象範囲は広いものの、権限、ルートの除外設定、DNS設定、クライアントの実装によって動作は異なります。多くのプロキシクライアントで「グローバルモード」とは、取り込み対象のリクエストに同じプロキシアウトバウンドを使うという意味です。すべてのアプリが自動的にクライアントを経由するわけではありません。

  • ✅ ブラウザー:プロキシ拡張機能、システムプロキシ、セキュアDNSを確認し、設定が互いに競合していないか調べます。
  • ✅ デスクトップアプリ:独自のプロキシ設定があるか確認し、クライアントの接続一覧でそのアプリのリクエストを探します。
  • ✅ コマンドラインツール:ツール固有のプロキシ引数とプロキシ環境変数を確認します。ブラウザーの結果をそのままターミナルに当てはめないでください。
  • ✅ ゲームや通話アプリ:関連する通信を取り込めるか確認します。特にUDPへの対応とアプリごとのルーティング設定に注意してください。
  • ❌ クライアントの通信量が増えただけで、すべてのアプリが保護されていると判断する。増加分はバックグラウンド通信だけの可能性があります。

WindowsやmacOSでは、システムプロキシとTUNは別々の設定であることがよくあります。モバイル端末は通常、OSが提供するVPNインターフェースを使いますが、アプリごとの振り分けや除外設定がある場合もあります。Linuxでは、デスクトップ環境のプロキシ設定とターミナルの環境変数が連動するとは限りません。メニュー名はクライアントによって異なるため、同じ名前のボタンを探すのではなく、機能を確認してください。

接続ログでルールとノードを確認する

クライアントの接続一覧または診断ログを開き、対象サイトにアクセスします。リクエストのドメイン、適用されたルール、アウトバウンド名、接続結果を優先して確認してください。ログに直接接続と表示される場合は、ドメインルール、プロセスルール、最後に適用されるルールを確認します。プロキシ経由なのにアクセスできない場合は、ノードへの接続、リモート側からの応答、対象サービス側の制限を調べてください。

ウェブページは、ログイン、画像、動画、APIなどのドメインにもリクエストを送ることがあります。メインページが開いても、これらすべてのリクエストが成功したとは限りません。「ページの文字は表示されるがログインできない」ときは、何度もトップページを切り替えるより、失敗した操作で新たに発生した接続を確認すると原因を特定しやすくなります。ブラウザーの開発者ツールで失敗したドメインを調べることもできますが、表示されるリモートアドレスはローカルプロキシや中継先であり、最終的なグローバル出口とは限りません。

ルールの問題とノードの問題を切り分けるため、すでに取り込み対象となっている通信を一時的にグローバルプロキシへ切り替えて再試行できます。使えるようになった場合は、振り分けルールの漏れを重点的に確認してください。それでも失敗する場合は、クライアントが通信を取り込む範囲、ノードへの接続、対象サービスの状態を確認します。テスト後は元の振り分け設定に戻してください。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは転送方式です。クライアントがサブスクリプションで実際に提供されている設定に対応している必要があります。プロトコル名だけではDNSが保護されている証明にはなりません。IEPL専用線、中継、直接接続も主に回線経路の構成を示すものであり、端末側の通信取り込みやルール設定に代わるものではありません。

アドレスファミリー、WebRTC、切断後の再確認

ネットワークはIPv4とIPv6の両方を提供している場合があります。どちらか一方しか設定で取り込まれていなければ、もう一方のアドレスファミリーに対応するサイトは別の出口を使う可能性があります。確認サイトで一方の結果しか表示されなくても、もう一方も保護されているとは限りません。両方を個別に確認できるツールを選び、クライアントのルーティング対応状況と合わせて判断してください。

ブラウザーのWebRTC機能はリアルタイム通信に使われ、通常のウェブページとは異なる経路を利用する場合があります。検査結果にローカルのプライベートアドレスや、隠された形式のローカルホスト識別子が表示されることは、グローバルIPアドレスが直接公開されることとは異なります。想定外のグローバル送信元が露出していないかを確認してください。異常が見つからなくても、端末上のすべての通信が取り込まれている証明にはなりません。

切断後の動作もテストしましょう。リモート接続の切断、PCのスリープからの復帰、ネットワークの切り替え時に、アプリが再接続する場合もあれば、直接接続へ切り替わる場合もあります。こうした動作の確認は、短時間の直接接続を許容できるテスト環境で行い、クライアントに接続中断時の保護機能がある場合は、正しく有効になっているか確認してください。VPNという名称だけで、切断後の通信が必ず遮断されると考えてはいけません。

検査結果が食い違うときの確認手順

まず「通信が取り込まれているか」、次に「取り込まれた通信がどこへ向かうか」、最後に「リモート側が利用可能か」を確認します。この順番なら、アプリがプロキシを使っていない問題をノード障害と取り違えたり、実際には対象サイトの制限が原因なのにDNSを変更したりするのを防げます。

  • IPアドレスが変わらない:検査ドメインが直接接続になっていないか、ブラウザーが独自のプロキシを使っていないか、システムプロキシまたはTUNが有効になっているかを確認します。
  • IPアドレスは変わったが、DNSはローカルに見える:地域だけで判断せず、DNSサービスのネットワーク上の所属、ブラウザー独自のDNS、クライアントのDNS振り分け、接続ログを確認します。
  • ブラウザーは使えるが、アプリは使えない:そのアプリがシステムプロキシに従うか、独自のプロキシ設定があるか、関連する通信がTUNに取り込まれているかを確認します。
  • グローバルモードに切り替えると使える:失敗したリクエストに適用されたルールと関連ドメインを調べます。すべての振り分けを長期間無効にする必要はありません。
  • クライアントに対象の記録がない:まず通信の取り込み範囲を確認します。ログ機能が無効なら、記録機能を有効にしてから判断してください。

サポートを依頼する場合は、OS、クライアント名、現在のモード、問題が起きるまでの操作手順、個人情報を伏せた接続ログを伝えてください。サブスクリプションURL、認証トークン、認証情報を含む設定を公開しないでください。サブスクリプションURLから設定にアクセスできる場合があります。漏えいした場合は、サービスが提供する管理方法で更新してください。

まとめ:VPNが機能しているかは、アプリとリクエストごとに確認します。IPアドレスの比較でウェブサイトから見える送信元を確認し、DNSテストで名前解決の経路を調べ、接続ログで振り分け結果を確認し、実際の操作で目的の機能を検証します。複数の結果が一致して初めて、現在の設定が想定どおりか判断できます。クライアントの接続アイコンは確認の出発点にすぎません。

Z7VPNのクライアントはユーザーパネルから利用できます。ログインしてサブスクリプションとクライアント情報を確認してください。初回のインポート後も、この記事の手順に沿って端末上の実際の通信経路を確認しましょう。操作方法は使い方ガイドを参照してください。設定についての質問はお問い合わせページからお寄せください。

無料で試す