VPNが本当に有効か確認する方法：IP・DNSを調べる初心者向け完全セルフチェック

VPNが本当に有効かどうかは、クライアントに「接続済み」と表示されているかだけでは判断できません。この表示で確認できるのは通常、クライアントがハンドシェイクを完了したことだけです。ブラウザやコマンドラインツール、その他のアプリの通信までトンネルを通っている証明にはなりません。確実に確認するには、切断時の基準値を記録し、出口IP、DNS、IPv6、システムルート、アプリごとの振り分けを順に確認します。

最も実用的なのは、「ワンクリックで合格」と表示される結果を探すことではなく、接続前後を同じ条件で比較する方法です。同じ端末、同じネットワーク、同じ検査ページを使い、切断時と接続時の差を記録します。出口アドレスだけ変わってDNSがローカルネットワークのままなら、Web通信と名前解決が別経路を通っている可能性があります。ブラウザだけ変化して他のアプリが変わらない場合は、システムプロキシ、TUNモード、アプリごとのルールが関係していることが多いです。

まず未接続時のネットワーク基準値を記録する

確認前にクライアントを完全に切断し、他のプロキシ、ブラウザ拡張機能、古い接続が動作していないことを確認します。本サイトの IPチェックページを開き、現在の出口IPのネットワーク事業者、国または地域、アドレスの種類を記録してください。ここで重要なのは、基準値そのものが正常かどうかではなく、「比較」することです。

続いて、現在使用しているDNSリゾルバーを確認します。検査ツールによってリゾルバー名や地域の判定が異なる場合があるため、地図上の位置だけを見ないでください。より重要なのは、そのリゾルバーがローカルネットワークの事業者やルーター、あるいは以前手動で設定したパブリックDNSに属しているかどうかです。

• ✅ クライアントを切断してIPチェックページを更新し、出口ネットワークと地域を記録する。
• ✅ 通信を個別にプロキシする可能性のあるブラウザ拡張機能を無効にし、古い設定が基準値に影響しないようにする。
• ✅ DNSリゾルバー名を記録し、地域のずれだけでリークと判断しない。
• ✅ 端末が想定したネットワークに接続されていることを確認し、ネットワーク切り替えによる出口の変化を除外する。
• ✅ 検査ページを残し、接続後も同じページで再テストする。

接続後に出口IPが切り替わったか確認する

クライアントを起動して回線を選び、状態が安定するまで待ちます。その後、元の検査ページに戻って再読み込みしてください。全体トンネルモードでは、公開出口は通常、ローカルネットワークの出口から選択した回線に対応する出口ネットワークへ切り替わります。アドレス、ネットワーク事業者、地域に期待どおりの変化がなければ、まず「有効になっていない」として扱い、クライアントのアイコンだけを信頼しないでください。

出口IPの変化は必要な確認ですが、それだけで結論にはなりません。ブラウザが拡張機能やシステムプロキシ経由で回線に入り、他のアプリは直接接続を続ける場合があります。反対に、TUNを有効にすると大部分のシステム通信がトンネルに入っていても、ルールで直接接続に指定されたWebサイトにはローカルの出口が表示されます。テスト前に、クライアントが現在グローバルモード、ルールモード、直接接続のどれを使っているかを確認してください。

1つのWebページだけを確認しても不十分な理由

システムプロキシの影響を受けるのは、主にシステムのプロキシ設定を読み取るアプリです。一部のコマンドラインツール、ゲーム、アップデートプログラム、独自のネットワークスタックを使うソフトウェアは、この設定を無視する場合があります。TUNモードは仮想ネットワークインターフェースを作成し、システムルートを通じてより多くの通信を引き受けますが、除外ルール、インターフェースの優先順位、システム権限の影響を受けることがあります。

ブラウザ拡張機能の適用範囲はさらに狭く、通常はそのブラウザ内のリクエストだけを処理します。Webページの出口が変わったからといって、端末全体がトンネルに入ったとは判断できません。他のアプリも保護したい場合は、クライアントでシステムプロキシまたはTUNが有効か、対象アプリが迂回リストに入っていないかを確認してください。

DNSが想定した経路で名前解決しているか確認する

