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

VPNが正しく機能しているか確かめるには、まず目的の通信の出口IPを確認し、次にDNSの名前解決経路、最後に実際に使うアプリを一つずつチェックします。クライアントに「接続済み」と表示されても、ローカルプロキシが起動した、またはトンネルインターフェースが作成されたことを示すだけの場合があります。すべての通信が想定どおり国際回線を通っているとは限りません。

判断基準は、すべてのテスト結果が同じ地域になることではありません。振り分けルールを使っている場合、国内サイトは直接接続し、海外サイトはプロキシ経由にする設定も可能です。この記事では、検査ページの表示色ではなく、通信が設定どおりに流れているかを確認します。

接続状態と通信経路を区別する

一般にVPNクライアントと呼ばれるソフトには、システムVPNトンネルを使うものと、システムにプロキシ設定を書き込むだけのものがあります。システムプロキシを利用するのは、通常、その設定を参照するアプリに限られます。ゲームやコマンドラインツール、独自のネットワーク設定を持つソフトは、プロキシを使わないことがあります。TUNモードやシステムVPNモードなら、より多くの通信を処理できますが、実際の範囲はルーティング、アプリの除外設定、プロトコルの対応状況によって異なります。

プロキシプロトコルの名称だけでは、通信経路を確認できません。Shadowsocks、VMess、Trojan、VLESSなどは、クライアントとサーバーの適切な連携が必要です。DNSを処理するか、UDPを転送するか、どのアプリを直接接続するかは、実装や設定によって決まります。サブスクリプションをインポートしてノード名が表示されても、システム権限やプロキシの有効化、振り分けルールまで整っているとは限りません。

表示された状態	確認できること	追加で確認すること
クライアントに接続済みと表示される	クライアントが接続またはローカルサービスの起動を報告している	目的の通信がクライアントに届き、正常に転送されているか
ブラウザーの出口IPが変わった	そのWebリクエストが別の出口を使った	ほかのアプリやアドレスファミリーも設定どおりか
DNSテストで海外のリゾルバーが検出された	テスト用ドメインの名前解決に、これらのリゾルバーが関与した	リゾルバーまでの通信経路が想定どおりか
アプリから海外サイトを開ける	現在の条件で対象サービスにアクセスできる	元から直接接続できたのではなく、指定した回線を経由したか

出口IP：同じ環境で比較する

信頼できるパブリックIP確認サイトを選び、接続前後のIPアドレス、アドレスファミリー、ネットワークの所属情報を記録します。パブリックIPと、端末のローカルネットワーク上のIPアドレスは別物です。ルーターがパソコンに割り当てたプライベートIPは、プロキシを有効にしても通常変わりません。確認のために、提供元が不明なブラウザー拡張機能をインストールしないでください。

接続前の状態を記録します。クライアントを一時的に切断し、ほかのプロキシツールをオフにして、同じブラウザーで確認サイトを開きます。現在のパブリックIPと出口情報を保存してください。
接続先の回線を選びます。クライアントに必要な権限が付与されていることを確認し、ルールモード、グローバルプロキシ、トンネルモードのどれを使っているかチェックします。
もう一度アクセスします。確認ページを再読み込みします。必要に応じて古いタブを閉じて開き直し、ページの古い情報や長時間接続による誤判定を防ぎます。
適用されたルールを確認します。クライアントの接続一覧を見て、確認サイトのドメインがプロキシと直接接続のどちらに振り分けられたかを確認してから、IPの変化を判断します。
実際の用途でも確認します。IP確認サイトだけでなく、利用する予定のWebサイトやアプリを開き、通信経路をチェックしてください。

ルールによって確認サイトが直接接続に振り分けられている場合、IPが変わらなくてもクライアントが機能していないとは限りません。確認中だけそのドメインを目的のプロキシに割り当て、比較後に元の設定へ戻す方法もあります。「グローバルプロキシ」も、クライアントに届いたリクエストをすべてプロキシ経由にするだけの場合があり、端末上の全アプリを必ず処理するわけではありません。

