VPN接続を確認する方法｜出口IP・DNS・アプリ別チェック入門

VPNに接続したら、まず出口IPを比較し、次にDNSを確認して、最後に実際に使うアプリでテストしましょう。クライアントの「接続済み」は、接続状態やローカルプロキシの起動を示すだけの場合があります。ブラウザー、会議アプリ、ターミナルが同じ経路を通るとは限りません。どのリクエストがどの経路を通り、どんな結果になったかを照らし合わせて判断します。

接続状態と出口IP：通信経路を確認する

出口IPとは、アクセス先のウェブサイトから見える送信元のグローバルIPアドレスです。プロキシやトンネルを経由してアクセスすると、通常はローカル回線のIPではなく、経由先の出口IPがウェブサイトに表示されます。確認するには、クライアントの状態アイコンだけを見るのではなく、接続前後に同じ確認ページを開いて結果を比べます。

クライアントの接続を切り、IP確認ページを開きます。グローバルIP、表示地域、IPv4とIPv6の結果がそれぞれ表示されるかを記録してください。
接続先の回線を選び、サブスクリプションでその回線が選択され、設定が有効になっていることを確認します。ページに残っている古い結果ではなく、改めて確認を実行してください。
IPアドレスが変わったかを比較し、クライアントの接続ログやルールの適用結果も確認します。確認ページへのリクエストがプロキシ経由で、直接接続ではないことを確かめましょう。
普段使っているルールベースの振り分けに戻して、もう一度テストします。一時的にグローバルプロキシで通ったとしても、普段のルールが対象アプリにも適用されるとは限りません。

IPアドレスが変われば、そのリクエストの出口が変わった有力な証拠になります。変わらない場合はルールも確認しましょう。確認サイトが直接接続に設定されていれば、結果が変わらないのは想定どおりかもしれません。逆に、確認サイトに回線の出口IPが表示されても、すべてのアプリの通信が経由しているとは限りません。

システムプロキシとトンネルモード：対象範囲を確認する

一般にVPNクライアントと呼ばれるソフトウェアには、システムのVPNインターフェースを利用するものと、システムプロキシを設定するものがあります。システムプロキシが適用されるのは、主にその設定を参照するプログラムです。TUNモードは仮想ネットワークインターフェースでルートを制御し、より広い範囲をカバーすることが多いものの、ルーティングや除外リスト、振り分けルールの影響を受けます。名称が似ていても、対象範囲は同じとは限りません。

通信の取り込み方式と確認範囲
方式	通常の対象	追加で確認する点
システムプロキシ	システムプロキシ設定に従うブラウザーやアプリ	アプリがプロキシを無視していないか、独自のプロキシ設定が有効になっていないか
ブラウザーのプロキシ拡張機能	そのブラウザー内で拡張機能のルールが適用されるリクエスト	ほかのブラウザー、デスクトップアプリ、ターミナルは自動的には対象にならない
TUNまたはシステムVPNインターフェース	ルーティングと設定でトンネル対象に指定された通信	アプリの除外設定、IPv6ルート、DNS設定、UDP対応
アプリ内プロキシ	そのアプリが明示的にプロキシへ送る接続	プロキシのアドレス、認証、ドメイン名の解決方法が適切か

「グローバルモード」も誤解されやすい設定です。クライアントによっては、プロキシエンジンに入ったリクエストをすべてプロキシ経由にするだけで、すべてのプログラムをエンジンに取り込むわけではありません。プログラムがシステムプロキシを参照していないなら、ルールモードを切り替えても解決しないことがあります。その場合はノードを何度も切り替えるのではなく、クライアントの説明に従ってTUNやアプリ内プロキシを確認してください。

サブスクリプションURLは回線や設定を取得するためのもので、通信を取り込むスイッチではありません。インポート後、利用可能な設定を選び、接続を開始する必要があります。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコル名だけでは、通信の対象範囲は判断できません。クライアントのバージョンやプロトコル対応状況、実際のルーティングが一致している必要があります。アクセス情報が含まれる可能性があるため、サブスクリプションURLを公開の確認サイトに貼り付けないでください。