Webサイトにアクセスすると、端末は通常、まずドメインをDNSリゾルバーに渡し、解決されたサーバーアドレスへ接続します。Webデータがトンネルを通っていても、DNSクエリはブラウザ、セキュリティソフト、OS、ローカルネットワークによって別々に処理される場合があります。いわゆるDNSリークで確認するのは、名前解決のリクエストが意図した経路から外れていないかどうかです。

回線に接続した後、DNS検査を実行し、基準値と比較します。クライアントがDNSをトンネルで処理すると説明しているのに、ローカルネットワーク事業者のリゾルバーが表示される場合は確認が必要です。パブリックDNSや回線側が提供するリゾルバーが表示された場合は、リゾルバーの所在地が回線地域と異なるだけで異常とは判断できません。パブリックDNSはエニーキャストネットワークで広く運用されており、検査データベースが同じサービスを別の地域として表示することもあります。

ブラウザの暗号化DNSで結果が変わる場合

一部のブラウザでは暗号化DNSを個別に有効化できます。有効にすると、ドメインリクエストがOSの標準リゾルバーを経由せず、ブラウザに設定されたサービスへ直接送られる場合があります。これは必ずしもリークを意味しませんが、ブラウザと他のアプリが異なる名前解決経路を使うことになります。確認時はブラウザのセキュアDNS設定を確認し、現在の要件に合っているか判断してください。

すべてのアプリのDNSをクライアントで統一して処理したい場合は、まずブラウザ独自の名前解決を一時的に無効にして、再度検査します。無効化後に結果が正常に戻るなら、問題は通常、ノードのプロトコルではなくブラウザ設定にあります。それでもローカルネットワークを指す場合は、クライアントのDNS引き受け、TUN権限、システムのネットワーク設定を続けて確認してください。

IPv6、WebRTC、振り分けルールを確認する

一部のネットワークはIPv4とIPv6の両方を提供しています。クライアントがIPv4だけを引き受け、OSがIPv6を優先して接続すると、IPv4は回線から、IPv6はローカルネットワークから出るという2種類の出口が現れることがあります。これは一般にIPv6リークと呼ばれます。

対処方法はクライアントの機能によって異なります。完全なデュアルスタックTUNに対応するクライアントなら、両方の通信を同時にルーティングできます。接続中に引き受けていないIPv6を無効にするクライアントもあれば、OSのネットワーク設定で個別に対処する必要があるものもあります。影響を把握しないままシステム設定を長期的に変更しないでください。まずクライアント設定を更新し、TUNとDNSの項目を確認してから、必要に応じてクライアントのドキュメントに沿ってシステムネットワークを調整するのが安全です。

WebRTCはブラウザのリアルタイム通信機能です。検査ページにローカルインターフェースのアドレス、仮想インターフェースのアドレス、匿名化された候補アドレスが表示されることがあります。ローカルネットワークのアドレスが見えたからといって、公開出口がリークしたとは限りません。ローカルアドレスだけでは外部アクセス経路を直接示せないためです。確認の中心は、本来表示されるべきでない公開の直接接続出口が露出していないかどうかです。

振り分けによってWebサイトごとに異なる出口が表示される

ルールモードでは、ドメイン、IP、アプリ、ルールセットに応じて回線経由か直接接続かを決めます。たとえばローカルサービスは直接接続し、国際的なWebサイトは回線経由にできます。この場合、2つの検査ページで出口が異なっても、必ずしも故障ではありません。それぞれが異なるルールに一致している可能性があります。

振り分けを確認するときは、まずクライアントを一時的にグローバルモードへ切り替え、出口とDNSを再確認します。グローバルモードは正常でルールモードだけ異常なら、接続やノード自体はおおむね利用可能で、問題はルールの一致判定にある可能性が高いです。次にクライアントの接続ログを確認し、検査用ドメインがプロキシ、直接接続、拒否のどのルールに一致したかを確認します。

