VPNに接続したのに反映されない？出口IPとDNSを確認する初心者向け完全ガイド

クライアントのアイコンが緑になり、ステータスも「接続済み」なのに、Webページを開くと速度も表示内容も元のまま——これが「VPNに接続したのに反映されない」の最も典型的な症状です。原因は通常、回線そのものではなく、通信が本当に回線へ送り込まれているかどうかにあります。システムプロキシ方式はプロキシ設定を読み取るアプリにしか効きません。振り分けルールが目的のドメインを直接接続と判定していることもありますし、DNS解決がそもそも回線を通っていない場合もあります。見分け方は難しくなく、順番も決まっています。まず出口IPを確認し、次にDNSを確認し、最後にアプリごとに検証します。この3ステップを踏めば、「つながっているように見えて実は回線を通っていない」ケースのほとんどで、具体的な原因を特定できます。

なぜ「接続済み」は本当に有効とは言えないのか

クライアントと回線の間に接続が確立しただけでは、制御チャネルが通ったことしか意味しません。ノード情報を取得し、認証が通り、ハートビートも正常という状態です。通信が実際にこのチャネルに入っているかは別の話で、クライアントの動作モード、振り分けルール、そして使用中のアプリがプロキシ設定を読み取るかどうかという3つの変数で決まります。

よく使われる動作モードは3つあり、適用範囲は大きく異なります。

システムプロキシ方式:クライアントが変更するのはOSのプロキシ設定(HTTP / SOCKS)です。この設定を自ら読み取るアプリだけが回線を通ります。ほとんどのブラウザは読み取りますが、ターミナルや一部のデスクトップアプリ、ゲームランチャーは読み取りません。
TUN / 仮想NIC方式:クライアントがシステム内に仮想NICを作成してルーティングテーブルを引き継ぐため、ほとんどのアプリの通信がまとめて引き継がれ、アプリ側がプロキシ設定を読み取る必要はなくなります。
グローバル / ルールモード:これは「どの通信を回線に通すか」のポリシーです。グローバルはすべてのリクエストを回線へ送り、ルールモードはドメイン、IP帯域、地域リストごとに判定し、直接接続ルールに該当したドメインは回線を通りません。

つまり「接続済み」は必要条件にすぎません。本当に反映されているかを判断するには、データを見る必要があります。出口IPが変わったか、DNS解決がどこを経由したか、個々のアプリが取得する送信元アドレスは何か、を確認します。

まずモードを確認してから切り分けを始める

同じ「反映されない」という症状でも、システムプロキシ方式とTUN方式では原因がまったく異なります。クライアントの設定を開き、現在どちらのモードなのかを確認してから切り分けを進めると、方向性が見えてきます。

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

出口IPは、反映されているかどうかを判断する最も直接的な証拠です。通信が回線を通っていれば、外部サイトから見える送信元アドレスは回線の着地点のアドレスになります。通っていなければ、自宅のブロードバンド回線やモバイル回線のアドレスのままです。手順は次の4ステップだけです。

接続する前に、送信元アドレスを表示するページを開き、アドレスと所在地をメモしておきます。
回線に接続し、状態が安定するまで5〜10秒待ってから操作します。
同じページを再読み込みし、接続前後のアドレスを比較します。
別の確認サイトでもう一度調べ、ページキャッシュによる誤判定を排除します。

比較結果	説明	次のステップ
アドレスが変わり、所在地が選択したノードと一致する	データチャネルは有効になっている	続けてDNSとアプリを確認する
アドレスがまったく変わらない	現在のアプリの通信が回線に入っていない	動作モードと振り分けルールを確認する
アドレスは変わったが、所在地が選択した地域と異なる	入口と着地点が同じ地域にない可能性、またはページがCDNのエッジアドレスを表示している可能性がある	別の確認サイトでクロスチェックし、クライアントのノード詳細も確認する

出口IPと回線タイプの関係

