VPN 接続後のIPアドレス・DNS確認ガイド｜初心者向け確認方法

接続状態と通信経路を分けて考える

クライアントの「接続済み」は、システムのトンネルが確立した状態を示す場合もあれば、ローカルプロキシが起動しただけの場合もあります。意味はクライアントの仕様によって異なります。アプリがそのプロキシを使っていない場合や、対象ドメインが直接接続のルールに該当する場合は、従来のネットワーク経由で通信します。

システムプロキシが影響するのは、通常、システムのプロキシ設定に従うソフトウェアです。仮想ネットワークアダプター方式なら、より広い範囲の通信を処理できますが、ルーティング、除外アプリ、プロトコル対応、DNS設定などの影響を受けます。「グローバルプロキシ」でも端末の全通信が必ずトンネルを通るとは限りません。クライアントの説明と実際のテストで確認してください。

接続前後を比較して出口IPアドレスを確認する

信頼できるパブリックIPアドレス確認サイトを選び、接続前後で同じサイトを使って比較します。IPv4とIPv6を分けて表示し、IPアドレスの割り当て情報を確認できるサイトが便利です。確認サイトにはアクセス元のIPアドレスが伝わります。検査のためにサブスクリプションURL、アカウント情報、クライアントの設定全体をアップロードしないでください。

1. 未接続時の状態を記録します。クライアントを切断してパブリックIPアドレスを確認し、アドレス、割り当て元のネットワーク、サイトに表示された地域を記録します。ローカルネットワーク上のアドレスは外部への出口ではありません。端末の設定に表示されるローカルIPアドレスを代わりに使わないでください。
2. 接続先の回線を選びます。クライアントで想定した出口が選択されていることと、現在のモードを確認します。どの設定の変更が影響したか分からなくならないよう、ブラウザーのプロキシ、DNS、分割トンネルのルールを同時に変更しないでください。
3. もう一度テストします。確認ページを再読み込みします。結果に疑問がある場合は古いタブを閉じて開き直し、必要に応じて別の信頼できる確認サービスでも照合します。
4. 変化が想定どおりか確認します。IPアドレスが変わり、割り当て情報も選択した出口とおおむね一致するなら、そのウェブリクエストは目的の経路を通った可能性が高いと考えられます。一致しない場合は、地域名だけで判断せず、ルールやクライアントのログを確認してください。

IPアドレスの位置情報データベースには更新の遅れがあり、回線名と各確認サイトの地域表示が完全に一致するとは限りません。また、IPアドレスが変わっただけではVPNが有効になった証拠にはなりません。ネットワークの切り替えや、通信事業者によるアドレスの再割り当てでも変化するため、テスト中は接続ネットワークを変えないようにしましょう。

DNSを確認する際は地域名だけで判断しない

DNSはドメイン名をIPアドレスに変換します。DNSリークとは、指定した経路や保護された経路で送る想定の問い合わせが、トンネルを通らずローカルネットワークのリゾルバーに送られるなど、別の経路を使う状態を指します。問題の有無は、クライアントのモード、分割トンネルの対象、ブラウザーの設定とあわせて判断してください。

信頼できるDNSリークテストのページを開いて検査し、表示されたリゾルバーの運営元を記録して、切断時の結果と比較します。接続後もローカルネットワークのリゾルバーが表示され、テスト対象のドメインがルール上プロキシ経由のはずなら、DNSの処理が適切に切り替わっているか確認しましょう。ただし、リゾルバーがローカル地域に表示されたというだけで、リークとは断定できません。パブリックDNSサービスが最寄りの拠点を使ったり、集中した出口から応答したりする場合があります。

ブラウザーのセキュアDNSとクライアントのDNSは別の仕組み

ブラウザーが暗号化DNSを使い、OSで指定したリゾルバーを経由せずに名前解決する場合があります。そのため、検査ページにパブリックDNSサービスが表示されても、必ずしも異常ではありません。ブラウザーからそのDNSサービスへの接続自体が直接か、プロキシ経由かも確認してください。問い合わせ内容を暗号化することと、問い合わせの経路を変えることは別です。

OSのDNS確認ツールは、システムの名前解決の動作を調べるのに役立ちますが、ブラウザーの検査の代わりにはなりません。ツールが指定したサーバーへ直接問い合わせる場合もあれば、ブラウザーが独自のDNSキャッシュや暗号化DNSを使う場合もあります。システムに表示されたリゾルバー名だけでは、すべてのウェブサイトのDNSが同じ経路を通るとは判断できません。

トラブルシューティングを始める前に現在の設定を保存し、クライアントが推奨するDNS設定を確認したうえで、ブラウザーのセキュアDNS、カスタムリゾルバー、分割トンネルのルールを一つずつ調べます。パブリックDNSへの変更を万能な解決策と考えないでください。DNSサービスが変わるだけで、問い合わせがプロキシを迂回する問題は解決しない場合があります。

アプリごとに分割トンネルとアドレスファミリーを再確認する

ブラウザー、デスクトップアプリ、コマンドラインツールでは、ネットワーク設定が異なる場合があります。ブラウザーがシステムプロキシを使っていても、ダウンロードツールや会議アプリが同じ設定に従うとは限りません。実際に利用するアプリで対象の機能を開き、接続結果を確認します。クライアントの接続ログも参照し、どの経路が選ばれたか確認してください。

