VPNが本当に接続されているか確認する方法｜出口IP・DNSのチェックガイド

VPNが有効か確認するには、まず接続前後の出口IPを比較し、次にDNSの問い合わせ経路を確認して、最後に実際に使うアプリで検証します。クライアントの「接続済み」という表示が示すのは、特定の接続状態が成立していることだけです。ブラウザーやターミナルなど、すべてのアプリの通信が想定どおりVPN経由だとは限りません。

判断の基準は、すべての検査結果が同じ地域を示すことではなく、実際の通信経路が設定した内容と一致していることです。ルールベースの振り分けでは、一部のサイトが直接接続になる場合があります。また、システムプロキシがすべてのアプリに適用されるとも限りません。どのアプリとサイトを確認するのかを先に決めてから結果を見れば、正常な振り分けを接続エラーと誤認しにくくなります。

接続状態と実際の通信経路

「接続」の定義はクライアントによって異なります。プロキシコアの起動を示すもの、仮想ネットワークインターフェースの有効化を示すもの、選択したノードへの到達性まで確認するものがあります。状態が正常でも、ルールによって対象サイトが直接接続になったり、アプリがシステムプロキシを使わなかったりすることがあります。

システムプロキシは、対応するアプリにプロキシ設定を提供する仕組みです。TUNモードやシステムVPNモードでは、通常、仮想インターフェースを通じてより多くの通信を処理しますが、ルーティングやアプリの除外設定、クライアントの実装に左右されます。クライアントの「グローバルプロキシ」も、端末全体の通信を引き受けるとは限りません。プロキシコアに渡されたリクエストを一律にノードへ送るだけの場合もあります。

各チェック項目で確認できること
チェック項目	確認できること	それだけでは確認できないこと
クライアントに「接続済み」と表示される	クライアントが接続または通信制御の有効状態を報告している	すべてのアプリが選択したノードを経由していること
ウェブページに表示される出口IPが変わった	そのページへのリクエストの出口が変わったこと	ほかのアプリやDNSも同じ経路を使っていること
DNS検査の結果	テストの問い合わせに使われた再帰DNSリゾルバーの情報	端末全体のすべてのDNS通信経路
クライアントの接続ログ	クライアントに届いたリクエストに適用されたルールと出口	クライアントに届かなかった通信の行き先

そのため、セルフチェックではウェブページの結果と端末上の接続ログを併せて確認しましょう。ログにリクエストが見当たらなくても、ノードの障害とは限りません。アプリが通信をクライアントに渡していない可能性もあります。

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

出口IPとは、接続先のウェブサイトから見えるグローバルIPアドレスで、端末のローカルネットワーク上のアドレスとは異なります。信頼できるグローバルIP確認ページを使い、同じブラウザーとページで確認して、IPアドレス、ネットワーク事業者、地域表示を記録します。確認ページには今回のリクエストのグローバルIPアドレスが伝わります。検査ページにサブスクリプションURLやアカウント情報を入力しないでください。

クライアントの接続を切り、ブラウザーから確認ページにアクセスできることを確かめます。現在のグローバルIPアドレスを記録し、直接接続時の基準にします。
接続先のノードに接続し、クライアントのモードと現在のルールを確認します。確認ページを再読み込みし、必要であれば古いページを閉じてから開き直して、キャッシュや既存の接続による影響を抑えます。
IPアドレスが変わったかを比較し、そのリクエストにクライアントでどのルールが適用されたかを確認します。確認対象のドメインが直接接続に設定されている場合は、ノードの障害と決めつけず、先にテスト条件を調整してください。
もう一度接続を切り、結果が直接接続時の経路に戻るか確認します。地域表示を一度だけ見るより、接続と切断を比較するほうが確かな判断材料になります。

IPアドレスの位置情報はデータベースに基づくため、更新が遅れることがあります。ノード名と確認ページの都市名が完全に一致しなくても、それだけで接続が無効とは判断できません。ネットワーク事業者、実際のIPアドレスの変化、クライアントのログを照らし合わせましょう。また、出口アドレスが変わっても身元が特定されなくなるわけではありません。ログイン中のアカウントやCookie、ほかのアプリのデータから利用状況が関連付けられる可能性があります。

