VPNが正しく機能しているか確認するときは、「接続済み」の表示だけで判断しないでください。まず出口IPを比較し、次にDNSの名前解決経路を確認し、最後に実際に使うアプリでテストします。接続アイコンが示すのはクライアントの接続状態であり、ブラウザーやデスクトップアプリ、バックグラウンド通信のすべてが同じ出口を使っているとは限りません。
判断の基準は、対象アプリの新しい通信が、想定したルールに従って選択した回線を経由しているかどうかです。ルール設定によって一部のサイトが直接接続される場合、国内サイトで元の出口が表示されても不具合とは限りません。逆に、ブラウザーの出口が変わっていても、すべてのアプリの通信が切り替わったとは言えません。
接続状態・出口IP・アプリの通信経路
プロキシクライアントは、システムプロキシ、仮想ネットワークアダプター、アプリ別ルールなどを使って通信を振り分けます。システムプロキシは、アプリ側がプロキシ設定に従うことが前提です。仮想ネットワークアダプターはより広い範囲の通信を扱えますが、ルーティングや除外リスト、プロトコルの対応状況に左右されます。まず現在のモードを確認してから検査結果を判断すれば、正常な振り分けを不具合と誤認しにくくなります。
| チェック項目 | 確認できること | これだけでは確認できないこと |
|---|---|---|
| クライアントに「接続済み」と表示される | 接続機能が開始されていること。具体的な意味はクライアントの仕様によって異なる | 対象アプリが回線を利用しているか |
| 出口IPが変わる | 今回の検索リクエストのインターネット出口が変わったこと | ほかのアプリやDNSも同じ経路を使っているか |
| DNSテスト | テスト対象のドメインをどの再帰リゾルバーが処理したか | すべてのドメイン検索が同じ方法で処理されているか |
| アプリの通信リクエストとルールの記録 | その接続に適用されたルールと、実際に選択された出口 | テストしていないアプリのその後の動作 |
出口IP：接続前の状態を記録してから比較
回線を切断し、IPアドレス確認ページを開いて、現在のグローバルIPアドレスとネットワークの情報を記録します。同じネットワーク環境のまま対象の回線に接続し、もう一度確認してください。その間にWi-Fiから別のネットワークへ切り替えた場合、元の出口自体が変わっている可能性があるため、この比較だけでは回線が機能した証拠になりません。
- 接続を切って現在の出口を確認し、手元で比較できるよう結果を記録します。アドレス全体を公開する必要はありません。
- 対象の回線に接続し、ノードを選択しただけでなく、クライアントに想定どおりのノードと動作モードが表示されていることを確認します。
- もう一度検索し、ページに残っている古い結果を見ないようにします。必要に応じて元のタブを閉じてから開き直してください。
- クライアントの接続ログで検索リクエストを探し、適用されたルールと出口の回線を確認します。
- 検索ドメインがルールで直接接続に設定されている場合は、クライアントが対応する一時的なプロキシルールで再テストし、終了後に元の設定へ戻します。
出口IPの変化は有用な手がかりですが、地域表示は正確な位置情報ではありません。データベースによって更新頻度や判定方法が異なるため、都市名が一致しなくても接続失敗とは限りません。地図上の表示だけで判断せず、アドレスやネットワーク情報、クライアントの出口ログを優先して確認してください。
IPv4とIPv6の違いにも注意が必要です。確認ページによっては、どちらか一方のアドレスしか表示されず、もう一方は別の経路を使っていることがあります。個別に検査できるツールを使い、クライアントのIPv6通信の取り込み設定も確認してください。IPv6を無効にする方法が、すべての端末に適した恒久対策とは限りません。
DNSの確認：名前解決サービスと通信の出口は別
DNSはドメイン名をIPアドレスに変換し、ウェブ接続はその結果を使って接続先にアクセスします。関連する処理ですが、役割は異なります。DNSテストページは通常、専用のドメイン名を使って再帰リゾルバーを確認するもので、個々のパケットが通った回線を直接表示するものではありません。そのため、リゾルバーの所在地と出口の所在地が異なっていても、それだけでDNSリークとは言えません。
ここでいうDNSリークとは、プロキシのプライバシー設定に従って処理されるはずの検索リクエストが、意図しないローカル経路から送信されることです。問題の有無は、クライアントのDNSモード、ブラウザーのセキュアDNS設定、リゾルバーの情報、実際のルールを合わせて判断してください。ルールでローカルドメインをローカルで解決する設定になっている場合は、ポリシー上の選択であり、ただちにリークと呼ぶべきではありません。
ブラウザーの暗号化DNSが検査結果に与える影響
ブラウザーによってはHTTPS経由のDNSを有効にし、システム設定とは別のDNSサービスを使います。暗号化されていることは、その通信区間で検索内容が保護されることを示しますが、必ずプロキシを経由するという意味ではありません。ブラウザーから送信されるDNSリクエストの出口も、ルーティングとプロキシのルールによって決まります。
検査結果に問題がある場合は、まずブラウザーのセキュアDNSの状態を記録し、クライアントがそのDNSを取り込む、または連携する機能に対応しているか確認します。比較のため一時的に設定を変更しても構いませんが、テスト後は自分に合った設定に戻してください。ブラウザーの設定とノードを同時に変更すると、どちらが結果に影響したのか分からなくなります。
DNSキャッシュにより、古い結果が引き続き使われることもあります。設定を変更した後は、ドメインを再検索し、システムやクライアントの案内に従ってキャッシュを処理してください。ページを更新してサイトが開けたからといって、新しいDNS設定が適用されたとは限りません。ページのリソースがキャッシュされている場合や、接続が再利用されている場合があります。
アプリ別の確認：ブラウザーで成功しても、すべてのアプリで成功するとは限らない
ブラウザーはシステムプロキシに従う一方、デスクトップアプリは従わないことがあります。これは「ウェブは使えるのにアプリは失敗する」よくある原因です。ブラウザーにプロキシ拡張機能が入っていて、独自の経路を使っている場合もあります。テストでは拡張機能のプロキシ、システムプロキシ、仮想ネットワークアダプターを区別し、同じ機能として扱わないようにしてください。
デスクトップとモバイルで確認するポイント
WindowsとmacOSでは、アプリがシステムプロキシに対応しているか、独自のプロキシ設定があるか、クライアントで仮想ネットワークアダプターのモードが有効かを確認します。ターミナルのプログラムはプロキシ環境変数に依存することもあるため、その通信結果をブラウザーの動作の証拠にはできません。仮想ネットワークアダプターを有効にしても通信が正しく取り込まれるとは限らず、権限やルーティングの状態も確認が必要です。
Androidのクライアントには、アプリを通信対象に含めたり除外したりする設定がある場合があります。対象アプリが除外されていないか確認してください。iOSでは、使っているクライアントが対応する通信の取り込み方法やルールを確認し、ほかのプラットフォームのメニュー名をそのまま当てはめないようにします。モバイル端末にVPNのステータスが表示されていても、対象アプリでの実際のテストは必要です。
- ✅ 対象アプリを終了して開き直し、ネットワーク接続が必要な操作を新たに実行します。
- ✅ クライアントの接続ログで該当するドメインやプロセスを探し、ルールと出口を確認します。
- ✅ アプリの除外リスト、ブラウザーのプロキシ拡張機能、ほかに起動中のネットワークツールを確認します。
- ✅ ウェブ閲覧、画像のアップロード、アプリのメッセージ送信を個別にテストし、キャッシュされたページを通信の証拠にしないでください。
- ❌ ブラウザーのテストが成功しても、すべてのアプリが選択した回線を使っているとは判断しないでください。
メッセージアプリや同期ツールなどは、長時間接続を維持することがあります。回線を切り替えても、既存の接続がすぐに作り直されるとは限りません。ウェブページを何度も更新するより、対象アプリを再起動するほうが判断材料になります。アップロード、音声・動画、リアルタイムメッセージに問題が集中する場合は、ウェブ閲覧だけをテストするのではなく、UDP転送への対応とルールも確認してください。
接続済みなのに回線を経由しない：症状から原因を絞り込む
出口IPが変わらないが、クライアントには通信量が表示される
まず検索リクエストに直接接続のルールが適用されていないか確認し、次にシステムプロキシや仮想ネットワークアダプターが実際に有効か調べます。クライアントの通信量は、サブスクリプションの更新や遅延測定、その他のバックグラウンド通信によるものかもしれません。対象のブラウザーが通信を取り込んでいる証拠にはなりません。ログに対象のリクエストが見つからない場合は、ノードを何度も切り替えるより、通信の取り込み範囲を先に確認してください。
出口IPは変わったが、対象サービスを利用できない
この場合、検査用のリクエストが回線を経由したとは考えられますが、対象サービスも利用できるとは限りません。サービスによってはアカウントの地域、支払い情報、出口IPの評価、セッション状態などを基に制限しています。まず対象リクエストの実際の出口を確認し、その後でエラーメッセージを調べてください。地域表示が正しいことはアクセス許可を意味しません。また、アクセス拒否の原因をすべてDNSに求めないでください。
ブラウザーは正常だが、単独のアプリでは失敗する
まず、そのアプリがシステムプロキシを迂回していないか確認し、次にプロセスごとのルール、アプリ内蔵のプロキシ、接続の再利用を調べます。特定の機能だけ失敗する場合は、正常に動く機能と使っているドメインや通信方式を比較してください。サブスクリプションにShadowsocks、Trojan、VLESSなどのプロトコル名が含まれていても、それは設定の種類を示すだけで、クライアントが対象アプリの通信を取り込んでいる証拠にはなりません。
通信の取り込みを有効にしたら、すべてネットにつながらなくなった
仮想ネットワークアダプターの権限、デフォルトルート、DNS設定、ほかのネットワークツールによる設定変更を確認します。まず通信できる状態に戻して基準を作り、その後、機能を一つずつ有効にしてください。確認のためにシステムの保護機能を長期間無効にしないでください。設定元が分からない場合は、エラーの記録を残してサポート窓口に相談するほうが、出所不明の設定を何度も読み込むより安全です。
再テストと結論：照合できる証拠を残す
適切に再テストするには、ネットワーク環境と対象アプリを変えず、一度に変更する要素を一つにします。テスト時刻、クライアントのモード、選択した回線、対象ドメイン、エラーの内容を記録し、出口IP、DNS、ルールのログを比較してください。これにより、ノードやルールの変更と、アプリ自体の状態による差を見分けられます。
サポートに問い合わせる際は、ヘルプページまたはユーザーパネルから情報を送信できます。スクリーンショットを共有する前に、サブスクリプションリンク、アクセストークン、個人情報を隠してください。接続ログにはアクセスしたドメインが含まれる場合があります。「匿名・ログなし」はサービスのプライバシーポリシーに関する説明であり、端末上のクライアントログを公開してよいという意味ではありません。
判断のポイント：対象アプリの新しい通信に想定したプロキシルールが適用され、出口IPが回線と一致し、DNSの動作も選択したポリシーに沿っていることを確認できれば、より確かな動作確認になります。
ウェブページでの一度のテストで確認できるのは、そのリクエストだけです。ほかのアプリやアドレスファミリー、切断後の動作を確認するには、それぞれ別にテストしてください。「接続済み」や「地域が正しい」という表示だけでは、確認の代わりになりません。
初回設定では、まずクイックスタートを参考に設定をインポートしてモードを選び、その後この記事の方法で確認してください。サブスクリプションリンクはノードや関連設定の更新に使うもので、通信を取り込む機能ではありません。設定のインポート、ノードの表示、実際のリクエストが回線を経由することは、それぞれ個別に確認する必要があります。