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

接続アイコンだけでなく、有効な範囲を確認する

VPNが実際に機能しているか確認するには、まず出口IP、次にDNS、最後に使いたいアプリをチェックします。クライアントに「接続済み」と表示されても、接続や通信制御の仕組みが確立したことを示すにすぎず、すべての通信が対象の回線を通っているとは限りません。

確認の前に、目的も明確にしましょう。特定の海外サイトだけをプロキシ経由にしたいのか、端末の大半の通信をトンネルに通したいのかを確認します。ルールによる振り分けでは、日本国内のサイトは直接接続し、海外サイトはプロキシ経由にできます。この場合、サイトによって異なる出口が表示されても、設定どおりの動作である可能性があります。すべての確認ページに同じ地域が表示されることではなく、実際のルールを基準に判断してください。

まず接続前後の状態を比較する

最初から設定をすべて変更するのは避けましょう。現在の設定を保存し、クライアントがルールモード、グローバルプロキシモード、TUNモードのどれを使っているか記録します。プロキシ設定の競合を避けるため、ほかのプロキシ拡張機能や同時起動中のネットワーククライアントは終了してください。組織の管理下にある端末では、管理上の要件を確認し、セキュリティソフトを独断で無効にしないでください。

1. 直接インターネットに接続できる環境で対象回線を切断し、信頼できるパブリックIP確認ページを開きます。表示されたアドレス、ネットワークの所属、確認時刻を記録してください。
2. 対象の回線に接続し、同じブラウザーでもう一度確認します。前回の結果がキャッシュ表示されているのではなく、新しいリクエストが行われたことを確認してください。
3. 確認ページのドメインに適用された振り分けルールを確認します。直接接続に設定されている場合は、そのドメインだけ一時的にプロキシ経由にして比較してください。
4. 結果を記録したら、元の振り分け設定に戻し、DNSと対象アプリを確認します。原因を特定しやすくするため、設定は一度に一つだけ変更してください。

サブスクリプションのインポート成功と、通信の取り込み成功は別のことです。サブスクリプションURLにはノードや関連設定が含まれますが、クライアントが使用されているプロトコルに対応し、通信の取り込みモードを正しく有効にする必要があります。ノード名はサーバー側のラベルにすぎない場合があり、出口の確認には代用できません。また、サブスクリプションURLにはアクセス認証情報が含まれることが多いため、見知らぬ確認サイトに貼り付けないでください。

出口IP：アドレスの変化とリクエスト経路を確認

接続後に確認ページのグローバルIPアドレスが対象の出口に変われば、そのブラウザーのリクエストが回線を経由した直接的な証拠になります。地域名はあくまで参考情報です。IPアドレスのデータベースによって所属地域が異なることがあり、特に都市の位置情報は正確な証拠として適しません。アドレスの変化、ネットワークの所属、クライアントのログを組み合わせて判断するのが確実です。

アドレスが変わらない場合は、まずブラウザー専用のプロキシ拡張機能が有効になっていないか、確認対象のドメインに直接接続ルールが適用されていないか、システムプロキシが正しく有効になっているかを確認します。新旧のノードが同じグローバルIPを共有している可能性もあるため、「ノードを切り替えてもアドレスが同じ」というだけでは、切り替え失敗とは断定できません。

IPv4とIPv6もそれぞれ確認してください。確認サービスが片方しかチェックしない一方、ブラウザーは別のアドレスを使ってほかのサイトに接続することがあります。クライアントが一部のアドレスファミリーしか制御していない場合、確認ページはプロキシ経由でも、ほかの接続は直接接続になる可能性があります。両方のアドレスを区別できる方法で確認し、クライアントのIPv6ルートとDNS設定も見直してください。

グローバルIPの確認で証明できるのは、確認サービスへの今回の接続だけです。パソコンのローカルIPアドレスが変わらなくても問題ありません。ルーター内部のアドレスも、国際回線の出口ではありません。

DNS：国旗だけでなく名前解決の経路を確認

DNSはドメイン名をIPアドレスに変換します。名前解決とウェブサイトへの接続は、異なる経路を通ることがあります。ウェブ通信の出口が変わっても、DNSクエリまで自動的にトンネル経由になるわけではありません。関連するクエリをすべてトンネルに通す設定なのに、ローカルネットワークのDNSサーバーへ問い合わせている場合は、さらに調査が必要です。

信頼できるDNSリーク確認では、通常、新たに生成したテスト用ドメインへの問い合わせを発生させ、処理した再帰DNSサーバーを表示します。接続前後のサーバー名、所属、変化を記録し、クライアントのDNS設定と照らし合わせてください。DNSサーバーが国内にあるからといって必ずリークとは限らず、海外にあるからといってトンネルで保護されているとも限りません。パブリックDNS、エニーキャストネットワーク、データベースの誤差も表示に影響します。

ブラウザーのセキュアDNS、システムの暗号化DNS、クライアント内蔵のDNSが同時に使われることがあります。ブラウザーでDoHが有効な場合、DNSクエリは独立したHTTPS接続を通ることがあり、その経路はプロキシやルーティングのルールによって変わります。暗号化DNSは問い合わせの通信を保護しますが、「暗号化されていること」と「指定した回線を通ること」は別の確認事項です。