DNSのセルフチェック：リゾルバーと問い合わせ経路

DNSはドメイン名を接続先のアドレスに変換する仕組みです。一般的なDNS検査ページでは、ブラウザーからテスト用ドメインにアクセスし、問い合わせに使われた再帰DNSリゾルバーを特定します。通常、表示されるのはリゾルバーの出口情報であり、端末のグローバルIPアドレスやノードの所在地ではありません。

接続前後で同じ検査ページを使い、リゾルバーの事業者名と結果の変化を記録して、クライアントのDNS設定と併せて確認します。ドメインの名前解決をプロキシ経由にする設定なのに、接続後もローカルネットワークのリゾルバーが表示される場合は、システムDNS、クライアントのDNS制御、ブラウザーの設定を確認してください。ローカルのサイトでローカルリゾルバーを使うルールが明示されているなら、その結果は仕様どおりの場合があります。

ブラウザーのセキュアDNSとシステムDNS

ブラウザーでは、HTTPS経由のDNS（DoH）が有効になっている場合があります。システムの既定リゾルバーを使わないため、ブラウザーでの検査結果がほかのアプリにも当てはまるとは限りません。また、DoHを使っているだけで「ノード経由で名前解決している」とも限りません。接続がプロキシ経由になるかどうかは、アプリのプロキシ方式と振り分けルールによって異なります。

問題を調べるときは、まずブラウザーのセキュアDNS設定を記録し、クライアントのドキュメントと照らし合わせます。影響を理解したうえで一時的に機能を無効にし、結果を比較しても構いません。確認後は元の設定に戻してください。ブラウザーのDNS、クライアントのモード、ノードを同時に変更すると、どの変更が結果に影響したのか分かりにくくなります。

ブラウザーのDNS検査は、WebRTCの検査とは別です。WebRTCはリアルタイム通信や候補アドレスの検出に関わります。検査ページにローカルアドレスや、非表示処理されたホスト名が出る問題は、DNSの問い合わせ経路とは異なります。ブラウザーやクライアントごとの動作をそれぞれ確認し、あらゆるアドレス表示を一括してリークと見なさないようにしましょう。

アプリごとに確認する：ブラウザー・ターミナル・クライアント

ブラウザーでアクセスできても、コマンドラインツールでもアクセスできるとは限りません。ターミナルのプログラムには個別のプロキシ設定や環境変数が必要な場合があり、デスクトップアプリには独自のHTTPまたはSOCKSプロキシ設定があることもあります。コンテナや仮想マシンも独立したネットワークを使う場合があります。ブラウザーだけで確認せず、実際に使う環境からリクエストを送信してください。

✅ ブラウザー：独立したプロキシ拡張機能とセキュアDNSを確認し、対象のリクエストがクライアントの接続ログに記録されているか確認します。
✅ ターミナルツール：ツールのドキュメントと現在のプロキシ環境変数（HTTP_PROXY、HTTPS_PROXY、ALL_PROXY、NO_PROXYなど）を確認し、除外リストによってプロキシを経由しない設定になっていないか確認します。
✅ デスクトップアプリ：システムプロキシとアプリ内プロキシのどちらを使うか確認します。設定を変更した後はアプリを再起動し、古い接続が使われないようにします。
✅ モバイルアプリ：システムVPNの状態、クライアントの振り分け、アプリの除外設定を確認し、実際のアプリで対象の機能を検証します。
✅ コンテナと仮想マシン：内部ネットワークとDNSの設定を確認します。ホスト側での検査結果を内部環境の結果と見なさないでください。

WindowsとmacOSでは、システムプロキシの設定と仮想インターフェースの有効化は異なる通信制御方式です。iOSのクライアントは通常、システムのネットワーク拡張機能を使って設定を構成しますが、実際のルーティングはクライアントの設定によって決まります。Androidのクライアントは、アプリごとの制御に対応している場合、一部のアプリを除外できることがあります。Linuxでは、現在のセッションのプロキシ環境変数とルーティング設定を確認してください。

SOCKSプロキシを使うツールでは、ドメインをローカルで名前解決するのか、プロキシ側に任せるのかも確認します。プロキシアドレスの指定方法はツールによって異なるため、ほかのアプリの設定をそのまま流用できるとは限りません。サブスクリプションのインポート方法は接続ガイドを参照してください。プロキシの具体的な動作については、使用するクライアントとツールのドキュメントを確認してください。

