VPNは本当に接続できている？出口IP・DNS・アプリ別の検証手順ガイド

「クライアントは接続済みなのにWebページが開かない」と「クライアントは接続済みなのに通信が実際には回線を通っていない」は別の問題です。VPNが本当につながっているかを判断するとき、クライアントのアイコンだけを見ても意味はありません。アイコンはローカル側とノードのハンドシェイクが完了したことしか示さず、すべてのリクエストがトンネルに入ることは保証しません。以下の3ステップ——出口IP、DNSの帰属、アプリ別テスト——はそれぞれ単独で結論を出せ、互いに裏付けも取れます。

検証に特別なツールは不要で、ブラウザとクライアントだけで完結します。順番は固定するのがおすすめです。まず出口アドレスが変わったことを... 確認し、次に名前解決も切り替わったことを確認し、最後に対象アプリが本当にこの回線を使っていることを確認します。

• 3ステップ 出口IP / DNSの帰属 / アプリ別を順に判定
• 120+ 国と地域の回線カバレッジ
• 240+ IEPL専用線と中継回線から選択可能
• 7日間 理由を問わない返金

「接続済み」でも通信が本当に回線を通るとは限らない理由

クライアントの「接続済み」は、ローカル側のプログラムとノードの間でハンドシェイクが成功したこと（セッション確立、認証通過、鍵交換の完了）を意味します。システム内のすべてのリクエストがこのトンネルに入ることは保証しません。実際に回線を通るかどうかは、クライアントの動作モード、振り分けルール、そしてアプリ自身のネットワーク設定によって決まります。

動作モードがカバー範囲を決める

仮想NIC（TUN）モードは仮想ネットワークアダプタを作成してシステムのルーティングテーブルを引き継ぎ、TCPとUDPは既定ですべてトンネルに入り、振り分けルールで許可された通信だけが直接接続になります。システムプロキシモードはシステムのプロキシ設定を変更するだけです。その設定に従うアプリは回線を通りますが、独自のネットワークスタックを持ちシステムプロキシを読まないソフトウェアはそのまま直接接続します。同じクライアント、同じ回線でも、2つのモードではカバー範囲がまったく異なります。

振り分けルールが例外を決める

振り分けは不具合ではなく設計上の目的です。中国本土のドメインとIPレンジは既定で直接接続となり、中国本土のサービスにアクセスするときに遠回りする必要がありません。リスクは誤判定です。対象ドメインがルールで直接接続側に分類されると、「接続済みなのに通っていない」という症状になります。ルールセットを長期間更新しないと、誤判定が増えていきます。

アプリとキャッシュによる干渉

ブラウザは独自のプロキシ設定を持てますし、拡張機能がリクエストを横取りすることもあります。安全なDNSを有効にすると、名前解決がシステム設定を完全に迂回することがあります。回線を切り替えた後も、すでに確立済みの長い接続（HTTP/2、HTTP/3セッション）は古い経路を使い続けることがあります。切り替えたらまずブラウザを再起動し、そのうえでシステム側でDNSキャッシュをクリアしてください：

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux（systemd-resolved）
sudo resolvectl flush-caches

出口IPの確認：接続前と接続後に1回ずつ

出口IPは外部から見えるあなたのアドレスであり、3ステップの中で最も再現しやすい項目です。接続前と接続後に1回ずつ調べて結果を比べます。確認ページはIPの帰属先とプロバイダ（ASN）を同時に表示できるものを選ぶと、情報が多いほど判断が楽になります。

1. クライアントを切断し、確認ページを開いて3つの情報を記録します：出口IP、国／地域、プロバイダまたはASN。
2. クライアントを接続し、回線を1つ選びます。日本やシンガポールの回線を例にすると、確認ページには該当する地域のアドレスが表示されるはずです。
3. 確認ページを強制リロードし、キャッシュされたページを使わずに、IPが変わったか、帰属先が選んだ回線と一致するかを比べます。
4. IPv6の欄を単独で見ます。あなたのIPv6アドレスが依然としてローカルのプロバイダに属しているなら、トンネルはIPv4しか引き継いでおらず、AAAAレコードも提供する一部のサイトはIPv6で直接出ていくことになります。
5. ブラウザだけで検証する場合は、WebRTCももう一度確認します。これは端末のローカルアドレスや実際のグローバルアドレスを露出する可能性があり、出口IPとは別の経路です。

