VPN接続を確認する方法｜グローバルIPとDNSのチェックガイド

接続状態と通信経路を区別する

「接続済み」の意味はクライアントによって異なります。システムトンネルの確立を示すものもあれば、ローカルプロキシサービスの待ち受け開始を示すだけのものもあります。ノードに到達できなくてもローカルプロキシが起動する場合があり、ノードに到達できてもアプリがそのプロキシを使っていない場合があります。

システムプロキシは通常、システムのプロキシ設定に従うプログラムで使われますが、すべての通信を自動的にカバーするわけではありません。TUNモードは仮想ネットワークインターフェースを通じ、ルーティング条件に合う通信を取り込みます。対象範囲はより広い傾向がありますが、除外ルールや権限、クライアントの実装による影響は残ります。モバイル端末にVPNアイコンが表示されても、すべてのアプリが同じ出口を使うとは限りません。

「ノードの遅延テストに成功」と「目的のウェブサイトにアクセスできる」も別の事象です。前者は特定の接続先やテスト用アドレスを調べているだけの場合があります。後者にはDNS、通信ルール、接続先サービスの状態、アカウントの制限も関係します。Shadowsocks、VMess、Trojan、VLESSなどのプロトコル名だけでは実際の動作を確認できません。対応する伝送機能を使えるかどうかは、クライアントとサービスの設定を確認してください。

グローバルIPの確認：接続前の値を記録して比較

グローバルIPは、接続先のウェブサイトから見える送信元アドレスです。ルーター内でパソコンに割り当てられるローカルアドレスとは異なります。システムのネットワーク設定に表示されるローカルアドレスを、IP確認サイトの結果と比較しないでください。結果に表示される国、都市、通信事業者はIPアドレスのデータベースに基づくため、更新が遅れている場合があります。地域表示はあくまで参考情報です。

1. 未接続時の結果を記録します。クライアントの接続を一時停止し、ブラウザーで「グローバルIP 確認」などと検索して、信頼できる確認ページを開きます。表示されたIPアドレス、地域、ネットワーク名を記録してください。比較中は同じネットワークを使い、Wi-Fiを切り替えないようにします。
2. 接続してモードを確認します。対象ノードを選び、システムプロキシまたはTUNがガイドどおりに有効か確認してください。ルールモードの場合は、確認ページ自体がプロキシ経由になる設定かも確かめましょう。確認ページにローカルIPが表示されても、それがルールどおりの結果である可能性があります。
3. もう一度確認します。確認ページを更新し、必要に応じてプライベートウィンドウで開き直して、IPアドレスが変わったか比較します。キャッシュや特定のデータベースの誤判定を避けるため、別の確認サービスでも照合してください。
4. 対象アプリでも確認します。クライアントの接続ログを開き、対象ドメインへのアクセスがプロキシルールに一致し、選択したノードを使っているか確認してください。テスト後は必要な通信ルールを元の設定に戻します。

確認ページにIPv4とIPv6の両方が表示される場合は、それぞれを確認してください。設定によっては片方しか取り込まれず、ブラウザーがもう一方の経路を優先することがあります。「どれか一つのIPが変わった」だけで、すべての通信が取り込まれたと判断しないでください。クライアントのIPv6対応状況とルーティングの説明に沿って対処します。

DNS漏れ：国ではなく名前解決の経路を確認

DNSはドメイン名をネットワークアドレスに変換します。ウェブ通信がプロキシ経由でも、名前解決まで同じ経路を使うとは限りません。DNS漏れに当たるかどうかは、想定した設定と照らして判断します。名前解決もトンネル経由にする設定なのに、ローカルネットワークから問い合わせが送信されている場合は、経路のずれとして対処が必要です。

接続後、信頼できるDNS漏れテストのページを検索して開き、案内に従ってテストを実施します。表示されたDNS事業者名を記録し、クライアントのDNS設定と照らし合わせてください。この種のテストは通常、専用ドメインを使って問い合わせに関与した再帰DNSサーバーを特定しますが、端末からDNSサーバーまでの通信経路全体を直接表示するものではありません。

そのため、ローカルの通信事業者のDNSが表示された場合は確認が必要です。一方、海外のパブリックDNSが表示されたからといって、DNS漏れがないとは限りません。パブリックDNS事業者は近くの拠点で接続を受け付けることがあり、ブラウザーのセキュアDNS（DoH）がシステムのDNSとは別に動作する場合もあります。DNS事業者の所在地だけでは判断できません。

• ✅ クライアントのリモートDNS、直接接続用DNS、ドメインごとの通信ルールを確認し、それぞれの用途を把握します。
• ✅ ブラウザーのセキュアDNSとクライアントの設定が競合していないか確認します。設定を変更したらブラウザーを再起動して、もう一度テストしてください。
• ✅ クライアントのログでDNS解決とルールの適用状況を確認し、テスト用ドメインが想定した経路を通ったか調べます。
• ❌ すべてのDNSアドレスを見慣れないパブリックDNSに変更しないでください。元の設定を迂回してしまう可能性があり、ルーティングの問題が解決するとも限りません。