出口に表示される地域とノード名が一致しない場合は、まずIPアドレスとネットワークの所属情報を確認します。位置情報データベースの更新が遅れていたり、サイトによって結果が異なったりすることがあります。ノードの入口、中継経路、パブリックIPの出口はそれぞれ別の概念です。地域表示だけで回線障害と判断しないでください。

DNSの漏えい：地域だけでなく経路を確認

DNSはドメイン名をIPアドレスに変換します。ここでいう漏えいとは、本来は指定した経路で保護するはずのDNSリクエストが、想定外の経路から送信されることです。たとえば、対象ドメインの問い合わせをトンネル経由にしたいのに、実際は利用中のネットワークのリゾルバーへ直接送られるケースです。問題かどうかは、振り分け設定とプライバシー上の目的を確認して判断します。

DNSテストサイトでは通常、ブラウザーから一時的なテスト用ドメインにアクセスし、名前解決に関与した再帰リゾルバーを確認します。表示されるのはリゾルバーの情報であり、端末上のすべてのDNS通信を完全に取得した結果ではありません。リゾルバーが国内にあっても、問い合わせがトンネルを通らなかったとは限りません。海外のリゾルバーが表示されても、そこまでの通信がプロキシ経由だったとは断定できません。

ブラウザーのセキュアDNSとクライアントのDNS設定は異なる場合がある

ブラウザーでDoHなどのセキュアDNSを有効にすると、OSの名前解決設定を完全には使わず、ブラウザーが暗号化されたリクエストを独自に送信することがあります。暗号化は通信中の問い合わせ内容を保護しますが、プロキシ経由を保証するものではありません。ブラウザーのポリシー、クライアントのルール、DNSサービスへの実際の通信経路を合わせて確認してください。

テスト後に元へ戻せるよう、OS、ブラウザー、クライアントのDNS設定を先に記録します。
回線に接続してDNSテストを実行し、リゾルバーの所属情報を確認します。クライアントのログも参照して、該当リクエストの経路を確かめてください。
結果に問題がある場合は、一時的にブラウザーとクライアントの名前解決設定を統一して再テストします。関係のない設定を同時にいくつも変更しないでください。
設定変更後は、関連アプリを再起動するかDNSキャッシュを消去し、古い名前解決結果が変更を隠さないようにします。

一部のクライアントはFake-IPを使い、アプリに合成アドレスを渡したあと、クライアント側でドメインと対応付けて転送します。この場合、システムに表示される名前解決結果は、接続先サーバーの実際のアドレスとは限りません。通常のDNS結果だけで障害を判断しないでください。また、コマンドラインのDNS確認ツールが別の経路を使う場合もあり、ブラウザーのDoHの動作を示すとは限りません。

アプリ別に確認する：ブラウザーだけでは不十分

パソコンでは、ブラウザー、デスクトップアプリ、ターミナルの各プログラムが、システムプロキシ、アプリ内プロキシ、直接接続のいずれを使うか異なる場合があります。WindowsやmacOSでシステムプロキシを有効にしても、すべてのプログラムがその設定を参照するとは限りません。Linuxではデスクトップの設定、ターミナルの環境変数、アプリ固有のオプションがそれぞれ影響することがあります。実際に使うソフトを対象にテストしてください。

Androidのクライアントには、アプリごとにVPNの対象に含める、または除外する設定が用意されている場合があります。対象アプリが除外されていないか確認してください。iOSでは、システムVPNの設定と、特定のネットワークだけに適用されるプロキシ設定を区別します。実際の適用範囲は、クライアントの実装や設定、OSのポリシーによって異なります。あるプラットフォームでの操作経験から、ほかのプラットフォームも同じだと決めつけないでください。

✅ ブラウザー：実際に利用するサイトを開き、クライアントの接続一覧でドメイン、適用ルール、出力先の回線を確認します。
✅ デスクトップのコラボレーションツール：接続し直して同期やコンテンツの読み込みを行い、該当するプロセスやドメインがクライアントに表示されるか確認します。
✅ コマンドラインツール：プログラムがプロキシ環境変数を参照するか、トンネルに取り込まれているかを確認します。ブラウザーの結果で代用することはできません。
✅ リアルタイム通信・ゲーム：ログイン、音声通話、実際のセッションを個別に確認します。Webページにログインできても、UDP通信まで通っているとは限りません。
❌ 総通信量のカウンターだけを見る：バックグラウンド更新でも通信量は増えます。カウンターの増加だけでは、対象アプリが指定回線を使った証拠になりません。

