VPNが接続済みでも、IPチェックで確認できるのは現在のリクエストの出口です。DNSを調べれば名前解決の経路が想定どおりか確認でき、実際に使うアプリも個別に検証する必要があります。クライアントに「接続済み」と表示されれば接続状態は正常と考えられますが、ブラウザーやゲーム、業務アプリがすべて同じ経路を使っているとは限りません。
判断のポイント：出口が想定どおりで、名前解決の経路が設定と一致し、対象アプリに想定したルールが適用されていることを確認できれば、十分な検証になります。ルール分岐では、一部の通信が通常の回線を使うのは正常です。「すべてのサイトでIPが変わること」だけを判断基準にしないでください。
まずモードを確認：接続状態とアプリの通信経路は別
日常的に使われる「VPN」は、OS全体を対象にするトンネルを指す場合もあれば、ローカルのプロキシポートを提供するクライアントを指す場合もあります。アプリの通信を処理する仕組みはそれぞれ異なります。システムプロキシは、対応するソフトウェアにリクエストをプロキシへ渡すよう指定するもので、端末の全通信を制御するものではありません。一部のゲームやコマンドラインツール、バックグラウンドのプログラムは、この設定を無視することがあります。
トンネルモードでは通常、仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を処理します。ただし、アプリの除外設定や直接接続ルール、DNS設定、アドレスファミリーの扱いによって違いが生じることがあります。「グローバルプロキシ」は、クライアントに入ったリクエストの出口を一律にプロキシへ振り分ける意味で使われることが多く、すべてのアプリの通信が取り込まれているとは限りません。「どのリクエストがクライアントに入るか」と「入ったリクエストがどの経路を使うか」は分けて確認しましょう。
サブスクリプションURLは、ノードや関連設定をクライアントに取り込むためのものです。インポートに成功しても、システムプロキシやトンネルが有効になったとは限りません。Shadowsocks、VMess、Trojan、VLESSなどはプロキシのプロトコルまたはプロトコル体系を示す名称であり、それだけで端末上のアプリがどこまで対象になるかは判断できません。まず現在のモードと設定を確認し、そのうえで回線の状態を調べてください。
検証を始める前に、選択中のノード、プロキシモード、現在のネットワークを記録してください。テスト中に変更する設定はできるだけ一つに絞りましょう。そうしないと、アクセスが復旧しても、どの変更が効果をもたらしたのか分からなくなります。
出口IPを確認：接続前後の結果を比較
信頼できるパブリックIP確認サイトを選び、接続を切った状態で結果を記録してから、想定する経路に接続し、同じブラウザーで再度確認します。IPアドレス全体と、確認サイトが示すネットワークの情報を記録し、国旗の表示だけで判断しないでください。IP位置情報データベースの更新には時間がかかることがあり、表示される都市がサーバーの実際の設置場所とは限りません。
- 基準値を記録。未接続時のパブリックIPアドレスを保存し、そのとき使っていたのが自宅、職場、モバイルデータ通信のどれかも記録します。
- 接続して再確認。ノードが選択されていることを確かめ、必要なプロキシまたはトンネルモードを有効にして、確認ページを再読み込みします。必要に応じてブラウザーの新しいセッションで試してください。
- 通信経路を確認。クライアントの接続ログを見て、確認用ドメインがプロキシ経由か直接接続かを確認します。ルールモードでは、確認サイトが直接接続に振り分けられることがあります。
- アドレスファミリーを確認。確認ツールが対応している場合は、IPv4とIPv6それぞれのパブリックIPを確認し、片方の経路だけで判断しないようにします。
接続後もIPが変わらない場合、プロキシが有効になっていない可能性もあれば、確認サイトがプロキシを通っていないだけの可能性もあります。ノードを何度も切り替えるより、確認用ドメインを一時的にプロキシ経由に設定して比較するほうが、原因を特定しやすくなります。反対にIPが変わっても、そのブラウザーのリクエストが別の出口を通ったことしか分かりません。他のアプリでも同じように機能しているとは限りません。
IPv4の出口は変わったのにIPv6が通常のネットワークのままなら、クライアントがIPv6の通信を取り込んでいるか、現在の設定でIPv6の直接接続が許可されているかを確認してください。これはルーティング範囲の問題で、DNSリークとは別のものです。原因を確認する前に、特定のアドレスファミリーを常に無効にする方法を一般的な解決策として扱わないでください。
DNSを確認：地域だけでなく名前解決の経路を見る
DNSはドメイン名を接続先のアドレスに変換します。DNSリークとは、本来想定していた保護経路を通るはずの問い合わせが、実際には別の経路、たとえばローカルネットワークのリゾルバーへ直接送信される状態を指します。Web通信がプロキシ経由でも、DNSの問い合わせまで同じ経路を通るとは限りません。実際の動作はクライアント、ブラウザー、OSの設定によって異なります。
信頼できるDNSチェックツールを使い、接続前後のリゾルバー情報を比較して、クライアントのDNSポリシーと照らし合わせます。多くのチェックサイトは専用ドメインへの問い合わせを発生させ、観測された再帰リゾルバーの出口を表示します。この結果は、端末上のすべてのDNS問い合わせを記録したものではありません。
リゾルバーがローカル地域に表示されても、それだけでリークが起きているとは断定できません。海外に表示されても、クライアントがDNSを適切に処理している保証にはなりません。パブリックDNSサービスはエニーキャストネットワークを使うことがあり、データベースの位置情報も正確とは限りません。より確かな判断には、誰が問い合わせを発行したのか、どのリゾルバーに送ったのか、どの方式で通信したのか、想定したルートが適用されたのかを確認します。
ブラウザーのセキュアDNSは、OSのリゾルバーを使わず、独自に暗号化DNSサービスを利用する場合があります。そのため、ブラウザーとシステムの確認結果が一致しないことは珍しくありません。暗号化DNSが保護するのはDNS問い合わせの通信であり、Webリクエストの出口IPを自動的に隠すものではありません。DNS接続がプロキシ経由かどうかは、別途ルールを確認してください。
システムコマンドで確認できること
Windowsでは、次のコマンドでシステムの名前解決ができるか確認できます。example.comは説明用のドメインであり、VPNの検査サービスではありません。
Resolve-DnsName example.commacOSまたはLinuxでは、対応するツールがインストールされていれば、以下のコマンドで名前解決の結果とツールが報告するサーバーを確認できます。
nslookup example.comコマンドが成功しても、その時点で名前解決できたことを示すだけです。DNSの経路がプロキシを通っている証明にはならず、ブラウザーが同じ設定を使っているとも限りません。ローカルのフォワーダーや仮想アドレスが表示された場合は、異常と決めつけず、クライアントの設定と上流の経路をあわせて確認してください。
確認ページの表示を「緑」にするためだけに、セキュリティソフトを無効にしたり、すべてのネットワーク設定をリセットしたりしないでください。まず現在の設定を保存し、ブラウザーのセキュアDNS、システムのリゾルバー、クライアントのDNSがそれぞれどの範囲を担当しているかを確認してから、元に戻せる変更を試します。
アプリごとに検証：ブラウザーが正常でもすべて正常とは限らない
実際に使うアプリでテストしてください。ブラウザー、デスクトップアプリ、ゲームでは、利用するネットワークインターフェースやプロキシ設定、通信方式が異なる場合があります。Webサイトは開けるのにデスクトップアプリが使えない場合は、すぐにノードの障害と判断せず、まずそのアプリの通信がプロキシに入っているかを確認しましょう。
テスト中はクライアントの接続ログを開き、対象アプリで新たな通信を発生させます。たとえば、リモートリストを更新する、キャッシュされていないページを読み込むなどの操作です。対象のドメインやプロセス、適用ルール、出口の選択、エラーメッセージを確認してください。アプリの再起動で古い接続が終了することもありますが、編集途中の内容は先に保存しましょう。
- ✅ ブラウザー：システムプロキシ、独自のプロキシ拡張機能、セキュアDNSを確認し、設定が互いに上書きし合っていないか確かめます。
- ✅ デスクトップアプリ：アプリ独自のプロキシ設定を確認します。システムプロキシに対応していない場合は、クライアントの説明を確認したうえでトンネルモードを検討してください。
- ✅ ゲーム・リアルタイム通信：必要な通信が現在の設定で処理されているか確認します。Webサイトでのテストは、こうしたアプリの実動確認の代わりにはなりません。
- ✅ iOS・Android：OSの接続状態とクライアントのアプリ範囲設定を確認し、ほかのネットワークツールが通信を制御していないか注意してください。
- ✅ Windows・macOS・Linux：実際に動作しているクライアントと設定を確認します。プラットフォームに対応していても、すべてのクライアントの初期設定や動作が同じとは限りません。
複数のプロキシツールに同時にシステム設定を変更させないでください。ブラウザー拡張機能、システムプロキシ、トンネルが重なると、想定と異なる経路で通信することがあります。まずは構成が明確なテスト経路を一つ用意して検証し、問題がなければ必要なツールを一つずつ戻しましょう。
よくある問題と確認手順
以下では、観測できる症状ごとに整理しています。表の原因は確認の手がかりであり、症状だけで診断が確定するわけではありません。まず適用されたルールを確認し、次に対象範囲を見直し、最後に回線の変更を検討してください。
| 症状 | 考えられる原因 | まず確認する項目 |
|---|---|---|
| IPを確認しても変わらない | 確認サイトが直接接続になっている、またはブラウザーがプロキシを使っていない | 確認用ドメインに適用されるルールとブラウザーの設定 |
| Webサイトは使えるがアプリは使えない | アプリがシステムプロキシを使っていない、または必要な通信が処理されていない | アプリのプロキシ設定とクライアントの接続ログ |
| DNSチェックとシステムの結果が異なる | ブラウザーが独自に名前解決している、またはシステムがローカルフォワーダーを使用している | セキュアDNSの設定とクライアントの上流DNSポリシー |
| 出口の地域は合っているのにサービスを利用できない | サービス側がアカウント、位置情報の権限、出口の信頼性などを総合的に判定している | サービス側のメッセージとアカウントの地域を確認し、設定を何度も作り直さない |
| 一部の通信が引き続き通常のネットワークを使う | ルール分岐、アプリの除外、アドレスファミリーの適用範囲が異なる | 対象のプロセスやドメイン、IPv6のルート |
サービス側で地域制限が表示されても、VPNが機能していないとは限りません。出口IPはサービス側が使う判定材料の一つにすぎません。また、ブラウザーの位置情報権限の結果をパブリックIPの情報と混同しないでください。端末の位置情報とIPアドレスによる位置推定は、別々の情報源です。ネットワーク経路とサービスへのアクセス結果を分けて確認しましょう。
IEPL専線、中継、直接接続は、回線の構成方式を表すもので、ここまでの確認作業に代わるものではありません。回線自体が正常でも、アプリの通信がプロキシに入っていなければ、その回線は使われません。回線の種類を変えても、誤った振り分けルールが自動で修正されることはありません。
記録を残す：あとから確認できる結論に
テスト後は、ネットワーク環境、クライアントのバージョン、ノード名、プロキシモード、確認サイトに適用されたルール、対象アプリの実際の動作を記録します。サポートに問い合わせる際は、個人情報を伏せたエラー情報と関連する接続ログを共有すると、「接続済みなのに使えない」とだけ伝えるより原因を特定しやすくなります。
スクリーンショットを撮る前に、サブスクリプションURL、アカウント情報、アクセストークンを隠してください。パブリックIPや接続ログも、必要な場合に限って共有します。サブスクリプションURLには認証情報が含まれることがあるため、出所の分からないオンライン変換・検査サイトに送信しないでください。通常、検査サイトがブラウザーの出口を確認するために、サブスクリプションの内容を知る必要はありません。
最終的な判断：まずアプリの通信がクライアントに入っているか確認し、次に出口とDNSがルールどおりかを確かめ、最後に対象サービスへのアクセスを検証します。この順序で確認すれば、設定の問題、名前解決の問題、サービス側の制限を切り分けられ、正常なルール分岐を接続不良と誤認するのも防げます。