VPNの接続状況を確認する方法｜出口IP・DNS漏えいチェック

VPNの接続確認：接続状態と通信経路を分けて考える

VPNが機能しているかどうかは、クライアントの接続アイコンだけでは判断できません。出口IPを調べると通信の出口を、DNS漏えいチェックでは名前解決の経路を確認できます。目的のアプリが正常に動くかも個別に検証しましょう。結果を総合すれば、正常な通信振り分けと設定漏れを見分けやすくなります。

クライアントに「接続中」と表示されていても、通常はトンネルやプロキシが起動したことを示すだけで、すべての通信が経由しているとは限りません。システムプロキシの影響を受けるのは、システム設定に従うアプリに限られる場合があります。TUNモードは仮想ネットワークインターフェースを通じて対象の通信を取り込みますが、経路設定や除外ルール、OSの権限にも左右されます。モード名だけで適用範囲を判断しないでください。

確認を始める前に、目的を決めましょう。特定の海外サイトだけをプロキシ経由にするのか、端末から外部への通信をすべてトンネルに通すのかを明確にします。ルールモードで国内向けサービスが直接接続されるのは、意図どおりの場合もあります。直結をすべて漏えいとみなすと、問題がない設定まで変更してしまうおそれがあります。

接続前後の出口IPを比較する

安全にプロキシを切断できる環境で、まず基準となる状態を記録します。直結にすると支障が出る作業中は、確認のために接続を切らないでください。先にクライアントのログを調べ、適切なタイミングで基準値を記録してもかまいません。IPアドレス全体、ネットワーク事業者、アドレスの種類を記録し、ページに表示される国や地域だけで判断しないようにします。

1. 切断した状態でIP確認ページを開き、ブラウザの現在のグローバルIPを記録します。IPv4とIPv6が別々に表示される場合は、それぞれ保存してください。
2. 利用する回線に接続し、サブスクリプションが有効でノードが選択されていることを確認します。システムプロキシ、または必要なTUNモードも有効にしてください。
3. 確認ページを再読み込みし、古いタブに残ったキャッシュを見ていないか確認します。地域名だけでなく、接続前後のIPアドレス全体を比べてください。
4. クライアントの接続ログを開き、確認ページのドメインに適用されたルールと出口を確認します。ページが直結に設定されている場合、その結果はプロキシの出口を示しません。
5. 別の確認サイトでも照合してから、目的のアプリをテストします。特定のサイトが開けないからといって、回線全体が使えないとすぐに判断しないでください。

IPアドレスの位置情報はデータベースに基づくため、更新が遅れたり、回線名と一致しなかったりすることがあります。同じ地域と表示されても出口が同じとは限らず、地域が変わってもすべての通信がプロキシ経由とは限りません。IPアドレスが実際に変わり、クライアントのログでも対象の通信が想定した回線を通っていることを確認するのが確実です。

DNS漏えいチェック：地域だけでなく名前解決の経路を確認

DNSはドメイン名を接続先のアドレスに変換します。アプリの通信がプロキシ経由でも、DNS問い合わせまで同じ経路を通るとは限りません。問い合わせはOSから送信される場合もあれば、ブラウザのセキュアDNS、クライアント内蔵のリゾルバー、プロキシサーバーが処理する場合もあります。漏えいかどうかは、隠したい、または制御したい名前解決の経路を基準に判断してください。

DNSLeakTestなどの外部サイトで確認できます。ページのテストを実行し、結果に表示されたリゾルバーの事業者を記録して、OS、ブラウザ、クライアントのDNS設定と照らし合わせます。テストサイトには確認用の問い合わせが送信されるため、利用前にプライバシーに関する説明を確認してください。

この種のテストでは、ブラウザから専用に生成されたドメインへ問い合わせ、その名前解決を行った再帰リゾルバーを確認します。表示されるのは主にテスト用ドメインのリゾルバーであり、端末上のすべてのアプリが使うDNSの完全な一覧ではありません。ローカルのリゾルバーが表示されなくても、バックグラウンドのアプリが別の経路を使っていないとは限りません。

外部DNSへの問い合わせをすべてトンネル経由にする想定なのに、接続先ネットワークのリゾルバーが繰り返し表示される場合は、さらに調べてください。パブリックDNSが表示された場合も、所在地やブランド名だけで安全性を判断できません。ブラウザが暗号化DNSでパブリックDNSに直接接続する場合と、トンネル経由で同じDNSに接続する場合では、結果の表示が似ていても経路は異なることがあります。

• クライアントでDNSの制御、リモート名前解決、関連するDNSルーティングルールが有効か確認します。設定項目の名称はクライアントの説明を参照してください。
• ブラウザのセキュアDNSが独立したサービスを使用しているか確認します。経路を統一したい場合は、設定をむやみに重ねるのではなく、クライアント側の構成と整合させてください。
• 設定を変更したら、関連するDNSキャッシュを消去するか、影響を受けるアプリを再起動してから再テストします。以前の名前解決結果が使われないようにしてください。
• クライアントがFake-IPを使用している場合、アプリはいったん割り当てられたアドレスを受け取り、その後の接続をクライアントが処理することがあります。アプリが受け取ったアドレスがグローバルIPの出口を示すわけではありません。

よくある結果と次の確認手順

出口IP、リゾルバー、接続ログを同じテストの中で確認します。変更は一度に一項目に絞り、変更前の結果も保存してください。どの設定が影響したか把握しやすくなります。以下は切り分けの目安であり、一度のテスト結果だけで断定するものではありません。

