VPNの接続確認ガイド｜出口IP・DNS漏れ・アプリ別チェック

VPNの接続確認では、クライアントの接続アイコンだけを見ても十分ではありません。出口IPの変化からはテスト対象の通信が別の出口を使ったか、DNSチェックからは名前解決の経路を確認できます。アプリ別チェックで、使用中のソフトが想定した経路を通っているかを確かめましょう。これらを合わせて確認すれば、正常なルール分岐、プロキシが適用されていない状態、実際の接続障害を見分けやすくなります。

「接続済み」と実際に通信できる状態の違い

「接続済み」の意味はクライアントによって異なります。プロキシのコアが起動した状態を示すもの、システムトンネルの確立を示すもの、ノードの応答まで確認するものがあります。いずれも、それだけでブラウザー、デスクトップアプリ、バックグラウンドプロセスの通信が同じ出口を通っているとは判断できません。

まず、どの範囲の通信を通したいのかを確認します。ルール分岐を使っている場合、中国本土のサイトは直接接続し、指定した海外サイトはプロキシ経由にする設定が正常なこともあります。VPNの対象となる通信をすべて選択した出口に通したい場合は、通信の取り込み方式と例外ルールを確認してください。クライアントの「グローバル」は通常、プロキシコアに入った通信の出口を統一する設定です。すべてのアプリの通信がコアに取り込まれるとは限りません。

確認できたこと	判断できること	まだ判断できないこと
クライアントに「接続済み」と表示される	クライアントが接続中、またはコアが動作中と認識している	対象アプリの通信が取り込まれているか
ブラウザーの出口IPが変わった	そのブラウザーのテスト通信が別の出口を使った	ほかのアプリやプロトコルの通信経路
DNSリゾルバーが設定どおり	今回のテストで確認した名前解決サービスが想定どおり	すべてのドメインとアプリが常に同じ方法で名前解決していること
対象アプリの通信が想定したルールに一致した	該当する通信がクライアントに入り、指定したポリシーが選択された	プラットフォームのアカウント要件、コンテンツへのアクセス権、接続品質の維持

出口IPの確認：まず直接接続時の基準を記録する

出口IPとは、アクセス先のサイトから見えるネットワーク上のアドレスであり、PCがローカルネットワークで使うアドレスではありません。アクセス経路を判断するには、システム設定のローカルアドレスより、ブラウザーで確認した出口IPが適しています。テスト前にネットワーク環境を記録し、Wi-Fiの切り替えや別のプロキシ、ブラウザー拡張機能による変化を今回の接続結果と取り違えないようにしましょう。

基準を記録する。短時間の直接接続が可能で、機密性の高い作業をしていないときにクライアントを一時停止します。信頼できるIP確認サイトを開き、パブリックアドレス、ネットワーク事業者、IPv4とIPv6が別々に表示されるかを記録します。
想定した設定を有効にする。選択した経路に接続し、必要に応じてシステムプロキシまたは仮想NICによる通信の取り込みが有効になっていることを確認します。ルールモードとグローバルモードのどちらを使っているかも記録してください。
もう一度リクエストを送る。確認サイトを再読み込みします。古いキャッシュが表示されているようなら、ページを開き直してください。接続前後のアドレスを比較し、クライアントに該当ドメインの接続記録があるかも確認します。
別の方法でも確認する。別の確認サイトを使って照合します。地域データベースの更新には差があるため、特定の都市名だけで判断せず、IPアドレスが変わったか、通信が想定した出口を使ったかを確認してください。

ルール分岐を有効にしてもIPが変わらない場合は、まず確認サイトが直接接続のルールに一致していないかを確認します。別のテストサイトを使っても変わるのはテスト対象の通信だけです。より確実なのは、クライアントで該当ドメインがどのルールに一致したかを確認することです。切り分けのためにモードを一時変更する場合は、元の設定を記録し、確認後に戻してください。

IPv4とIPv6は別々に確認しましょう。IPv4の出口が変わっても、IPv6の通信まで取り込まれているとは限りません。ただし、クライアントがIPv6転送に対応しておらず、システムにも利用可能なIPv6経路がない場合、ページにIPv6が表示されなくても異常とは限りません。IPv6がローカル側の出口を使っている場合は、システム全体のセキュリティ機能をすぐに無効化せず、クライアントの対応範囲、ルーティング、漏れ防止設定を確認してください。