DNSの確認：名前解決の経路が設定どおりか

DNSはドメイン名をIPアドレスに変換します。ウェブへのリクエストが回線を経由していても、DNSの問い合わせが同じ経路を通るとは限りません。システムDNS、クライアント内蔵の名前解決、ブラウザーのセキュアDNS、アプリ独自の暗号化DNSなどが関係する場合があります。確認の目的は、実際の名前解決経路が設定と一致しているかを確かめることです。見慣れないDNS事業者が表示されたというだけで、異常と判断する必要はありません。

信頼できるDNSリーク確認ページで新しいドメインを検索し、表示された再帰リゾルバーをクライアントのDNS設定と照らし合わせます。こうしたページで確認できるのは、通常、確認用ドメインへの問い合わせを最終的に処理したリゾルバーです。端末からリゾルバーまでの経路すべてが分かるわけではありません。また、パブリックDNSは分散した出口を使うことがあるため、リゾルバーの地域と回線の出口地域が一致しない場合もあります。

海外ドメインの名前解決もトンネル経由にする設定なのに、ローカル回線の事業者のリゾルバーが繰り返し表示される場合は、クライアントがDNSを制御しているか、ブラウザーに別のセキュアDNSが設定されていないか、システムに手動設定が残っていないかを確認してください。国内ドメインにローカルDNSを使うルールなら、ローカルで解決されても、それだけでDNSリークとは限りません。どのドメインがどこへ送られ、設定した方針に沿っているかが重要です。

ターミナルの nslookup や dig は名前解決結果の確認に使えますが、ブラウザーのセキュアDNSと同じ動作を再現するとは限りません。同じドメインから同じIPアドレスが返っても、同じリゾルバーを通ったとは限りません。異なるアドレスが返る場合も、コンテンツ配信ネットワークによる通常の振り分けである可能性があります。

アプリごとの確認：ブラウザーで通っても、すべてのアプリが通るとは限らない

実際に使うアプリで確認してください。ブラウザー、コマンドライン、会議ソフト、ゲームではネットワーク処理が異なる場合があります。ウェブサイトにはプロキシ経由でアクセスできても、デスクトップアプリは直接接続していることがあります。クライアントに接続ログがある場合は、対象のドメインやプロセス、適用されたルール、最終的な接続先を確認しましょう。画面上の名称はソフトウェアによって異なるため、実際の機能を基準にしてください。

✅ ブラウザー：プロキシ拡張機能がシステム設定より優先されていないか確認し、IP確認を再実行します。確認用ドメインの接続ログも確認してください。
✅ デスクトップアプリ：終了してから再起動し、ネットワーク通信を伴う操作を実行します。そのプロセスや対象ドメインが想定した接続先に送られているか確認しましょう。
✅ ターミナル：プログラム独自のプロキシ設定と環境変数を確認します。コマンドラインツールは、デスクトップのシステムプロキシ設定を参照しないことがあります。
✅ 会議・リアルタイムアプリ：ログイン、会議への参加、音声、映像を個別に確認します。ログインページが使えても、メディア通信の経路が正常とは限りません。
❌ タスクバーのアイコン、単一のウェブページが開くこと、クライアント内のノード遅延だけで、すべてのアプリに接続が適用されたと判断する。

WindowsとmacOSでは、システムプロキシとトンネルの権限をそれぞれ確認してください。Androidでは、アプリごとの対象・除外リストに加え、省電力設定によってクライアントがバックグラウンドで停止していないか確認します。iOSでも、クライアント設定のルートと除外ルールを見直してください。システムにVPNのアイコンが表示されても、インターフェースの状態を示すだけです。対象アプリでの実際のテストに代わるものではありません。