クライアントにプロセス名ではなくドメイン名だけが表示される場合は、関係のないアプリをいったん終了し、対象の操作を実行して新しい接続を確認します。既存の長時間接続は以前の経路を使い続けることがあります。ノードを切り替えた後はセッションを再確立してください。テスト時刻と操作内容を記録すると、ノードを何度も切り替えるより原因を特定しやすくなります。

よくある問題：確認材料をもとに調べる

接続済みと表示されるが、対象アプリのリクエストがない

まず、システムプロキシがほかのソフトに上書きされていないか、トンネルの権限が許可されているか、対象アプリが除外リストに入っていないか、アプリ独自のプロキシ設定がないか確認します。この場合、端末からクライアントまでの区間に問題がある可能性があります。リモートノードを変えても解決しないことがあります。

リクエストは確認できるが接続に失敗する

ルールで選択された出力先、ドメインの名前解決結果、具体的なエラーを確認します。サブスクリプションの期限切れや設定更新の失敗、プロトコルの非対応、接続先サービスによる拒否なども、同様の症状につながります。サブスクリプションURLにはアクセス認証情報が含まれるため、信頼できる管理画面から取得し、対応クライアントにインポートしてください。公開の場に貼り付けないでください。

Webページは使えるが、音声通話やゲームに問題がある

まず、クライアントのモードと回線が必要なUDP転送に対応しているか確認し、次にアプリ側のプロキシ対応とネットワーク権限を調べます。TCPを使うWebページが開けても、リアルタイム通信の経路が正常とは限りません。プロキシを経由していても、パケットロスや遅延の揺らぎ、接続先サーバーの負荷、ローカルの無線ネットワークが影響する場合があります。

IPは変わったが、接続先のサービスを利用できない

アカウントの地域設定、コンテンツの利用許諾、出口IPの評価、サーバー側のリスク判定、キャッシュなどが原因の可能性があり、プロキシが機能していないとは限りません。「通信が回線を経由したか」と「接続先サービスがアクセスを許可したか」は分けて判断してください。確認サイトを何度も再読み込みしても、接続先サービスが表示するエラーの代わりにはなりません。

検証結果とプライバシーの範囲

ブラウザーのWebRTCテストは補助的に使えますが、プライベートネットワークの候補アドレスとパブリックIPの出口を区別してください。ブラウザーがmDNS名を使い、ローカルアドレスを隠すこともあります。プライベートアドレスの候補が表示されても、Webサイトに元のパブリックIPが知られたとは限りません。想定外のパブリックIP候補が見つかった場合は、ブラウザーの設定、UDP通信の処理状況、実際の接続をあわせて確認してください。

同様に、IPやDNSのテストだけでは、サービス提供者がログ方針を守っているか確認できません。また、ログイン済みアカウント、Cookie、ブラウザーの特徴によるアクセス者の識別も防げません。VPNTeeは「ログを記録しない」方針を掲げていますが、これはサービスの運用方針であり、テストを一度実行するだけで匿名性が証明されるわけではありません。

まとめ：VPNが機能しているかは、出口IP、DNSの経路、対象アプリの実際の接続を照らし合わせて判断します。すべてのテスト結果が同じ地域になることより、振り分け設定どおりの結果になっていることが重要です。結果が一致しない場合は、まず通信の対象範囲、次にルールと名前解決、最後にリモート回線と接続先サービスを確認してください。

OSやクライアントの更新、サブスクリプションの更新、ネットワークの切り替え後にも、同じ手順で再確認すると安心です。クライアントへのインポート方法や権限設定はクイックスタートをご覧ください。設定について不明な点がある場合は、サポートページで引き続き確認できます。