VPNは接続済みなのに効かない？出口IPとDNSの確認方法

VPNが接続済みでも、本当に通信に適用されているとは限りません。クライアントの接続アイコンだけで判断せず、出口IPとDNSを確認しましょう。接続前の結果を記録し、接続後の出口や名前解決、対象アプリの動作と比較します。確認すべきなのは、指定したアプリの特定の通信が想定どおりプロキシを経由しているかどうかです。

一般にVPNクライアントと呼ばれるものでも、実際にはプロキシプロトコルやルールによる振り分けを使い、端末全体の通信を処理するとは限りません。以下の確認方法はシステム全体で接続する場合にもサブスクリプションクライアントにも使えますが、実際の動作モードに応じて判断してください。

接続アイコンと実際の出口の違い

「接続済み」は、システムのトンネルが確立した、またはローカルのプロキシサービスが起動したことを示すだけの場合があり、リモートノードに到達できるとは限りません。ノードが利用できなくても動作中のままになるクライアントもあります。また、システムプロキシの設定を参照しないアプリもあります。そのため、クライアントの状態、ウェブ上の出口、アプリの動作はそれぞれ別に確認しましょう。

各チェック結果から分かること
確認項目	分かること	それだけでは分からないこと
クライアントに「接続済み」と表示される	クライアントまたはシステムの接続が動作中である	リモート出口が使えること、すべてのアプリの通信が経由していること
ウェブ上で出口IPが変わる	そのウェブページへのリクエストが別のパブリック出口を使った	ほかのアプリやアドレスファミリー、DNSも同じ経路を使っていること
DNSテストの結果が変わる	テスト用ドメインの名前解決を別の再帰DNSサーバーが処理した	すべての通信がプロキシを経由していること
対象アプリにアクセスできる	そのアプリの現在の機能を利用できる	ログイン、メディア、ダウンロードなどの通信がすべてプロキシを経由した
クライアントの接続ログでルールが適用されている	クライアントがリクエストを識別し、経路を判定した	サーバーがリクエストを受け付けたこと、コンテンツを再生できること

まず、何を実現したいのかを明確にしましょう。ルールモードでは、国内サイトは直接接続し、海外サイトはプロキシ経由にする設定が正しい場合があります。特定のアプリの通信をすべてプロキシ経由にしたい場合は、テスト用ページだけでなく、そのアプリに関係するすべてのルールを確認してください。

出口IPを確認する：接続前の状態を記録して比較

出口IPとは、ウェブサイトがリクエストを受信したときに認識する送信元のパブリックIPアドレスです。LAN内で端末に割り当てられたアドレスとは異なります。ブラウザーで「グローバルIPアドレス確認」などと検索し、IPv4とIPv6を区別して表示できるページを選びましょう。テストサービスにもアクセス情報は送信されるため、プライバシーに関する説明を確認してください。サブスクリプションURLやクライアント設定をテストページに送信してはいけません。

プロキシを切断して基準値を記録します。ネットワークを変えずにテストページを開き、パブリックIPアドレス、アドレスファミリー、通信事業者を記録します。ネットワーク側ですでに別のプロキシを使っている場合は、その条件も記録してください。
クライアントを接続し、経路モードを確認します。選択中のノード、システムプロキシやトンネルの設定、ルールモードが想定どおりかを確認します。ノードを選んだだけでは、システム全体への適用が有効になったとは限りません。
テストページに再度アクセスします。ページを更新し、必要に応じてブラウザーを開き直します。シークレットウィンドウを使うと、一部のサイトのキャッシュやログイン状態による影響を減らせますが、プロキシ設定の確認に代わるものではありません。
アドレスを比較し、ルールを確認します。出口が変わった場合、そのリクエストの経路が変わったことを示します。変化がなければ、まずテスト対象のドメインが直接接続のルールに該当していないかを確認し、そのうえで接続の異常を調べます。
利用可能なアドレスファミリーをそれぞれ確認します。IPv4がプロキシ経由でも、IPv6も適用されているとは限りません。IPv6が検出された場合は、接続前の結果と比較してください。

テストページに表示される国や都市はIPアドレスの位置情報データベースに基づくため、情報が古かったり、ノードの表示名と異なったりすることがあります。都市名だけで失敗と判断しないでください。パブリックIPが変わったか、ネットワークの割り当て元が想定どおりか、クライアントに該当するプロキシ接続の記録があるかを確認するほうが有効です。