アプリ内で現在のセッションの接続元アドレスを確認できる場合は、補助的な証拠として使えます。ただし、過去のログイン履歴には反映の遅れがあるかもしれません。確認のために、よく知らないサイトへアカウント情報を入力しないでください。また、サブスクリプションURL、アクセストークン、個人のセッション情報を含むデバッグログを公開しないでください。

接続中なのに通信が経由しない場合：症状から原因を絞り込む

ブラウザーは使えるのに、ほかのアプリは直接接続している

まず、ブラウザーだけが拡張機能のプロキシを使っていないか確認し、次にデスクトップアプリがシステムプロキシに対応しているかを確認します。より広い範囲の通信を取り込む必要がある場合は、使い方ガイドを参考に、クライアントが対応するトンネル方式を有効にして、必要な権限が許可されていることを確認してください。切り替え後は、古い接続が使い続けられないよう対象アプリを再起動します。

出口IPは変わったのに、サイトの地域表示が違う

ウェブサイトはアカウントの地域、支払い情報、位置情報へのアクセス許可、Cookie、IPアドレスのデータベースなどを総合して判定することがあります。新しいブラウザーセッションを使うとキャッシュの影響を切り分けやすくなりますが、アカウント自体の地域設定は変わりません。まず出口IPを確認し、その後でサービス独自の判定方法を調べてください。サイトの表示だけを根拠に、回線が機能していないと判断することはできません。

一部の通信が回線を経由しない、またはリアルタイム機能だけ使えない

IPv4とIPv6を個別に確認してください。クライアントがIPv6を取り込んでおらず、アプリがIPv6を優先すると、出口が異なる場合があります。WebRTCの確認で表示されるローカルネットワークのアドレスやmDNS名は、パブリックIPの漏えいと同じではありません。確認すべきなのは、ローカル回線で使っている本来のパブリックIPが露出していないか、該当する通信が想定した対象範囲に入っているかです。

リアルタイム機能ではUDPが使われることもあります。ウェブページを読み込めても、リアルタイムのメディア通信が正常とは限りません。クライアント、回線、現在の設定がUDPに対応しているか、対象アプリがどのように接続を切り替えるかを確認しましょう。あらゆる不具合をDNSのせいにしないでください。

回線を切り替えても結果が変わらない

以前の接続が再利用されていないか、切り替えが実際に反映されたか、確認用ドメインがルールで直接接続に固定されていないかを調べます。同時に動作しているプロキシ、VPN、セキュリティソフトがルートやDNSを取り合っている可能性もあります。確認に必要な接続ツールは残したまま設定を記録し、ひとつずつ原因を切り分けましょう。続けて設定を変更すると、原因を特定しにくくなります。

確認のまとめ：証拠を個々のリクエストと照合する

役立つ確認記録には、そのときのネットワーク環境、クライアントのモード、選択した回線、対象アプリ、出口IPの確認結果、適用されたルールを含めます。サポートを求めるときは、ヘルプセンターに、個人情報を伏せたうえでこれらの情報を提供してください。「接続済みと表示されるのに開けない」という説明だけでは、名前解決、ルーティング、サーバー側の制限を切り分けられないことがほとんどです。

判断の目安

対象リクエストの出口が想定どおりで、DNSの解決方針が設定と一致し、実際のアプリの接続ログや機能テストでも確認できた場合に、その利用状況では接続が有効だと判断できます。これは現在のアプリと設定に対する結論であり、端末上のすべての通信に対する恒久的な保証ではありません。

接続確認は、プライバシー監査とは異なります。VPNIzはプライバシー方針の主な説明として「匿名・ノーログ」を掲げています。出口IPが変わっただけではログ方針を検証できません。また、ウェブサイトへのログイン、ブラウザーのCookie、端末の権限による識別も防げません。回線は通信経路を担いますが、アカウントとアプリのプライバシー設定は別途管理する必要があります。