VPN接続後も機能しない？出口IPとDNSを確認する方法

VPN接続時は、クライアントに表示される「接続済み」だけで判断しないようにしましょう。この表示は通常、クライアントと接続先ノードの通信が確立したことを示すだけで、ブラウザーやダウンロードツールなどすべてのアプリの通信が経路を通っているとは限りません。出口IP、DNSの解決経路、システムルート、アプリ別の振り分けを順番に確認する必要があります。

最も確実な確認方法は、ノードを何度も切り替えることではなく、接続前の基準結果を残し、接続後と比較することです。出口IPが変われば、少なくとも一部の通信は別経路に切り替わっています。DNSの問い合わせ元も想定どおりで、複数のアプリで同じ結果が得られれば、システムが通信を取り込む範囲をさらに確認できます。

まず「機能している」の定義を確認：接続状態と通信の取り込みは別

クライアントが接続を確立した後、システムにプロキシ設定や仮想ネットワークインターフェース、ルート規則を書き込む必要がある場合があります。通信の確立と通信の取り込みは別の段階です。前者はノードへ到達できるようにし、後者はどのパケットを経路に入れるかを決めます。システム規則が書き込まれていない、別のネットワークツールに上書きされた、または一部のアプリだけを取り込むモードになっていると、「接続成功」と表示されてもアクセス結果が変わらないことがあります。

クライアントによって通信を取り込む方法も異なります。システムプロキシモードは、システムのプロキシ設定に従うアプリに主に影響します。仮想ネットワークアダプターのモードはより多くのアプリを対象にできますが、振り分けルール、LANのバイパス、アプリ独自のネットワーク実装の影響を受ける場合があります。ブラウザーが独自プロキシや暗号化DNSを使用していると、システム上の他のアプリと結果が一致しないこともあります。

つまり、「機能しているか」は3つに分けて判断するとよいでしょう。確認ページで出口が変わっていること、ドメイン解決が想定外の経路に漏れていないこと、通信を取り込む必要があるアプリがプロキシまたはトンネルのルートを実際に使用していることです。いずれか1つだけを満たしていても、経路が部分的に機能しているとは言えますが、確認を終えるには不十分です。

出口IPを確認：基準値を残してから接続後に再測定

出口IPは、Webサイトから見えるリクエスト元のアドレスです。未接続時は通常、現在利用しているネットワークから割り当てられます。経路が通信を取り込んだ後は、確認ページにノードまたはその上流の出口が表示されるはずです。前後の比較は同じブラウザー、同じ確認ページで行い、サイトごとのデータベースの違いによる影響を避けましょう。

1. クライアントを切断し、ブラウザーに独自プロキシの拡張機能があれば無効にします。信頼できるIP確認ページを開き、アドレス、国や地域、ネットワーク事業者を記録してください。
2. 対象ノードに接続し、クライアントの状態が安定するまで待ちます。その後、元のページを強制更新してください。以前から開いていたタブの内容だけを確認してはいけません。
3. アドレスが変わったかを比較し、選択した経路のおおよその出口地域と位置情報が一致するか確認します。データベースの更新には遅れがあるため、地域名は補助的な判断材料にとどめ、アドレスの変化を重視しましょう。
4. 別のブラウザーやOS標準のネットワークツールでも同じリクエストを実行します。結果が異なる場合は、ブラウザーのプロキシ、キャッシュ、拡張機能、振り分けルールを優先的に確認してください。

• ✅ 接続前後は同じネットワーク、同じ確認ページを使い、変数を減らす。
• ✅ ページを更新してから結果を読み直し、古いタブやスクリーンショットに頼らない。
• ✅ アドレスと事業者情報を同時に記録し、国旗や地域名だけで判断しない。
• ❌ 「特定のWebサイトを開けること」で出口IPの確認を代用しない。
• ❌ 複数のノードを続けて切り替えた後に、結果を混ぜて比較しない。