直接接続・中継・IEPL専用線が変えるのは「ローカルから着地点まで」の経路です。直接接続はクライアントが海外ノードへ直接つなぎ、公共の国際出口を通ります。中継はまず中国本土の中継サーバーへ接続し、そこから海外の着地点へ転送します。IEPL専用線は国際イーサネット専用線リンクを使い、公共インターネットの出口を通りません。3者が影響するのは遅延とパケットロスの安定性で、出口IPは着地点のノードが決めます。ノードを変えれば出口アドレスも変わり、直接接続を中継に変えても所在地は変わりません。

DNSを確認:名前解決リクエストの経由先を調べる

ドメイン名はまずIPアドレスに解決されてからでないと接続できません。DNSクエリが回線を通らず、ローカルISPのリゾルバに渡されている場合、通常は2つの問題が起きます。アクセス先が名前解決の段階でローカルネットワークに露出してしまうこと、そして解決結果が近隣だが到達不能なアドレスや汚染されたアドレスを指すことがあり、「つながるのに開けない」「調子の良い時と悪い時がある」といった症状になります。

確認方法は2つあります。

DNSリーク検出ページを開き、表示されるリゾルバを確認します。一覧にローカルISPのアドレスがあれば、名前解決リクエストが回線を通っていない証拠です。
コマンドラインで確認する方法もあります。Windowsでは nslookup example.com を実行し、macOS / Linuxでは dig +short example.com を実行します。macOSでは scutil --dns で現在のリゾルバの順序を確認することもできます。

DNSが回線を通らない3つのよくある原因

ブラウザ側でセキュアDNS(DNS over HTTPS)が有効になっている。ブラウザがDoHサーバーへ直接接続し、システムDNSを迂回するため、クライアントが引き継げません。対処:ブラウザの設定でセキュアDNSを無効にするか、「システムの設定を使用」に変更します。
クライアントがTCPのみをプロキシし、UDP 53を引き継いでいない。対処:クライアントでDNS引き継ぎやリモート解決に関するオプションを有効にします。
振り分けルールがDNSリクエストを直接接続と判定している。対処:ルール一覧を確認し、DNSがプロキシに従うようにします。

IPv6も一度確認しておきたい

ローカルネットワークにIPv6アドレスが割り当てられていて、回線がIPv4しかプロキシしていない場合、一部の通信が回線を迂回してIPv6で直接接続されることがあります。クライアントでIPv6サポートを有効にするか、いったんシステムのIPv6を無効にして再テストしてください。

アプリごとに個別検証:ブラウザが通ってもターミナルが通るとは限らない

ブラウザは最もプロキシの影響を受けやすいアプリなので、ブラウザだけをテストすると結論が楽観的になりがちです。より確実なのは、3つの典型的なシーンをそれぞれ1回ずつテストすることです。

ブラウザ:送信元アドレスを表示するページを開き、アドレスが選択したノードの地域と一致するか確認します。
ターミナル:Windows 10 / 11にはcurlが標準搭載されているので、curl https://api.ipify.org をそのまま実行します。PowerShellなら Invoke-RestMethod https://api.ipify.org、macOS / Linuxなら curl -s https://api.ipify.org を使います。
デスクトップアプリとモバイル:メールクライアント、同期ストレージ、ゲームランチャーの多くはシステムプロキシを読み取らないため、アプリ内で個別に設定するか、TUNモードに頼る必要があります。スマートフォンではWi-Fiとモバイル回線を切り替えたあとに、もう一度確認してください。

ターミナルとブラウザの結果が一致しない場合の対処

ブラウザは回線のアドレスを表示するのに、ターミナルがローカルのアドレスを返す場合、現在はシステムプロキシ方式である可能性が高いです。ターミナルは既定でシステムプロキシを読み取りません。対処は2つあります。クライアントのTUNモードを有効にしてルーティング層に引き継がせるか、現在のターミナルセッションにだけ一時的にプロキシを指定するかです。

# 現在のターミナルセッションにだけプロキシを指定。ポートはクライアント画面に表示されるローカルポートに合わせる
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890

# 出口アドレスをもう一度確認
curl https://api.ipify.org

Windows PowerShellでは $env:https_proxy="http://127.0.0.1:7890" と書きます。現在のウィンドウでのみ有効で、ウィンドウを閉じると失効します。

つながっているように見えて、実はVPNを迂回しているよくあるケース

