VPN接続後の確認方法｜出口IP・DNS・アプリ別にチェック

まず確認：接続成功と通信経路の有効化は別

一般にVPNと呼ばれるツールでも、通信を処理する方法はさまざまです。システムレベルのトンネルは、ルーティングされた通信を取り込めます。一方、ローカルプロキシはアプリがシステムプロキシ設定に従う必要があり、クライアントの仮想NICモードで通信を処理する場合もあります。システムプロキシだけを有効にしていると、それに従わないアプリは直接通信することがあります。

ルールモードでは、リクエストごとに経路を分けることもあります。特定のドメインはプロキシ経由、ローカルネットワークや一部のWebサイトは直接接続、といった設定です。そのため、「すべてのサイトで出口IPが変わること」は共通の合格基準ではありません。まず、確認したい対象が特定の海外サイトなのか、デスクトップアプリなのか、端末でサポートされるすべての通信なのかを明確にしましょう。対象範囲によって判断は異なります。

出口IPを確認する：接続前後を比較

出口IPは、Webサイトから見たリクエストの送信元アドレスです。家庭内ネットワークで端末に割り当てられたローカルIPとは異なります。システムのネットワーク設定に表示されるローカルアドレスでは、通常、プロキシが機能しているかを判断できません。信頼できるグローバルIP確認サイトを使い、接続前後で同じサイト、同じブラウザーを使って比較してください。

1. 接続前の状態を記録。一時的に接続を切っても問題のない環境で、現在のグローバルIP、ネットワーク事業者、アドレスの種類を確認します。確認のみを行い、このテスト中に機密性の高い作業はしないでください。
2. 接続し、モードを確認。ノードを選び、クライアントがルールモード、グローバルプロキシモード、仮想NICモードのどれを使うか記録します。システムプロキシや通信を取り込む関連設定が有効になっていることも確認してください。
3. リクエストを再送信。確認ページを再読み込みします。必要に応じてブラウザーを完全に終了してから再起動し、既存の接続が再利用される影響を減らしましょう。シークレットウィンドウでは一部サイトの状態の影響を抑えられますが、システムのネットワーク設定を自動で回避するものではありません。
4. クライアントの記録と照合。クライアントに接続一覧がある場合は、確認ページのドメイン、適用ルール、送信先の経路を探します。ページの表示とクライアントの記録が一致すれば、判断材料がよりそろいます。

IPが変わらない場合は、まず確認サイトへの通信がルールで直接接続に設定されていないか確認しましょう。すぐにノードの故障と決めつける必要はありません。IPが変わっても、位置情報に表示される都市だけで経路の真偽を判断しないでください。位置情報データベースの更新が遅れていたり、確認サービスごとに同じアドレスの表示が異なったりすることがあります。地図上の都市名より、ネットワーク事業者、アドレスの変化、クライアントの送信記録のほうが参考になります。

確認サービスでIPv4とIPv6を別々に表示できる場合は、それぞれ確認してください。一部の通信はプロキシ経由でも、もう一方のアドレス種類はローカルネットワーク経由のままということがあります。異常かどうかは、クライアントの対応状況と通信を取り込む範囲によって異なります。片方だけを確認して、端末全体が保護されていると判断しないでください。

DNSを確認する：名前解決の送信元と実際の経路

DNSはドメイン名を接続可能なアドレスに変換します。出口IPが変わっていても、ドメインの問い合わせがローカルネットワークの設定に従って送信される場合があります。DNSの問い合わせも指定した経路を通したい場合、想定と異なる送信経路がないか確認しましょう。ただし、「DNSサービスの所在地とノードの地域が異なる」だけでは、情報漏えいの証拠にはなりません。

一般的なDNSテストサイトは、専用のドメインへの問い合わせを発生させ、名前解決に関わった再帰リゾルバーを表示します。通常表示されるのは、再帰リゾルバーが外部に問い合わせた際の送信元であり、端末がリクエストをどこへ渡したかを直接示すものではありません。パブリックDNSは分散配置されていることがあるため、地域表示だけで端末が想定外の経路を通ったとは判断できません。

ブラウザーのセキュアDNSとシステムDNSを分けて確認

ブラウザーのセキュアDNSは、DoHなどの暗号化DNSを使うことが一般的です。システムDNSとは別に動作することがありますが、暗号化されたリクエストがプロキシ経由か直接接続かは、アプリの動作、ルーティング、クライアントのルールによって決まります。したがって、ブラウザーの検査結果が正常でも、ほかのアプリも同じとは限りません。特定のパブリックDNSが表示されても、それだけで失敗とは言えません。

ブラウザーのセキュアDNS、システムDNS、クライアントのDNSモードをまず記録し、複数の設定を同時に変更しないでください。クライアントにDNSクエリの記録機能があれば、対象ドメインに新しいリクエストを送り、名前解決の経路と適用ルールを確認します。キャッシュにより新たな名前解決が発生しない場合は、OSまたはクライアントの案内に従って該当するキャッシュを削除し、再度テストしてください。

プロキシプロトコルとDNSの処理方式は別のものです。Shadowsocks、VMess、Trojan、VLESSなどのプロトコル名だけでは、DNSをローカルとリモートのどちらで処理するかは分かりません。実際の動作は、クライアントのコア、設定、分割トンネルの方式にも左右されます。Fake-IPモードでは、クライアントが内部マッピング用の仮想アドレスを返すことがあります。これをDNS汚染と即断しないでください。

アプリごとに確認：ブラウザーだけでは不十分

同じ速度測定ページを何度も開くより、実際に使いたいアプリを一つずつテストするほうが有効です。Webページ、デスクトップアプリ、リアルタイム通信機能は、それぞれ異なるネットワークライブラリや通信方式を使うことがあります。同じアプリ内でも、機能によって経路が異なる場合があります。

