VPNが接続済みでも、クライアントに表示される「接続済み」だけでは不十分です。この表示は通常、クライアントとリモートノードのハンドシェイクが完了した、またはローカルプロキシポートが起動したことを示すだけです。ブラウザー、コマンドラインツール、その他のアプリの通信がすべて目的の経路を通った証拠にはなりません。出口IP、DNS解決、IPv6経路、アプリ別ルールを順に確認する必要があります。
調査中はノード、プロトコル、システム設定を頻繁に切り替えないでください。一度に変更するのは1つだけにし、同じテストを繰り返します。これにより、ノードの問題か、ルーティングの問題か、特定のアプリがプロキシを回避しているのかを切り分けられます。以下の方法は、一般的なシステムVPN、システムプロキシ、TUNモード、およびShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICの設定を使うクライアントに対応しています。
「接続済み」でも機能していない可能性がある理由
クライアントが接続を確立した後も、通信を対応するトンネルまたはローカルプロキシポートへ送る必要があります。この処理には、システムプロキシ、ルーティングテーブル、仮想ネットワークアダプター、DNS設定、アプリ独自のネットワーク実装が関わります。どこか1つでも正常に引き継げないと、「クライアントは正常なのにアクセス結果が変わらない」状態になることがあります。
接続モードによって対応範囲は異なります。システムプロキシが影響するのは、システムプロキシ設定を読み取るアプリが中心です。ブラウザーは通常読み取りますが、一部のコマンドラインプログラム、ゲーム、ダウンロードツール、独自のネットワークスタックを使うソフトは無視することがあります。TUNモードは仮想ネットワークアダプターを通じてより広範なIP通信を処理しますが、ルート除外、LAN回避、ルール分岐、システム権限の影響は受けます。
| 表面的な現象 | 実際に起きている可能性 | 優先して確認する項目 |
|---|---|---|
| クライアントに接続済みと表示される | ノードとのハンドシェイクだけが完了し、アプリがローカルプロキシまたはトンネル経路を使っていない | 出口IP、システムプロキシ、TUNの状態 |
| ブラウザーでは機能するが、他のアプリでは機能しない | ブラウザーはシステムプロキシを読み取るが、他のアプリは直接接続している | アプリ別ルール、アプリのプロキシ設定、TUNモード |
| ウェブ上の出口は変わったが、名前解決に異常がある | ウェブ通信はノードを経由しているが、DNSはローカルネットワークで処理されている、またはキャッシュされている | DNSモード、キャッシュ、クライアントログ |
| 一部のウェブサイトだけ経路に異常がある | ドメインルール、IPルール、IPv6経路が想定と異なる | ルールのヒット記録、IPv6、ルーティングポリシー |
| ノードを切り替えても結果が変わらない | 検証ページがキャッシュされている、または現在のアプリがプロキシ経路に入っていない | 再読み込み、別アプリで再テスト、ルーティング確認 |
プロトコル名だけでは対応範囲を判断できません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、クライアントとノードの間でデータを転送する方法を示すものです。アプリ通信がその接続に入るかどうかは、ローカル待受ポート、システムプロキシ、TUN、ルーティングルールによって決まります。プロトコルのハンドシェイク成功と、すべての通信の引き継ぎは別の問題です。
未接続時のネットワーク基準値を先に記録する
変化を判断するには、まず未接続時の状態を把握する必要があります。クライアントの接続を切り、システムプロキシとTUNが元に戻ったことを確認してから、現在の出口IP、ネットワーク事業者情報、IPの種類、おおまかな地域を記録します。この作業は本サイトのIPチェックページで行えます。
基準値の確認には、後で検証するのと同じアプリを使います。ブラウザーを確認するなら、そのブラウザーで記録します。問題がコマンドラインツールで発生している場合は、コマンドラインから個別にテストしてください。ブラウザーの結果で他のアプリを判断することはできません。両者でプロキシ設定が異なる場合があるためです。
- ✅ 現在の接続を切り、クライアントがシステムプロキシや仮想ネットワークアダプターを使用していないことを確認する。
- ✅ 対象アプリでIPチェックページを開き、出口IP、IPの種類、地域を記録する。
- ✅ 通信経路を変える可能性がある他のプロキシ拡張機能や並行稼働中のクライアントを終了する。
- ✅ テスト中は有線、無線、その他のネットワークを切り替えず、接続先を変えない。
- ✅ 対象ノードに再接続した後、同じアプリ、同じ検証ページで再テストする。
切断後もノード側の出口が表示される場合、システムプロキシ、ブラウザー拡張機能、仮想ネットワークアダプター、バックグラウンドプロセスが元に戻っていない可能性があります。この状態で接続テストを続けても意味がありません。基準値が古い設定に汚染されているためです。関連クライアントを終了し、システムのネットワーク設定を確認してから、基準値を取り直してください。
出口IPを確認：ウェブ通信の経路を確かめる
基準値を記録したら対象ノードに接続し、IPチェックページをもう一度開きます。キャッシュの影響を減らすには、ページを再読み込みするか、新しいブラウザータブを使います。出口IPがローカルネットワークのアドレスからノードの出口へ変わり、ネットワークの帰属情報も選択した経路と一致していれば、そのブラウザータブのウェブリクエストがプロキシ経路を通ったと確認できます。
出口IPの変化は最も直接的な証拠ですが、確認対象となったリクエストの経路しか証明しません。ブラウザー拡張機能はブラウザーだけをプロキシすることがあり、システムプロキシは一部のプログラムしか読み取らない場合があります。分岐ルールによって、検証サイトだけノードを経由し、他のドメインは直接接続になることもあります。そのため、実際に問題が起きているアプリと対象ドメインも確認してください。
出口IPが変わらない場合の確認方法
- クライアントがローカルプロキシポートを起動しただけで、システムプロキシ設定を自動的に変更していない可能性を確認する。
- ブラウザーに個別のプロキシ設定がないか確認する。個別設定がシステム設定を上書きしている、またはすでに無効な古いポートを指定している可能性があります。
- クライアントの現在のモードを確認する。ルールモードでは検証ドメインが直接接続と判定されることがあるため、診断中だけでも適用範囲が明確なモードを使う。
- TUNを使用している場合は、仮想ネットワークアダプターが正常に作成され、ルート変更に必要なシステム権限をクライアントが取得しているか確認する。
- 実行ログを確認し、リクエストがプロキシルール、直接接続ルール、拒否ルールのどれに一致したか確認する。
クライアントにサブスクリプションURLから設定を取り込んでも、システムプロキシが有効になったとは限りません。クライアントによっては、「サブスクリプションを更新」「ノードを選択」「ローカルサービスを起動」「システムプロキシに設定」が別々の操作になっています。調査では、サブスクリプションを何度も取り込み直すのではなく、これらの状態を確認してください。
出口IPが変わっても対象サービスを開けない
この段階では、問題は「プロキシを経由しているか」から「この経路が対象リクエストに適しているか」へ絞り込めます。DNSの応答異常、対象サービスによる出口ネットワークの制限、分岐によって関連サブドメインが別経路になっている、ブラウザーが古い接続を保持している、といった原因が考えられます。プロトコルを切り替える前に、DNS、ルールのヒット状況、アプリログを確認してください。
DNSを確認：ドメイン解決の経路を判断する
ウェブサイトにアクセスする前に、システムは通常、ドメインをIPアドレスへ解決します。ウェブ接続がノードを経由していても、DNSクエリが同じ経路を通るとは限りません。DNSがローカルネットワークで処理されていると、ノードの地域と一致しない結果が返る、一部ドメインだけ異常になる、ドメインリクエストがローカルの名前解決サービスに伝わる、といった状態が起こることがあります。
DNSを調べる際は、システム画面にどのサーバーが入力されているかだけを見てはいけません。多くのシステムはローカルスタブリゾルバーを使い、クライアントがクエリを引き継いだり、仮想アドレスを返したり、トンネル内にカプセル化したりすることもあります。画面にローカルアドレスが表示されても、必ずしも漏えいを意味しません。重要なのはクライアントログでの処理方法と、最終的にどちら側が再帰的な名前解決を行ったかです。
ブラウザーとシステムのDNSは異なる場合がある
最新のブラウザーでは独自の暗号化DNSを有効にできます。有効にすると、ブラウザーの名前解決経路がOSと異なる場合があります。そのため、コマンドラインの問い合わせは正常なのにブラウザーだけ異常になる、またはブラウザーは正常でも他のアプリがローカルネットワークのリゾルバーを使い続けることがあります。調査では個別にテストし、1つの結果だけでシステム全体を判断しないでください。
ターミナルでキャッシュされていない対象ドメインを問い合わせ、同時にクライアントログを確認できます。Windowsでは通常nslookup、macOSとLinuxではdigまたはnslookupを使います。コマンドの出力は解決結果を示し、クライアントログはリクエストが引き継がれたか、転送されたか、ルールに従って直接接続されたかを示します。
nslookup example.com
dig example.com
nslookup example.com 指定するDNSサーバー最後の「指定するDNSサーバー」は、実際にテストするサーバーアドレスに置き換えてください。パブリックDNSサービス自体をプロキシと考えてはいけません。DNSはドメインを解決するだけで、ウェブ接続の出口を自動的に変えるものではありません。
DNSキャッシュによる誤判定を避ける
システム、ブラウザー、クライアントはいずれも解決結果をキャッシュすることがあります。ノードを切り替えた直後に同じドメインを問い合わせても、古い応答が表示される場合があります。関連するタブを閉じ、アプリ内のDNSキャッシュを消去し、再接続してから問い合わせるのが確実です。システムのキャッシュ削除コマンドに慣れていない場合は、対象アプリを再起動してください。不明なネットワーク設定をむやみに削除してはいけません。
- ✅ 出口IPが変わったことを確認してからDNSを調べ、2つの問題が同時に影響しないようにする。
- ✅ ブラウザーとシステムのコマンドラインを個別にテストし、特定のアプリだけが異常か確認する。
- ✅ クライアントログを確認し、DNSリクエストがプロキシ経由の名前解決と直接接続のどちらに一致したか確認する。
- ✅ ブラウザーで独自の暗号化DNS設定が有効になっていないか確認する。
- ❌ システム画面にローカルスタブアドレスが表示されているだけで、DNS漏えいと判断しない。
- ❌ ドメインを解決できることと、ウェブ通信がトンネルに入っていることを同一視しない。
IPv6とアプリ別ルーティングを確認する
一部のネットワークではIPv4とIPv6を同時に提供しています。クライアントが一方だけを引き継ぐこともあれば、システムの対応状況に応じて異なる経路を選ぶこともあります。IPv4はノード経由でもIPv6がローカルに直接接続されていると、IPv6対応サイトでは引き継がれていない経路が優先される場合があります。その結果、同じブラウザーでもサイトによって結果が異なります。
確認時はIPチェックページで、現在公開されているのがIPv4、IPv6、またはその両方かを確認します。一部のプロトコルスタックだけを引き継いでいる場合は、クライアントで対応機能を有効にするか、クライアントのドキュメントに従ってIPv6ポリシーを調整してください。ブラウザー上で結果を隠すだけでは不十分です。基盤となるルーティングは変わらないためです。
アプリ別プロキシでよくある境界
アプリ別機能では通常、アプリを含めるか除外するかによって経路を決めます。設定時には、「選択したアプリだけがプロキシを通る」と「選択したアプリはプロキシを通らない」という2つの意味を混同しがちです。クライアント更新後にアプリの経路やプロセス名が変わり、古いルールに一致しなくなることもあります。
ブラウザーは複数の補助プロセスを起動することもあります。メインプログラムをルールに追加しても、システムコンポーネントが処理するリクエストまで対象になるとは限りません。一方、TUNモードは通常、アプリがプロキシ設定を読み取るかどうかに完全には依存せず、ネットワーク通信とルールの一致によって処理するため、システムプロキシに対応しないソフトの確認に適しています。ただし、TUNだから無条件にすべての通信を引き継ぐわけではありません。LAN、予約アドレス、直接接続ドメイン、手動の除外項目は引き続き回避する可能性があります。
| 引き継ぎ方式 | 通常対応する通信 | 見落としやすい範囲 | 適した検証方法 |
|---|---|---|---|
| ブラウザー拡張機能 | ブラウザー内で拡張機能が処理するリクエスト | 他のアプリ、システムのバックグラウンドリクエスト | ブラウザーとコマンドラインで個別に出口を確認 |
| システムプロキシ | システムプロキシ設定に従うアプリ | システムプロキシを無視するソフト、一部の非ウェブ通信 | アプリごとにテストし、ログを確認 |
| TUNモード | 仮想ネットワークアダプターに入り、ルーティングに一致するIP通信 | 除外ルート、LAN通信、引き継がれていないプロトコルスタック | ルーティング、IPv6、ルールのヒットを確認 |
| アプリ内プロキシ | アプリが自発的にプロキシポートへ送るリクエスト | アプリ外の通信、設定で対象になっていない接続 | アドレス、ポート、アプリログを照合 |
クライアントログから接続層の問題を特定する
出口IPとDNSの両方が想定どおりでない場合、ノードを何度も切り替えるよりログを確認する方が効果的です。ログからは、サブスクリプションの解析失敗、ノードのハンドシェイク失敗、ローカルポートの競合、証明書や時刻の異常、ルートの書き込み失敗、リクエストを処理したルールなどを切り分けられます。確認は接続操作を行った時刻から始め、過去のエラーに惑わされないようにします。
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICではハンドシェイク方式が異なり、エラー文も完全には一致しません。ただし、確認の順序はほぼ同じです。まず設定が完全か確認し、次にノードへ到達できるか、ローカル待受が正常かを確認し、最後に対象リクエストが対応するアウトバウンドに入ったかを確認します。ハンドシェイクが成功しているのにログに対象リクエストがない場合、問題はリモート側のプロトコルではなく、ローカルでの引き継ぎや分岐ルールにある可能性が高いです。
サブスクリプションURLの取り込みに失敗した場合は、まずURLが完全か、クライアントがサブスクリプションに含まれる設定形式に対応しているか、更新が現在のネットワークで遮断されていないかを確認します。取り込みに成功した後も、有効なノードを選択して接続を開始する必要があります。ノード一覧が表示されただけでは、そのノードが使用中とは限りません。
プラットフォーム別の確認ポイント
Windowsでは、残存するシステムプロキシ設定、仮想ネットワークアダプターの状態、アプリがWinHTTPまたは独自のプロキシ設定を使っているかを確認します。macOSでは、現在のネットワークサービスのプロキシ設定を確認し、システム拡張機能やネットワーク拡張機能に必要な権限が付与されているか確認します。Linuxでは、デスクトップのプロキシ設定とターミナルの環境変数が独立していることがあります。ブラウザーで機能しても、ターミナルのコマンドが機能するとは限りません。
モバイルプラットフォームでは通常、システムVPNインターフェースが通信をまとめて処理しますが、省電力設定、アプリ別VPN、常時接続、LANアクセスの設定によって結果が変わります。バックグラウンド復帰後に機能しなくなった場合は、ステータスバーのアイコンだけを見るのではなく、クライアントを開いてトンネルの状態と最新ログを確認してください。
「接続済み」に見える典型的なケース
ブラウザーは正常だが、ダウンロードツールはローカルの出口を使う
これは通常、システムプロキシの対応範囲に関する問題です。ブラウザーはシステムプロキシを読み取る一方、ダウンロードツールは直接接続のネットワークスタックを使います。ダウンロードツールがプロキシに対応しているか確認するか、この種の通信をカバーできるTUNモードを使い、2つのアプリの出口を個別に検証してください。
ノードを切り替えてもウェブ上の地域が変わらない
まずページキャッシュと古い接続の再利用を除外し、ルールモードによって検証ドメインが直接接続になっていないか確認します。ログに検証リクエストがない場合、ブラウザーが現在のクライアントに入っていない可能性があります。ログ上で新しいノードを経由しているのに位置情報が更新されない場合は、地域の文字表示だけでなく、出口IPとネットワークの帰属情報を基準にしてください。
接続を有効にするとネットワークにまったくアクセスできない
接続保護や同様の遮断ポリシーを有効にしている場合、ノードのハンドシェイクに失敗するとローカルの直接接続もブロックされることがあります。これは通信が密かに直接接続されているのではなく、接続を利用できないときに保護ルールが通信を許可しない状態です。ハンドシェイクエラー、ローカル時刻、ネットワーク権限、ノードへの到達性を確認してください。
一部のドメインだけ失敗する
まずドメインの分岐、DNSの応答結果、関連サブドメインを確認します。1つのサービスが複数のドメインを使い、メインサイトとAPIリクエストが異なるルールに一致することがあります。メインドメインだけをプロキシリストに追加しても、すべてのリソースが同じ経路を使うとは限りません。ログのルールヒット記録から、分岐点を直接確認できることが多いです。
直接接続、通常の中継、IEPL専用線で結果が異なる
直接接続は、端末がリモートノードへ直接接続する方式で、経路は公衆ネットワークのルーティングに左右されます。通常の中継では、まず中継入口に接続し、そこから出口へ転送します。IEPL専用線では通常、入口と出口の間を専用リンクで転送しますが、利用者から入口まで、そして出口から対象サービスまでの経路も全体の一部です。回線の種類は経路の安定性に影響しますが、ローカルプロキシやDNSの確認に代わるものではありません。専用線を使っていても、ローカルアプリがトンネルに入っていなければ出口は変わりません。
繰り返し実行できる検証手順
詳細な調査でも、多数の設定を同時に変更する必要はありません。以下の順序では、観察しやすい現象から始め、システムとクライアントの内部へ段階的に進みます。各手順の結果を記録し、異常が見つかったらその層で対処してください。後段のプロトコルパラメーターを先に変更する必要はありません。
- 接続を切り、対象アプリの出口IP、IPの種類、ネットワークの帰属情報を記録して基準値を作る。
- 対象ノードに接続し、同じアプリで出口を再確認して、リクエストの経路が変わったか確認する。
- ブラウザーとシステムツールでDNSを個別に確認し、クライアントログと合わせて解決方式を判断する。
- IPv4とIPv6の両方が想定どおり引き継がれているか確認し、デュアルスタック環境で経路が分離しないようにする。
- 実際に問題が発生しているアプリで再テストし、システムプロキシ、TUN、アプリ内プロキシの対応範囲を確認する。
- ルールのヒット状況とアウトバウンドログを確認し、直接接続、プロキシ、拒否、名前解決エラーを切り分ける。
- 最後にノードまたはプロトコルを切り替え、他の条件を変えずに変化の原因を比較する。
問題が解決しない場合は、クライアント内で接続時刻、プラットフォーム、接続モード、プロトコルの種類、エラーログ、実施済みの確認項目を整理し、サイト内のFAQまたはトラブルサポート窓口で引き続き確認してください。「どのアプリで、どのドメインが対象か、出口が変わったか、DNSがどう処理されたか」を具体的に伝える方が、「接続できない」とだけ説明するより原因の層を特定しやすくなります。