DNS漏れの確認：国旗ではなく名前解決の経路を見る

DNSはドメイン名をネットワークアドレスに変換します。DNS漏れとは、名前解決のリクエストが想定した保護経路を通らず、ローカルネットワークや別の想定外のDNSサービスに送られる状態を指します。Webページの通信がプロキシ経由でも、DNSだけ別の経路を使うことがあります。「サイトが開く」ことだけではDNSの確認になりません。

信頼できるDNS漏れテストサイトを開き、テストを最後まで実行して、結果に表示されたDNS事業者を確認します。クライアントのDNS設定、システムの名前解決設定、ブラウザーのセキュアDNS設定と照らし合わせましょう。この種のページでは、専用のドメインへのアクセスを通じて、名前解決に参加した再帰DNSサーバーを確認します。端末上のDNS通信をすべて記録した結果ではありません。

接続後もローカル事業者のDNSリゾルバーが表示される場合は、追加確認が必要です。ただし、リゾルバーの所在国だけでDNS漏れと判断することはできません。パブリックDNSは、最寄りの拠点で接続を受け付けたり、別の場所から通信を送出したり、異なる登録情報を使ったりすることがあります。逆に、海外のリゾルバーが表示されても、DNSリクエストが選択したトンネルを通った証拠にはなりません。

✅ 設定を照合：クライアントがリモートDNS、システムDNS、ドメインごとのDNS振り分けのどれを想定しているか確認します。
✅ ブラウザーを確認：セキュアDNSが独自にDNSサービスを選ぶ場合があります。自分のプライバシー方針に合った設定か確認しましょう。
✅ 再テスト：設定を変更したら、システムまたはクライアントの案内に従って関連するキャッシュを消去し、リクエストを再実行します。古い名前解決結果が影響しないようにしてください。
❌ リゾルバーの国旗だけで結論を出したり、一度テストに成功しただけですべてのアプリも問題ないと判断したりしないでください。

暗号化DNSは、端末とDNSサービスの間の問い合わせ通信を保護しますが、DNSサービスから問い合わせ内容が見える場合はあります。また、DNS問い合わせが自動的にVPN経由になるわけではありません。プロキシモードによってはドメイン名がリモート側で処理され、アプリが独自に名前解決することもあります。実際の接続記録とあわせて確認してください。画面にFake-IPと表示される場合、通常はクライアントがドメイン名を対応付けるための内部的な仕組みであり、実際のパブリック出口IPではありません。

アプリ別の確認：ブラウザーが使えても、すべてのアプリが使えるとは限らない

システムプロキシは、設定に従うアプリにHTTPまたはSOCKSプロキシの接続先を提供するもので、あらゆる通信を取り込む汎用スイッチではありません。デスクトップソフト、コマンドラインツール、ゲーム、バックグラウンドサービスの中には、システムプロキシを使わないものがあります。アプリ独自のプロキシ設定を持つものもあります。ブラウザー拡張機能の影響はブラウザー内に限られることがあり、デスクトップアプリの通信経路を確認する根拠にはなりません。

仮想NICモードは通常、システムのルーティングを通じてより多くの通信を取り込みますが、アプリの除外設定、ルートの例外、DNSポリシー、権限、プロトコルの対応状況に左右されます。WindowsやmacOSでは、ほかのネットワークツールがシステムプロキシやルートと競合していないか確認してください。Androidではアプリごとの対象・除外リストを、iOSでは有効なネットワーク設定とクライアントのルールを確認します。クライアントによって機能は異なるため、別のプラットフォームの設定名をそのまま当てはめないでください。

対象アプリで実際の操作を再現する

クライアントの接続パネルまたはログを開き、まず既存の通信を確認します。バックグラウンド更新を対象アプリの通信と取り違えないようにしてください。
対象アプリでコンテンツを更新するか、実際の操作を行います。新たに発生したドメイン、接続先アドレス、適用されたポリシーを確認してください。プロセスを識別できるクライアントでは、プロセス名も照合します。
通信が想定したプロキシグループと経路を選択しているか確認します。直接接続、拒否、意図しない自動選択になっていないかも確認してください。
ルールやプロキシ設定を変更した場合は、保存してから接続し直します。必要に応じて対象アプリを終了して再起動し、既存の長時間接続が以前の経路を使い続けるのを防ぎます。

