VPNの接続が本当に有効か確認する方法：出口IP・DNS・アプリ別チェック

まず接続前後を比較する

ダウンロードや同期などのバックグラウンド処理を一時停止し、現在のネットワーク、クライアントのモード、テストするアプリを記録します。デバイスをリモート操作中の場合は、接続を維持している通信を不用意に切断せず、元に戻せる手順を用意してください。テスト中はできるだけ同じネットワークを使い、ネットワーク切り替えによる出口の変化をプロキシの効果と取り違えないようにします。

プロキシを一時的に切断し、信頼できるグローバルIP確認ページを開いて、IPアドレス、プロバイダー、おおよその地域を記録します。クライアントを再接続し、同じページを更新して再確認します。IPアドレスは個人のネットワーク情報です。記録は手元にとどめ、結果をそのまま公開の掲示板に貼り付けないでください。

ルールベースの分岐モードでは、日本国内の確認ページがもともと直接接続に設定されている場合があります。その場合は、プロキシ経由が明確に必要な確認先を選ぶか、一時的にその接続先をプロキシに設定して比較します。クライアントの「グローバル」は通常、クライアントが処理する通信を選択中のポリシーにまとめる機能であり、デバイス全体の通信を必ず対象にするわけではありません。

1. 未接続時のグローバルIPと、確認ページのドメインを記録する。
2. サブスクリプションが読み込まれ、ノードが選択され、プロキシまたはトンネルが有効になっていることを確認する。
3. 接続後にページを再読み込みし、IPアドレスの変化と対象ルールを確認する。
4. モードを切り替えて確認する場合は、元の設定を記録し、テスト後に戻す。

3つの確認事項を分けて考えましょう。サブスクリプションの更新成功は設定を取得できたこと、ノードの応答はプローブに応答があったことを示すにすぎません。今回の目的を確認するうえで重要なのは、対象アプリの通信が想定した出口を通ることです。

出口IPを確認する：地域表示だけで判断しない

グローバルIP確認ページに表示されるのは、そのページにアクセスした通信の送信元です。接続後にアドレスが変わり、クライアントの接続ログでそのドメインにプロキシルールが適用されたと確認できれば、「このブラウザーからの今回の通信はプロキシ経由」と判断する根拠になります。ただし、ほかのアプリにも同じことが当てはまるとは限りません。

地域表示はIPアドレスのデータベースに基づくため、更新が遅れている場合があります。ノード名が示すのは入口や回線グループであり、出口の所在地とは限りません。表示地域が異なる場合は、信頼できる別の確認結果や回線の説明と照らし合わせましょう。都市名だけを根拠に、回線が機能していないと判断しないでください。

デュアルスタックネットワークでは、IPv4とIPv6の両方を確認しましょう。ブラウザーがどちらか一方を優先する一方で、クライアントがもう一方しか制御していない場合があります。両方の結果を個別に表示できるツールを使い、クライアントのドキュメントで対応範囲を確認してください。確認ページを「すべて正常」にするためだけに、システムのネットワーク機能をむやみに無効化しないでください。

DNSの名前解決経路を確認し、漏えいと通信分岐を区別する

DNSはドメイン名をIPアドレスに変換します。DNSテストでは通常、ブラウザーからテスト用ドメインにアクセスし、テスト提供元への問い合わせに使われた再帰リゾルバーを確認します。表示されるのはリゾルバーに関する手がかりであり、デバイス上のすべてのアプリの名前解決経路を示すものではありません。また、すべての通信内容がどの経路を通るかを直接証明するものでもありません。

まず想定する経路を確認します。対象ドメインの名前解決がトンネル経由であるべきなのに、ローカルネットワークのリゾルバーに問い合わせている場合は調査が必要です。一方、日本国内のドメインをルールに従って直接接続し、ローカルDNSを使う設定なら、必ずしも漏えいではありません。重要なのは、実際の経路が明確な設定上の想定から外れているかどうかです。

ブラウザーのセキュアDNS、システムの暗号化DNS、クライアントのDNS機能が、それぞれ名前解決に関与することがあります。ブラウザーが暗号化DNSを使っていても、通信がプロキシ経由とは限りません。暗号化DNSを直接接続で使うこともできます。検査結果にパブリックDNSサービスの名前が表示された場合は、そのDNS問い合わせの経路も確認してください。名前だけで安全性を判断することはできません。

• ✅ クライアントがDNSを処理しているか、プロキシ経由のドメインと直接接続のドメインでどのDNS設定が使われるかを確認する。
• ✅ ブラウザーのセキュアDNSとシステムDNSの設定を確認し、違いを記録して一つずつ検証する。
• ✅ 設定を変更した後は、関連するDNSキャッシュを消去するかテストアプリを再起動し、新しい問い合わせを発生させる。
• ❌ 「リゾルバーが海外にある」ことを、通信がプロキシ経由である証拠とみなさない。
• ❌ 検査ページで異常が見つからなかったからといって、デバイス全体に迂回通信が一切ないと判断しない。

設定の競合を調べるときは、一度に一つだけ変更して再テストします。ノード、ブラウザー、DNSを同時に変更すると、どの変更が影響したのか判断できません。想定した状態に戻ったら、一時的に無効化した保護機能を元に戻し、最後にもう一度確認してください。

アプリごとに確認する：ブラウザーだけで全体を判断しない

ブラウザーは正常でもほかのアプリが通信できない場合、通信制御の対象範囲が異なることがよくあります。WindowsやmacOSのシステムプロキシは、通常、システムプロキシ設定に従うプログラムに適用されます。その設定を無視するプログラム、独自のプロキシを使うプログラム、ネットワークに直接接続するプログラムは、別の経路を通る可能性があります。