接続済みでも実際には有効でないケース

サブスクリプションを追加したが、利用可能な設定が選択されていない

サブスクリプションURLは、ノードやルールなどの設定を取得するためのもので、通信制御を有効にするスイッチではありません。インポート後は設定が有効になっているか、対象のプロキシグループで想定したノードが選択されているかを確認してください。サブスクリプションを更新するとノード名や選択中のルールが変わることがあるため、再確認が必要です。サブスクリプションURLにはアクセス情報が含まれるため、問い合わせの際に公開しないでください。

振り分けルールによって直接接続になっている

対象のドメインが、直接接続ルール、アプリの除外設定、またはバイパスリストに一致している可能性があります。クライアントの接続ログで該当ドメインを探し、最終的に適用されたルールを確認してください。必要であれば一時的にルールモードを切り替えて比較し、確認後は元の設定に戻します。ルールの変更は原因の切り分けに役立ちますが、設定上の原因を無視したまま使い続けるためのものではありません。

既存の接続や複数のネットワークツールとの競合

ブラウザー、チャットアプリ、開発ツールには既存の接続が残る場合があります。ノードを切り替えた直後は、新しいリクエストと既存の接続が一時的に異なる経路を通ることがあります。対象のアプリを終了してから再起動してください。複数のプロキシやVPNクライアントを同時に動かすと、システムプロキシの上書き、仮想インターフェースのルーティング競合、DNS設定の衝突が起きる可能性もあります。切り分けるときは、確認対象のクライアントだけを動かしてください。

アクセス制限を回線の不具合と取り違えている

出口IPが変わっても対象のサービスにアクセスできない場合、アカウントの地域設定、ログイン状態、サービスのポリシー、出口アドレスの評価などが原因の可能性があります。ページは開けても特定の機能を使えない場合も、帯域だけが原因とは限りません。まず通信経路を確認し、その後にサービス側の制限を調べましょう。診断の代わりにノードを何度も切り替えるのは避けてください。

回線の種類と接続確認

IEPL専線、中継、直接接続は、それぞれ異なる通信経路の構成を示すもので、接続が有効である証明ではありません。専線は通常、特定区間の専用伝送に使われます。中継では中間の入口を経由して転送し、直接接続は通常、クライアントが出口側のサーバーに直接接続することを指します。具体的な区間やルーティングは回線の説明を確認してください。どの種類でも、出口IPとアプリの通信を検証する必要があります。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたはプロトコル体系です。プロトコル名だけからDNSも制御されていると判断してはいけません。実際の動作を決めるのは、クライアントがサブスクリプション内のプロトコルに対応しているか、正しい設定が有効か、どこでドメインを名前解決するか、通信がどのルールで振り分けられるかです。

VPNEPの回線情報はノード一覧で確認できます。回線を選んだ後も、接続前後の結果を自分で比較することをおすすめします。回線名、クライアントの状態、ウェブページの地域表示だけで接続を判断しないでください。

セルフチェックのまとめと問い合わせに必要な情報

問題が解決しない場合は、接続前後の検査結果を保存し、OS、クライアント名、現在のモード、ノード名、対象アプリを記録してください。接続時、名前解決時、ページ読み込み時、ログイン時のどの段階で問題が起きるかを伝えると、「使えない」とだけ伝えるより原因を特定しやすくなります。

サポートページに情報を送る際は、サブスクリプションURL、パスワード、アクセストークン、プライベートドメインを隠してください。クライアントのローカル診断ログと、サーバー側のログポリシーは別のものです。VPNEPの「ノーログ」はサービスのプライバシー方針であり、端末側の設定確認に代わるものではありません。また、第三者の検査ページがリクエスト情報を処理しないという意味でもありません。

最後に、正常に使える設定をひとつ保存しておきましょう。変更する項目は一度にひとつに絞り、検証後は一時的な設定を元に戻します。ノードの変更、DNS設定、アプリのアップデートなどが原因で問題が起きても、接続アイコンに頼らず、同じ方法で通信経路を確認できます。