VPNの接続確認方法出口IPとDNSのチェック｜初心者向けガイド

接続状態と実際の通信の違い

まず「何が接続されたのか」を確認しましょう。システムプロキシを使うクライアントは、主にシステムプロキシ設定に従うアプリの通信を処理します。仮想ネットワークアダプターやシステムVPNインターフェースを使う場合は、ルーティングルールに従って通信を処理します。画面上の表示が似ていても、対象となる通信の範囲は異なることがあります。ブラウザーがVPN経由でも、ゲームやターミナルなど他のアプリが同じ出口を使っているとは限りません。

スプリットトンネリングを使うと、通信経路はさらに変わります。一部のドメインは直接接続し、ほかはプロキシを経由する設定にできます。アプリごとに振り分ける場合、指定したアプリだけがトンネルに入ります。確認ページへのアクセスが直接接続のルールに該当するなら、元のIPアドレスが表示されても接続失敗とは限りません。確認前に、現在のモードと対象ドメインに適用されるルールを記録しておきましょう。

設定に沿って判断することが大切です。全通信をVPNに通す設定なら、その適用範囲を確認します。通信を振り分けている場合は、対象アプリに想定どおりのルールが適用されているか確認しましょう。すべての通信で同じ出口が表示される必要はありません。

出口IPアドレス：接続前後を比較する

出口IPアドレスとは、確認サイトがリクエストを受け取った際に認識する送信元アドレスです。家庭用ルーターが端末に割り当てるプライベートIPアドレスではなく、ここではインターネット上の出口を確認します。ブラウザーのアドレスバーに表示される接続保護のマークは、ウェブサイトとの通信にHTTPSが使われていることを示すだけで、VPN経由であることの証明にはなりません。

1. クライアントの接続を切り、VPNKDのIPアドレス確認ページを開いて、パブリックIPアドレス、ネットワーク事業者、表示地域を記録します。IPv4とIPv6が別々に表示される場合は、それぞれ記録してください。
2. 選択した経路に接続し、通信の処理モードを確認してから、確認ページを再読み込みします。画面に残った古い結果だけを見ないようにしてください。
3. アドレスが変わったか比較し、ネットワーク事業者の情報も確認します。地域データベースの更新には時間がかかることがあるため、都市名が一致しないだけで経路が無効とは判断できません。
4. 別の独立した確認サービスでも検証します。結果が異なる場合は、それぞれ異なる振り分けルールに該当していないか、異なるIPアドレスの種類を使っていないか確認してください。
5. 接続を切ってからもう一度確認し、元の出口に戻るかを見ます。問題を再現しやすいよう、接続前後の結果を保存しておきましょう。

アドレスが変わらない場合は、まず確認リクエストがプロキシ経由になる設定かを確認します。ログに直接接続と表示されるなら、ルールを調べてください。プロキシ経由と表示されるのに想定と異なる場合は、ブラウザー独自のプロキシ設定、拡張機能、既存の接続、クライアントのエラーメッセージを確認します。「地域が変わらない」という理由だけで、経路を何度も切り替えるのは避けましょう。

IPv4の出口が変わっても、IPv6にローカルネットワークが表示される場合は、IPv6のルーティングを個別に確認します。クライアントが一部のIPアドレスの種類だけを処理している場合や、ルールによってIPv6が直接接続になっている場合があります。まずクライアントのIPv6対応状況と通信の処理方法を確認し、そのうえで設定を調整してください。あらゆる状況でIPv6を無効にすればよいとは限りません。

DNSのチェック：リゾルバーが異なってもDNSリークとは限らない

DNSはドメイン名をネットワークアドレスに変換する仕組みです。DNSテストでは、ブラウザーからテスト用ドメインへリクエストを送り、サーバー側の観測結果から、再帰リゾルバーが処理に関与した可能性を調べます。これはDNSの経路を推測する手がかりであり、端末上のすべてのアプリのDNS記録を示すものではありません。

DNSリークとは、指定した経路を通る想定のDNSリクエストが、実際には別の経路から送信される状態です。問題かどうかは、設定で想定している経路によって異なります。ブラウザーが独自の暗号化DNSを使っている場合、別のDNSサービスが表示されるのは設定どおりかもしれません。その暗号化DNSへの接続自体がプロキシ経由の可能性もあります。リゾルバーの事業者名や国だけでは、通信経路を判断できません。

• まずクライアントのDNS設定を確認し、リモートで名前解決する設定か、直接接続するドメインに個別のリゾルバーを指定しているかを確認します。
• ブラウザーのセキュアDNS設定を確認します。システムの名前解決設定より優先されることがあります。システムDNSのアドレスだけを変更するのではなく、クライアントのDNSポリシーとあわせて確認してください。
• ネットワークを変えずに、接続を切った状態と接続した状態のテスト結果を比較します。接続後もローカルネットワークのDNSリゾルバーが表示されるなら、調査する手がかりになります。ただし、ログや設定も確認して判断しましょう。
• 新しいテスト用ドメインを使うか、テストをやり直します。キャッシュが残っていると、名前解決のリクエストが発生せず、結果が表示されなかったり、変化がないように見えたりすることがあります。

暗号化DNSが保護するのは、端末とDNSサービス間の問い合わせ通信です。それだけでウェブ閲覧時の出口が変わるわけではありません。逆に、ウェブ通信がプロキシ経由でも、すべてのDNSリクエストがプロキシ経由とは限りません。「ドメインをどこで名前解決するか」と「接続がどこから外に出るか」は分けて確認してください。

アプリごとに確認する：ブラウザー以外もチェック

ブラウザーでのテスト結果が示すのは、そのブラウザーから送ったリクエストだけです。普段使うアプリも確認するには、対象アプリで新しい通信を発生させ、クライアントの接続一覧やログを確認します。ルール名や通信経路が表示される場合は、リクエストが直接接続と選択したプロキシ経路のどちらに振り分けられたか確認してください。