チェック項目	正常な状態	対処が必要な状態
IPv4の出口	回線のある国／地域のアドレスが表示され、接続前と異なる	接続前とまったく同じ、または帰属先が依然として... ローカルのまま
IPv6の出口	IPv6アドレスがない、または回線側のアドレスが表示される	ローカルプロバイダのIPv6アドレスが表示される
WebRTC	トンネル内または回線側のアドレスだけが表示される	端末のローカルアドレスや実際のグローバルアドレスが表示される
プロバイダ / ASN	回線側のデータセンターまたはプロバイダとして表示される	依然としてローカルのブロードバンドプロバイダのまま

確認ページにIPv6アドレスが表示されるのに、クライアントがIPv6を引き継いでいない場合、最も手軽なのはクライアント側でIPv6転送を無効にし、ドメインをIPv4の経路に戻すことです。代償はIPv6専用サイトにアクセスできなくなることですが、日常利用ではほとんど気になりません。

DNSの帰属確認：名前解決はどこで行われているか

出口IPは「データがどこから出ていくか」に答えるだけで、「どのドメインを引いたか」には答えません。名前解決の経路は、誰があなたのアクセス先サイトの一覧を見られるかを決めるため、第2ステップではDNSを単独で確認します。

2つの名前解決経路

トンネル内での解決：クライアントはDNSクエリもトンネルに送り込み、ノード側のリゾルバが解決します。Fake-IPモードでは、まずローカルでドメインを仮想アドレス（一般には 198.18.0.0/15 のような予約セグメント）にマッピングし、実際の解決はノード側で行われ、接続はドメイン名で開始されます。ローカルでの解決：アプリがルーターやプロバイダのリゾルバに直接問い合わせ、アドレスを取得してからどの経路を使うかを決めます。この場合、Webの通信がトンネルに入っていても、ドメインの一覧はローカルネットワークに残ります。これが一般にDNSリークと呼ばれるものです。

テスト方法

1. DNSリーク確認ページを開くと、あなたのクエリを解決したリゾルバのアドレスと帰属先が一覧表示されます。
2. 回線に接続した状態で数回リロードし、確認ページから複数の異なるドメインのクエリを発生させます。
3. リゾルバの一覧を見ます。正常ならノード側のリゾルバだけが表示されるはずです。ローカルのプロバイダのリゾルバやあなたの都市が混ざっていれば、それらのクエリはローカルを通っています。

ブラウザの安全なDNSはよくある妨害要因

Chrome、Edge、Firefoxはいずれも安全なDNS（DoH）のスイッチを提供しており、有効にするとブラウザはDoHプロバイダに直接暗号化クエリを送ります。TUNモードではこれらのクエリ自体もトンネルに入りますが、リゾルバがDoHプロバイダに変わるだけです。システムプロキシモードでは、リクエストがトンネルを完全に迂回して直接出ていく可能性があります。切り分けの際はまずこのスイッチをオフにするか、トンネルを通っていることを確認してください。

対処法

• クライアント側でDNS引き継ぎ（DNSハイジャック）を有効にし、ポート53宛てのクエリをトンネル内のリゾルバにリダイレクトします。
• ブラウザの安全なDNSを無効にするか、トンネル内のリゾルバを指定します。
• 2つのプロキシツールを同時に動かさないでください。ルーティングテーブルとDNS設定を奪い合います。

アプリ別と振り分けルールのテスト

最初の2ステップはシステム側の検証で、第3ステップはアプリ側の検証です。アプリ別プロキシはどのアプリを回線に通すかを指定し、振り分けルールはどのドメインを回線に通すかを決めます。どちらも同じIP確認ページで異なる結果を返す要因になります。

アプリ別プロキシの確認方法

1. 同じ端末で、2つの異なるアプリから同じ出口IP表示ページにアクセスします。
2. 1つはプロキシ対象のアプリ（通常はブラウザ）、もう1つはプロキシ対象外のアプリです。
3. 前者の出口IPは回線側のアドレス、後者はローカルのアドレスのままであるべきです。両方が期待どおりなら、アプリ別設定が効いています。
4. 両方が同じアドレスを表示する場合は、クライアントのアプリ一覧を確認してください。デスクトップではプロセス名、モバイルではアプリのパッケージ名で照合するため、再インストールや名前変更の後は選び直す必要があります。

振り分けルールのマッチ順

ルールは上から下へ1つずつ照合され、一致した時点で止まるため、順序そのものが設定の一部です。よくある種類は次のとおりです：

