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

VPNに接続できているか確認するときは、クライアントの接続アイコンだけを見て判断しないでください。接続前後の出口IPアドレスを比較し、DNSの名前解決経路を確認してから、利用するアプリを一つずつ検証します。判断の基準は「すべての通信が変わったか」ではなく、「VPN経由にするはずのリクエストが、想定どおりVPN経由になっているか」です。

この方法は、OS標準のVPN接続にも、サブスクリプションリンクからノードを追加するプロキシクライアントにも使えます。ただし、通信を制御する範囲は異なる場合があります。ノードに接続できたことがわかるのは接続処理が進んだということだけで、ブラウザーやデスクトップアプリ、バックグラウンドサービスの通信まで確認できたことにはなりません。

「接続成功」と「通信の経路制御」を区別する

Webサイトへのアクセスでは通常、ドメインの名前解決、経路の選択、接続先サービスとの通信が行われます。クライアントに接続済みと表示されても、トンネルが確立しただけの場合もあれば、プロキシのコアが起動しただけの場合もあります。アプリがその接続経路を使うかどうかは、システムプロキシ、仮想ネットワークインターフェース、ルールによる振り分け、アプリ独自のネットワーク設定にも左右されます。

「システムプロキシ」は、設定に従うアプリに対して、該当するリクエストをプロキシに渡すよう指示する仕組みです。端末のすべての通信を制御するわけではありません。TUNモードは仮想ネットワークインターフェースとルーティングを使ってIP通信を処理するため、より広い範囲を制御できることが多いものの、除外設定や権限、プロトコルの対応状況、具体的な設定に左右されます。「グローバルプロキシ」も、クライアントに届いたリクエストをまとめてノードに転送するだけの場合があり、すべてのアプリの通信が自動的にクライアント経由になるわけではありません。

確認項目ごとにわかること
確認項目	主に確認できること	それだけでは確認できないこと
クライアントの接続状態	コア、トンネル、ノードの接続状況	対象アプリのリクエストがノードを経由したかどうか
ブラウザーの出口IPアドレス	そのブラウザーで確認サイトにアクセスした際のパブリックIPアドレス	ほかのアプリや異なるアドレスファミリーも同じ経路を使うかどうか
DNSチェック	テスト対象ドメインの再帰リゾルバーと関連情報	すべての通信の出口とプライバシー保護の範囲
クライアントの接続ログ	対象リクエストに適用されたルール、ポリシー、アウトバウンド	接続先サービスへのアクセスや操作が必ず成功するかどうか
対象アプリでの実際の操作	現在の経路で必要な機能を利用できるかどうか	端末上のすべてのアプリがVPN経由になっているかどうか

出口IPアドレス：同じ条件で接続前後を比較する

未接続の状態で、信頼できるパブリックIPアドレス確認サイトをブラウザーで開き、IPアドレス、アドレスファミリー、ネットワークの割り当て先を記録します。次に、利用するノードへ接続して、同じブラウザーで同じページを再読み込みします。キャッシュ情報だけを表示するページではなく、現在のリクエスト情報を返すページを使いましょう。

確認リクエストにプロキシルールが適用されていれば、通常は出口IPアドレスがノードの接続先に応じて変わります。IPアドレスの地域情報が選択した地域と一致していれば参考になりますが、位置情報データベースには更新の遅れや表示の違いがあります。都市名が異なるだけで異常と判断したり、ローカルネットワークのIPアドレスをパブリックIPアドレスと取り違えたりしないようにしましょう。

接続前のパブリックIPアドレスを記録し、ブラウザーでほかのプロキシ拡張機能が動作していないことを確認します。
ノードに接続したら、現在のモードを確認し、確認用ドメインがルールによって直接接続に設定されていないかを確認します。
確認リクエストをもう一度実行して、IPアドレスの変化を比較します。必要に応じて古いタブを閉じ、既存の接続が再利用されないようにします。
クライアントの接続ログで、確認用ドメインに適用されたアウトバウンドとページの結果を照合します。
接続を切ってからもう一度確認し、変化が今回の接続によるものか、別のプロキシやネットワーク切り替えによるものかを確かめます。

