本文へスキップ

VPN接続の確認方法|IPアドレスとDNSのチェック

接続前後のIPアドレスやDNSを確認し、アプリごとに通信経路を検証する方法を解説。「接続済みなのにVPNを経由しない」場合の原因と対処法も紹介します。

VPNが機能しているか確認するには、まず接続前後のIPアドレスを比べ、次にDNSを確認し、最後に実際に使うアプリで通信を検証します。クライアントの「接続済み」は状態表示にすぎず、すべての通信がVPN経由である証拠にはなりません。確認すべきなのは、対象の通信が想定した出口を通っているか、ドメイン名の名前解決が設定どおりかどうかです。

接続状態と実際の出口の違い

多くのクライアントで「接続」と表示されるのは、ローカルプロキシやシステムトンネルが起動した状態です。リクエストが発生してからリモート接続を確立するクライアントもあるため、画面が正常でも対象サイトにアクセスできたとは限りません。サブスクリプションの読み込み、ノードの選択、回線への接続、アプリがプロキシを使うかどうかは、それぞれ別の段階です。

システムプロキシは、システムのプロキシ設定に従うアプリへの接続経路を提供します。ブラウザー拡張機能の影響範囲は通常、そのブラウザーに限られます。TUNモードやシステムVPNモードはより多くの通信を取り込めますが、ルールによる振り分け、除外アプリ、ルーティング設定の影響を受ける場合があります。デスクトップやステータスバーのアイコンだけで、通信の適用範囲を判断しないでください。

確認項目 確認できること それだけでは確認できないこと
クライアントが接続済み ローカルサービスまたはトンネルが有効 すべてのアプリがリモート出口を経由していること
出口IPアドレスが変化 今回テストしたリクエストの出口が変わったこと ほかのアプリや別のアドレスファミリーも同じ経路を使うこと
DNSテスト テスト用ドメインの問い合わせ先として表示された再帰DNSリゾルバー 端末上のすべての名前解決通信の経路
対象アプリでの確認 そのアプリの個々のリクエストがルールどおり処理されたか 未テストのアプリの接続状況

接続前の出口、選択した回線、プロキシモード、接続後の出口、対象アプリでの結果を簡潔に記録しておくと便利です。設定を一度にひとつだけ変えれば、回線側の問題か、端末側の通信取り込みの問題かを切り分けやすくなります。

出口IPアドレスの確認:接続前後を比較する

  1. 接続前の結果を記録する。クライアントを一時的に切断し、信頼できるIPアドレス確認サイトを開いて、アドレス、ネットワークの事業者、地域を記録します。ルーターの管理画面に表示されるLAN内のアドレスを、インターネット側の出口と混同しないでください。
  2. 接続先の回線につなぐ。クライアントが「ダイレクト接続」モードになっていないことを確認し、IPアドレス確認サイトへの通信が直接接続に振り分けられていないかチェックします。確認に使うページ自体も、想定したルールを経由する必要があります。
  3. リクエストを再実行する。確認ページを再読み込みし、必要に応じて新しいブラウザーウィンドウを使います。国名表示だけでなくIPアドレス自体を比較してください。地域データベースの更新には時間がかかることがあります。
  4. 実際に使うサイトへのアクセスを確認する。目的のサイトを開き、クライアントの接続ログでドメイン、適用ルール、出口を確認します。プロセスごとの表示に対応している場合は、該当アプリも記録してください。

出口が変わった場合に確認できるのは、今回の確認リクエストが異なる出口を経由したということです。これは有効な証拠ですが、「端末全体でVPNが有効」とまでは言えません。逆に出口が変わらなくても、確認サイトへの通信が通常どおり直接接続に振り分けられている可能性があり、回線の不具合とは限りません。

IPv4とIPv6は個別に確認する

