VPNの接続を確認する方法：IPアドレス・DNS・アプリ別にチェック

VPNの接続状態と通信経路を分けて確認する

VPNの接続を確認するには、IPアドレス・DNS・アプリ別の経路をそれぞれ調べます。接続表示で分かるのは、クライアントが何らかの接続状態にあることだけです。対象アプリの通信を処理しているか、DNS問い合わせがどこへ送られるか、出口が想定どおりかは、実際の通信で確認する必要があります。

プロキシクライアントとシステム全体のVPNでは、通信を処理する範囲が異なる場合があります。システムプロキシは、その設定に従うアプリにプロキシの接続先を提供するもので、すべてのプログラムに使用を強制するわけではありません。ブラウザー拡張機能の影響も、通常は該当ブラウザーに限られます。TUNモードは仮想ネットワークインターフェースとルーティングを通じて、条件に合う通信を処理しますが、除外アプリ、ルール、アドレスファミリーの設定に左右されます。「ブラウザーで開けた」ことだけで端末全体の動作を判断すると、こうした違いを見落とす可能性があります。

テストの前に確認したい目的を決めておきましょう。特定のアプリだけ国際回線を使うのか、通常の通信をすべてトンネルに通すのかを明確にします。ルールモードで指定サイトを直接接続する設定は、必ずしも障害ではありません。実際の経路が設定した目的と異なる場合に、詳しく調べます。

出口IPアドレス：接続前後を比較する

出口IPアドレスとは、接続先のウェブサイトから見える通信元です。端末のローカルIPアドレスとは異なり、サブスクリプション設定に記載されたサーバーアドレスと同じとも限りません。設定上のアドレスが中継用の入口で、実際の出口は別の場所にある場合があります。同じツール、同じブラウザー、同じネットワーク環境で結果を比較してください。

1. クライアントの接続を切り、ブラウザーのプロキシ拡張機能も一時的に無効にします。信頼できるグローバルIP確認ツールで、現在の出口、ネットワーク事業者、IPv4とIPv6が個別に表示されるかを記録します。
2. 利用する回線に接続し、目的に応じてシステムプロキシまたはTUNが有効になっていることを確認します。ルールモードの場合は、確認ツールのドメインにプロキシルールが適用されているかも調べます。
3. あらためて確認を実行します。以前開いたタブの結果だけで判断しないでください。必要に応じて新しいブラウザーセッションを使い、キャッシュや既存の接続による影響を除きます。
4. クライアントの接続ログを開き、確認ツールへのリクエストに適用されたルール、ポリシーグループ、実際の出口回線を照合して、確認結果と比較します。
5. 出口の地域が異なる回線に切り替えてから、もう一度確認します。結果が変わらない場合は、回線の障害と決めつけず、まず通信の処理範囲とルールを調べます。

国や地域の表示は、あくまで参考情報です。IPアドレスの位置情報データベースは更新が遅れる場合があり、確認ツールによって結果が異なることもあります。同じ地域にある複数の回線が出口を共有している場合もあります。より確かな確認方法は、リクエストログで選択したポリシーが適用されたことを確認し、表示されたネットワーク事業者情報がその回線の出口と一致するか照らし合わせることです。応答速度だけでは出口を確認できません。

IPv4の出口は変わったのにIPv6がローカルネットワークのままの場合は、クライアントがIPv6を処理しているか、アプリがIPv6を優先していないかを確認します。すべての通信を処理したい場合は、クライアントのドキュメントに従ってIPv6ルートを設定するか、対応する保護機能を使用してください。IPv4だけを調べるページでは、IPv6の経路は分かりません。

DNSの漏れ：名前解決の経路を確認する

DNSは、ドメイン名をIPアドレスに変換する仕組みです。ブラウザーの通信はプロキシ経由でも、名前解決はローカルネットワークのDNSリゾルバーに送られることがあります。プロキシ側で名前解決される場合もあります。ここでいう「DNS漏れ」は、想定する経路に照らして判断します。対象のDNS問い合わせを管理されたトンネルに通す設定なのに、ローカルのリゾルバーへ送信されている場合は、設定した経路から外れています。