デスクトップでは、WindowsやmacOSのシステムプロキシ設定にすべてのソフトウェアが従うとは限りません。ターミナルのプログラムはプロキシ環境変数を参照する場合も、無視する場合もあります。Linuxのデスクトッププロキシ設定も、すべてのプロセスに適用される共通の設定ではありません。仮想ネットワークアダプターを使うモードは、より多くのIP通信を処理できますが、ルーティングや除外設定、クライアントの機能に左右されます。

iOSやAndroidのクライアントは、システムVPNインターフェースを使って通信を処理することがあります。実際の対象範囲は設定によって異なります。Androidのクライアントには、対象アプリを含めたり除外したりする設定が用意されている場合があります。あるプラットフォームの操作手順を別のプラットフォームにそのまま当てはめないでください。アプリが接続を維持している場合は、経路を変更したあとにアプリの接続を確立し直してからテストしましょう。

• ✅ 使用するアプリを開き、キャッシュ済みの画面を見るだけでなく、実際に通信を行います。
• ✅ クライアントのログで該当リクエストを見つけ、ドメイン、ルール、通信経路を確認します。
• ✅ アプリ固有のプロキシ設定、ブラウザー拡張機能、システムプロキシ設定が互いに上書きしていないか確認します。
• ✅ モードを変更したらアプリの接続を確立し直し、同じネットワークで再確認します。
• ❌ あるウェブサイトが開くことだけを、すべての端末やアプリの通信がVPN経由になっている証拠にしないでください。

アプリによっては、出口IPアドレスを表示しません。その場合は接続ログ、ルールの適用状況、機能の動作をあわせて確認し、どこまで判断できるかを明確にします。接続先のウェブサイトがアクセスを拒否しても、アカウントの状態、地域ごとのポリシー、出口の評価などが原因の場合があり、端末の接続が有効でないとは限りません。

「接続済みなのにVPN経由にならない」場合の確認手順

問題を調べるときは、まず通信がクライアントに届いているかを確認し、次にどこへ送られているかを調べます。サブスクリプションを何度も更新したり、接続先を次々に変更したりするより、原因を見つけやすい順序です。一度に変更するのは一項目だけにし、リクエストを再送して変化を記録しましょう。設定を元に戻す際にも判断材料になります。

1. 設定が選択されていることを確認します。サブスクリプションURLを追加しただけでは設定を取得したにすぎず、接続先を選択して通信の処理を有効にしたことにはなりません。現在の設定、選択中の経路、接続エラーを確認してください。サブスクリプションURLにはアクセス用の認証情報が含まれるため、公開スクリーンショットや掲示板に掲載しないでください。
2. システム側の入口を確認します。システムプロキシモードではプロキシが有効か確認し、仮想ネットワークアダプターモードでは権限とルーティング状態を確認します。ほかのネットワークツールがこれらの設定を書き換えることもあります。テスト中は複数のツールが同じ通信の入口を奪い合わないようにしてください。
3. ルールが適用されていることを確認します。対象ドメインが直接接続になっている場合は、ルールの順序、アプリごとの除外設定、デフォルトの通信経路を確認してください。原因の切り分けのためにモードを一時変更することはできますが、すべての通信を長期にわたって同じ経路にする理由にはなりません。
4. 名前解決が成功していることを確認します。ログに名前解決エラーがある場合は、まずDNSの経路を調べます。出口IPアドレスが正常でも、対象ドメインを正しく名前解決できるとは限りません。
5. 通信経路が利用できることを確認します。リクエストがプロキシに届いているのに接続エラーが起きる場合は、接続先、ネットワーク、クライアントの互換性を確認します。エラーメッセージだけで、経路の構成やサーバー側の障害を断定することはできません。
6. 一連の証拠をもう一度確認します。設定を調整したら、出口、DNS、対象アプリを再確認してください。いずれか一つが正常になっても、別の項目に問題が残っていないか確認しましょう。

プロトコル名だけでは、接続が有効かどうかは判断できません。Shadowsocks、VMess、Trojan、VLESSなどの設定が通信を処理でき、正常に使えるかどうかは、クライアントの対応状況、トランスポート設定、サーバー設定にも左右されます。経路に直接接続、中継、専用線などの表示があっても、端末の出口を確認する代わりにはなりません。IPアドレスの地域表示から具体的な経路構成を推測することもできません。

ブラウザーのIPアドレス露出とテスト結果の範囲

一部の確認ツールはWebRTCアドレスも表示します。WebRTCはリアルタイム通信に使われ、通常のウェブ閲覧とは異なる経路を使う場合があります。ローカルネットワークのアドレス、プライバシー保護のために加工されたローカルアドレス、パブリックアドレスは区別が必要です。ローカルアドレスが表示されても、パブリックな出口がVPN経由になっていない証拠とは限りません。

想定外のパブリックアドレスが表示された場合は、ブラウザーのポリシー、クライアントが対象の通信に対応しているか、ルーティング設定を確認してください。拡張機能を大量に追加して対処するのは避けましょう。拡張機能がブラウザーにしか作用しなかったり、既存のプロキシ設定と競合したりすることがあります。設定変更後は、実際に使うアプリでもう一度確認してください。

このテストでわかるのは実施時点の通信経路であり、常に同じ状態が続くことを証明するものではありません。ネットワークの変更、クライアントの更新、ルールの調整、設定の再インポート後は、改めて確認するとよいでしょう。IPアドレスが変わってもプライバシーが保証されるわけではありません。ログイン中のアカウント、ウェブサイトのCookie、アプリの権限からも本人を特定する手がかりが得られる場合があります。