DNSテスト：名前解決の経路とウェブの出口は別

DNSはドメイン名をIPアドレスに変換します。ウェブ接続はプロキシを経由していても、ドメインの問い合わせはローカルネットワークで処理されることがあります。また、ブラウザーのセキュアDNSが独自に名前解決し、その後ウェブのリクエストをプロキシに渡す場合もあります。これらの経路には関係がありますが、同じものではありません。

一般的なDNSテストページでは、ブラウザーが一時的に生成されたドメインにアクセスし、名前解決に関与した再帰DNSサーバーが表示されます。まず接続を切ってテストし、次に接続して再テストし、DNSサーバーに変化があるか確認しましょう。通常、ページに表示されるのは再帰DNSサーバーの出口であり、端末に直接設定されたDNSサーバーとは限りません。また、プロキシノードと同じ地域にあるとも限りません。

DNSリークかどうかは、想定しているポリシーを基準に判断します。対象ドメインをプロキシ側で名前解決する想定なのに、実際にはローカルネットワークのDNSサーバーへ問い合わせている場合は、原因を調べる必要があります。一部のドメインをローカルで名前解決するルールが設定されているなら、その結果だけで異常とは判断できません。よく知られたパブリックDNSの名前が表示されても、問い合わせが暗号化されているか、プロキシを経由したかは分かりません。

想定外の名前解決結果が出たときに確認する項目

ブラウザーのセキュアDNS：ブラウザーが独自に選んだ暗号化DNSを使う場合、システムDNSとは異なる動作になります。設定を記録してから条件をそろえて比較し、問題を隠すためにセキュリティ機能を常時無効にすることは避けてください。
クライアントのDNSモード：プロキシ側での名前解決、DNSの横取り、Fake IPの利用状況を確認します。Fake IPはクライアント内部のマッピング方式です。仮想アドレスが表示されても、それだけで接続失敗を意味するわけではありません。
システムとネットワークの設定：企業ネットワークのポリシー、ほかのネットワークツール、手動設定したDNSサーバーによって、問い合わせ経路が変わることがあります。
キャッシュ：過去の名前解決結果が一時的に再利用されることがあります。新しいテスト用ドメインを生成するDNSテストを再実行するほうが、同じ一般的なページを何度も更新するより参考になります。

コマンドラインのnslookupは、従来のDNS問い合わせを確認する補助として使えます。ただし、ブラウザーのセキュアDNSの動作を反映するとは限らず、アプリがプロキシ側で名前解決することとも同じではありません。コマンドラインとブラウザーの結果が違っても、すぐにクライアントの動作不良と判断しないでください。

ルールによる振り分けと各プラットフォームでの適用範囲

システムプロキシが影響するのは、通常、その設定に従うアプリだけです。ブラウザーはプロキシ経由でも、ターミナル、ゲーム、ダウンロードソフトは直接接続のままということがあります。TUNモードは仮想ネットワークインターフェースを使って通信を処理するため、適用範囲がより広い傾向にありますが、ルーティング、除外ルール、アドレスファミリー、システム権限の影響を受けます。有効にしただけで確認が不要になるわけではありません。

WindowsとmacOSでは、まずクライアントが有効にしているのがシステムプロキシかネットワークトンネルかを確認し、ブラウザー拡張機能、内蔵プロキシ、ほかのネットワークツールが設定に影響していないかも調べましょう。ターミナルのプログラムはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYなどの環境変数を参照する場合があります。個別の設定が必要なこともあります。

Androidでは、プロキシの適用対象から除外されているアプリがないか、クライアントがシステム接続の許可を得ているかを確認します。iOSでは、想定したネットワーク構成が有効か、クライアントのルールに問題がないかを確認してください。システムに接続中の表示が出ても、すべてのドメインがプロキシ経由に選ばれているとは限りません。

Linuxでは、デスクトップ環境、ターミナル、バックグラウンドサービスがそれぞれ異なるプロキシ設定を使う場合があります。デスクトップの設定でプロキシを有効にしても、サービスのプロセスに引き継がれるとは限りません。問題が起きているプログラム自体で確認し、ブラウザーだけで代用しないでください。

プロトコル名だけでは、適用状況は分かりません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシ接続方式です。アプリの通信がプロキシ経由になるか、DNSをどこで解決するかは、クライアントの実装と設定によって決まります。明示的に直接接続するルールがある場合、プロトコルを変更しても解決しません。