結果が想定と異なる場合は、まずクライアントが推奨するDNSモードを確認し、ブラウザーがシステム設定を上書きしていないか確認します。古い記録の影響を避けるため、DNSキャッシュを削除するか関連アプリを再起動してから、もう一度テストしてください。確認ページの国旗を一致させるためだけにDNSサーバーのアドレスを適当に設定したり、問題を隠すために名前解決の保護を長期間無効にしたりしないでください。

アプリ別のチェック：ブラウザーで確認できても端末全体とは限らない

システムプロキシは、対応しているアプリにプロキシ設定を提供する仕組みであり、端末上のすべての通信を強制的に置き換えるものではありません。一部のコマンドラインツール、ゲーム、アップデーター、アプリ内のネットワーク機能はシステムプロキシを参照しないことがあり、個別の設定が必要な場合もあります。ブラウザーで問題なく確認できても、まず確認できたのはブラウザーの経路だけです。

TUNモードは仮想ネットワークアダプターとルーティングを使ってIP通信を取り込むため、通常はより広い範囲をカバーします。ただし、除外ルート、アプリ別ルール、プロトコル対応状況、権限の影響を受けます。「グローバルプロキシ」も、プロキシエンジンに渡されたリクエストの出口を一律に選ぶだけの場合があり、端末全体の通信を取り込むことと同じではありません。

WindowsとmacOSでは、システムプロキシ、ネットワーク拡張機能、仮想ネットワークアダプターの権限をそれぞれ確認します。モバイル端末では、アプリに通信の取り込みを許可しているか、クライアントにアプリの除外ルールが設定されていないかを確認してください。クライアントによって項目名は異なるため、設定名だけで対象範囲を判断できません。インストールと権限の設定は、サイトの使い方ガイドを参照してください。

• ✅ ブラウザー：新しいページを開いて出口を確認し、プロキシ拡張機能とセキュアDNSの個別設定も確認します。
• ✅ 対象アプリ：完全に終了してから再起動し、実際に通信する操作を行います。クライアントの接続ログで、該当するドメインやプロセスを確認してください。
• ✅ コマンドラインツール：システムプロキシを参照するか、ツールが対応するプロキシ引数や環境変数の設定が必要かを確認します。
• ✅ ルールの適用状況：リクエストにプロキシ、直接接続、拒否のどのルールが適用されたかを確認し、選択された出口が用途に合っているか確認します。
• ❌ ウェブページが開く、アカウントにログインできる、クライアントのアイコンが点灯しているという理由だけで、端末上のすべての通信が取り込まれていると判断すること。

ログを読む際は、ドメイン、プロセス、時刻の対応関係に注意してください。DNSクエリ、バックグラウンドのハートビート、実際のサービスリクエストは、別々の接続である可能性があります。ログが見つからない場合も、記録レベルの設定や既存の長時間接続が原因かもしれません。サポートにログを共有する前に、サブスクリプションの認証情報、アカウント識別情報、関係のないアクセス記録を削除してください。

接続済みに見えても回線を経由しない主な原因

既存の接続が以前の経路を使い続けている

アプリが接続プール、バックグラウンドセッション、確立済みの接続を再利用している場合があります。出口を切り替えた後は、対象アプリを完全に終了して再起動し、新しいリクエストを発生させてください。ブラウザーで新しいタブを開いても、接続自体は新規とは限りません。最新の確認結果とログを合わせて判断しましょう。

振り分けルールによって対象リクエストが直接接続されている

ウェブページでは、メインサイト、リソース用ドメイン、ログインAPI、メディア用ドメインなどが使われることがあります。メインサイトだけのルールを変更しても、ほかのリクエストが別の出口を通る可能性があります。ログを見ながら関連リクエストを一つずつ確認してください。一時的にプロキシを一律適用して問題が解消した場合は、ルールモードに戻して関連ルールを修正すればよく、無関係な通信まで長期間プロキシ経由にする必要はありません。

プロトコルへの対応、またはUDP通信の取り込みが不完全

ノードのプロトコルと通信の取り込みモードは、それぞれ異なる問題に対応します。Shadowsocks、VMess、Trojan、VLESSなどを利用するには、クライアントが該当する設定に対応している必要があります。Hysteria2とTUICはUDP通信にも依存します。ノードのテストが成功しても、すべてのアプリのUDPリクエストが転送されるとは限りません。クライアント、出口側の対応状況、ローカルネットワークの制限を確認してください。

プラットフォーム側の制限を回線の不具合と誤認している

出口が想定どおりでもプラットフォームを利用できない場合、アカウントの地域設定、アプリのキャッシュ、出口の評価、プラットフォームのアクセスルールが原因かもしれません。IEPL専線、中継、直接接続は通信経路を表すもので、最終出口の確認の代わりにはならず、アプリの利用を保証するものでもありません。地域を何度も切り替えても、アカウントが利用可能だと判断することはできません。

あとから確認できる結論のまとめ方

接続前後の出口、DNSの結果、通信の取り込みモード、対象アプリのログを保存してください。「VPNは正常」のように曖昧にまとめず、「ブラウザーから確認用ドメインへの通信は対象出口を経由し、対象アプリのリクエストにはプロキシルールが適用された」のように具体的に記録します。誤った判断を減らし、環境の変化にも気づきやすくなります。

さらに問題を調べる場合はヘルプセンターをご覧いただくか、ユーザーパネルからお問い合わせください。端末のOS、クライアント名、通信の取り込みモード、エラーの内容、実施済みの確認事項を伝えると、「接続済み」と表示された画面だけを共有するよりも原因を特定しやすくなります。