1. 現在の接続を切断し、IPとDNSの基準値を記録する。
2. グローバルモードを有効にして、同じ回線へ再接続する。
3. 同じ検査ページを更新し、出口、DNS、IPv6を確認する。
4. ルールモードに戻し、結果が変化するか確認する。
5. 接続ログでドメインの一致先と最終的な送信先を確認する。
6. ルールを修正したら再テストし、古いページの結果を新しいリクエストの代わりにしない。

プラットフォームごとにルートが実際に変わったか確認する

プラットフォームによってクライアントに与えられるネットワーク権限が異なり、確認方法も完全には同じではありません。WindowsとmacOSでは通常、システムプロキシと仮想ネットワークインターフェースの2種類が併存します。Linuxではルーティングテーブル、ポリシールーティング、DNSサービスを直接確認することが多く、iOSとAndroidは主にOSが提供するVPNインターフェースを介して動作するため、アプリ側から確認できる低レベルのルート情報は限られます。

Windows

クライアント内で現在のモードを確認します。システムプロキシだけを有効にしている場合、ブラウザは正常でもプロキシ設定を無視するプログラムは直接接続を続けることがあります。より広い範囲をカバーするには、クライアントがTUNに対応しているか、また有効になっているかを確認し、仮想インターフェースがセキュリティソフトに阻止されていないことも確認してください。ターミナルで次のコマンドを実行すると、ルーティングテーブルを確認できます。

route print

クライアントが作成した仮想インターフェースが存在するか、デフォルトルートまたは対象ネットワークがそのインターフェースを指しているかを確認します。ルーティングテーブルの内容はクライアントの実装によって異なるため、インターフェース名だけで判断しないでください。接続ログや出口検査と併せて確認する必要があります。

macOSとLinux

macOSではシステムのネットワーク設定からプロキシの状態を確認でき、ルーティングテーブルにトンネルインターフェースが現れているかも確認できます。Linuxはデスクトップ環境、ネットワーク管理サービス、コマンドラインクライアントの組み合わせが多いため、ポリシールーティングとDNSサービスが同時に更新されているか特に注意してください。

netstat -rn
ip route

macOS環境では通常、前のコマンドでルートを確認し、Linuxでは後のコマンドを使います。クライアントが透過プロキシを採用している場合、システムのファイアウォールルールで通信をリダイレクトすることもあります。その場合、デフォルトルートだけでは全経路を把握できないため、クライアントのログも併せて確認してください。

iOSとAndroid

モバイル端末では通常、システムレベルのVPN状態が表示されますが、状態アイコンが示すのはOSのインターフェースが確立したことだけです。接続前後で同じIP検査ページを使って比較し、アプリごとの迂回、選択したアプリだけをプロキシする設定、ローカルネットワークへの直接接続などが有効になっていないか確認してください。

ネットワークを切り替えた後も接続状態が維持されているのにWebページへアクセスできない場合は、いったん切断してトンネルを再確立します。ネットワークインターフェースの変更で古いセッションが無効になっても、クライアント画面の更新が遅れることがあります。特定のアプリだけが常に直接接続する場合は、そのアプリがアプリごとのルールで除外されていないか確認してください。

プロトコル、サブスクリプション、回線種別だけでは検証の代わりにならない

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれもプロキシ通信を運べますが、プロトコル名だけでシステム通信がトンネルに入ったとは証明できません。Shadowsocksは暗号化プロキシプロトコルです。VMessとVLESSは複数の伝送方式に対応するクライアントでよく使われます。Trojanは通常、TLSに見える形で接続を運びます。Hysteria2とTUICはQUIC系の伝送設計に基づき、複雑なネットワーク環境での通信性能を重視します。

これらのプロトコルが解決するのは、クライアントとサーバーの間でデータをどう伝送するかという問題です。システムプロキシ、TUN、DNSの引き受け、振り分けルールが決めるのは、「どのリクエストをこの接続へ渡すか」です。ノードのハンドシェイクに成功しても、クライアントがサーバーと通信できたことしか示しません。アプリが該当する送信先へルーティングされていなければ、ローカルネットワークを使い続ける可能性があります。

サブスクリプションURLも設定を配布する入口にすぎません。インポートすると、クライアントはノード、名前、関連パラメータを取得しますが、利用可能なノードを選び、接続を確立し、適切なシステム側の引き受け方式を有効にする必要があります。サブスクリプションの更新成功は現在のノードへの接続を意味せず、ノードを選択しただけでシステムプロキシやTUNが有効になるわけでもありません。

