VPNが使えているか確認するには、まず接続前後のグローバルIPを比較し、次にDNSの名前解決経路を調べ、最後に実際に使うアプリごとに確認します。クライアントに「接続済み」と表示されても、接続状態やプロキシコアの起動を示すだけの場合があります。端末のすべての通信が選択した経路を通るとは限りません。
大切なのは「すべてのアドレスが変わること」ではなく、通信が設定どおりに処理されているかどうかです。ルールモードでは、国内サイトへの直接接続が想定どおりの場合があります。グローバルプロキシを使っていても、プロキシ対象外のアプリは直接通信することがあります。以下の手順で順に確認し、サイトが開くこと、ノードの遅延が正常なこと、表示地域が変わったことだけで、すべての通信がVPN経由だと判断しないようにしましょう。
まず確認する対象を整理：接続状態、出口、アプリ
サブスクリプションURLは、ノードや設定をクライアントに取り込むためのものです。読み込みや更新に成功しても、プロキシが有効になったとは限りません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはそれぞれ異なるプロキシプロトコルです。クライアントが該当プロトコルに対応しているか、設定が揃っているかは接続に影響しますが、プロトコル名だけでは通信がプロキシ経由かどうかは分かりません。
通信経路と端末側で通信を取り込む方式も区別しましょう。IEPL専線、中継、直接接続は、主にサーバー側やアクセス回線の構成を表します。一方、システムプロキシ、アプリ内プロキシ、TUNモードは、端末のどの通信をプロキシに通すかを決めます。専線でも、プロキシ設定のないアプリの通信が自動的に切り替わるわけではありません。TUNモードを使う場合も、実際のルーティングやDNSの挙動を確認してください。
| 確認項目 | 確認できること | 確認できないこと |
|---|---|---|
| クライアントの接続状態 | クライアントが接続の確立またはプロキシコアの稼働を報告していること | すべてのアプリがその接続を経由していること |
| ブラウザーの出口IP | 今回のブラウザーのリクエストで使われた外部向けアドレス | デスクトップアプリ、ゲーム、バックグラウンドサービスの出口 |
| DNSテスト | テスト対象ドメインの問い合わせで確認できるリゾルバーの情報 | すべてのドメイン、すべてのアプリの完全な名前解決経路 |
| クライアントの接続ログ | リクエストに適用されたルールと選択されたアウトバウンド | 接続先サイトへのアクセス可否やアカウントの地域 |
出口IPの確認：接続前後の比較を記録する
信頼できるグローバルIP確認サイトで、アドレスと地域を確認します。アカウントのパスワードやサブスクリプションURLを入力する必要はありません。まずプロキシを切断し、現在のネットワークの出口IP、通信事業者名、IPv6の表示有無を記録します。次にクライアントを有効にしてノードを選び、同じブラウザーから同じ確認サイトにアクセスし、両方の結果を保存します。
- 基準値を記録する。ネットワークはそのままにして、ほかのプロキシツールや通信を制御する可能性のあるブラウザー拡張機能を一時停止し、未接続時のグローバルIPを確認します。
- クライアントのモードを確認する。選択中のノードと、ルール・グローバル・直接接続のどのモードを使っているかを記録します。システムプロキシまたはTUNが有効になっていることも確認してください。
- テスト用の通信を再実行する。確認ページを開き直します。キャッシュの影響を減らすには、必要に応じてプライベートウィンドウを使います。プライベートウィンドウでも、システムプロキシを自動的に回避できるわけではなく、匿名通信になるわけでもありません。
- 実際のアウトバウンドを確認する。クライアントの接続ログで確認ページのドメインを探し、適用されたルール、ポリシーグループ、最終的に選ばれたノードを確認します。
- 別の方法でも確認する。別の独立した確認サイトでも結果を見ます。地域が異なる場合は、まずIPアドレスが同じかを比べ、すぐにノードの不具合と決めつけないでください。
出口IPが変わり、ログにも選択したノードを経由した記録があれば、今回のブラウザーの通信はプロキシ経由と判断できます。アドレスが変わらない場合は、確認用ドメインに直接接続ルールが適用されていないか、ブラウザーに別のプロキシ設定がないかを確認しましょう。結果が同じというだけで、ノードに接続できないと断定することはできません。
IPアドレスの地域情報はデータベースに基づくもので、リアルタイムの位置情報ではありません。同じアドレスでも、データベースによって都市や地域の表示が異なることがあります。また、IPの登録情報がサーバーの実際の設置場所と一致するとは限りません。動画配信サービスなどのサイトは、アカウントの地域や支払い情報、利用履歴も使って地域を判断することがあります。出口IPが変わっても、特定のサービスを必ず利用できるとは限りません。
DNSの漏れは、リゾルバーの国だけでは判断できない
DNSはドメイン名をアドレスに変換し、実際の通信は接続先にアクセスします。この2つが異なる経路を通ることがあるため、出口IPに問題がなくてもDNSの挙動を確認する必要があります。ここでいうDNS漏れは、プロキシのルールで保護するはずの問い合わせが、意図せずローカルネットワークや想定外のリゾルバー経由で送信される状態を指します。設定内容と照らし合わせて判断し、表示された国名だけで結論を出さないようにしましょう。
まず、未接続の状態で信頼できるDNS漏れテストを実行し、リゾルバー名と通信事業者を記録します。接続後も同様のテストを実行し、クライアントのDNS設定とログを確認します。テストサイトは通常、専用ドメインへの問い合わせを使って外部から見える再帰リゾルバーのアドレスを調べます。端末からリゾルバーまでの経路をすべて表示するわけではありません。
接続後も国内の通信事業者のリゾルバーが表示され、設定ではリモートDNSを使うことになっている場合は、原因を調べる必要があります。一方、海外のパブリックDNSが表示されても、問い合わせがプロキシ経由だとは限りません。未接続時からシステムやブラウザーがそのDNSを直接利用している可能性もあります。
ブラウザーのセキュアDNSとクライアントのDNS設定をあわせて確認
ブラウザーのセキュアDNSは通常DoHを使い、システム側でも暗号化DNSが設定されていることがあります。これらは該当するDNS通信を暗号化しますが、プロキシ経由になるとは限りません。ブラウザーがシステムの名前解決設定を使わず、DNSサービスに直接接続することもあります。その通信がプロキシを通るかは、システムプロキシ、TUN、分割ルールの設定によって変わります。
結果が一致しない場合は、まず現在の設定を記録します。そのうえで一時的にブラウザーをシステムの名前解決設定に合わせ、クライアント推奨のDNS設定と組み合わせて再テストします。確認ページの表示を「緑」にするためだけに、すべてのセキュアDNSをむやみに無効化しないでください。ルールモードでは、国内のドメインをローカルで、その他をリモートで名前解決する設定もあります。これは意図しない漏れとは異なります。
DNSキャッシュがあると新たな問い合わせが発生しないため、テストではページから新しい確認リクエストを送信してください。クライアントがFake-IPを使う場合、アプリには内部マッピング用の合成アドレスが渡されることがあります。これは最終的な出口IPではないため、地域情報からノードの場所を判断することはできません。
アプリごとに確認：ブラウザーが正常でも、すべての通信が正常とは限らない
WindowsやmacOSのシステムプロキシは、通常、システム設定に従うアプリにのみ影響します。端末のすべての通信をトンネルに通す設定とは異なります。デスクトップアプリが独自のプロキシ設定を持つ場合や、ターミナルツールが環境変数に依存する場合、アプリが直接接続する場合もあります。TUNモードを使えば対象範囲を広げられますが、権限やルーティングの除外設定、クライアントの対応状況も確認が必要です。
Androidのクライアントには、アプリごとにプロキシの対象または対象外を設定できるものがあります。iOSのクライアントは通常、システムのネットワーク拡張機能を通じて通信を処理しますが、実際の対象範囲はクライアントの機能と設定によって異なります。あるプラットフォームの画面にあるスイッチ名を、別のプラットフォームにもそのまま当てはめないでください。実際の操作はクライアントの使い方ガイドを参照してください。
- ✅ ブラウザー：出口IPを確認し、確認用ドメインのアウトバウンド記録が接続ログにあるか調べます。
- ✅ デスクトップアプリ：既存の接続を閉じてからリクエストを再実行し、時刻、接続先ドメイン、またはプロセスでログを確認します。クライアントにプロセス情報が表示されない場合は、プロセス単位で無理に判断しないでください。
- ✅ ターミナルツール：システムプロキシや個別のプロキシ設定に対応しているか確認し、クライアントのログと照らし合わせます。ブラウザーの結果をそのまま当てはめないでください。
- ✅ モバイルアプリ：アプリ別プロキシの対象リストとシステムの許可設定を確認し、アプリを開き直して実際の機能でテストします。
- ❌ アプリのホーム画面にコンテンツが表示されることだけで、通信がVPN経由だと判断する。ローカルキャッシュが表示されているだけで、新しいネットワークリクエストが発生していない可能性があります。
出口IPを確認できないアプリでは、新しい接続がクライアントのログに表示されるか、想定したアウトバウンドが適用されているかを確認します。ただし、ログに表示されないからといって、必ず直接接続とは限りません。ログの詳細度が不足している、接続が再利用されている、またはクライアントが該当する記録を表示しない可能性もあります。アプリのネットワーク診断やシステム設定もあわせて確認してください。
接続済みなのに通信がVPNを経由しないときの確認手順
まずモードとルールを確認し、次にネットワークの取り込みを調べる
まず、直接接続モードになっていないか、接続先ドメインが除外リストに入っていないかを確認します。ルールモードでは、接続先に地域ルール、プロセスルール、フォールバックルールが適用される場合があり、ポリシーグループで直接接続が選ばれていることもあります。ノード一覧で選択中の名前を見るだけでなく、最終的なアウトバウンドを確認してください。一時的にグローバルプロキシに切り替えるとルールの問題を特定しやすくなりますが、通常はプロキシコアに入った通信の出口を変えるだけで、対象外だったアプリが自動的にプロキシへ接続されるわけではありません。
ブラウザーとほかのアプリで挙動が異なる場合は、システムプロキシが別のソフトに上書きされていないか、ブラウザー拡張機能が別の出口を設定していないか、TUNに必要な権限があるか、アプリ別の除外設定が適用されているかを確認します。テスト中は通信を取り込むクライアントを1つだけにすると、原因を特定しやすくなります。
次に既存の接続、プロトコル対応、ネットワークの切り替えを確認する
ノードを切り替えても、確立済みの長時間接続は以前の経路を使い続けることがあります。状態アイコンを何度も更新するより、対象アプリを開き直すか、古い接続を切って新しいリクエストを発生させるほうが効果的です。Wi-Fiとモバイルデータを切り替えた後も、接続状態とルーティングを確認してください。
ウェブページは使えても、音声通話、ゲーム、その他のリアルタイム機能に問題がある場合は、UDPの対応状況と関連ルールを個別に確認します。それだけでプロキシ全体が機能していないとは判断できません。逆に、ノードの遅延テストに成功しても、テストのリクエストが完了したことを示すだけです。接続先サービスの通信、認証、地域制限に問題がないとは限りません。
最後に、サブスクリプションが更新済みか、現在のクライアントが登録されたプロトコルに対応しているか、管理画面に正常なプランと通信量が表示されているかを確認します。サブスクリプションURLを、見知らぬ変換サイトに貼り付けてトラブルシューティングしないでください。アクセス情報が含まれている可能性があります。サポートが必要な場合は、サポート窓口から、クライアント名、OS、エラーの内容、個人情報を伏せたログをお知らせください。
まとめ：複数の証拠を照らし合わせて確認する
出口IPの比較でリクエストの接続先を確認し、DNSテストで名前解決が設定どおりかを調べ、アプリごとの確認で普段使うソフトが実際に接続対象になっているかを確かめます。複数の結果を照らし合わせるほうが、「接続済み」の表示だけを見るより確実です。いずれのテストも、その時点の個々のリクエストを確認するものであり、常時匿名で通信できることや、すべてのアプリが常に保護されることを示すものではありません。
普段から設定を何度も切り替える必要はありません。正常に動作しているときの出口IP、モード、DNS設定を一度記録しておき、問題が起きたら基準値と比較して、条件を一つずつ変えて確認しましょう。原因を特定しやすくなり、特定のアプリを直すために正常な分割ルールを崩すことも避けられます。プロトコルや回線の用語については、プロトコルと回線のガイドをご覧ください。