ログに記録がないからといって、アプリが通信していないとは限りません。ログレベルやフィルター条件、クライアントが記録できる範囲が限られている可能性もあります。まず、ほかの既知の通信がログに含まれているかを確認し、そのうえでアプリ独自のプロキシ設定と通信の取り込み範囲を確認してください。コマンドラインツールがプロキシ環境変数を参照することもあるため、ブラウザーで成功してもターミナルで成功するとは限りません。

Webページ、音声、動画では、使われる通信方式が異なる場合があります。ブラウザーのQUICは通常UDPを利用します。UDPが通信の取り込み対象か、プロキシチェーンが該当する転送に対応しているかを個別に確認してください。テキストページは表示されるのに音声が使えない場合は、ページが読み込めることだけで経路の問題がないと判断せず、プロトコルとルール分岐の対応を確認しましょう。

接続表示だけで通信できないとき：症状から原因を切り分ける

接続中だが、出口IPが変わらない

プロキシコアだけが起動し、システムプロキシが有効になっていない可能性や、テスト対象のドメインが直接接続ルールに一致している可能性を確認します。ブラウザーが別のプロキシ拡張機能を使っていないか、アプリに古い設定が残っていないかも確認してください。複数の通信制御ツールを同時に有効にすると、プロキシの接続先、ルーティング、DNSが互いに上書きされ、原因を特定しにくくなります。

出口IPは変わったが、目的のサービスを利用できない

この場合、すぐにVPNが機能していないと判断することはできません。プラットフォーム側で、アカウントの地域、既存のセッション、IPのリスク判定、サービスの提供地域などを理由にアクセスが制限されている可能性もあります。まず具体的なエラーを記録し、接続タイムアウト、名前解決の失敗、証明書エラー、プラットフォームが明示した権限メッセージを区別しましょう。権限メッセージは、通信障害とは限りません。

サブスクリプションを読み込めたが、通信がすべて失敗する

読み込みに成功したという表示は、クライアントが設定を受け取り、解析できたことを示すだけで、ノードへの接続を保証しません。選択中のノード、サブスクリプションの更新結果、クライアントの互換性を確認してください。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロトコルまたはプロトコル群です。クライアントが設定で使われているプロトコルと関連する転送パラメーターに対応している必要があります。これらはIEPL、中継、直接接続のような通信経路の説明とは別のものです。

IEPL専用線、中継、直接接続は、通信が通るネットワーク経路に関わるもので、アプリの通信取り込みやDNSの確認に代わるものではありません。同じ名称の経路でも、利用するローカルネットワークによって挙動が異なる場合があります。経路の名称だけから、未測定の遅延や安定性を判断しないでください。

確認結果を記録してから設定を変更する

有効な記録には、ローカルネットワーク環境、クライアントのモード、選択した経路、出口IPの変化、DNSテストの結果、対象アプリの具体的なエラー、ルールの一致状況を含めます。一度に変更する要素は一つにし、同じ操作をもう一度行ってください。これにより、経路の変更、ルールの修正、アプリの再接続のどれが改善につながったかを把握できます。

テストを通すために、ファイアウォールをむやみに無効化したり、証明書の警告を無視したり、提供元の不明なルート証明書をインストールしたりしないでください。「軍用レベルの暗号化」は通信保護の表現であり、適切な通信取り込み設定の代わりにはなりません。アクセス先サイトのHTTPS検証、アカウント情報の管理、端末のセキュリティも別途必要です。

VPN接続を確認するための実用的な基準

テスト対象の通信が想定した出口を使い、DNS経路が設定と一致し、対象アプリの実際のリクエストが正しいポリシーに一致して、結果を説明できることが基準です。これらを確認できれば、現在の利用状況で接続が想定どおりに動作していると判断できます。すべてのアプリ、あらゆる時間、各プラットフォームでの利用権限を保証するものではありません。

クライアントの設定を続ける場合は使い方ガイドをご覧ください。プランごとのデータ通信量のルールを確認する場合は料金プランをご覧ください。まず通信経路を確認してから経路を選び、使い心地を比較すると、原因をより簡単に切り分けられます。