アドレスがまったく変わらない場合は、現在のモードがルール振り分けになっていないか確認します。ルールによってはIP確認サイトを直接接続にし、対象サイトだけを経路に通すことがあります。これは必ずしも接続障害ではありません。診断時だけ全体通信を取り込むモードへ一時的に切り替えて確認できます。検証後は元の振り分け設定に戻してください。全体モードは問題の切り分けには適しますが、長期運用に必ずしも向いているとは限りません。

ブラウザーでは出口が変わるのに、コマンドラインツールや他のアプリでは変わらない場合、現在のシステムプロキシモードを後者が読み取っていない可能性があります。逆に、システムツールでは経路が変わり、ブラウザーだけ元の出口のままなら、ブラウザー内のプロキシ、拡張機能、セキュアDNSの設定を確認してください。

DNSを確認：解決経路とブラウザーの違いを見分ける

ドメインへアクセスする前に、端末はドメイン名を接続可能なアドレスへ変換する必要があります。通常、この処理をDNSが担います。Web通信が経路を通っていても、ドメイン問い合わせが元のネットワークのDNSへ送られていれば、DNSリークが起きる可能性があります。ここでいう「リーク」は経路を示す表現であり、アカウント情報やWebページ本文が直接公開されたという意味ではありません。

DNSを確認する際は、信頼できるDNSテストページを使い、切断時と接続時でDNSサービスの提供元が変わるかを確認します。サーバーがどの都市に表示されるかだけで判断しないでください。DNSサービスは近い拠点へ振り分けられることがあり、位置情報データベースも遅れる場合があります。提供元、ネットワークの帰属、接続前後の差のほうが重要です。

現在のシステム設定は、ローカルコマンドでも補助的に確認できます。コマンドが示すのは端末が認識しているDNS設定であり、ブラウザーが最終的に使う解決経路と一致するとは限りません。Web上の検査結果と組み合わせて使い、相互に置き換えないようにしましょう。

Windows
ipconfig /all
nslookup example.com

macOS
scutil --dns
nslookup example.com

Linux
resolvectl status
nslookup example.com

ブラウザーとシステムの確認結果が異なる理由

現在のブラウザーにはセキュアDNSが有効になっており、ブラウザーで指定したDNSサービスへ直接問い合わせる場合があります。このとき、システムコマンドが示すのはOSの設定で、ブラウザーの確認ページに表示されるのは別の経路です。クライアントがシステムDNSを取り込んでいるか確認したい場合は、ブラウザー独自のセキュアDNSを一時的に無効にして再テストします。無効化後に結果が一致するなら、差異の原因はノードではなくブラウザー設定です。

もう1つの一般的な原因はキャッシュです。OS、ブラウザー、アプリはいずれも、過去に解決したドメインの結果を保持することがあります。経路を切り替えた直後に普段使うサイトへアクセスすると、アプリがキャッシュ済みのアドレスを使い続け、新たなDNS問い合わせを行わない場合があります。ブラウザーのネットワークキャッシュを削除するか、まだアクセスしていないドメインを調べて確認するほうが確実です。

アプリ別に検証：どのアプリが経路を使っていないかを特定する

ブラウザーが正常に動作することを確認したら、次に実際に使うアプリを確認します。アプリごとにネットワークスタックが異なり、システムプロキシに従うもの、アプリ内プロキシだけを読むもの、直接接続するもの、従来のプロキシモードでは取り込みにくいデータグラム通信を使うものがあります。そのため、同じ端末で「Webページは正常なのにクライアントは異常」という状態になることは珍しくありません。

検証時は、まずクライアントの接続ログでアプリのリクエストがルールに一致しているか確認します。接続一覧に対応している場合は、対象ドメインやプロセスがプロキシ、直接接続、拒否のどれに分類されているかを見ます。接続ログがない場合は、比較テストを行います。ノードを固定したまま、システムプロキシモードと仮想ネットワークアダプターのモードで同じアプリをテストしてください。仮想ネットワークアダプターのモードだけで機能するなら、そのアプリはシステムプロキシに従っていない可能性が高いでしょう。