• ✅ ブラウザーのプロキシ拡張機能がシステム設定より優先されていないか、特にサイトごとの切り替えルールを確認します。
• ✅ クライアントの接続ログで対象ドメイン、プロセス、適用されたルールを確認し、プロキシ経由か直接接続かを調べます。
• ✅ パブリックIPv4とIPv6を別々にテストします。端末でIPv6を利用できない場合は「テスト不可」と記録し、結果がないことをリークとみなさないでください。
• ✅ アプリ内蔵のプロキシ、環境変数、除外リストを確認し、システム設定と競合していないか調べます。
• ❌ 速度テストの成功、接続アイコン、ウェブページが開くことのいずれか一つだけを、すべてのアプリで接続が有効になった証拠とみなさないでください。

IPv4が回線経由でも、IPv6で元のネットワークの出口が表示される場合は、まず対象の通信がルール上直接接続を許可されているか、クライアントがIPv6に対応し、その通信を処理できているか確認します。クライアントが提供する関連設定を優先して使い、影響が分からないままシステムのネットワーク機能を長期的に無効にしないでください。

WebRTCの検査結果の見方

ブラウザーのリアルタイム通信は、通常のウェブリクエストとは異なる経路を使う場合があります。検査ページに接続前のパブリックIPアドレスが表示された場合は、関連する通信をブラウザーとクライアントがどう処理しているか確認してください。ただし、端末内のプライベートアドレスや、隠されて表示されるローカルホスト名は、パブリックな出口IPアドレスのリークとは異なります。まずアドレスの種類を見分け、元のネットワークの出口が実際に公開されたか判断しましょう。

接続済みでも有効にならないよくある原因

サブスクリプションを読み込んだだけで、適切な接続先を有効にしていない

サブスクリプションのインポートは回線設定をクライアントに追加するだけで、プロキシが有効になったことを意味しません。更新が完了していること、使用する回線が選択されていることを確認し、システムプロキシまたは仮想ネットワークアダプターの接続設定が有効か調べます。クライアントのダウンロードやサブスクリプションの取得はユーザーパネルから行い、ログインやプランの条件に従ってください。

クライアントがサブスクリプションで使用されているプロトコルと設定形式に対応している必要もあります。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、自由に置き換えられる名称ではありません。インポートでエラーが発生した場合は、クライアントの対応状況とサブスクリプションの形式を確認し、プロトコルの項目を自己判断で変更しないでください。このページでは、VPNMTがどのプロトコルを提供しているかは判断できません。

複数のプロキシ設定が干渉している

ブラウザー拡張機能、古いクライアント、手動で設定したシステムプロキシが同時に有効な場合があります。古いプログラムを終了しても、その設定が自動的に解除されるとは限りません。問題を調べるときは必要な接続方法だけを残し、システム設定がまだ稼働しているローカルプロキシを参照していないか確認します。元に戻せるよう、設定を事前に保存してください。

古い接続やルールのキャッシュが結果に影響する

アプリが既存の接続を再利用したり、ドメイン名の解決結果がキャッシュされたりすることがあります。回線を切り替えたら、対象アプリを終了して再起動し、新しいリクエストを送信してください。シークレットウィンドウを使うと一部の閲覧データの影響は減らせますが、システムのDNSキャッシュが消えるとは限らず、アプリが新しい経路を使う保証もありません。

回線の種類を接続確認の結果と取り違えている

直接接続、中継、IEPL専用線は、通信経路や伝送方式を示すもので、端末の通信がその回線に入った証拠ではありません。出口を確認できても、アカウントの地域、コンテンツの利用許諾、ネットワーク上のリスク判定などにより、対象サービスへのアクセスが制限される場合があります。暗号化方式、出口の地域、サービスへのアクセス可否は、それぞれ別に確認してください。

プラットフォームごとの確認ポイント

Windows・macOS：システムプロキシ、仮想ネットワークアダプターの権限、他のネットワーク関連ソフトとの競合を重点的に確認します。ブラウザーでは正常でもデスクトップアプリで問題が起きる場合は、アプリがシステムプロキシに従うか確認し、必要に応じてクライアント対応の仮想ネットワークアダプター方式を検討してください。

iOS・Android：まず、システムの接続設定が有効になっていることを確認し、クライアントでアプリが除外されていないか、アプリごとの分割トンネルが設定されていないか調べます。Wi-Fiとモバイルデータ通信を切り替えた後は、接続ネットワークの変化でルーティングや名前解決の動作が変わる可能性があるため、再テストしてください。

Linux：デスクトップのプロキシ設定とターミナルツールの環境変数は、別々に設定されている場合があります。バックグラウンドサービスが現在のターミナル設定を引き継ぐとも限りません。ブラウザー、ターミナル、対象サービスをそれぞれ確認し、一つの結果を他のプロセスの確認に代用しないでください。

VPNMTはWindows、macOS、iOS、Android、Linuxに対応し、同時に接続できる端末数に制限はありません。端末ごとに個別に確認してください。特に、分割トンネルのルールやブラウザーのDNS設定が異なる端末は注意が必要です。

あとから確認できる結論をまとめる

接続前後の出口の結果、現在のモード、対象アプリの名称、関連ルールの適用記録を残します。サポートを依頼する場合は、問題に関係する箇所だけを共有してください。スクリーンショットを共有する前に、ユーザー名、サブスクリプションURL、トークン、不要なネットワークアドレスを隠してください。

問題が続く場合は、出口、DNS、アプリのルールの順に調べ、関連する設定を一度に一つだけ変更して、同じ手順で再テストしてください。高度な暗号化がルーティングの確認に代わるわけではありません。接続状態、暗号化による保護、実際のアクセス経路は、それぞれ個別に確認する必要があります。