端末がIPv4とIPv6の両方で接続できる場合があります。クライアントが片方のアドレスファミリーしか取り込まないと、ブラウザーがもう一方の経路でアクセスすることがあります。デュアルスタックに対応した確認ページで違いを調べられますが、IPv6非対応のネットワークでは該当する結果は表示されません。

想定と異なるIPv6の出口が見つかった場合は、クライアントのIPv6ルーティング、トンネルの対応状況、漏えい防止設定を優先して確認してください。問題の切り分けにIPv6を一時的に無効化する方法はありますが、すべての端末に共通する恒久的な対策ではありません。

DNSリーク:国名だけでなく名前解決の経路を確認

DNSはドメイン名を接続可能なアドレスに変換します。プロキシ通信がリモート経由でも、ドメイン名の問い合わせまでリモート経由とは限りません。クライアントによっては、ローカルでの名前解決、リモートでの名前解決、暗号化DNS、ドメインごとの使い分けが行われます。

一般的なDNSリークテストでは、ブラウザーから一時的に生成されたドメインへアクセスし、問い合わせに関与した再帰DNSリゾルバーを表示します。これはテスト用リクエストを調べる手がかりであり、端末上のすべてのDNS通信を記録したものではありません。リゾルバーの地域表示も、通信が実際に転送された場所を示すものではありません。

確認結果の読み方

  • ローカルの通信事業者のリゾルバーが表示される:すべての名前解決がトンネル経由となる設定なら、確認が必要です。一方、ローカルサイトへの直接接続とローカルでの名前解決がルールで明示されている場合、名前だけを根拠にDNSリークと判断することはできません。
  • パブリックDNSサービスが表示される:クライアントの設定による場合もあれば、ブラウザーのセキュアDNSによる場合もあります。設定を確認し、別の国にあるという理由だけで安全または異常と判断しないでください。
  • 複数のリゾルバーが表示される:ブラウザー、OS、クライアントで名前解決の方針が異なる場合や、DNSサービスの転送構成が関係する場合があります。想定外のローカル経路が使われていないかを確認することが重要です。

まずブラウザーのセキュアDNSとクライアントのDNS設定を記録し、接続前後を比較します。どちらかを一時的に変更する場合は、再テストして違いを記録し、終了後は日常利用に適した設定に戻してください。提供元が分からないDNS設定一式を、確認せずに読み込まないようにしましょう。

キャッシュも確認結果に影響します。一度名前解決したドメインでは、新たな問い合わせが発生しないことがあります。確認ページで新しく生成したドメインを使うと調べやすくなります。キャッシュの消去やアプリの再起動は再テストの補助にはなりますが、名前解決の方針そのものの確認に代わるものではありません。

アプリごとに確認:ブラウザーが使えても全体が正常とは限らない

ブラウザーではアクセスできるのにデスクトップアプリでは失敗する場合、通信を取り込む範囲の違いがよくある原因です。ブラウザーが拡張機能のプロキシを使う一方で、デスクトップアプリはシステムプロキシを無視することがあります。ゲームや音声アプリでは、ウェブページとは異なる通信方式が使われる場合もあります。対応範囲はクライアントの説明を確認してください。

  • ✅ ブラウザー:拡張機能に個別のプロキシ設定があるか、通常ウィンドウとシークレットウィンドウで拡張機能が有効か、セキュアDNSがどう設定されているかを確認します。
  • ✅ デスクトップアプリ:アプリ内プロキシの有無、システムプロキシへの対応状況、クライアントのログにそのアプリの新しい接続が記録されているかを確認します。
  • ✅ モバイル端末:システムVPNの権限、アプリごとの除外リスト、ネットワーク切り替え後もトンネルが正常に動作しているかを確認します。
  • ✅ 対象サイト:接続ログの適用ルールと出口を照らし合わせ、「リクエストが回線を経由していない」場合と「経由したがサービスに拒否された」場合を切り分けます。

