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

VPNが正しく機能しているか確認するには、まず出口IPアドレスを比較し、次にDNSを確認して、最後に対象アプリで検証します。クライアントに「接続済み」と表示されても、接続状態を示すだけで、すべてのリクエストが選択した経路を通る証明にはなりません。現在のモードや振り分けルールとあわせて確認しましょう。

この記事では、実際のトラブルシューティングの順に説明します。検査ページのすべての項目を同じ地域にそろえることが目的ではありません。プロキシ経由にするリクエストが実際にその経路を通ること、ドメイン名の解決が設定どおりであること、直接接続するリクエストも想定どおりであることを確認します。

まず「有効」の確認範囲を把握する

システムトンネル、システムプロキシ、ブラウザープロキシでは、対象となる通信の範囲が異なります。システムプロキシの影響を受けるのは、通常その設定に従うソフトウェアだけです。ブラウザー拡張機能が処理するのは、ブラウザーの通信に限られる場合があります。トンネルモードはより広範な通信を処理できますが、ルーティング、除外アプリ、振り分けルールの影響を受けます。システムにVPNアイコンが表示されているだけで、すべてのアプリの通信がVPN経由だとは判断できません。

ルールモードでは、国内サイトへの直接接続と、海外サイトへのプロキシ接続が同時に成立することがあります。出口IPの確認サイトも、直接接続のルールに該当する場合があります。クライアントの「グローバル」は、多くの場合、処理対象のリクエストにプロキシを一律適用するという意味で、すべてのアプリの通信を自動的に捕捉するわけではありません。

確認を始める前に、現在のモード、ノード名、ブラウザーのセキュアDNS設定、トンネルが有効かどうかを記録します。その後は一度にひとつの条件だけを変更すれば、結果が変わった理由を把握しやすくなります。

出口IPアドレス：接続前後を比較する

出口IPアドレスとは、接続先のウェブサイトから見えるインターネット上のIPアドレスです。デバイスがローカルネットワークで使うアドレスとは異なります。接続を切った状態で、信頼できるIPアドレス確認ページをブラウザーで開き、アドレスとネットワーク事業者を記録します。選択した経路に接続したら、同じブラウザーで再度確認してください。かなり前のスクリーンショットを比較に使うのは避けましょう。通常のネットワークのIPアドレスも変わることがあります。

1. 接続を切り、現在のネットワークで使われているIPアドレスを記録します。検査ページにIPv4とIPv6の両方が表示される場合は、どちらも記録してください。
2. 選択した経路に接続し、クライアントにハンドシェイクや認証の失敗、設定エラーが表示されていないことを確認します。
3. 検査ページを再読み込みします。必要に応じて新しいプライベートウィンドウを使い、ページキャッシュの影響を取り除きます。
4. クライアントの接続ログを開き、検査用ドメインに適用されたルールと、選択された出口を確認します。
5. 別の独立した検査サービスでもアドレスを確認し、地図に表示される都市名だけで判断しないようにします。

接続後にアドレスが変わり、ログでも対象のリクエストが選択したプロキシを通っていると確認できれば、より確かな判断材料になります。位置情報データベースが古いと、都市名が正確でないことがありますが、それだけで経路が機能していないとは限りません。アドレス、ネットワーク事業者、リクエストの経路を優先して確認し、国旗や地域表示だけで判断しないでください。

アドレスが変わらなくても、すぐに接続失敗と決めつける必要はありません。まず、検査用ドメインがルールで直接接続に設定されていないか、ブラウザーがシステムプロキシを経由しているか、検査ページが一方のアドレス種別だけを表示していないかを確認します。比較のために一時的にグローバル設定を使う場合は、検査後に元の設定へ戻してください。

DNS：リゾルバーが違っても、必ずしも漏えいではない

DNSはドメイン名をIPアドレスに変換します。DNS検査ページは通常、専用のテスト用ドメインを使い、どの再帰リゾルバーが権威サーバーへ問い合わせたかを調べます。表示されるのは多くの場合、リゾルバーが外部へ問い合わせる際のアドレスで、デバイス自身の出口IPアドレスではありません。そのため、DNSのアドレスとウェブ通信の出口IPが異なるのはよくあることです。