TUNなどの仮想ネットワークアダプター方式では、より広い範囲の通信を制御できますが、ルーティング、除外設定、権限、クライアントの実装にも左右されます。「グローバルルール」と「TUNによる通信制御」は別の設定です。前者はクライアントが受け取った通信の処理方法を決め、後者はどの通信がクライアントに渡されるかに関係します。

Androidクライアントには、アプリごとの対象・除外リストが用意されている場合があります。選択したアプリが「プロキシ経由」なのか「プロキシを使わない」のか、現在のリストの意味を確認してください。iOSの個人用VPN構成と、管理対象デバイスのアプリ別VPNは異なります。すべてのクライアントで任意のアプリを選べるとは限りません。利用できる機能は、使用中のクライアントとOSの設定に従ってください。

対象アプリで実際の操作を再テストする

対象アプリを完全に終了してから開き直し、コンテンツの更新、情報の検索、メディアの読み込みなど、ネットワークが必要な操作を行います。古い画面が表示されているだけでは確認になりません。キャッシュから表示されている可能性があるためです。その後、クライアントに該当する接続が表示されているか、どのルールとポリシーグループが適用されたかを確認します。

アプリによっては複数のドメインに接続するため、ログインできてもメディアのリクエストが成功するとは限りません。ログイン、コンテンツ一覧、実際の再生をそれぞれテストしてください。プラットフォームは、アカウントの地域、決済地域、デバイスの位置情報、過去のセッションなども利用可能なコンテンツの判定に使うことがあります。対象のプラットフォームごとに検証し、無条件に利用できると判断しないでください。

クライアントのローカル接続ログはルールの確認に役立ちますが、アクセスしたドメインが記録される場合があります。調査が終わったら、必要に応じて一時的な詳細ログを無効にしてください。サポートに情報を送る場合は、サブスクリプションリンク、認証情報、無関係なアクセス記録を伏せてください。

接続しているように見えるときによくある原因

サブスクリプションを読み込んでも、設定が有効とは限らない

サブスクリプションリンクはノードや設定を取得するためのものであり、接続そのものではありません。互換性のあるクライアントに読み込まれていること、設定が有効になっていること、利用可能なポリシーが選択されていることを確認してください。サブスクリプションリンクにはアクセス用の認証情報が含まれることが多いため、公開の検査サイトに貼り付けないでください。VPNPOでは、ログインパネルからサブスクリプションを取得できます。クライアントのダウンロード権限はパネルの表示に従います。

プロトコルには対応していても、通信制御方式が合っていない

Shadowsocks、VMess、Trojan、VLESSなどのプロトコルが使えるかどうかは、クライアントのコアと個別の設定が対応しているかによります。プロトコル名だけでは、システムの通信が制御されているとは限りません。読み込みに失敗する場合は、まずサブスクリプションの形式とコアの互換性を確認してください。ブラウザーは使えてもほかのアプリが使えない場合は、プロキシモードとアプリ別ルールを優先して確認します。

回線名を接続の証拠とみなしている

IEPL専線、中継、直接接続は、回線の構成方法を示すものであり、デバイスでの実際の確認に代わるものではありません。中継では通常、別の入口を経由して通信を転送します。直接接続では通常、その種の中継入口を経由しません。IEPLという表示だけで、すべての通信が実際にどの回線を通るかを証明することもできません。どの回線を選んでも、出口IP、DNS、アプリの通信を確認してください。

ブラウザー拡張機能や別のネットワークツールが通信を制御している

ブラウザーのプロキシ拡張機能、ほかのVPNクライアント、企業向けネットワークツールが設定に影響する場合があります。必要な接続は維持しながら、各ツールの説明に従って競合要因を一つずつ切り分けてください。ブラウザーの出口IPが変わっているのにクライアント側に対応する接続が見当たらない場合は、現在のクライアントではなく、ブラウザーが別のプロキシを使っている可能性もあります。

検査サービスも慎重に選びましょう。グローバルIPやDNSの確認に、サブスクリプションリンク、パスワード、決済情報を入力する必要はありません。設定全体のアップロードや、詳細不明の証明書のインストールを求められた場合は、操作を中止してください。

キルスイッチとブラウザーの迂回経路も確認する

プロキシの切断後にインターネット接続も遮断する必要がある場合は、クライアントにキルスイッチ機能があるか確認し、OSの「VPNに常時接続」などの設定との適用範囲も確認してください。作業内容を保存したうえで、制御できる環境で接続を手動で切断し、対象アプリが新たな外部通信を開始できるかを確認します。その後、再接続してもう一度テストしてください。

ブラウザーのWebRTC検査では、ローカルネットワークのアドレス、隠蔽処理されたホスト名、またはパブリックIPの候補が表示されることがあります。ローカルネットワークのアドレスが表示されても、実際のグローバル出口IPが漏れているとは限りません。本来表示されないはずのパブリックIPが表示された場合は、ブラウザーのポリシー、UDPのルーティング、クライアントの通信制御範囲をさらに確認してください。

グローバル出口IPが変わっても、アカウントの識別情報が消えるわけではありません。ログイン状態、Cookie、デバイスの権限は、接続先のサービスから引き続き利用されることがあります。VPNPOはログを保存しない方針ですが、これはサービスの運用方針です。デバイスの設定確認に代わるものではなく、アクセス先のウェブサイトが受信したアクセスを記録しないことを保証するものでもありません。

原因を特定できない場合は、OSとクライアントの名称、使用モード、問題が起きるアプリ、適用されたルール、個人情報を伏せた検査結果を整理し、トラブルシューティングガイドを確認するか、サポートページから問い合わせてください。「接続済みなのに使えない」だけでなく、「どの通信が想定した経路を通らないか」を説明すると、原因を絞り込みやすくなります。