アプリごとに検証し、リクエストがどこで想定経路から外れるか確認

ブラウザーでのテストが通ったら、実際に使いたいアプリを開き、ログイン、メディアの読み込み、ファイルのダウンロードなど、確認したい操作を行います。同時に、クライアントの接続状況画面や診断ログで、該当アプリのドメイン、適用されたルール、最終的な出口を確認してください。画面の名称はクライアントによって異なるため、別のクライアントのメニューをそのまま当てはめる必要はありません。

同じアプリでも、ログイン、画像、メディアに別々のドメインを使うことがあります。トップページが開いても、動画のリクエストがプロキシ経由とは限りません。逆に、サービスが特定の出口を拒否しても、リクエストがプロキシを経由していないとは限りません。アカウントの地域、コンテンツの利用許諾、キャッシュ、端末の位置情報権限、サービス側の制限も結果に影響します。

✅ まず目標を明確にする：対象のアプリと機能、直接接続かプロキシ経由かを決めます。
✅ 一度に変更する設定は一つだけにし、接続前後の結果を記録します。
✅ 適用されたルールと選択中の出口を確認し、目的の操作をもう一度試します。
✅ ブラウザーと対象アプリを別々に確認し、ウェブページの結果を端末全体に当てはめないでください。
❌ ページの言語、検索結果の地域、通信速度だけを根拠にしないでください。
❌ IPv4のテストに成功しても、IPv6やDNSも問題ないとは限りません。

WebRTCによるアドレスの露出が心配な場合は、専用のテストを使い、LAN内のアドレスとパブリックアドレスを区別してください。ブラウザーによっては、ローカルアドレスを隠した形式で表示します。ローカルネットワークの情報が表示されても、パブリック出口がプロキシを迂回したとは限りません。元のネットワークのパブリックIPが表示された場合は、ブラウザーのポリシーとUDP通信の適用状況を確認してください。

接続済みに見えるのに効かない場合の切り分け手順

クライアントの削除や設定の全消去から始める必要はありません。まず現在の設定と接続前の基準値を保存し、次の手順で原因を絞り込みましょう。再現可能な情報を残し、複数の設定を同時に変更して原因が分からなくなるのを防げます。

基本のネットワーク接続を確認します。接続を切った状態で一般的なウェブサイトにアクセスできるかを確認し、ネットワーク認証の未完了やローカルネットワークの障害を先に除外します。
サービスとサブスクリプションの状態を確認します。管理画面でプラン、残りの通信量、サブスクリプション情報を確認してください。サブスクリプションを更新しても、端末側の適用設定が自動的に修復されるわけではありません。
リモートノードに到達できるか確認します。クライアントのエラーメッセージを確認してください。必要であれば利用可能なノードに切り替えて比較します。ただし、クライアント内の遅延テストだけでは、ウェブサイトへのアクセス成功を証明できません。
通信がクライアントに届いているか確認します。システムプロキシ、トンネルの権限、アプリの除外設定を確認してください。対象リクエストの記録がまったくない場合は、まず適用範囲を調べます。
ルールと名前解決の経路を確認します。リクエストが直接接続と判定されていないか、DNSが想定どおりかを確認してから出口を調べます。一時的にルールを変更した場合は、確認後に元に戻し、恒久設定を適切に修正してください。
最後にアプリ側の制限を確認します。出口とルールが想定どおりなのに機能しない場合は、アカウント、キャッシュ、アプリのバージョン、接続先サービスの利用条件を確認してください。

結論：接続アイコンではなく、リクエストの経路で判断しましょう。

出口IPの比較でウェブの通信経路を、DNSテストで名前解決の動作を、アプリでの実測とルールの記録で実際の利用状況を確認できます。複数の情報が一致して初めて、接続が想定どおりだと判断できます。どこかに異常があれば、対応する層に戻って調べ、「接続済み」や「開けない」という表示だけで結論を出さないでください。

VPNEastをご利用の場合、クライアントとサブスクリプションの設定情報はログイン後の管理画面から確認できます。接続設定については使い方ガイドをご覧いただくか、ヘルプセンターをご利用ください。VPNEastはログを保存しないプライバシーポリシーを採用しています。ローカルクライアントの診断情報の生成・保存については、ご利用のクライアントの設定を別途ご確認ください。