Windowsでは、アプリによって参照するプロキシ設定が異なります。macOSのシステムプロキシも、すべてのプログラムを取り込むとは限りません。Androidのクライアントにはアプリごとの振り分け機能が用意されている場合があります。iOSで取り込める範囲は、クライアントが使うネットワーク拡張機能と設定によって異なります。プラットフォーム名だけでは、通信がすべて取り込まれているかは分かりません。

WebRTCの確認結果も慎重に読み取る必要があります。ブラウザーにLAN内の候補アドレスや、プライバシー保護処理されたローカルホスト名が表示される場合がありますが、それだけでインターネット側の出口IPが漏れたとは言えません。想定と異なる実際のグローバルIPアドレスが表示された場合は、ブラウザーのポリシーとトンネルのルーティングを確認してください。

「接続済みなのに回線を経由しない」場合の確認手順

まずルールを確認し、その後に回線を調べる

クライアントの接続ログから、直前に行った対象リクエストを探します。適用ルールが「ダイレクト接続」なら、ドメインルール、アプリの除外設定、ルールの優先順位を確認してください。切り分けのため、クライアントに用意されたグローバルプロキシモードへ一時的に切り替える方法もあります。ただし「グローバル」がすべてのアプリを対象にするかは、通信の取り込み方式によって異なります。

ログでリクエストがプロキシ出口に渡されたことを確認できるのにアクセスできない場合は、ノードの状態、サブスクリプションの更新状況、アカウントの通信量、ローカルネットワークの制限を確認します。すべてのエラーをDNSの問題と決めつけないでください。また、ノード、DNS、ルールを同時に変更すると原因を追えなくなるため避けましょう。

プロキシの重複設定と接続の再利用を確認する

ブラウザー拡張機能、ほかのネットワークツール、システムプロキシの設定が互いに干渉することがあります。まず現在の設定を保存し、不要なツールを一時的に無効にして、通信を取り込む経路をひとつに絞ってください。モードを切り替えても古い長時間接続が元の経路を使い続ける場合があります。対象アプリを終了してから起動し直し、再確認してください。

設定を手動で読み込んだ場合は、クライアントがサブスクリプション内のプロトコルとトランスポート設定に対応しているか確認します。サブスクリプションURLは設定を読み込むためのもので、VPNサーバーのアドレスではありません。読み込みに成功しても、各ノードの設定が現在のクライアントに対応しているとは限りません。サブスクリプションURLにはアクセス用の認証情報が含まれるため、公開の確認ページや掲示板に貼り付けないでください。

サービス側の地域判定は別に確認する

出口IPアドレスが変わっても、サービス上の地域表示が変わらない場合があります。アカウントの地域、ログイン状態、位置情報の権限、コンテンツの利用許諾、IPアドレスの分類などが原因として考えられます。これは通信が回線を経由しているかどうかとは別の問題です。まず出口とログを確認してからサービス側の表示に対処し、関係のないクライアント設定を何度も変更しないようにしましょう。

動作確認の根拠と利用上の注意

接続アイコンを見るより、リクエスト単位で確認するほうが確実です。

テスト用リクエストの出口が想定どおりで、DNSの名前解決が設定に従い、対象アプリのログでも正しい回線が適用されていれば、その利用環境についてより確かな判断ができます。ルールによってローカル通信を直接接続するのは正常な設計の場合があります。確認していないアプリまで通信が取り込まれていると考えないでください。

確認結果は、その時点のネットワークと設定を記録したものです。クライアントの更新、ルールの変更、接続ネットワークの切り替え後に問題が起きた場合は、同じ手順で再確認してください。暗号化通信を使っていても、サイトの本人確認やアカウントの安全管理に代わるものではありません。IPアドレスが変わっても、アクセス行動が関連付けられなくなるとは限りません。

VPNMakeの利用時は、クライアントの使い方ガイドで設定の読み込みと権限を確認してから、この記事の手順で動作を確認できます。回線情報は回線一覧をご覧ください。ログの結果を判断できない場合は、個人情報を伏せた記録をサポート窓口からお送りください。

無料で始める