DNS設定を変えても、既存のDNSキャッシュやアプリの長時間接続が以前の結果を使い続ける場合があります。まず対象アプリを終了してから開き直してください。システムのキャッシュを消去する必要がある場合は、利用しているプラットフォームの公式手順を参照します。ノード、DNS、ルールを同時に変更すると、テストに成功しても原因を特定しにくくなります。

アプリごとに確認：ブラウザーで成功してもすべて有効とは限らない

ブラウザー拡張機能の影響は、多くの場合ブラウザー内の通信に限られます。独立したアプリが自動的にプロキシを使うわけではありません。反対に、拡張機能がシステムプロキシの設定に優先し、ウェブ通信とほかのプログラムで出口が異なることもあります。切り分ける際は、不要なプロキシ拡張機能を一時停止し、通信を取り込む方法を一つに絞ってください。

WindowsとmacOSでは、ほかのネットワークツールによってシステムプロキシ設定が書き換えられていないか、対象アプリがその設定に従うかを確認します。Linuxのデスクトップ環境のプロキシ設定も、コマンドラインのプログラムに反映されるとは限りません。環境変数からプロキシ設定を読み込むプログラムもあれば、個別設定が必要なものもあります。ブラウザーでの確認だけでは、ターミナルツールの通信経路までは分かりません。

iOSとAndroidのクライアントは通常、システムが提供するVPNインターフェースを使いますが、アプリごとの除外や接続先ごとのルーティングが設定されている場合があります。ブラウザーは使えるのに独立したアプリで問題が起きる場合は、ノードの障害と決めつけず、まずアプリが除外されていないか、対象ドメインが直接接続のルールに一致していないか確認します。

実用的なのは、クライアントの接続ログを開いてから対象アプリを起動し、ログイン、コンテンツの読み込み、リクエストの送信など、実際の操作を行う方法です。新たに表示されるドメイン、適用されたルール、出口ノードを確認してください。アプリが複数のドメインに同時接続することもあります。トップ画面が開いただけでは、ログインやメディアの通信が同じ経路を使ったとは限りません。

よくある「偽の接続」を切り分ける手順

出口が変わらない場合：まずルール、次に通信の取り込みを確認

ルールモードでは一部のウェブサイトを直接接続できるため、日本国内のIP確認ページにローカルの出口が表示されても、必ずしも異常ではありません。まずそのリクエストに適用されたルールを確認してください。比較する必要がある場合は、テスト対象の通信だけを一時的にプロキシ経由にして、確認後に元の設定へ戻します。クライアントが「グローバルモード」と表示していても、対象範囲を確認してください。実装によっては、システムのすべての通信を取り込むわけではありません。

ウェブページは開くのに、アプリでエラーが出る

まずアプリの通信がプロキシ経由か、関連ドメインに適切なルールが適用されているかを確認します。経路を確認したうえで、地域の利用条件、アカウントの状態、サービス側の障害、出口IPに対する制限を調べてください。キャッシュされたページが開いているだけで、正常に通信できているように見えることもあります。すでに読み込まれたページではなく、新しい通信を必要とする操作で確かめましょう。

ノードを切り替えても結果が変わらない

以前の接続が維持されていたり、アプリが古いセッションを再利用していたりする可能性があります。対象アプリを終了して開き直し、新しい接続のログを確認してください。それでも変わらない場合は、現在のポリシーグループで選択されているノードを確かめます。自動選択、フェイルオーバー、アプリ専用のポリシーグループが、メイン画面に表示された選択と異なる場合があります。

サブスクリプションをインポートできても、正常にアクセスできない

サブスクリプションをインポートできたことから分かるのは、クライアントが設定を読み込めたということだけで、ノードが使える証拠にはなりません。サブスクリプションが更新済みか、アカウントのプランが有効か、クライアントが設定で使われているプロトコルと伝送方式に対応しているかを確認してください。接続を直すために証明書の検証を無効にしたり、入手先の分からない証明書をインストールしたりしないでください。まずサービスのガイドに沿って設定を確認します。

別の経路に切り替えて正常に動作する場合は、元の経路、問題が起きたアプリ、エラーメッセージ、適用されたルールを記録してサポート窓口に伝えてください。IEPL専用線、中継、直接接続は経路の構成方法を表すもので、端末側のプロキシ設定やDNS設定の代わりにはなりません。経路の名称だけでは接続が有効である証拠になりません。

最後にチェックリストで確認

接続のたびにすべてのテストを行う必要はありません。初回設定時、クライアントの切り替え後、ルールの変更後、地域表示に問題があるときに、同じ手順で確認してください。何度も再インストールするより、簡単な記録を残すほうが問題を特定しやすくなります。

• ✅ 接続前後のグローバルIPを記録し、テスト対象の通信がプロキシ経由になる設定か確認しました。
• ✅ DNS設定とブラウザーのセキュアDNSを確認し、DNS事業者の国だけで判断していません。
• ✅ 対象アプリで実際に通信する操作を行い、該当する接続ログを確認しました。
• ✅ IPv6、アプリの除外、既存の接続を確認し、テスト後に普段使う通信ルールへ戻しました。

VPNUYの利用者は、まず使い方ガイドでクライアントの設定をご確認ください。サポートが必要な場合はヘルプセンターからお問い合わせのうえ、個人情報を隠したエラーメッセージと確認記録をお送りください。