IEPL専線、中継、直接接続は、クライアントから回線出口までの上流経路を表します。直接接続では通常、端末が遠隔の入口へ直接接続します。中継ではまず中間ノードに入り、そこから出口へ転送します。IEPL専線は通常、事業者側の国際伝送回線を重視した方式です。どの上流経路でも、ローカルでの確認方法は同じです。リクエストがクライアントに引き受けられているか、出口が想定どおりか、DNSが設定どおり処理されているかを確認してください。

接続済みに見えるのに有効にならない主な原因

クライアントに接続済みと表示されるのに検査結果がローカル出口のままなら、次の順番で対処します。一度に1項目だけ変更し、そのたびに再接続してテストしてください。複数の設定を同時に変更すると、原因を特定しにくくなります。

• ❌ ノードを選択しただけで、システムプロキシまたはTUNを有効にしていない。
• ❌ ブラウザ拡張機能は接続しているが、他のアプリはその拡張機能の対象外である。
• ❌ 検査サイトが振り分けルールで直接接続に指定されている。
• ❌ 対象アプリがアプリごとの迂回リストに入っている。
• ❌ システムに古いプロキシ設定が残り、通信が別のローカルポートへ渡されている。
• ❌ TUNに必要な権限が許可されておらず、仮想インターフェースが正しく作成されていない。
• ❌ IPv4は回線に入っているが、IPv6はローカルネットワークから直接外部へ出ている。
• ❌ ブラウザ独自のDNS設定とクライアントのDNSポリシーが一致していない。
• ❌ ネットワーク切り替え後に古いセッションが無効になり、クライアントの状態がまだ更新されていない。
• ❌ 複数のクライアントが同時にシステムプロキシやルートを変更し、設定が上書きされている。

複数のクライアントが競合している場合は、まずすべてを切断し、使用していないクライアントを終了してから、システムプロキシを整理して再接続します。クライアントを切り替える前に現在の接続を切断すると、古い仮想インターフェース、古いDNS、残存するプロキシ状態の影響を抑えられます。

特定のWebサイトだけアクセスできない場合、すぐに回線全体の障害だと判断しないでください。まず他のWebサイトをテストし、DNSが名前解決できるか、接続ログが拒否ルールに一致していないか、サイト側が現在の出口を制限していないかを確認します。回線全体の障害なら複数の対象に影響することが多く、単一サイトの異常は振り分け、名前解決、出口制限、サイト自身の状態が原因である可能性が高いです。

再現可能な完全セルフチェック手順を作る

安定した検証手順は繰り返し実行でき、各ステップで明確な結論を出せるものでなければなりません。まず接続を切断して基準値を作り、次にグローバルモードで回線の基本機能を確認し、その後で普段の振り分けに戻します。これにより、ノード、システム側の引き受け、ルールの問題を分けて対処できます。

1. 他のプロキシと拡張機能を無効にし、クライアントを切断する。
2. ローカルの出口ネットワーク、地域、DNS、IPv6の状態を記録する。
3. 対象の回線に接続し、システムプロキシまたはTUNが有効になっていることを確認する。
4. 同じページで出口IPを再確認する。
5. DNS検査を実行し、リゾルバーの所属を確認する。
6. IPv6がトンネルに入っているか、正しく処理されているか確認する。
7. ブラウザと実際に使用するアプリをそれぞれテストする。
8. 振り分けルールを戻し、対象ドメインがどの送信先に一致したか確認する。
9. ネットワークを切り替えた後は重要な確認を再実行し、古い結論をそのまま使わない。

最終判断は、1つの緑色の表示ではなく、複数の結果が一致しているかで行います。出口IPは現在のリクエストがどこからインターネットへ出ているかを示し、DNSは誰がドメインを解決しているかを示します。IPv6の確認でデュアルスタックの経路を補い、アプリのテストで振り分け範囲を検証できます。4項目すべてが現在の設定に合って初めて、VPNが想定どおり有効になっていると判断しやすくなります。