比較する際は、すべての結果がノードのある地域に一致するかではなく、リゾルバーの事業者や設定を確認しましょう。パブリックDNSは分散型サービスを使うことがあり、検査ページの地域表示はデータベース上の推定にすぎません。クライアントがドメインごとにローカルDNS、リモートDNS、合成アドレス方式を使い分ける場合もあり、こうした設定が結果に影響します。

確認が必要なのは、関連する名前解決をすべてプロキシ経由にする想定なのに、検査でローカル回線のリゾルバーが繰り返し表示され、ログや設定からも想定した経路を通っていないと確認できる場合です。よく知られたパブリックDNSのサービス名が表示されただけでは、漏えいとは判断できません。

暗号化DNSとプロキシの出口は別の問題です。ブラウザーでDoHを使うと、ブラウザーとDNSサービス間の問い合わせを暗号化できますが、その通信自体が直接接続になる場合があります。暗号化DNSを使っていても、DNSが選択した経路を通っているとは限りません。

まずブラウザーのセキュアDNSを確認し、次にクライアントのDNSポリシーとシステム設定を確認します。ブラウザーによっては独自に名前解決し、クライアントで設定したDNSサービスを経由しないことがあります。クライアントがDNSリクエストを内部モジュールで処理する場合もあります。検査ページの結果をそのまま設定にコピーしたり、一度にすべてのDNS設定を変更したりしないでください。

ブラウザーの結果をデバイス全体に当てはめず、アプリごとに確認する

ブラウザーの出口が想定どおりでも、確認できるのは検査ページへのリクエストだけです。デスクトップアプリ、ゲーム、ターミナル、バックグラウンドサービスでは、異なるネットワークスタックを使うことがあります。システムプロキシを参照しないアプリやUDPを使うアプリもあり、確立済みの接続はノードを切り替えてもすぐには移行しない場合があります。

実際に確認するときは、対象アプリを終了してから再起動し、明確なネットワーク操作を行います。同時にクライアントの接続ログを確認し、対象のドメイン、プロセス、宛先アドレスを探して、適用ルールと出口を確認してください。通信量の合計が増えただけでは、アプリのリクエストかシステムのバックグラウンド通信かを区別しにくくなります。

• ✅ ブラウザー：検査ページを再度開き、出口アドレスと検査用ドメインのルールを確認する。
• ✅ 対象アプリ：再起動して実際の機能を使い、該当する接続ログが記録されるか確認する。
• ✅ UDPを使う場合：クライアントの通信処理方式と経路の対応状況を確認し、ウェブページへのアクセスだけで判断しない。
• ✅ ルールモード：プロキシ経由にする通信と直接接続にする通信をそれぞれ確認し、どちらも想定どおりか確かめる。
• ❌ ページが開く、アプリのアイコンが点灯する、通信量の数値が増えるといった理由だけで、すべての通信が処理されていると判断する。

WindowsとmacOSでは、システムプロキシとトンネルによる通信処理を区別します。Androidでは対象アプリが除外されていないか確認してください。iOSではVPN構成の追加を許可しただけでは、通信が正しく処理されているとは限りません。クライアントのポリシーと実際の接続を確認しましょう。メニュー名はプラットフォームによって異なるため、使用中のクライアントの説明を参照してください。

ターミナルのツールは、プロキシ環境変数の影響を受ける場合もあります。ブラウザーでは接続できるのにコマンドラインでは失敗する場合は、すぐに経路を変更せず、コマンドラインが同じプロキシ経路を使っているか確認してください。設定方法はクイックスタートで、通信の処理方式と設定のインポート手順を確認できます。

IPv6とWebRTC：見落としやすい経路も確認する

ネットワークがIPv4とIPv6の両方に対応している場合、アプリはどちらかを優先して使うことがあります。クライアントが一部の通信しか処理していないと、ウェブ通信のIPv4出口は変わっても、IPv6はローカルネットワークを使い続けることがあります。目立つアドレスひとつだけで判断せず、それぞれ確認してください。

ローカルネットワークでIPv6を利用できない場合、検査に失敗してもプロキシの異常とは限りません。検査でローカルネットワークのグローバルIPv6アドレスが表示されたら、まずそのリクエストが直接接続を許可されているか確認し、次にトンネル、IPv6ルート、除外ルールを確認します。問題の切り分けに一時的なIPv6無効化が役立つ場合はありますが、一般的な恒久対策ではありません。