1. ネットワーク設定を変更する可能性がある他のプロキシ、フィルター、パケットキャプチャーツールを終了し、現在のクライアントだけを動作させます。
2. ブラウザーで出口IPが変わったことを確認し、ノードと基本接続が利用できることを確かめます。
3. 対象アプリを開き、新しいネットワークリクエストが発生する操作を行います。オフラインキャッシュの読み込みは避けてください。
4. クライアントの接続記録またはルールの一致結果を確認し、そのアプリがプロキシと直接接続のどちらに振り分けられたかを確認します。
5. 通信の取り込みモードを一時的に切り替えて再テストします。結果がモードによって変わるなら、サブスクリプションを何度も変更するのではなく、アプリ用のルールを調整してください。

振り分けルールで「部分的にしか機能しない」理由

振り分けルールは、ドメイン、アドレス範囲、アプリのプロセス、ルールセットなどに応じて経路を決めます。通常は、国内向けサービスを直接接続し、国際アクセスを国際経路へ振り分けるために使いますが、すべてのリクエストを認識できるとは限りません。1つのWebサイトがログイン、画像、API、メディア用の複数ドメインを同時に呼び出すこともあります。メインページはプロキシに入り、APIドメインは直接接続になると、ページは開くのにログインできない、またはコンテンツが完全に読み込まれない状態になります。

この問題を調べるときは、まず全体通信を取り込むモードで比較します。全体モードで正常なら、ノード、プロトコル、サブスクリプションに根本的な問題はない可能性が高く、原因はルールにあると考えられます。その後、ルールモードへ戻し、クライアントのログから直接接続になった関連ドメインを探して、必要なドメインをプロキシルールへ追加します。未知のドメインをすべて長期的にプロキシへ回すのは避けてください。振り分けの意味が失われます。

プロトコル、サブスクリプション、経路の種類は何に影響するか

Shadowsocks、VMess、Trojan、VLESS、TUICなどのプロトコルは、クライアントとノードの間でデータを転送する方法を決めます。プロトコルのハンドシェイクに成功しても、その接続が確立したことしか分かりません。通信がプロトコル接続へ入るかどうかは、システムプロキシ、仮想ネットワークアダプター、振り分けルールによって決まります。したがって、「プロトコルが接続済み」と「アプリが経路を使っている」は同じではありません。

サブスクリプションURLは、クライアントへノードと設定を提供します。サブスクリプションを取り込むと、クライアントは通常、リモートの内容をローカルに保存します。サーバー側でノードが更新されても、ローカルの一覧が自動的に同期されるとは限りません。ノード名は残っていても設定が古いと、接続失敗、ハンドシェイク異常、接続後のアクセス不能が起きることがあります。確認前にクライアントでサブスクリプションを更新し、新しいノードを選び直してください。同じ古い内容を繰り返し取り込むだけでは不十分です。

プロトコルと経路の搬送方式も区別する必要があります。直接接続は端末からノードの入口へ直接アクセスする方式で、ローカルネットワークや国際回線の影響を受けやすくなります。中継はまず中継入口へ接続し、その後のノードへ転送します。IEPL専線は、特定の国際接続用の搬送経路を指すことが一般的です。これらはルーティングや安定性に影響しますが、クライアントによるシステム通信の取り込みを代替するものではありません。中継やIEPLを選んでも、アプリが直接接続に振り分けられていれば、通信は自動的にその経路へ入りません。

典型的な障害：接続成功に見えるのに経路が切り替わらない

システムプロキシが他のツールに上書きされている

ブラウザー拡張、ネットワークフィルターツール、開発・デバッグ用プロキシ、他のクライアントがシステムプロキシを書き換えることがあります。後から起動したツールが先の設定を上書きし、終了時に元へ戻さない場合もあります。対処時は関連する他のツールを終了し、システムのネットワーク設定でプロキシのアドレスが現在のクライアントによって管理されているか確認してから、切断と再接続を行ってください。

仮想ネットワークアダプターの権限またはルート書き込みに失敗している

