VPNが実際に機能しているかは、クライアントの接続アイコンだけでは判断できません。IP、DNS、アプリごとの通信経路を確認すれば、通信の出口、ドメインの名前解決先、対象アプリが想定どおりの経路を使っているかが分かります。接続前後の結果を比較し、ルール設定と照らし合わせて、用途に合った設定か判断しましょう。
まず確認する範囲を決める：「接続済み」でもすべての通信がVPN経由とは限らない
「接続済み」とは通常、トンネルやプロキシの接続が確立した状態を指しますが、端末上のすべてのリクエストが経由するとは限りません。ブラウザー拡張機能はブラウザーだけに作用する場合があります。システムプロキシは各アプリが設定に従う必要があり、TUNやシステムVPNインターフェースはより広い範囲の通信を取り込めますが、ルーティング、アプリの除外設定、対応プロトコルの範囲に左右されます。
プロキシクライアントの「グローバル」も、意味は設定によって異なります。プロキシエンジンに届いたリクエストをすべて選択中のノードへ送るだけで、すべてのアプリが自動的にプロキシを使うとは限りません。ルールモードでは、ドメイン、宛先アドレス、プロセスなどの条件に応じて、プロキシ、直接接続、拒否を選択します。そのため、中国本土向けのサイトで通常の接続元が表示されても、必ずしも不具合ではありません。
グローバルIPを確認：接続前後の比較を記録する
グローバルIPは、アクセス先のサイトから見える通信元アドレスです。VPN97のIPアドレス確認ページを開き、まずプロキシを切断した状態で、グローバルIP、アドレスの種類、通信事業者の情報を記録します。接続後にもう一度確認してください。テスト中は同じネットワークを使い、Wi-Fiと別のネットワークを同時に切り替えないようにしましょう。出口の変化が、接続ネットワーク自体の変更による可能性があるためです。
- ほかのプロキシ拡張機能や、重複して起動しているクライアントを終了し、未接続時の確認結果を記録します。
- 対象のノードに接続し、クライアントのモードがテスト内容に合っていることを確認してから、確認ページを再読み込みします。
- クライアントの接続ログを確認し、確認ページへのリクエストが想定したプロキシルールと出力先に一致しているかを調べます。
- 切断後にもう一度確認し、結果が元の接続ネットワークに戻るかを見ます。必要に応じてページを閉じてから開き直してください。
出口が変われば、この確認リクエストが別のネットワーク経路を通ったことは分かりますが、ほかのソフトも通信を取り込まれている証明にはなりません。アドレスが変わらなくても、すぐにノードの故障と決めつけないでください。確認サイトが直接接続のルールに振り分けられている、ブラウザーがシステムプロキシを使っていない、別のアドレス種別を使っている、といった可能性があります。
IPアドレスの位置情報データベースは、更新状況によって表示に差があります。確認ページの都市名とノード名が異なっても、それだけでは不具合の証拠になりません。グローバルIP、通信事業者、クライアントの出力ログ、利用したいサービスが想定どおり使えるかを併せて確認しましょう。
| 確認結果 | 分かること | 追加で確認すること |
|---|---|---|
| 確認ページの出口が変わった | このページへのリクエストは別の出口を使った | 対象アプリとDNSもルールどおりか |
| 確認ページの出口が変わらない | 今回のリクエストでは想定した出口が確認できない | 直接接続ルール、プロキシの入口、キャッシュ、アドレスの種類 |
| DNSの表示地域が異なる | 名前解決サービスとWeb通信の出口は、同じ場所とは限らない | 名前解決サービスが想定した設定に従っているか |
| ブラウザーは正常だが、ほかのアプリに問題がある | アプリごとにプロキシ経路が異なる可能性がある | アプリ独自のプロキシ設定、除外設定、ルーティング |
DNSを確認：名前解決の場所と漏えいを見分ける
DNSはドメイン名を接続可能なアドレスに変換します。Webリクエストがプロキシを経由していても、名前解決も必ずプロキシ経由になるとは限りません。名前解決をトンネル内にとどめる想定なのに、実際にはローカルネットワークのDNSサービスへ送られている場合は、意図しない外部送信がないか確認が必要です。一方、ローカルドメインをローカルDNSで解決するルールが明示されているなら、その結果だけで漏えいとは判断できません。
新しいドメインの問い合わせを発生させられるDNS検査ページを使い、接続前後のDNSサービス一覧を比較します。注目するのはサービス提供元がクライアントの設定に合っているかであり、DNSサービスの国とノードの国が完全に一致することではありません。パブリックDNSの分散配置、上流への転送、検査サイトの判定方法によって、表示結果が変わることがあります。
ブラウザーのセキュアDNSとシステムDNSは分けて確認する
ブラウザーのセキュアDNSは、DoHで独自に名前解決リクエストを送信し、システムのDNS設定を使わない場合があります。そのリクエスト自体も、プロキシ経由にも直接接続にもなり得ます。確認時はまずブラウザーの設定を記録し、クライアントがそのリクエストを取り込んでいるか調べましょう。「暗号化DNSを有効にした」ことだけで「DNSがトンネル内にある」とは判断できません。
以下のコマンドは、システムの名前解決ツールが返すサーバーと結果を確認する補助になりますが、ブラウザーの名前解決経路を証明するものではありません。システムによってはローカルの転送先アドレスが表示される一方、ツールが指定したDNSサービスへ直接アクセスする場合もあります。
nslookup example.com設定を変更した直後は、DNSキャッシュが残っていて、新しい問い合わせが検査に反映されないことがあります。まず検査ページの新規問い合わせ機能を使い、その後、対象アプリを再起動して確認してください。キャッシュの消去は古い結果の影響を取り除くための手段であり、名前解決経路の確認に代わるものではありません。
アプリごとに確認：ブラウザーの結果だけでは全アプリを判断できない
対象のソフトを完全に終了してからプロキシに接続し、もう一度起動します。既存の長時間接続は以前の経路を使い続けることがあり、バックグラウンドプロセスが接続を維持している場合もあります。その後、クライアントの接続パネルで対象ドメイン、適用されたルール、出力ノード、通信量の変化を確認します。合計通信量が増えただけでは、そのソフトの通信が取り込まれたとは判断できません。
- ✅ ブラウザー：拡張機能のプロキシ設定とシステムプロキシが重複していないか確認し、確認リクエストの出力ログと照合します。
- ✅ デスクトップアプリ：アプリ独自のプロキシ設定があるか確認し、クライアントの除外対象になっていないか調べます。
- ✅ コマンドラインツール：プロキシ環境変数とツール独自の設定を確認します。ターミナルの結果をそのままブラウザーにも当てはめないでください。
- ✅ ゲーム、会議、リアルタイム通信：ログイン、コンテンツの読み込み、メディア接続をそれぞれ確認し、UDPなどの関連通信が現在のモードでサポートされているかを調べます。
- ✅ モバイルアプリ：システムVPNの状態、アプリごとの振り分け、バックグラウンド制限を確認し、ネットワークを切り替えた後に再検証します。
WindowsとmacOSでは、システムプロキシと仮想ネットワークインターフェースは異なる通信の取り込み方式です。Linuxでは、ターミナル、デスクトップ環境、アプリがそれぞれ独自のプロキシ設定を使う場合があります。iOSとAndroidのVPNインターフェースでも、アプリごとの振り分けやクライアントの機能を確認する必要があります。違いがある場合は、使用中のOSとクライアントで実際に選べる設定を基に調べてください。
対象サイトが開けることから分かるのは、現在アクセスできるということだけです。もともと直接接続できるサイトかもしれません。反対に、サイトへのアクセスが拒否されても、アカウントの地域設定、サイト側のリスク判定、サービス提供地域、アプリのキャッシュなどが原因の可能性があります。それだけでプロキシが完全に機能していないとは判断できません。
よくある違い：IPv6、WebRTC、振り分けルール
アドレスの種類ごとに通信経路が異なる
端末はIPv4とIPv6の両方で接続している場合があります。プロキシが一方しかカバーしていなければ、もう一方は接続ネットワークの出口を使う可能性があります。アドレスの種類ごとに検査できるツールを使い、クライアントのIPv6対応状況とルーティング設定を照合してください。特定の種類のアドレスが検出されなくても、現在のネットワークがその接続を提供していないだけの場合があります。その結果から、あらゆる環境で外部送信がないと結論づけることはできません。
WebRTCの結果はアドレスの種類を確認する
ブラウザーのリアルタイム通信は、候補アドレスを通じてネットワーク経路を調べる場合があります。検査結果に表示されるローカルネットワークのアドレスや、隠す処理が行われたローカルホスト名は、接続ネットワークのグローバルIPとは別のものです。想定外のグローバルIPが表示された場合は、UDPのルーティングとブラウザーの設定を追加で確認してください。アドレスが増えたというだけで、すべての通信が漏れていると判断する必要はありません。
ルール、サブスクリプション、接続状態は別のもの
サブスクリプションをインポートすると、サービスから提供されたノードや設定がクライアントに追加されますが、システムプロキシが有効になるわけではありません。サブスクリプションを更新した後も、選択中のノード、モード、ルールが想定どおりか確認してください。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどはプロトコル方式の名称です。プロトコル名だけでは、アプリの通信が取り込まれているか判断できません。
根拠に基づいて確認し、設定の変更を繰り返さない
元の設定を残し、関連する項目を一度に一つだけ変更します。たとえば、まず対象アプリがプロキシを使っていない問題を解決し、その後にDNSを確認します。ノード、ルール、DNSサービスを同時に変更すると、復旧しても原因が分かりにくくなります。テストが終わったら、日常の用途に合った設定に戻してください。
サポートに問い合わせる際は、OS、クライアントのバージョン、接続モード、問題が起きるアプリとドメインを伝え、個人情報を伏せた適用ルールと出口の変化を添えてください。「ブラウザーの出口は変わったが、対象アプリの接続は直接接続のまま」のように具体的に説明すると、「VPNが使えない」とだけ伝えるより原因を特定しやすくなります。
判断の目安：グローバルIPが想定どおりで、DNS経路が設定に合い、対象アプリが正しい出力先のルールに一致していること。これらの証拠がそろって初めて、テストした利用環境で機能していると判断できます。一度の検査で継続的な設定確認を代替することはできません。ネットワークの切り替え、クライアントの更新、ルールの変更後は、もう一度確認してください。
VPN97ではクライアントの使い方ガイドと接続先情報を提供しています。設定画面の確認にご活用ください。ログを保存しない方針はサービスのプライバシーに関する姿勢を示すものであり、端末側で意図しない直接接続が起きないことを保証するものではありません。ローカルのルーティング、DNS、アプリ設定は個別に確認してください。