WebRTCはブラウザーのリアルタイム通信に使われ、通常のウェブリクエストとは別の経路で候補アドレスを検出することがあります。検査結果に表示されるローカルネットワークのアドレス、隠蔽処理されたホスト名、グローバルIPアドレスはそれぞれ意味が異なります。アドレスがひとつ表示されたからといって、すべてを漏えいと呼ぶのは適切ではありません。

確認すべきなのは、想定していないローカルネットワークのグローバルIPアドレスが表示されるかどうかです。表示される場合は、ブラウザーのプライバシー設定、クライアントのUDP処理、トンネルのポリシーを確認します。設定を変更する前に、ビデオ会議などで必要な機能も考慮してください。検査ページの表示を整えるためだけに、必要な機能をむやみに無効化しないようにしましょう。

接続済みなのに反映されない場合、症状から原因を絞り込む

サブスクリプションをインポートしたのに、選択中の設定が更新されない

サブスクリプションURLはノードや設定を取得するためのもので、接続成功を証明するものではありません。更新失敗、クライアントとの形式の不一致、古い設定の使用などにより、画面にはノード名が残っていてもリクエストが正常に処理されないことがあります。更新日時やエラーメッセージを確認し、選択したノードが最新の設定に含まれているか確かめてください。クライアントがサブスクリプションに含まれるプロトコルに対応している必要があります。ノード名が同じでも、互換性の確認にはなりません。

サブスクリプションURLにはアカウントの認証情報が含まれることがあります。サポートを求める際にURL全体を公開したり、出所不明のオンライン変換ツールに貼り付けたりしないでください。スクリーンショットやログにアクセストークンが含まれている場合は、事前に隠してください。

出口は変わったのに、アクセス先のウェブサイトを利用できない

この場合は、「プロキシが機能しているか」と「ウェブサイトがリクエストを受け付けるか」を分けて考えます。ウェブサイトはアカウントの地域、過去のセッション、出口の評価、サービスのポリシーなどを基準に判断することがあります。アプリが古い接続を保持している場合もあります。まずアプリを再起動して新しいリクエストのログを確認し、次にウェブサイト側の案内を確認してください。アクセスできない原因をすべてDNSのせいにしないようにしましょう。

再接続やネットワークの切り替え後に結果が変わる

ネットワークを切り替えると、システムDNS、デフォルトルート、確立済みの接続が変わる場合があります。ブラウザーのページキャッシュ、システムのDNSキャッシュ、クライアントの名前解決キャッシュも、必ずしも同時に更新されません。まずリクエストを再実行し、関連するアプリを再起動します。それでも結果が一致しない場合は、プラットフォームの説明に従ってキャッシュを消去してください。操作を記録し、キャッシュ消去、ノード変更、DNS変更、モード変更を同時に行わないようにします。

IEPL専線、中継、直接接続は、回線の伝送方式を表すもので、デバイス側で通信を処理する範囲を示すものではありません。専線でも、アプリがプロキシを迂回したり、誤ったルールが適用されたりする問題は自動的に解消されません。プロトコルやネットワーク構成の用語は、回線とプロトコルで確認できます。

検査結果を記録し、あとから確認できる形にまとめる

役立つ記録には、ネットワーク環境、クライアントとモード、ノード名、接続前後の出口、DNSの事業者、対象アプリの動作、ログで適用されたルールを含めます。時刻と操作順も記録し、同じ条件で再検査すれば、一時的な障害と設定の問題を切り分けやすくなります。

結果の原因を特定できない場合は、サポート窓口から個人情報などを伏せた記録を送ってください。どの種類の通信をプロキシ経由にしたいのか、実際に何が確認できたのかを伝えると、「接続できない」とだけ伝えるより原因を特定しやすくなります。ログに完全なグローバルIPアドレス、アクセス先のドメイン、サブスクリプションの認証情報が含まれる場合は、調査に必要な情報だけを残してください。

最後に、検査中に一時変更した設定を元に戻し、普段使うアプリでもう一度確認します。検査ページは状態を調べるためのもので、最終的な目的ではありません。日常的に使うリクエストが、自分のルールどおりの経路を継続して通るかを確認しましょう。