VPNは接続済みなのに使えない場合、原因は一つとは限りません。クライアントの「接続済み」は、クライアントとリモートノード間で何らかの接続処理が完了したことを示すだけで、ブラウザー、デスクトップアプリ、システムサービスがすべて通信をこの経路へ渡したとは限りません。出口IPが変わらない、DNSがローカルネットワークで解決される、特定のアプリがプロキシを迂回する、といった要因で「接続済みなのにアクセス結果が変わらない」状態になります。
確認時は、運任せにノードを何度も切り替えないでください。クライアントがセッションを確立したか、システムがプロキシや仮想NICの設定を受け入れたか、対象アプリがルール分岐に一致したか、名前解決が想定した経路を通ったか、リモートサービスが現在の出口を受け入れたかというように、経路を複数の独立した段階に分けて確認するのが確実です。各段階を個別に検証すれば、問題の発生箇所を特定できます。
まず「接続済み」と「通信を引き受け済み」を区別する
「接続済み」の定義はクライアントによって完全には同じではありません。Shadowsocks、VMess、Trojan、VLESSでは、まずローカルプロキシポートを起動してからリモートノードをテストする場合があります。このとき、システムプロキシ設定を読み取るアプリ、またはプロキシアドレスを明示的に設定したアプリだけがリクエストをローカルポートへ送ります。設定を読み取らないアプリは、通常どおり直接インターネットへアクセスできます。
Hysteria2とTUICは、従来のTCP転送とは異なる方式で通信することが多いものの、システム通信を引き受けるかどうかはクライアントの動作モードで決まります。プロトコル接続が成功しても、ルーティングテーブル、仮想NIC、ルール分岐が正しく設定されたことを自動的に証明するわけではありません。プロトコルはクライアントとノード間の転送方法を決め、システム側の引き受け設定はどの端末通信をその経路へ入れるかを決めます。両者を混同しないでください。
システムプロキシモードは、OSのプロキシ設定に従うプログラムに主に影響します。TUNモードは仮想NICとルーティングルールを使って、より広い範囲の通信を受け取るため、システムプロキシを参照しないデスクトップアプリに適することがあります。アプリ内プロキシは指定したソフトウェアだけに適用されます。3つのモードが同じクライアントに存在する場合もありますが、名称、必要な権限、ルールの実装はプラットフォームによって異なります。
| 確認できた現象 | 該当する可能性がある段階 | 優先して確認する項目 |
|---|---|---|
| すべてのアプリで出口が変わらない | システムプロキシ、TUNルート、クライアントの通信引き受け | 動作モード、システム権限、プロキシ設定 |
| ブラウザーでは有効だが、デスクトップアプリでは有効にならない | アプリがシステムプロキシを読み取っていない | TUNモード、アプリ内プロキシ、ルール分岐 |
| 出口は変わったが、ドメインの名前解決元が不自然 | DNS経路 | クライアントのDNS設定、ブラウザーのセキュアDNS |
| アクセスできるサイトと、結果が変わらないサイトがある | ルール分岐、キャッシュ、対象サービスのポリシー | ルールの一致記録、シークレットウィンドウ、出口地域 |
| ノードを切り替えても、古いページに以前の地域が表示される | 接続の再利用、キャッシュ、セッション状態 | 古い接続を閉じ、ページを開き直し、アプリを終了する |
出口IPでインターネット通信の経路を確認する
出口IPは、外部から確認できる最も直接的な証拠です。確認前に経路を切断し、サイト内のIP確認を開いて、現在のネットワークの帰属情報を記録します。次に対象ノードへ接続し、確認ページを開き直します。アドレスと帰属が想定どおり変われば、このブラウザーのインターネット通信はリモート出口を経由しています。結果がまったく同じなら、ブラウザーが通信を引き受けられているかをさらに確認します。
テストでは、長時間開いたページを更新するだけにしないでください。ブラウザーが接続プール、プロキシ認証状態、ページキャッシュを保持している可能性があり、サイトによっては地域情報をセッションに保存します。より確実なのは、テスト用タブを閉じて新しいブラウジングセッションを作成し、再度確認する方法です。ブラウザーに独立したプロキシ拡張機能を入れている場合は、拡張機能がシステムプロキシを上書きしていないか、現在のドメインを強制的に直接接続にしていないかも確認してください。
- クライアントを切断し、現在の出口の帰属を確認して記録する。
- 対象ノードへ接続し、クライアントがローカルポートの起動だけで止まっていないことを確認する。
- 新しいブラウジングセッションを作成し、出口の帰属をもう一度確認する。
- 別のアプリでも同じ確認を行い、結果が一致するか比較する。
- クライアントの接続ログを確認し、テスト通信がプロキシルールまたは直接接続ルールに一致したか確認する。
出口が変わったことから証明できるのは、テストしたアプリのインターネット通信がその経路を通ったことだけです。すべてのアプリが同じ経路を使っているとは限りません。ブラウザーはシステムプロキシを使い、コマンドラインツールは直接接続することがあります。デスクトップアプリが独自のネットワーク処理を使う場合もあり、システム更新、LAN機器、バックグラウンドサービスも同じルール群の対象とは限りません。そのため、出口の確認後はDNSとアプリ別の結果も確認してください。
DNSが想定した経路で名前解決しているか確認する
DNSはドメイン名を接続可能なアドレスへ変換します。ウェブの内容がリモート出口を通っていても、名前解決まで同じ経路を通るとは限りません。システムがローカルネットワークのDNSを使い続けると、アクセス通信と名前解決の通信が別々の経路を通ります。この状態はDNSリークと呼ばれることがあります。ローカルネットワーク側の名前解決元が分かるほか、対象地域に適さない結果をルール分岐が受け取る可能性もあります。
確認時は、接続前後でDNSの名前解決サービスの帰属を比較します。出口が変わったのに、解決サービスが明らかに現在のローカルネットワークに属している場合は、クライアントでリモートDNS、暗号化DNS、またはTUNが管理する名前解決モードが有効か確認してください。項目名はクライアントによって異なるため、「自動」という表示だけで有効と判断せず、接続ログと外部確認の結果も合わせて確認するのが安全です。
ブラウザーが独自のセキュアDNSを有効にして、OSやクライアントが指定したリゾルバーを迂回することもあります。これは必ずしも障害ではありませんが、クライアントのルールとブラウザーの名前解決経路が一致しなくなります。特定のブラウザーだけDNS結果が異常な場合は、一時的にブラウザーをシステム設定に従わせて再確認してください。企業ネットワークのセキュリティソフトが名前解決を管理している場合は、所属ネットワークの管理方針に従います。
- ✅ 出口の帰属が選択したノードの地域と一致し、DNSの帰属もクライアント設定に合っている。
- ✅ ブラウザーを変えても結果が一致し、特定ブラウザー固有の名前解決設定ではない。
- ✅ クライアントログにドメインの名前解決リクエストが記録され、想定したプロキシまたはリモートDNS経路が表示される。
- ❌ 出口は変わったが、DNSがローカル接続ネットワークを指し続けている。
- ❌ ブラウザーとシステムツールで名前解決の帰属が完全に異なり、ルール分岐でも差を説明できない。
- ❌ DNSを変更した後、古いページを更新しただけで、既存の接続と名前解決キャッシュを消去していない。
DNS設定を変更した後は、古い名前解決結果を無効にする必要があります。対象アプリを終了して再起動し、経路を切断してから再接続し、必要に応じてOSが提供するDNSキャッシュの更新機能を使います。出所不明のクリアコマンドを無闇に実行しないでください。OSによってコマンドや権限モデルが異なり、誤操作で通常のネットワーク設定に影響する可能性があります。
ブラウザー、クライアント、システムサービスをアプリ別に確認する
アプリ別検証の目的は、「どのプログラムで有効になり、どのプログラムで有効にならないか」を特定することです。まずシステムプロキシに従うブラウザーを基準にし、次にシステムプロキシを必ずしも読み取らないデスクトップアプリをテストし、最後にコマンドラインやシステムサービスを確認します。一度に一つの条件だけを変えることで、差がアプリ、モード、ノードのどこから生じたか判断できます。
ブラウザーでは有効だが、デスクトップアプリでは有効にならない
通常は、システムプロキシは設定されているものの、デスクトップアプリが読み取っていない状態です。独自のプロキシ画面を使うアプリもあれば、起動時にシステム設定を読み取る必要があるアプリもあります。また、TUNモードでのみ一括して通信を引き受けられるアプリもあります。まずアプリのネットワーク設定に「システム設定に従う」「直接接続」「カスタムプロキシ」などの項目があるか確認し、アプリ内プロキシとTUNのどちらを使うか決めます。
アプリでHTTPまたはSOCKSプロキシを入力できる場合は、クライアントが実際に待ち受けているローカルアドレスとポートを指定します。経験だけでポートを入力したり、サブスクリプションURLをプロキシアドレスとして使ったりしないでください。サブスクリプションURLはクライアントへノード設定を配布する入口であり、プロキシアドレスは端末上のアプリがクライアントへ接続する入口です。用途が異なります。
デスクトップアプリでは有効だが、ブラウザーでは有効にならない
ブラウザー拡張機能、独立したセキュアDNS、起動パラメーター、企業ポリシーがシステム設定を上書きすることがあります。まずプロキシ経路を変更する拡張機能を停止し、ブラウザーが「システム設定に従う」状態か確認してから、新しいブラウジングセッションで検証します。特定のユーザープロファイルだけに問題がある場合は、クライアント全体をすぐ再インストールするのではなく、一時的なプロファイルを作成して比較してください。
一部のドメインだけ有効にならない
この場合はルールモードを重点的に確認します。一般的なモードには、グローバルプロキシ、ルール分岐、グローバル直接接続があります。ルール分岐は、ドメイン、アドレス範囲、プロセス、ルールセットに基づいて経路を決めます。対象ドメインが直接接続ルールに一致すると、他のサイトは正常なのにそのサイトだけローカル出口を使う状態になります。クライアントログのルール一致項目を確認するほうが、ノードを繰り返し切り替えるより効果的です。
サブスクリプション、プロトコル、ノード設定を切り分ける
クライアントにサブスクリプションを読み込んだ後、ノードは表示されるのに有効な通信が確立しない場合は、「サブスクリプションの取得成功」と「ノード接続成功」を分けて考えます。サブスクリプションURLは設定を取得する入口で、通常はノードアドレス、ポート、プロトコル、認証パラメーターが含まれます。クライアントがサブスクリプションを正常にダウンロードできても、そこに含まれるすべてのノードが現在のネットワーク環境でセッションを確立できるとは限りません。
読み込み時は、クライアントが明確に対応しているサブスクリプション形式を選びます。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはパラメーター構造が異なるため、プロトコル名だけを変更して置き換えることはできません。クライアントのバージョンがサブスクリプション内の転送方式に対応していないと、ノード名は表示されても正しく接続できない場合があります。サービス提供元が推奨するクライアントを優先し、クライアントのサブスクリプション更新機能で設定を取得してください。認証項目を手作業で削除・変更しないでください。
ノードには接続できるのにデータが流れない場合は、ログのハンドシェイク、認証、名前解決、ルーティング情報を確認します。認証失敗は、設定の期限切れやパラメーター不一致を示すことが多く、接続タイムアウトはローカルネットワーク、ノードアドレス、転送方式が原因の可能性があります。リクエストが直接接続と記録されるならルールの問題です。ログにローカルポートの起動情報しかなく、リモートセッションがない場合は、クライアントがまだノードへ実際に接続していない可能性があります。
中継、直接接続、IEPL専線は、それぞれ異なる経路構成を指します。直接接続は通常、利用者のネットワークからノードの入口へ直接アクセスします。中継ではまず中継入口へ入り、そこから目的の出口へ転送します。IEPL専線は、国境をまたぐ区間の専用伝送構成を重視します。これらは経路や用途に影響しますが、端末側のプロキシ引き受け設定に代わるものではありません。経路自体が正常でも、システムプロキシが無効、またはルールが直接接続に一致していれば、アプリはその経路を通りません。
プラットフォームごとの違いと確認の順番
デスクトップOSは通常、システムプロキシと仮想NICモードの両方に対応しますが、TUNには追加の権限が必要なことがあります。権限が許可されていないと、クライアント画面にはノード接続済みと表示されても、ルートが完全には設定されません。この場合は、ネットワーク拡張、仮想NIC、管理者権限の許可を求める表示がOSに出ていないか確認し、許可後に接続をやり直します。
モバイルOSでは、通常OSが提供するVPNインターフェースで通信を引き受けます。別のネットワークツール、コンテンツフィルター、企業管理設定が同じインターフェースを使用していると、新しい接続が想定どおり動作しないことがあります。OSのネットワーク設定で現在有効な構成を確認し、アプリ内のボタンだけを見て判断しないでください。省電力設定がバックグラウンドでの接続維持を制限し、前面では一時的に使えてもアプリを切り替えると無効になる場合もあります。
コマンドラインプログラムによって、プロキシ環境変数への対応は異なります。HTTPプロキシを読むツール、SOCKSに対応するツール、システムプロキシを完全に無視するツールがあります。コマンドライン通信をテストするときは、まずそのツールのプロキシ仕様を確認してください。プロキシ非対応のプログラムも一括して通信を引き受けたい場合は、ブラウザーの確認結果をそのまま端末へ当てはめず、TUNモードを検討します。
- ✅ まずクライアントで正しいノードと動作モードが選択されていることを確認する。
- ✅ 次に出口確認で基準ブラウザーを検証する。
- ✅ 続いてDNSの帰属とブラウザー独自の名前解決設定を確認する。
- ✅ その後、問題のあるアプリについてプロキシ、権限、ルール一致を個別に確認する。
- ✅ 最後にノードまたはプロトコルを変更し、複数の条件を同時に変えないようにする。
- ❌ ログを確認せずに設定を連続して切り替え、元の問題を再現できなくなる。
まだ有効にならない場合の総合チェックリスト
基本確認を終えても原因を特定できない場合は、端末からリモート側まで経路の順番に沿って再確認します。まずサブスクリプションの選択ミスとクライアントモードを除外し、次にシステム権限、アプリによる上書き設定、DNS、キャッシュを確認します。ノード接続と対象サービスの制限を確認するのは最後です。この順番なら因果関係を整理できます。
- 現在選択しているノードが、使用中のサブスクリプションに含まれていることを確認する。古い設定や重複グループではないことも確認する。
- クライアントのモードが、システムプロキシ、TUN、アプリ内プロキシのうち想定した設定になっていることを確認する。
- OSがプロキシ、仮想NIC、ネットワーク拡張の権限を受け入れているか確認する。
- 経路を切断して元の出口を記録し、再接続後に新しいブラウジングセッションを作成して比較する。
- DNSの帰属を確認し、ブラウザーが名前解決経路を独自に上書きしていないことを確認する。
- クライアントログでテストドメインを検索し、直接接続ルールではなくプロキシルールに一致したことを確認する。
- 別のアプリでも出口を確認し、問題が全体に及ぶのか単一アプリだけなのか判断する。
- 古いページと接続を閉じてから再テストし、キャッシュ、セッション、接続の再利用を除外する。
- 設定を変えないままノードを切り替え、特定ノードの接続問題かどうか判断する。
- 必要なログと再現手順を保存し、具体的な障害情報をサービスサポートへ提出する。
問い合わせ時は、OS、クライアント名、使用モード、プロトコルの種類、問題が発生したアプリ、出口の変化、DNSの変化、ログに記録されたエラーの種類を伝えるとよいでしょう。認証情報や完全なサブスクリプションURLをスクリーンショットや問い合わせ本文に載せてはいけません。適切に情報を伏せたログのほうが、「接続できない」という説明だけより原因を特定しやすくなります。
最終的な判断基準はクライアントのアイコンが変わったかではなく、対象アプリのリクエスト経路が想定どおりかどうかです。出口の帰属が正しく、DNS経路を説明でき、ルール分岐が正しく一致し、アプリ間の差がそれぞれのプロキシ設定で説明できる必要があります。この順番で確認すれば、「接続済みのように見えるのに経路を通っていない」問題の多くを具体的な段階まで絞り込めます。