VPN接続の確認方法｜IP・DNS・アプリ別チェックガイド

VPNに接続したら、本当に機能しているか確認しましょう。まずグローバルIP、次にDNSを確認し、最後に実際に使うアプリで通信経路を検証します。接続アイコンが示すのは、システムやクライアントで何らかの接続が確立したことです。すべての通信が選択した経路を通るとは限りません。確認したいのは、結果を一律に「海外」にすることではなく、実際の経路が分割トンネルの設定どおりかどうかです。

まず確認：接続状態と通信経路の違い

クライアントに「接続済み」と表示されても、システムトンネルが起動した場合もあれば、ローカルプロキシの待ち受けが始まっただけの場合もあります。サブスクリプションのインポート成功は、設定を読み込めたことを示すにすぎません。ノード認証やDNS名前解決、リモート接続まで正常とは限らないのです。画面上は簡単に緑になりますが、ネットワークまで思いどおりに動くとは限りません。

システムプロキシは通常、アプリがプロキシ設定に従うことで機能します。TUNモードは仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。一般に対象範囲は広いものの、除外設定やアプリ別ルール、システムの制限を受けます。モバイル端末にVPNの表示が出ていても、すべての通信先が同じ出口を使うとは限りません。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、それぞれ異なるプロキシプロトコルまたは方式です。名称だけでは通信の取り込み範囲は分からず、実際の確認に代わるものでもありません。IEPL専用線、中継、直結は回線の構成を表すもので、すべてのアプリで通信が有効になった証拠にはなりません。

グローバルIP：接続前後を比べ、地域だけで判断しない

IPアドレス確認ページを開き、未接続時のIPアドレスとネットワークの割り当て先を記録します。次に接続したい回線を選び、同じブラウザーで再度確認してください。テスト中はネットワークを変えず、Wi-Fiの切り替えによるIPの変化をVPNの効果と取り違えないようにしましょう。

1. 現在のモードを確認し、確認サイトへの通信がプロキシルールと直結ルールのどちらに一致するかを調べます。
2. 接続後に確認ページを再読み込みします。古いキャッシュが疑われる場合は、新しいプライベートブラウジングウィンドウでも確認してください。
3. 都市名だけでなく、IPアドレスそのもの、ネットワークの割り当て先、想定している出口を比較します。
4. 実際に使いたいウェブサイトを開き、クライアントの接続ログで通信経路を確認します。

IPアドレスの位置情報データベースは更新が遅れることがあり、ノード名の都市とデータベースに登録された都市が一致するとも限りません。IPアドレスが変わり、ネットワークの割り当て先も想定どおりなら、都市名が異なるだけで失敗と判断する必要はありません。反対に、ページの言語や検索結果が変わっても、出口が変わった証拠にはなりません。アカウントの地域設定、位置情報の権限、過去の利用傾向も表示に影響します。

IPアドレスが変わらない場合は、まず確認サイトへの通信が直結に設定されていないか調べます。ルールモードでは、それが正しい動作のこともあります。影響を理解したうえで、一時的に確認サイトのドメインをプロキシ経由に設定して再テストし、終了後は元の設定に戻してください。ひとつの確認結果のために、分割トンネルのルール全体を恒久的に無効にしないでください。

DNS：国旗ではなく名前解決の経路を確認する

DNSはドメイン名を接続先のアドレスに変換します。グローバルIPが変わったと分かるのは、そのウェブページへの通信の出口が変わったことだけです。ドメインの名前解決は、引き続きローカルネットワークで行われる場合があります。一般にDNSリークとは、DNS問い合わせが想定した経路を通らないことを指し、検査結果に特定の国が表示されたというだけでは判断できません。

DNSテストページを使うときは、説明を読み、新しいテスト用ドメインの問い合わせが実際に行われるか確認します。表示されたDNSサーバーの割り当て先を確認し、クライアントのDNS設定と照らし合わせてください。大規模なDNSサービスは分散型のサーバーを使うことがあるため、検出されたサーバーのアドレス、実際の所在地、ブラウザーの出口が一致するとは限りません。

ブラウザーのセキュアDNS、システムの暗号化DNS、クライアント内蔵のDNSリゾルバーが別々に動作する場合があります。ブラウザーで暗号化DNSを有効にすると、ブラウザー独自のHTTPS接続でDNS問い合わせが送信されることがあります。その通信がプロキシを通るかどうかは、接続に適用されるルートで決まります。つまり、「暗号化DNSを使うこと」と「DNSが必ずトンネルを通ること」は同じではありません。

DNS設定を変更した後も、既存の接続やキャッシュが結果に影響する場合があります。関連ページを閉じて接続を確立し直してから、再テストしてください。クライアントがFake-IPを使う場合、アプリにはマッピング用の合成アドレスが表示されます。これは実際のサーバーアドレスではありません。調査中は一度にひとつだけ設定を変更しましょう。そうすれば、どの設定が影響したのか分かりやすくなります。

IPv6とWebRTC：ブラウザーの検査だけでは見えない通信

