VPNは接続済みなのに通信が通らない？出口IPとDNSを確認する完全検証ガイド

クライアントが「接続済み」と表示しているのに、ブラウザで目的のサイトが開けない。あるいはページは開けても、出口アドレスを調べるとローカル回線の事業者のままになっている。こうしたケースはトラブル記録でも頻出で、多くは回線側の故障ではなく、通信がそもそもトンネルに入っていないことが原因です。VPNが本当に効いているかどうかは、画面の接続状態ではなく、検証できる2つの指標で判断します。出口IPが変わっているか、DNS解決も切り替わっているかです。

本記事では、出口IPの確認、DNSリークの検査、アプリ別の比較テストという3ステップの検証手順を示し、「つながっているように見えて実は通っていない」6つの典型例と対処法を整理します。手順は Windows、macOS、iOS、Android、Linux をカバーし、追加の検証ツールは不要で、使うのはブラウザのページとOS標準のコマンドだけです。

2 必ず確認する項目:出口 IP と DNS リゾルバの所在地

3 検証手順:IP の確認 → DNS の確認 → アプリ別の比較

1 判断基準:出口アドレスが変わって初めて有効

「接続済み」が有効とは限らない理由

クライアントの接続状態は、クライアントのプロセスと回線の入口との間でハンドシェイクが成功したことしか示していません。システム上のほかのアプリの通信がこのトンネルを通ることは保証されません。実際に「有効」かどうかを決めるのは、通信をどの層で取り込むかです。クライアントがどの方式で通信をトンネルへ導くか、DNS と IPv6 も一緒に取り込まれているかが鍵になります。

取り込みの階層:拡張機能・システムプロキシ・TUN

取り込み方式	対象範囲	典型的な失敗の症状
ブラウザ拡張 / 単一アプリのプロキシ	拡張機能を入れたブラウザ、または個別にプロキシを設定したアプリ	ほかのソフトで出口 IP を調べるとローカルのアドレスのまま
システムプロキシ(PAC / 手動設定)	システムプロキシ設定を読む HTTP(S) アプリ	コマンドラインツール、UDP 系アプリ、一部のデスクトップソフトは直接迂回する
TUN / 仮想ネットワークアダプタによる取り込み	システムレベルのルーティング。通常は IPv4 と IPv6 の両方をカバー	ルーティングルールが「直結」に一致。IPv6 が未取り込みの場合はローカルのまま

3つの方式に絶対的な優劣はありません。システムプロキシは導入が軽くシステムへの変更も小さい一方、対象範囲は狭く、システムプロキシ設定を読むアプリにしか効きません。TUN は対象範囲が広い代わりに、より高い権限が必要です。Windows では仮想アダプタドライバのインストール、macOS と Linux ではネットワーク拡張の許可、または相応の権限での実行が求められます。すべてのアプリをトンネル経由にしたいなら、まずクライアントがシステムプロキシモードではなく TUN / グローバル取り込みモードになっていることを確認してください。

もう一つ見落とされがちなのが DNS です。通信がすでにトンネルに入っていても、名前解決のリクエストがローカルネットワークから配布されたリゾルバに送られていれば、近隣に振り分けられた結果や置き換えられた結果を受け取ることがあります。症状としては「つながっているのにドメインが開けない」「別の地域のバージョンが開く」といった形で現れます。そのため検証では IP と DNS を必ず同時に確認する必要があります。どちらか一方では不十分です。

ステップ1:出口 IP を確認し、通信の出口が変わっているかを見る

このステップの目的はシンプルです。接続前と接続後の2つの出口アドレスを取得して比較します。以下の順にひと通り試せば、おおむね判断できます。

クライアントを切断し、まず1回測定して出口 IP、所在地、事業者(ASN)を記録します。
クライアントを接続し、現在どの回線・どの地域を使っているかを確認します。
同じ照会サービスでもう一度測定し、IP と所在地が変化したか比較します。
IPv6 の出口だけを単独で確認します。IPv6 は見落とされやすく、「つながっているのに通っていない」が多発する領域です。
別の照会サービスで再測定し、ページキャッシュによる誤判定を排除します。

照会サービス自体も CDN の影響を受けます。一部の照会サイトは CDN 経由で、返ってくる所在地は CDN ノードの位置であり、実際の出口ではありません。「IP は変わったのに所在地がおかしい」という場合は、別の照会サービスに切り替えるか、ASN の項目を直接見て判断してください。

# 現在の出口 IPv4
curl -4 -s https://api.ipify.org

# 現在の出口 IPv6(出力がない場合は通常、本機に IPv6 の出口がないことを示す)
curl -6 -s https://api.ipify.org

# 所在地と ASN 付きの照会
curl -s https://ipinfo.io/json