以下の対照表は、初心者が最もよく遭遇するいくつかのケースをまとめたものです。切り分けは上から順に進めるのがおすすめです。まず全体として反映されているかを確認し、その後に個別のアプリや特定サイトの例外を処理します。

症状	考えられる原因	対処の方向性
出口IPが接続前後で完全に一致	クライアントがシステムプロキシ方式で、現在のアプリがプロキシ設定を読み取らない	TUNまたはグローバルモードに切り替えるか、そのアプリに個別設定を行う
ブラウザは正常だが、ターミナルがローカルアドレスを返す	ターミナルは既定でシステムプロキシを読み取らない	TUNモードを有効にするか、http_proxy / https_proxy 環境変数を設定する
特定のサイトだけ回線を通らず、ほかは正常	振り分けルールがそのドメインを直接接続と判定している	クライアントの接続ログとルールの一致状況を確認し、そのドメインをプロキシ一覧に追加する
ノードを変えても出口アドレスが元のまま	ノードが実際には切り替わっていない、または古い接続が使われ続けている	切断して再接続し、クライアントで現在選択中のノードを確認する
DNS検出ページにローカルISPのリゾルバが表示される	ブラウザのセキュアDNSがシステムの名前解決を迂回している、またはクライアントがDNSを引き継いでいない	ブラウザのセキュアDNSを無効にし、クライアントのDNS引き継ぎを有効にする
別のプロトコルなら接続できるが、元のものは接続できない	ネットワーク環境がUDPパケットを破棄している	TCP伝送が可能なプロトコルに切り替えて比較テストする
Webページは開けるが、音声通話はローカルのまま	WebRTCやアプリ独自のP2P直接接続がプロキシを迂回している	ブラウザのWebRTCを無効にするか、アプリ内で直接接続を制限する
ステータスは接続済みなのに、実際にはまったく通信できない	システムに古いプロキシ設定が残っており、すでに終了したソフトのポートを指している	システムのプロキシ設定を確認し、自動に戻すか無効にしてから再接続する

プロトコルとトランスポート層

Hysteria2やTUICといったプロトコルはQUICベースで、UDPに依存します。Shadowsocks、VMess、Trojan、VLESSはTCP伝送を利用できます。「ノードは正常なのに接続できない」という場合は、まず伝送方式を変え、それでもだめならノードの変更を検討してください。社内ネットワークやキャンパスネットワークでUDPが破棄されるケースは珍しくありません。

3ステップのセルフチェックと結論

ここまでの内容を、そのまま実行できるチェックリストにまとめました。ネットワーク環境やノードを変えたら、そのたびに一通りやり直してください。

✅ 接続前と接続後に出口IPを確認し、アドレスが変わり、かつ所在地が選択したノードの地域と一致する。
✅ DNS検出ページに表示されるリゾルバの中に、ローカルISPのアドレスがない。
✅ ターミナルの curl とブラウザが同じ出口アドレスを返し、ブラウザだけでなく全体に反映されている。
✅ 実際に使うアプリを1つずつ開いて確認する。ブラウザのトップページを試すだけで終わらせない。
✅ Wi-Fiとモバイル回線を切り替えたら、もう一度確認する。前回の結論をそのまま流用しない。

結論3ステップすべてを通過して——出口アドレスが変わり、DNSが漏れず、ターミナルとブラウザの結果が一致して——初めて本当に反映されたと言えます。どれか1つでも通らない場合は、まず対照表に沿って対処し、最初のステップから再テストしてください。検証を飛ばしてノードを変えるのは避けましょう。

同じ回線で問題が繰り返し起きる場合、たとえば夜のピーク時間帯にパケットロスが続く、UDP系プロトコルが長期間遮断されるといったケースは、クライアントの設定では解決できません。回線タイプを検討すべき段階です。VPNBFは100+の国・地域、230+の回線を用意し、IEPL専用線と中継回線を含みます。回線は全区間で軍事レベルの暗号化、同時接続台数は無制限、Windows / macOS / iOS / Android / Linuxに対応。登録はユーザー名とパスワードだけで、メールアドレスは不要です。7日間の無条件返金保証、トラフィックパックは無期限です。

100+国・地域
230+選べる回線
無制限同時接続台数
7日間無条件返金