仮想ネットワークアダプターのモードを初めて有効にするとき、システムによるネットワーク拡張機能や管理権限の確認を求められることがあります。許可が完了していないと、クライアントにはノード接続済みと表示されても、システムルートが実際には切り替わりません。クライアントのログでインターフェース作成、ルート書き込み、権限エラーの有無を確認し、システムのネットワーク設定で該当する拡張機能が許可されているか確認してください。

LANとローカルアドレスがバイパスされている

クライアントは通常、プリンター、ルーター、ローカルストレージへ引き続きアクセスできるよう、LANアドレスを直接接続にします。これは一般的な設計であり、経路が無効になったことを意味しません。ただし、対象サービスが内部ドメイン、社内DNS、特殊なアドレス範囲を使っている場合、バイパスルールによって解決やアクセスが想定外の経路へ進むことがあります。実際のネットワークに合わせて調整してください。

システム時刻が正確でない

一部の暗号化プロトコルは、証明書やハンドシェイクの検証に正確なシステム時刻を必要とします。端末の時刻が大きくずれていると、接続と切断を繰り返したり、クライアント画面に一時的に接続済みと表示されても通信できなかったりします。まずシステムの自動時刻合わせを有効にしてから、再接続してテストしてください。

ネットワーク切り替え後に古いルートが残っている

端末を有線ネットワークから無線ネットワークへ切り替えた後、または別のアクセスポイントへ移動した後、クライアントが古いインターフェースに関連するルートを保持することがあります。最も簡単な対処手順は、経路を切断し、システムのネットワーク切り替えが完了するまで待ち、通常のWebページへ直接アクセスできることを確認してから、クライアントへ再接続することです。

確認の手順：変更を最小限にして始める

問題が起きたときは、以下のチェックリストを上から順に実行することをおすすめします。まず基本ネットワークを確認し、次にサブスクリプションとノード、最後にシステムの通信取り込みと振り分けを変更する順序なら、元のネットワーク自体に問題がある場合でもクライアントを誤判定しにくくなります。

• ✅ 経路を切断し、現在のネットワーク自体でドメイン解決とWebアクセスが正常に行えることを確認する。
• ✅ 切断状態で出口IPとDNSの検査結果を記録し、基準値にする。
• ✅ サブスクリプションを更新し、現在接続可能なノードを選び直す。
• ✅ 接続後に検査ページを強制更新し、出口IPが変わったか確認する。
• ✅ DNSサービスの提供元を確認し、ブラウザー独自のセキュアDNS設定にも注意する。
• ✅ 別のブラウザーまたはアプリで相互テストし、問題が特定のプログラムに限られるか判断する。
• ✅ 接続ログとルールの一致を確認し、対象リクエストが直接接続になっていないことを確かめる。
• ✅ 一時的に全体通信を取り込むモードで比較し、その後元に戻してルールを修正する。
• ✅ システムのネットワーク拡張機能、仮想ネットワークアダプターの権限、残ったプロキシ設定を確認する。
• ❌ ネットワーク、プロトコル、ノード、DNSを同時に変更しない。変数を特定できなくなる。

出口IPとDNSがともに想定どおりでも、特定のWebサイトを利用できない場合、問題は「経路が機能しているか」という層にはない可能性があります。対象サイトがアカウントの地域、ブラウザーキャッシュ、位置情報の権限、コンテンツ配信の方針でアクセス地域を判断していることもあります。この場合、システムDNSをさらに変更しても効果は限られます。サイトデータを個別に削除し、アカウント地域とアプリの権限を確認し、関連ドメインが同じルールセットに一致しているかを確認してください。

すべての検査結果が元のネットワークのままなら、クライアントの通信取り込み層に戻ります。システムプロキシが書き込まれているか、仮想ネットワークアダプターに権限があるか、他のツールにルートを上書きされていないかを確認してください。ノードだけが接続できない場合は、プロトコルログ、サブスクリプションの更新時刻、現在のネットワークとの互換性を確認します。「ノードに接続できない」と「ノードには接続できるが通信を取り込めない」を分けて対処するほうが、設定を何度も切り替えるより効果的です。