✅ 接続前後で出口 IP が異なり、所在地が選択した回線の地域と一致する
✅ IPv4 の結果が回線の出口を指している。本機に IPv6 がない場合、IPv6 の照会は出力なし
✅ 同じ端末で2つ目の照会サービスを使って再測定し、結果が一致する
❌ 画面は接続済みなのに、出口 IP が切断時と完全に同じ:通信が取り込まれていない
❌ ブラウザでは出口が変わるのに、コマンドラインツールではローカルのアドレスのまま:現在はシステムプロキシまたは単一アプリのプロキシモード
❌ IPv6 の照会がローカル事業者のアドレスを返す:IPv6 の通信がトンネルを迂回している

判断基準はただ一つ:出口 IP が変わって初めて、通信が本当に回線を通ったと言えます。クライアントの接続状態、リアルタイム速度、遅延の数値はこの確認の代わりにはなりません。

ステップ2:DNS のリークを確認し、名前解決も回線を通っているか確かめる

DNS の問い合わせは接続の確立より前に発生します。名前解決のリクエストがローカルネットワークから配布されたリゾルバに送られると、その後の通信がトンネルを通っていても、近隣に振り分けられた結果や置き換えられた結果を受け取ることがあります。症状は「つながっているのに開けない」「誤った地域のバージョンが開く」「速いときと遅いときがある」などです。こうした状態は一般に DNS リークと呼ばれ、回線の品質とは関係なく、取り込み範囲の問題です。

DNS 検査の結果の読み方

検査ページには、今回の解決に使われたリゾルバの IP、所在地、事業者が表示されます。判断方法は、リゾルバの所在地が回線の出口と一致しているか、少なくとも同じ事業者のネットワークに属していることです。ローカルの固定回線やモバイル回線の事業者名が表示されていればリークです。リゾルバのアドレスが出口 IP と同じセグメントか同じ ASN であれば正常です。

ブラウザ内蔵の暗号化 DNS(DNS over HTTPS)はシステムの DNS 設定を迂回するため、検査ページにブラウザ自身のリゾルバが表示されることがあります。これはリークではありませんが、回線側の解決ポリシーを同じように迂回します。切り分けの際は、まずブラウザの「セキュア DNS」をオフにしてから再検査してください。

対処は優先度の高い順に次のとおりです。

クライアント側で DNS の取り込み(クライアントによっては DNS ハイジャック、DNS プロキシと呼ばれます)を有効にし、名前解決のリクエストをトンネル経由にします。
回線側から配布されるリゾルバのアドレスに切り替え、ルーターから配布されるローカルアドレスを使い続けないようにします。
ブラウザで暗号化 DNS が有効になっていないか確認します。システムの DNS 設定を迂回するため、切り分け時はオフにしてから検査します。
ルーター側で IPv6 を有効にしている場合は、IPv6 の DNS も取り込まれているか確認します。そうでないと、名前解決が IPv6 の経路から漏れ出す可能性があります。

# Windows:システムが現在使用している DNS サーバーを確認
ipconfig /all

# macOS:システムのリゾルバ設定を確認
scutil --dns

# Linux:現在の名前解決設定を確認
cat /etc/resolv.conf

# 返ってくるアドレスがリゾルバの出口。出口 IP と比較できる
nslookup whoami.akamai.net

ステップ3:アプリ別・シーン別の比較テスト

出口 IP と DNS がどちらも正しくても、一部のアプリだけ回線を通らないことがあります。このステップの目的は、「どのアプリが通っていないか」を特定することであり、回線のせいだと大まかに決めつけることではありません。

ブラウザ:シークレットウィンドウを使うかキャッシュを一度消してから目的のサイトにアクセスし、結果を記録します。
コマンドライン:curl で出口 IP を調べ、ブラウザの結果と比較します。コマンドラインツールは既定ではシステムプロキシを読まないため、http_proxy / https_proxy 環境変数を明示的に設定するか、TUN による取り込みに頼る必要があります。
デスクトップアプリ:クライアントのアプリ別プロキシ一覧で、そのアプリが回線経由として設定されているか確認します。UDP 主体のソフトは、システムプロキシモードでは通常プロキシされません。
モバイル:Android では VPN 権限が付与されているか、クライアントが省電力の除外リストに入っているかを確認します。iOS では VPN 構成が接続状態にあり、オンデマンド接続ルールで早々に切断されていないかを確認します。
クロスチェック:同じアカウントの別の端末で再測定します。VPNDX は同時接続台数が無制限なので、端末を変えての再測定に追加の操作は不要です。

プラットフォームごとの違いを順に確認