• ✅ ブラウザー：対象サイトを開き、実際のページ内容を確認します。クライアントの接続記録でドメインと送信先の経路も照合してください。
• ✅ デスクトップアプリ：完全に終了してから再起動し、コンテンツの更新やファイルの同期など、実際の操作を行って対応する通信が発生するか確認します。
• ✅ 会議・通話：ログイン、会議への参加、音声・映像の送受信をそれぞれ確認します。ログインできたことだけで、メディア通信の経路まで正常だと判断しないでください。
• ✅ 開発ツール：ツール独自のプロキシ設定と、ターミナル環境のプロキシ変数を確認します。システムプロキシと一致しているとは限りません。
• ✅ ローカルリソース：プリンター、LAN共有、社内ネットワークに想定どおりアクセスできるか確認し、通信を取り込む設定で正常な直接接続まで妨げないようにしましょう。

WindowsとmacOSでは、システムプロキシに従うアプリもあれば、独自の設定を使うアプリもあります。モバイル端末のVPNアイコンは、関連するネットワーク接続が存在することを示しますが、アプリごとの除外設定、分割トンネルのルール、クライアントの権限によって通信を取り込む範囲が変わる場合があります。別のプラットフォームに切り替えた場合は、通信の処理方式を改めて確認してください。ほかの端末でのテスト結果をそのまま当てはめることはできません。

リアルタイムメディアや一部のWeb通信はUDPを使います。システムのHTTPプロキシが、あらゆるUDP通信を自動で取り込むわけではありません。仮想NICモードで正しく処理できるかどうかも、クライアント、プロトコル、経路の対応状況によります。「Webは使えるのに通話できない」場合は、DNSだけを変更するのではなく、該当する通信が取り込まれているか確認してください。

ブラウザーのWebRTCテストでは、アドレスの種類を区別しましょう。LAN内のアドレスや、mDNSで隠されたローカル識別子が表示されても、Webサイトに実際のグローバルIPが見えているとは限りません。想定と異なるグローバルIPが検出された場合は、ブラウザーの権限、UDPの通信経路、クライアントの記録をあわせて確認してください。

接続済みなのに通信経路が変わらない場合の対処

ブラウザーは正常なのに、ほかのアプリは直接接続する

まず、システムプロキシが適用される範囲、アプリ独自のプロキシ設定、除外ルールを確認してください。より広い範囲の通信を取り込む必要があれば、クライアントの案内に従って仮想NICモードを検討できます。ただし、クライアントの「グローバルプロキシ」は、端末のすべての通信を自動で取り込むという意味ではありません。ツールによっては、プロキシコアに渡されたリクエストを一つの送信先に統一する意味にとどまります。

ノードを変更しても、結果が変わらない

ブラウザーのプロキシ拡張機能がシステム設定より優先されていないか、ほかのプロキシツールが動作していないか、対象ドメインが固定ルールで別の送信先に割り当てられていないかを確認します。その後、対象アプリを再起動し、既存の接続が再利用される可能性を排除してください。複数のノードで同じグローバルIPが表示される共有出口もあるため、クライアントで選択した送信先の記録も確認しましょう。

出口IPは変わったのに、対象サービスが利用できない

必ずしもプロキシが機能していないとは限りません。サービスがアカウントの地域、利用許可の範囲、Cookie、リスク管理などをもとに判断している場合や、サービス側で障害が発生している場合もあります。まず通常のWebページやアプリの基本通信を確認し、接続タイムアウト、名前解決の失敗、証明書エラー、サービス側のアクセス拒否を切り分けましょう。証明書エラーを回避するために、証明書検証を無効にしないでください。

ノードを選べるのに、接続に失敗し続ける

サブスクリプションのインポートに成功したことは、クライアントが設定を取得できたことを示すだけで、ノードに現在接続できることを保証しません。サービスの案内に従ってサブスクリプションを更新し、システム時刻、クライアントの互換性、エラーログを確認してください。サブスクリプションURLには接続情報が含まれるため、公開の検査サイトに貼り付けたり、相談用のスクリーンショットに全体を表示したりしないでください。

IEPL専用線、中継、直接接続は、回線の構成方法を表すものであり、端末側で通信が取り込まれているかの確認に代わるものではありません。どの種類の回線を選んでも、アプリの通信がプロキシに渡されていなければ、その回線の特性はリクエストに反映されません。まず経路を確認し、その後で利用時の体感を比較することが、目的に合う回線を選ぶ順序です。

再テストと問い合わせ：状況を説明できる記録を残す

原因を調べるときは、同じ端末、同じネットワーク、同じ接続先を使い、一度に変更する設定は一つにして、同じ操作を再度行いましょう。ノード、DNS、モード、キャッシュを一度に変更すると、アクセスが復旧しても原因を特定しにくくなります。同じ問題が再発したときに、また最初から推測することになります。

問い合わせには、発生日時、OS、クライアント名、通信を取り込むモード、対象ドメイン、エラーメッセージ、試した操作を記載してください。ログは関連箇所だけを抜き出し、アカウント情報、サブスクリプションURL全体、トークン、不要なグローバルIPアドレスを隠しましょう。さらに確認する場合はトラブルシューティングガイドを参照するか、サポートチケットからお問い合わせください。

プライバシーについても、別の観点から確認する必要があります。VPNの接続確認で検証できるのはリクエストの通信経路であり、サービスのプライバシーへの取り組み全体を監査できるわけではありません。VPNSweetのノーログポリシーはサービス方針の説明であり、一度のIP確認やDNSテストから絶対的な保証を導くことはできません。