IPv4とIPv6に対応した端末では、それぞれの経路を確認してください。設定によっては一方のアドレスファミリーしか処理せず、ブラウザーがもう一方の経路を使うことがあります。関連するパブリック通信をすべてノード経由にする場合は、両方の通信が制御されていることを確認するか、クライアントの説明に従って適切な遮断設定を使いましょう。一方のIPアドレスが変わっただけで確認を終えないでください。

DNS：名前解決の経路を確認する。国名だけで判断しない

DNSはドメイン名をIPアドレスに変換します。DNS漏えいとは、保護される想定の名前解決リクエストが、たとえばローカルネットワークのリゾルバーで処理されるなど、意図しない経路を通ることです。通信の出口とは別の問題で、Webサイトへのリクエストがノードを経由していても、ドメインの問い合わせだけがローカルで行われることがあります。

一般的なDNSチェックサイトでは、テスト用ドメインを生成し、どの再帰リゾルバーが問い合わせを行うかを確認します。結果に表示されるIPアドレスは通常、DNSサービスのものであり、通信の出口ではありません。パブリックDNSサービスはエニーキャストやキャッシュ、転送を利用することがあるため、表示された地域が実際の処理場所と一致するとは限りません。したがって「リゾルバーとノードが別の国にある」というだけでは、DNS漏えいとは判断できません。

重要なのは、現在の設定でどのDNSサーバーが名前解決を行う想定かです。クライアントはシステムのDNSを制御していますか。ブラウザーで独自の暗号化DNSが有効になっていませんか。リモートで名前解決する設定なのに、ローカルの通信事業者のリゾルバーが繰り返し表示される場合は、さらに確認が必要です。一方、通信事業者の名前が表示されないからといって、すべてのアプリのDNSが保護されているとは限りません。

✅ クライアントのDNSモード、リモート名前解決の設定、直接接続するドメインの名前解決ルールを確認します。
✅ ブラウザーのセキュアDNS設定を確認し、クライアントの設定と独立しているかを確かめます。
✅ 設定を変更した後にテストを再実行し、キャッシュや既存の接続を新しい結果と取り違えないようにします。
✅ クライアントのログに記録されたドメイン、接続先IPアドレス、アウトバウンドを照合し、名前解決と通信の経路が想定どおりか確認します。
❌ リゾルバーの名前や地域が一致するかどうかだけで、安全性やDNS漏えいを判断しないでください。

一部のクライアントはFake-IPを使い、アプリに合成アドレスを返した後、内部でドメイン名と実際のアウトバウンドを関連付けます。この種のアドレスは一般的なパブリックDNSの結果とは異なりますが、DNSの障害を意味するわけではありません。ローカルネットワークの端末、社内ドメイン、特定のアプリに問題が起きた場合は、DNS設定全体を安易に変更せず、該当する除外ルールを確認してください。

アプリごとに確認する：ブラウザーが動いてもほかのアプリが動くとは限らない

ブラウザー、コマンドラインツール、ゲーム、デスクトップアプリでは、異なるネットワーク処理が使われることがあります。ブラウザーはシステムプロキシに従うことが多い一方、コマンドラインツールは環境変数や独自のプロキシ引数を参照する場合があります。システムプロキシを使わないアプリもあります。モバイル端末のクライアントでは、アプリの許可リストや除外リストを設定できる場合もあるため、実際に使うアプリで確認してください。

Windows・macOS

システム設定が上書きされないよう、まずブラウザーのプロキシ拡張機能を終了します。デスクトップアプリをテストするときは、対象のプロセスやドメインがクライアントの接続ログに表示されるか確認してください。ブラウザーの記録はあるのに対象アプリの記録がまったくない場合は、アプリ独自のプロキシ設定、クライアントの通信制御モード、仮想ネットワークインターフェースの権限を優先して確認します。管理対象の業務端末では、組織が設定したネットワークポリシーが適用されている場合もあるため、独断で上書きしないでください。

Android・iOS

まず、システムがクライアントによるVPN接続を許可していることを確認し、クライアントにアプリ別ルールがある場合は、その設定が有効か確認します。Androidではバックグラウンド動作や省電力制限にも注意してください。アプリの切り替えや画面ロック後に接続が切れる問題は、初回接続に失敗する問題とは異なります。iOSで通信が制御される範囲はクライアントの実装とシステム設定によって異なるため、デスクトップの設定手順をそのまま当てはめないでください。

コマンドラインとバックグラウンドタスク