回線に接続した状態で、信頼できるDNS検査ツールを使ってテストし、表示されたリゾルバーとネットワーク事業者情報を記録します。この種のツールは、専用のテスト用ドメインを利用して再帰DNS問い合わせの送信元を調べます。表示されるのは名前解決に関与したサーバーであり、ウェブサイトへの通信の出口ではありません。リゾルバーと出口の地域が異なるだけでは、DNS漏れとは判断できません。

ブラウザーのセキュアDNS、システムDNS、クライアントのDNS、アプリ内蔵の名前解決機能が同時に使われる場合があります。セキュアDNSは暗号化してDNSサービスに接続することが多いものの、「暗号化」されているからといって自動的にVPN経由になるわけではありません。ブラウザーがシステムのリゾルバーを使わない場合もあるため、ブラウザーの検査結果がすべてのアプリに当てはまるとは限りません。

• まずクライアントとブラウザーのDNS設定を記録し、どのリゾルバーを使う想定か、DNS問い合わせをプロキシ経由または直接接続のどちらにするかを明確にします。
• クライアントで、直接接続するドメインとプロキシ経由にするドメインのDNS経路が個別に設定されているか確認します。ルールによる振り分けでは、ローカルドメインの問い合わせをローカルのリゾルバーに送る設計もあります。
• 経路の違いを調べるため、ブラウザーのセキュアDNS設定を一時的に変更して検査を繰り返す方法があります。一度に変更する設定は一つだけにし、テスト後は必要な設定に戻してください。
• クライアントにDNSログ機能があるか確認し、キャッシュからの応答、プロキシ側での名前解決、クライアント内での名前解決、実際に送信された問い合わせを区別します。

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

アプリごとの確認では、対象アプリから新しいリクエストを発生させます。先にクライアントの接続ログを開き、テスト対象のアプリを再起動して、プロキシが必要な機能やページにアクセスします。リクエストの時刻、対象ドメイン、適用ルール、ポリシーを照合してください。ログがない場合は、「開けた」という理由だけで経路を判断できません。そのサービスが通常どおり直接接続できる場合や、キャッシュの内容を表示している場合もあります。

WindowsやmacOSでは、システムプロキシに従わないプログラムがあります。その場合は、プログラム自体のプロキシ設定を使うか、クライアントのドキュメントに従ってTUNを有効にします。仮想ネットワークインターフェースの作成に権限が必要な場合もあるため、使用するクライアントの案内を確認してください。コマンドラインツールでは、専用のプロキシ引数や環境変数が必要なこともあります。システムプロキシが動作していても、ターミナルからの通信が同じ経路になるとは限りません。

Androidのクライアントは、システムVPNインターフェースを利用し、アプリを許可または除外する設定を提供する場合があります。対象アプリが正しいリストに含まれているかに加え、システムのVPN設定や仕事用プロファイルも確認してください。iOSのクライアントは通常、システムのネットワーク拡張機能を使ってトンネルを構築します。対応するルーティング機能はクライアントと設定によって異なるため、Androidのアプリ別メニューの手順をそのまま当てはめないでください。

ルールの確認では、個々のルールの記述だけでなく、最終的にどのルールが適用されたかを見ます。先に一致したルールが後続の選択に優先する場合があり、ポリシーグループの接続先が直接接続や別の回線のままになっていることもあります。設定を変更したら、新しい接続を発生させてください。既存のセッションはすぐに新しい経路へ切り替わるとは限りません。

接続済みなのに通信が経由しない場合の確認手順

まずサブスクリプションが正しく読み込まれ、更新も完了しているか確認します。次に、現在のポリシーで回線が選択されているか調べてください。サブスクリプションURLは設定を取得するためのもので、ウェブサイトの動作確認用URLやアプリのインストーラーではありません。読み込みに成功したことが示すのは、クライアントが設定を取得できたことだけです。対応プロトコルか、接続できているか、対象アプリの通信が処理されているかは、それぞれ別に確認する必要があります。