IPv4とIPv6の両方を提供するネットワークもあります。クライアントがIPv4だけを取り込む設定なら、アプリがIPv6で直接接続する可能性があります。確認時は、両方のアドレスファミリーで出口を調べてください。確認ページにIPv6が表示されなかったとしても、今回はIPv6の結果を取得できなかったというだけで、端末がIPv6を使わない証明にはなりません。

想定外のIPv6経路が見つかった場合は、まずクライアントがIPv6通信の取り込みに対応しているか、関連するルートが現在の設定で有効かを確認します。影響を把握したうえで、一時的にIPv6を無効にして比較する方法もありますが、これは原因を特定するための手段であり、すべてのネットワークに適した最終解決策ではありません。

WebRTCはブラウザーのリアルタイム通信に使われ、通常のウェブページとは異なるネットワーク候補アドレスを取得することがあります。ローカルのプライベートアドレスや、隠す処理が施されたローカルホスト名は、パブリックIPの漏えいと同じではありません。確認すべきなのは、本来隠すべきローカルネットワークのパブリックIPが露出していないか、メディア通信が想定した経路を通っているかです。

ブラウザー拡張機能の影響は通常、ブラウザー内の一部の通信に限られ、対応範囲は実装によって異なります。会議ソフトやデスクトップアプリも使う場合、拡張機能の検査結果を端末全体の判定として扱わないでください。

アプリ別に確認：ウェブが使えても、オフィスアプリは別

WindowsやmacOSでは、システムプロキシを参照するアプリ、独自のプロキシ設定を使うアプリ、直接接続するアプリがあります。Linuxの環境変数も、対応するプロセスにしか適用されず、すべてのアプリの通信経路が自動で変わるわけではありません。コマンドラインで通信できても、デスクトップアプリの動作確認にはなりません。

iOSやAndroidのクライアントは、通常、システムが提供するネットワーク拡張機能やVPNインターフェースを通じて動作します。それでも、アプリごとの除外設定、オンデマンド接続、ルール設定によって通信の取り込み範囲は変わります。クライアントによって画面も異なるため、画面上部のアイコンだけで特定アプリの通信を判断することはできません。

• ✅ 対象のアプリを開き、文書の読み込み、コンテンツの同期、テスト会議への参加など、実際の操作を行います。ログイン画面を表示するだけでは不十分です。
• ✅ クライアントの接続ログも確認し、対象ドメイン、適用されたルール、実際の出口を照合します。
• ✅ ルールを変更したら対象アプリを終了して再起動し、新しい接続を確立します。既存のセッションが使い続けられるのを防ぎます。
• ❌ ブラウザーでサイトが開くことを、会議の音声・映像、ファイル同期、コマンドラインツールも機能している証拠にしないでください。

会議ソフトでは、ログイン、メッセージ、メディアの送受信に別々のドメインや通信方式を使う場合があります。ウェブ版にはログインできてもメディアが使えないときは、関連する接続とUDPの対応状況を個別に確認し、すぐにDNSが原因だと決めつけないでください。調査情報を共有する際は、必要なエラー情報とルールだけを提示し、アカウント識別情報やサブスクリプションの内容は隠してください。

接続しても機能しないときは、症状から原因を絞り込む

ブラウザーでは使えるが、ほかのアプリは元のネットワークを使う

まず、アプリがシステムプロキシを無視していないか、アプリの除外設定がないか、TUNでの取り込みが必要かを確認します。組織が管理する端末では、ネットワークポリシーを独断で上書きしないでください。管理者に許可されている設定方法を確認しましょう。

クライアントは接続済みなのに、どのサイトにもつながらない

サブスクリプションが更新されているか、ノードが利用可能か、認証情報が有効か、クライアントがサブスクリプションで使われているプロトコルや設定項目に対応しているかを確認します。サブスクリプションURLはウェブページのURLでも、ノードそのものでもありません。インポート後は、実際に使用するノードを選び、通信の取り込みを有効にする必要があります。基本操作は使い方ガイドをご覧ください。

出口は想定どおりなのに、特定のサイトで地域制限やアクセス制限が表示される

必ずしも接続の失敗とは限りません。ウェブサイトはアカウントの地域、IPアドレスの評価、位置情報、既存のセッションなどを総合的に判断する場合があります。まず対象の通信が使う出口を確認し、その後でサイトの表示を確認してください。地域制限の表示をもとに、回線全体が機能していないと判断しないでください。

切断後もアプリを使える

対象への直結が許可されているなら、これは正常な動作です。ページのキャッシュや読み込み済みの内容も、確認結果に影響します。トンネルが切断されたときに直結を防ぎたい場合は、クライアントに通信遮断機能があるか、その対象範囲も含めて確認してください。影響を管理できる環境でテストし、進行中の業務セッションでは試さないでください。

確認結果のまとめ：それぞれの証拠が示す範囲を把握する

確認後は、ネットワーク、クライアントのモード、ノード、対象アプリと、それぞれの結果を記録しておきましょう。ネットワークを切り替えたりルールを更新したりした後は、問題があった経路を重点的に再確認すれば十分です。サブスクリプションURL全体を公開しないでください。アクセスに使える認証情報が含まれていることが多く、漏えいした場合は管理画面の手順に従って再設定してください。