ブラウザーでアクセスできても、ターミナルのリクエストが同じ経路を使うとは限りません。ツールがプロキシ環境変数を参照するか、ローカルで名前解決するか、ドメイン名をプロキシ側に渡して名前解決するかを確認します。ターミナルでリクエストが成功しただけで、ノードを経由したと判断しないでください。出口IPアドレスとクライアントのログも照合しましょう。スケジュール実行されるタスクの環境は、対話型ターミナルと異なる場合もあります。

確認には、アプリの表示更新や公開リソースへのアクセスなど、実際に使う低リスクの操作を行ってください。アプリのトップ画面を開くだけではローカルキャッシュが表示されることがあり、新しいリクエストの経路を確認できません。接続テストのために、決済や投稿など取り消せない操作を繰り返すのも避けてください。

接続済みに見えるのに機能しない場合は、症状から原因を探す

ノードの遅延テストに成功しても、確認用リクエストに応答があったことしかわかりません。目的のサービスを利用できるかどうかは、DNS、ルール、通信方式、接続先の制限にも左右されます。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどはそれぞれ異なるプロトコル方式を示すもので、通信が正しく制御されている証拠ではありません。クライアントが、サブスクリプションで提供されるプロトコルと設定に対応している必要があります。

ノードを変更する前に、まず設定を確認する
症状	考えられる原因	次に確認すること
接続済みと表示されるが、出口IPアドレスが変わらない	確認用ドメインが直接接続になっている、システムプロキシが機能していない、またはアプリの通信が制御されていない	そのリクエストに適用されたルールとアウトバウンドを確認する
ブラウザーは使えるが、ほかのアプリは使えない	アプリがシステムプロキシを使わない、除外対象になっている、または異なる通信方式を使っている	アプリの設定、通信制御の範囲、必要なプロトコルへの対応を確認する
出口IPアドレスは変わったが、接続先サイトに拒否される	サービスの地域別ポリシー、アカウント制限、出口IPアドレスの評価	サービス側の案内を確認し、アクセス拒否をそのままプロキシの不具合と判断しない
ノードを切り替えても、以前の出口IPアドレスのように見える	既存の長時間接続が再確立されていない、またはページに古い結果が表示されている	該当アプリを終了してから再試行し、接続ログを確認する
画面ロックやネットワーク切り替え後に使えなくなる	バックグラウンド動作の制限、トンネルの再接続失敗、ルーティングの未復旧	クライアントを再び動作させて接続を再確立し、対象アプリをもう一度確認する

IEPL専用線、中継、直接接続は、通信経路や伝送方式を表すもので、端末側の通信制御を代わりに行うものではありません。専用線を選んでも、ルールの設定が誤っていればリクエストは直接接続されます。反対に、中継回線でも設定どおりに転送できます。回線の種類だけで判断せず、出口IPアドレス、名前解決、アプリの動作を照らし合わせて確認してください。

確認結果を整理してから設定を変更する

トラブルシューティングでは、関連する設定を一度に一つだけ変更し、元に戻せるよう元の設定を残しておきます。まずサブスクリプションが正しくインポートされ、ノードが利用可能か確認します。次に対象リクエストがクライアントに届いているか、アウトバウンドとDNSが想定どおりかを調べ、最後に接続先サービスの案内を確認します。最初からノード、リゾルバー、ルールを同時に変更すると、一時的に解決しても原因を特定しにくくなります。

サポートが必要な場合は、サポートページから、端末のOS、クライアント名、使用中のモード、問題が発生する状況、実施済みの確認項目をお知らせください。スクリーンショットを送る際は、サブスクリプションリンク、ユーザー名、パスワード、トークンなどの個人情報を隠してください。サブスクリプションリンクは設定用の認証情報です。公開の確認サイトに貼り付けたり、掲示板などにリンク全体を掲載したりしないでください。

VPNGQの使い方ガイドでは、インストールやサブスクリプションの追加方法を確認できます。設定を詳しく確認する場合は、総合マニュアルをご覧ください。サービスのプライバシーポリシーに記載された「匿名・ログなし」は、ブラウザーのログイン状態やWebサイトのトラッキング、アプリのアカウント情報が自動的に消えることを意味しません。接続経路の確認とアカウントのプライバシー管理は、別々に行う必要があります。