Shadowsocks、VMess、Trojan、VLESSは、よく使われるプロキシプロトコルです。Hysteria2とTUICは、一般にQUICベースの通信を利用します。プロトコル名だけでアプリの通信が自動的にプロキシ経由になるわけではありません。クライアントが該当プロトコルと設定項目に対応している必要があり、ローカルネットワーク側でも使用する通信方式が許可されていなければなりません。IEPL専用回線、中継、直接接続は回線の経路を表し、プロトコルや端末側の通信処理方式とは別の要素です。

• ✅ ブラウザーの出口が変わらない：システムプロキシが有効か、拡張機能が設定を上書きしていないか、確認用ドメインに直接接続ルールが適用されていないかを調べます。
• ✅ ブラウザーは使えるのにアプリは使えない：アプリ独自のプロキシ設定、アプリ別の除外リスト、TUNのルーティングを確認します。サブスクリプションを何度も変更するのは後にしましょう。
• ✅ すべてのアプリで失敗する：クライアントのエラーログ、選択中のノード、プロトコルの対応状況を調べ、ローカルネットワークで使用する通信方式が許可されているか確認します。
• ✅ 再起動後にだけ有効になる：既存の接続や設定の再読み込み動作を確認し、再起動が必要なのはクライアントか対象アプリかを記録します。
• ✅ 出口は正しいのに接続先サービスでエラーが出る：通信経路の問題と、アカウントの地域、コンテンツの利用権、リスク管理、サービス側の障害を切り分けます。エラーだけを根拠にVPNが機能していないと判断することはできません。
• ✅ DNS検査で想定外のリゾルバーが表示される：ブラウザーのセキュアDNS、システムの名前解決、クライアントのルールを照合し、問い合わせの経路を特定してから変更します。

WebRTCの検査も個別に考える必要があります。リアルタイム通信では、候補アドレスから追加のネットワーク情報が分かる場合があります。ただし、ローカルIPアドレスが検出されたからといって、インターネット向け通信がトンネルを迂回しているとは限りません。想定外のグローバルIPアドレスが候補に表示される場合は、ブラウザーのポリシーとUDPの処理を確認してください。通常のウェブページで出口を確認しただけでは、すべてのリアルタイム通信が想定どおりの経路を使っているとは証明できません。

切断時やネットワーク切り替え後に再確認する

「接続中に機能すること」と「切断後もプライバシー上の想定を満たすこと」は別の問題です。自動的な直接接続を許可する設定では、ノードが使えなくなったときにローカル回線での接続へ戻る場合があります。切断時に通信をブロックする機能があるクライアントでも、その機能が有効で、必要な範囲をカバーしているか確認してください。すべてのクライアントにこの機能があると考えないでください。

機微な情報を含まないテストページを使い、ノードが一時的に使えなくなったときの動作を確認します。新しいリクエストが失敗するのか、別のポリシーに切り替わるのか、直接接続になるのかを記録してください。クライアントを手動で終了した場合と、ノードが予期せず切断された場合では、動作が異なることがあります。テスト記録には状況を明記しましょう。端末のスリープ復帰後やネットワーク切り替え後にも、出口と対象アプリの通信を再確認し、接続が再確立されているか調べます。

サポートに問い合わせる場合は、クライアント名、OSのバージョン、接続モード、問題の発生時刻、対象ドメイン、関連するエラー情報を残してください。スクリーンショットを撮る前に、サブスクリプションURL、トークン、アカウント情報、不要な閲覧履歴を隠します。原因を再現するためでも、設定全体を公開の掲示板に貼り付けないでください。VPNHOをご利用の方は、サポートチケットから調査に必要な情報を送信できます。

確認結果を、ローカルネットワーク、選択した回線、通信の処理モード、対象アプリ、出口、DNS、切断時の動作を含む簡単な記録にまとめます。次に問題が起きたときは、プロトコル、DNS、ルールを一度に変更するより、記録と比較するほうが原因を特定しやすくなります。クライアントの利用開始方法や設定の読み込み手順は使い方ガイドをご覧ください。回線の種類とプロトコルの用途については、回線一覧とプロトコルの解説で紹介しています。