Windows:切り分けの前に「設定 → ネットワークとインターネット → プロキシ」がほかのソフトによって自動構成に戻されていないか確認します。一部のアプリは WinHTTP プロキシを使うため、netsh winhttp show proxy で個別に確認できます。TUN モードは仮想アダプタドライバに依存するため、セキュリティソフトがドライバをブロックすると取り込みに失敗します。
macOS:一部のアプリはシステムプロキシを読みません。scutil --dns でシステムのリゾルバを、networksetup -getwebproxy Wi-Fi で現在のプロキシ項目を確認できます。ネットワーク拡張で取り込む場合は、システム設定での許可が必要です。
iOS:システムの VPN 構成が一括で取り込むため、通常はアプリ別の設定は不要です。低電力モードはバックグラウンド更新を制限するので、長時間バックグラウンドに回した後はクライアントを呼び出して状態を確認してください。
Android:アプリ別プロキシはシステムレベルの機能で、システムの VPN 設定またはクライアント内で一部のアプリだけを回線経由にできます。省電力ポリシーがクライアントのプロセスを回収し、つながっているように見えて実際は切断されていることがあります。
Linux:TUN デバイスの作成には root または相応の権限が必要です。コマンドラインツールは既定ではシステムプロキシを読まないため、環境変数を設定するか TUN 経由にする必要があります。

切り分けの際は複数の設定を同時に変えないでください。一度に変えるのは1項目だけです。まず取り込みモードを変え、次に DNS を触り、最後にアプリ別の一覧を見ます。そうしないと、問題が消えてもどの手順が効いたのか分からず、次に同じ症状が出たときにまた最初からやり直すことになります。

「つながっているのに通っていない」6つの典型例と対処法

上記3ステップの結果を次の表と照らし合わせれば、原因はほぼ特定できます。

症状	考えられる原因	対処
出口 IP が切断時と完全に同じ	クライアントがシステムプロキシモードで、そのソフトがシステムプロキシを読まない	TUN / グローバル取り込みモードに切り替えるか、アプリ内で個別にプロキシアドレスを入力する
ブラウザの出口は変わるが、コマンドラインは変わらない	ブラウザだけがシステムプロキシを読んでいる	同上。アプリごとに設定するのではなく、グローバル取り込みが必要かどうかを確認する
IPv4 は回線を通るが、IPv6 はローカルのまま	クライアントが IPv6 のルートを取り込んでいない	クライアントで IPv6 の取り込みを有効にするか、クライアント / ルーター側で IPv6 を無効にする
出口 IP は正常なのに、ドメインが開けない・名前解決がおかしい	DNS が依然としてローカルのリゾルバで処理されている	クライアントの DNS 取り込みを有効にし、ブラウザの暗号化 DNS 設定を確認する
特定のアプリだけ回線を通らない	アプリ別プロキシ一覧でそのアプリが回線経由になっていない	そのアプリを回線経由の一覧に追加するか、グローバル取り込みモードに切り替える
別のネットワークに移ると効かなくなる	ネットワーク切り替え後にルートとプロキシ設定が再構築されていない	クライアントを切断して再接続する。必要ならクライアントのプロセスを再起動してから再測定する

6つのうち最初の4つは同じ手順で解決できます:取り込みの階層をシステムプロキシから TUN に変え、DNS と IPv6 も一緒に取り込まれているか確認します。残りの2つは設定漏れなので、項目ごとに確認すれば済みます。

いつ再検証が必要か

3ステップの検証は一度きりの作業ではありません。次のようなタイミングの後は取り込み状態が変わっている可能性があるため、もう一度ひと通り試すことをおすすめします。

ネットワーク環境を変えた後:家庭の固定回線から社内ネットワークへ、Wi-Fi からモバイルホットスポットへ切り替えると、ルートとプロキシ設定が再構築されます。
回線や回線の地域を切り替えた後:ルーティングルールとリゾルバが回線に合わせて変わる可能性があります。
クライアントや OS のメジャーアップデート後:ネットワーク拡張の権限やシステムプロキシ設定がリセットされることがあります。
ルーターの再起動や交換後:配布される DNS アドレスと IPv6 プレフィックスが変わります。
「開けるが遅い」「特定のサイトだけ開けない」とき:まず検証を行い、それから回線側の問題かどうかを判断します。

3ステップの検証に通ったら、そのときの出口 IP とリゾルバのアドレスをベースラインとして記録しておきます。次にアクセス異常が出たときは、この2つの値と比べるだけで、ローカル側の取り込みが失敗したのか、回線側に変化があったのかをすぐに切り分けられます。

出口 IP の照会ページをブックマークしておけば、3ステップは通常2分もかかりません。「回線障害」の多くはこの段階で、ローカル側の取り込みが効いていないのか、回線側に本当に異常があるのかを判断できます。VPNDX は 120+ カ国 / 220+ 回線を提供し、IEPL 専用線と中継、直結回線をラインナップ。同時接続台数は無制限で、クライアントは Windows、macOS、iOS、Android、Linux に対応、軍用グレードの暗号化を採用し、登録にメールアドレスは不要、Alipay、WeChat、USDT での支払いに対応、30日間の無条件返金保証付きです。サイト内の回線ページでは回線の状態を確認でき、ローカルの検証結果と照らし合わせることで、問題がどちら側にあるかをより早く判断できます。

まずローカルを検証し、それから回線を疑う。出口 IP、DNS リゾルバ、アプリ別の3つがすべて通って初めて、通信が本当に回線を通ったと言えます。どれか一つでも通らなければ、問題はローカル側の取り込みにあり、回線を変えても解決しません。