遅延テストに成功しても、特定の通信に応答があったことしか分かりません。ウェブページ、ログインAPI、画像、リアルタイム接続がすべて同じ経路を通るとは限りません。同様に、トップページが開いても、アプリ内のすべてのドメインにルールが適用されているとは限りません。実際に失敗した操作に対応するログを確認してください。

アプリ別に確認する：ブラウザ・デスクトップ・モバイル

Windows・macOS：プロキシの適用先を確認

まずOSのネットワークプロキシ設定がクライアントと一致しているか確認し、ブラウザ拡張機能がOSの設定を上書きしていないか調べます。デスクトップアプリはシステムプロキシを使う場合もあれば、独自のネットワーク機能を使う場合もあります。プロキシ経由にする必要があるアプリで、ログイン、コンテンツの読み込み、リクエストの送信などを実際に行い、同時にクライアントのログを確認してください。

開発ツールやターミナルは、特に個別の確認が必要です。HTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照するプログラムもあれば、専用の設定が必要なものもあります。環境変数を設定すればすべてのコマンドに適用されるとは限りません。ローカルプロキシのポートを設定する場合は、ほかのガイドに記載されたポートを使い回さず、クライアントの現在の設定を確認してください。

iOS・Android：通信の適用範囲を確認

OSで現在のクライアントによるVPN接続が許可されているか、別のVPN設定が通信を制御していないか確認します。Androidのクライアントには、アプリごとに対象・除外を設定できるものがあります。目的のアプリが正しい対象範囲に含まれているか確認してください。iOSでもVPNのステータス表示だけでは不十分です。実際のルートはクライアントの設定によって異なります。

Linux：デスクトップ設定とプロセス環境を分けて確認

デスクトップ環境のプロキシ設定が、バックグラウンドサービス、コンテナ、ターミナルツールに引き継がれるとは限りません。プロセスが実際に使用する設定と環境変数を確認してください。TUNを使う場合は、ルーティングと権限も確認します。コンテナのネットワーク環境がホストと異なる場合、ホスト上のブラウザの結果をコンテナ内の通信に当てはめることはできません。

Shadowsocks、VMess、Trojan、VLESSなどのプロキシプロトコル名だけでは、クライアントがどの方式でシステム通信を取り込むか分かりません。プロトコルは接続方式の一部を定め、システムプロキシ、TUN、振り分けルールはどの通信をプロキシに渡すかを決めます。原因を調べるときは、「プロトコルの変更」と「通信の適用範囲の拡大」を混同しないでください。

IPv6・WebRTC・切断時の保護範囲

IPv4のテストに問題がなくても、IPv6を確認してください。端末と接続ネットワークがIPv6に対応していて、クライアントが想定どおりに処理していない場合、一部の接続が別経路を使うことがあります。まずクライアントの対応状況とルーティングポリシーを確認してください。OSの設定を一時的に変更する場合は、影響を理解したうえで行い、変更後に再テストします。

WebRTCはブラウザのリアルタイム通信に使われ、テストページにはホスト、サーバー反射、中継の候補アドレスが表示されることがあります。プライベートアドレスや、秘匿化されたホスト候補が表示されても、実際のグローバルIPが漏えいしたとは限りません。想定した出口とは異なるグローバルIPが表示された場合は、ブラウザのポリシー、UDPの経路、クライアントのログをあわせて調べてください。

切断時の保護を確認する場合は、機密情報を扱わないテスト環境で、トンネルが切れたときにプロキシ経由にするはずの通信が失敗するのか、直結に切り替わるのかを確認します。設定画面に関連するスイッチがあるだけでは、保護が有効とは限りません。実際の作業セッションで不用意にネットワークを切断してテストしないでください。

IEPL専用線、中継、直結は回線の構成を表すもので、端末上のDNS制御やアプリの通信振り分けを代わりに行うものではありません。別の種類の回線に切り替えると通信の状態が変わることはありますが、ブラウザ独自のプロキシ設定、アプリの除外、未対応のIPv6ルートが自動的に修正されるわけではありません。

再テストのチェックリストと結果の記録

設定を調整したら、最初に問題が起きたアプリと操作をもう一度試します。接続モード、回線名、適用されたルール、出口の確認結果、テスト日時を記録しておくと便利です。サポートが必要な場合はヘルプセンターで問い合わせ方法を確認するか、使い方ガイドを参照してクライアント設定を見直してください。

• ✅ 確認リクエストに想定したルールが適用され、出口IPが目的の経路と一致している。
• ✅ DNSの確認結果をOS、ブラウザ、クライアントの名前解決設定と照合できている。
• ✅ クライアントの接続表示だけでなく、対象アプリで実際の操作を完了している。
• ✅ 対象となるネットワーク環境でIPv4、IPv6、リアルタイム通信の経路をそれぞれ確認している。
• ✅ 設定を変更した後、関連する接続を確立し直している。以前のセッション結果で新しい設定を判断しない。
• ✅ スクリーンショットやログを共有する前に、サブスクリプションURL、認証情報、トークン、不要な個人情報を隠している。

サブスクリプションURLにはアクセス情報が含まれることがあるため、公開の確認サイトや掲示板に貼り付けないでください。トラブルシューティングに必要なのは通常、機密情報を伏せたルール適用状況、エラーメッセージ、出口の確認結果です。設定ファイル全体を公開する必要はありません。ログのどの項目が機密情報にあたるか判断できない場合は、必要最小限の情報をサポートに確認してください。