ルールの種類	マッチ対象	典型的な用途
DOMIN	完全なドメイン名	単一のドメインを正確に許可またはプロキシ
DOMAIN-SUFFIX	ドメインのサフィックス	1つのサイトとそのすべてのサブドメインをカバー
DOMAIN-KEYWORD	ドメインに含まれるキーワード	同種のサイトをまとめてマッチ
IP-CIDR	IPアドレス範囲	アドレス範囲で振り分け
GEOIP	IPの帰属国／地域	中国本土は直接接続、海外は回線経由
RULE-SET	外部ルールセット	継続的にメンテナンスされているルールリストを参照
MATCH	残りのすべての通信	フォールバックルール。最後の1行に置く

振り分けが期待どおり動いているかを確認する最も直接的な方法は、接続ログを見ることです。多くのクライアントはリアルタイムの接続一覧を提供しており、各記録にはどのルールに一致したか、プロキシと直接接続のどちらを通ったかが書かれています。対象ドメインが DIRECT と表示されるなら、それはルールによる許可であり、回線の故障ではありません。ルールセットには更新日時があり、長期間更新しないと新しいドメインを誤判定します。クライアント側で購読とルールセットを手動更新するのが、最も手軽な修復方法です。

「つながっているように見えて実は通っていない」よくあるケース

以下は切り分けで最も頻繁に見られる現象です。現象・原因・対処の3列で照合してください。

現象	考えられる原因	対処
クライアントは接続済みなのに、ブラウザはローカルIPのまま	ブラウザが独自のプロキシ設定を使っている、または拡張機能がリクエストを横取りしている	ブラウザのプロキシ系拡張機能を無効にし、クライアント側で一元管理する
一部のサイトは開けるが、別のサイトは開けない	対象ドメインが直接接続または REJECT ルールに一致している、ルールセットが古い	接続ログでルールの一致を確認し、購読とルールセットを更新する
IPv4は切り替わったが、IPv6はローカルのまま	トンネルがIPv6を引き継いでおらず、ローカルネットワークがIPv6を提供している	クライアント側でIPv6転送を無効にする、またはトンネルにIPv6を引き継がせる
確認ページにローカルのDNSリゾルバが表示される	ブラウザの安全なDNSが直接接続している、またはシステムプロキシモードでローカル解決している	DNS引き継ぎを有効にし、ブラウザの安全なDNSを無効にする
接続は成功するが、リクエストがすべてタイムアウトする	ノード出口の異常、MTUとフラグメントの問題、UDPのブロック	回線を変える、プロトコルを切り替える（TCP / QUIC）、MTUを調整する
回線を切り替えても古いIPが表示される	長い接続の再利用とDNSキャッシュ	DNSキャッシュをクリアし、ブラ... ウザを再起動し、切断して再接続する

もう1つ区別しておきたいことがあります。検証で分かるのは「通信が回線を通ったこと」だけで、「回線の品質」までは分かりません。回線タイプが決めるのは安定性です。直接接続の回線はクライアントから海外ノードへ直接つなぎ、全区間が公衆網を通るため、夜間のピーク時間帯は混雑の影響を受けやすくなります。中継回線はまず近くの入口に接続してから出口へ転送するため、経路はある程度制御できますが、後半区間は依然として公衆網に依存します。IEPL専用線は専用のチャネルを通り公衆網を経由しないため、ジッターとパケットロスが小さくなります。3ステップすべてをクリアしても速度が物足りない場合、問題は回線選びにあり、検証にはありません。

確認項目と判断基準

上記の3ステップを1つのチェックリストにまとめました。順に照合してください：

• ✅ 出口IPが選んだ回線の帰属先と一致し、接続前と異なる
• ✅ 確認ページにローカルプロバイダのIPv6アドレスが出ていない
• ✅ プロキシ対象ドメインのリゾルバがノード側にあり、ローカルのリゾルバが混ざっていない
• ✅ 接続ログで対象ドメインがプロキシルールに一致しており、DIRECT ではない
• ✅ プロキシから除外したアプリが確かにローカルアドレスを表示し、アプリ別設定が効いている
• ❌ 確認ページに依然としてローカルのブロードバンドアドレスが表示され、キャッシュ削除とブラウザ再起動後も変わらない
• ❌ リゾルバ一覧にローカルのプロバイダとローカルの都市が同時に表示される
• ❌ 接続ログで対象ドメインがすべて DIRECT または REJECT に一致している

よくある質問