VPNが接続済みかどうかを判断する際、クライアントに表示される緑色のアイコンだけでは不十分です。実際の通信がどこからデバイスを出ていくのか、ドメインを誰が解決しているのか、対象アプリが現在のルートに従っているのかを確認する必要があります。接続状態は、クライアントが一部のハンドシェイクを完了した、またはローカルプロキシポートを開いたことを示すだけで、ブラウザーやダウンロードツールなどすべてのアプリが想定した経路に入ったことを単独で証明するものではありません。
確認中に、経路、プロトコル、DNS、振り分けルールを同時に変更しないでください。複数の変数が一度に変わると、問題が一時的に解消しても、どの設定が作用したのか分からなくなります。まず直通時の状態を記録し、次に経路へ接続して、出口IP、DNS、対象アプリの順に確認するのが安全です。各手順では一つの問いだけに答えます。
「接続済み」と「通信が引き継がれた」を分けて考える
クライアントによって「接続成功」が示す状態は異なります。システムレベルのトンネルを使う場合、クライアントは通常、仮想ネットワークインターフェースを作成し、OSにルートを書き込みます。システムプロキシを使う場合は、HTTP、SOCKS、または混合プロキシのポートをローカルで開き、システムプロキシをそのポートへ向けるだけのことがあります。また、ローカルコアだけを起動するクライアントでは、ブラウザー設定や振り分けモード、個別設定によってアプリ通信を引き継ぐかどうかが決まります。
そのため、同じデバイス上でブラウザーはプロキシを経由しているのに、ターミナルのコマンドは直通することがあります。多くのサイトは経路を通っていても、LAN、特定のドメイン、指定アプリだけがルールに従って直通する場合もあります。これは必ずしも障害ではなく、クライアントが設定済みの振り分けルールを実行しているだけかもしれません。重要なのは、現在の結果が選択したモードと一致しているかどうかです。
| 確認できた現象 | 分かること | それだけでは証明できないこと | 次に確認する項目 |
|---|---|---|---|
| クライアントに接続済みと表示される | ハンドシェイクが完了した、またはローカルプロキシコアが起動した | すべてのアプリが経路に入った | 接続前後の出口IPを比較する |
| 出口IPが変わった | 今回のテストリクエストは別の出口を経由した | 他のアプリとDNSリクエストも同じ経路を使っている | DNSと振り分けルールを確認する |
| DNSリゾルバーが変わった | 現在のドメイン検索が別の解決経路を使った | Webページのリクエストが必ずプロキシを経由している | 対象アプリを一つずつ確認する |
| あるWebサイトに正常にアクセスできる | そのサイトへの現在のリクエスト経路は利用できる | デバイス全体が引き継がれている | 他のブラウザーと単独アプリをテストする |
Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコルは、クライアントとリモートノード間のデータ転送を担います。しかし、「プロトコル接続に成功した」ことと「システム通信がプロトコルコアに入った」ことは別です。どのプロトコルを使っていても、最終的にはルート、プロキシ設定、DNS、アプリの動作を確認する必要があります。プロトコルを何度も変更するだけでは、システムプロキシが有効になっていない問題や、アプリがプロキシを迂回している問題は解決できません。
手順1：接続前後の出口IPを比較する
出口IPとは、対象サイトへアクセスした際に相手サーバーから見える公開アドレスです。確認するときは、まず経路を切断して信頼できるIP確認ページを開き、国または地域、ネットワーク事業者、アドレスを記録します。次に対象の経路へ接続し、同じページを更新します。アドレスとネットワークの所属が変わり、選択した経路のおおよその地域とも一致すれば、そのWebリクエストはプロキシの出口から送信されたと判断できます。
テスト前に確認ページを閉じて開き直すか、ブラウザーのプライベートウィンドウを使うと、古い結果のキャッシュを避けられます。ブラウザーに独立したプロキシ拡張機能を入れている場合は、拡張機能が有効かどうかも記録してください。拡張機能がシステムプロキシを上書きし、ブラウザーと他のアプリで結果が異なることがあります。テスト中は引き継ぎ方式を一つだけにし、システムクライアントとブラウザー拡張機能を重ねて使わないでください。
- クライアントを切断し、開いていたIP確認ページを閉じてから、確認ページを開き直し、直通時の結果を記録します。
- 確認する経路へ接続し、クライアントが明確に接続済みになるまで待ちます。
- 確認ページを開き直し、古いタブに残ったキャッシュ済みの文字だけを読まないでください。
- アドレス、地域、ネットワークの所属を比較し、地図上の位置だけで判断しないでください。
- 別のブラウザーまたは単独アプリで再確認し、結果が一致するか確かめます。
地図上の位置は補助情報にすぎません。IPデータベースは登録情報、データセンターの所在地、過去の記録などから場所を推定するため、データベースによって表示が異なることがあります。出口が切り替わったかを判断するには、地図のピンよりもアドレスの変化とネットワークの所属が重要です。選択したノードが日本にあり、確認結果もその経路が利用する日本のデータセンターネットワークを示しているなら、テストの方向性はおおむね正しいといえます。切断前とアドレスが完全に同じなら、プロキシの引き継ぎ方式をさらに確認してください。
出口IPが変わらないときの確認項目
- ✅ クライアントがローカルポートだけを起動しているのではなく、システムプロキシまたは仮想ネットワークインターフェースモードを有効にしていることを確認する。
- ✅ ブラウザーが「直通」に設定されていないか、別のプロキシ拡張機能がシステム設定を上書きしていないか確認する。
- ✅ 現在の振り分けモードで、IP確認サイトが直通ルールに一致していないか確認する。
- ✅ 他のネットワークプロキシツールを終了し、複数のクライアントがシステムプロキシやデフォルトルートを奪い合わないようにする。
- ❌ 古いページを更新するだけで判断しない。キャッシュされた内容では完全なリクエストが再実行されていない可能性がある。
- ❌ 複数のプロトコルやノードを続けて変更しない。実際の引き継ぎ問題が見えにくくなる。
特定のブラウザーだけ出口が変わらない場合は、そのブラウザーで独立したプロキシポリシーが有効になっていないか確認してください。ブラウザーの一部はシステムプロキシに従いますが、コマンドラインツールの一部はデフォルトでシステムプロキシを読み取りません。ダウンローダーやゲームも直接ネットワーク接続を作ることがあります。システムプロキシ方式では、すべてのアプリが自動的に接続するとは限りません。デバイス全体を引き継ぐ必要がある場合は、クライアントが対応する仮想ネットワークインターフェースまたはシステムトンネルモードを使い、ルートが正常に書き込まれたことを確認してください。
手順2：DNSリクエストの経路を確認する
DNSはドメイン名を接続可能なアドレスへ変換します。Webページの内容がプロキシを経由していても、ドメイン検索が同じ経路を通るとは限りません。システムがローカルネットワークの指定リゾルバーへ検索を送っていると、プロキシの出口地域と一致しない結果が返ることがあります。地域に応じた配信を行うストリーミング、ダウンロードミラー、コンテンツ配信ネットワークでは、この不一致によりページは開けてもコンテンツでエラーが出たり、ノード選択が不安定になったり、読み込み速度が安定しないことがあります。
DNSリークとは一般に、現在のプライバシーまたはルーティングの目的から、トンネルや指定した暗号化リゾルバーを通すべき検索が、ローカルネットワークインターフェースから別のリゾルバーへ送られる状態を指します。ローカルリゾルバーが見つかったからといって、すべてのWebコンテンツが直通しているとは限りません。ただし、DNS経路が想定どおり統一されていないことを示すため、クライアントのDNS引き継ぎ設定をさらに確認する必要があります。
確認方法は出口IPの場合と同様です。まず切断状態でリゾルバーのネットワーク所属を記録し、経路へ接続して再テストします。どのネットワークが検索を処理しているか、地域が対象出口と明らかに矛盾していないか、繰り返しテストしてもローカルネットワークのリゾルバーが混在しないかを確認します。解決されたWebサイトのアドレスだけを見ないでください。大規模サイトは地域、キャッシュ、負荷に応じて異なる結果を返すことがあります。
nslookup example.com
# システムの現在の DNS 設定を確認
# Windows
ipconfig /all
# macOS
scutil --dns
# 一般的な Linux 環境
resolvectl statusこれらのコマンドはそれぞれ異なる問題を確認するものです。nslookupは、現在の検索で使われたDNSサーバーと返された結果を表示できます。システムネットワークコマンドは、OSに設定されているDNSを確認するためのものです。ただし、どちらもブラウザーが同じリゾルバーを使っていることを単独では証明できません。最新のブラウザーでは安全なDNSが有効になっている場合があります。これはHTTPSで検索を個別に送信するため、OSの設定を迂回することがあります。ブラウザーとシステムの結果が一致しない場合は、ブラウザーの安全なDNS設定を確認してください。
DNS結果に異常がある場合の一般的な原因
クライアントがTCPまたはUDPのアプリ通信だけをプロキシし、システムDNSを引き継いでいないことがあります。仮想ネットワークインターフェースは作成されていても、DNSルートが元のネットワークインターフェースを向いたままの場合があります。ブラウザーが独自の暗号化DNSを使うこともあります。また、振り分けルールによって、日本国内のドメインは直通で解決し、それ以外のドメインはリモートで解決する設定になっている場合もあります。最後のケースは一般的な振り分け設計であり、リゾルバーが異なるだけで障害と判断せず、対象ドメインの一致ルールと合わせて確認してください。
DNSを変更しても結果が変わらない場合、システム、ブラウザー、またはローカルプロキシコアにキャッシュが残っている可能性があります。まずブラウザーを再起動し、次にクライアントを切断して再接続してください。それでも更新されない場合は、OSが提供するDNSキャッシュのクリア機能を使います。「キャッシュのクリア」を長期的な解決策にしないでください。接続のたびに手動対応が必要なら、クライアントのDNS引き継ぎとルート設定に戻って根本原因を確認すべきです。
手順3：ブラウザーとアプリを一つずつ確認する
ブラウザーの出口とDNSを確認しても、すべてのソフトが機能しているとは判断できません。アプリが経路に入るかどうかは、システムプロキシに従うか、仮想ネットワークインターフェースに引き継がれるか、どの転送プロトコルを使うか、振り分けルールが対象アドレスにどう一致するかで決まります。ブラウザー、ターミナル、ゲームプラットフォーム、動画アプリ、ダウンロードツールで結果が異なることがあります。
アプリ名、想定経路、実際の出口、DNSの状態、アクセス結果を記録する簡単な表を作ると便利です。重要なアプリからテストし、「あるWebページが開ける」ことをデバイス全体の確認結果にしないでください。あるアプリだけが異常で他が正常なら、問題は通常、アプリのプロキシ設定、プロトコル対応、振り分けルールにあり、ノード全体の停止ではありません。
| アプリの種類 | 一般的な引き継ぎ方式 | 差が生じる原因 | 確認のポイント |
|---|---|---|---|
| ブラウザー | システムプロキシ、拡張機能、安全なDNS | 拡張機能がシステム設定を上書きし、DNSが独自に解決する | 出口IP、ブラウザーのDNS、拡張機能の状態 |
| コマンドラインツール | 環境変数、明示的なプロキシ、仮想ネットワークインターフェース | デフォルトではシステムプロキシを読み取らない | 同じリクエストでのターミナルとブラウザーの出口の違い |
| ストリーミングアプリ | 仮想ネットワークインターフェースまたはシステムルート | 地域確認で出口とDNSを同時に参照する | 対象ドメインのルールと解決地域の整合性 |
| ゲームとリアルタイム通信 | 仮想ネットワークインターフェース、プロセスプロキシ、ルーティングルール | UDPを使う可能性があり、システムプロキシでは引き継げない場合がある | プロセスがルールに一致しているか、UDPが経路に入っているか |
| ダウンロードツール | 内蔵プロキシまたはシステムトンネル | 独自にドメインを解決する、またはアドレスへ直接接続する可能性がある | ツール内のプロキシ設定と実際の接続経路 |
システムプロキシは、プロキシ設定を読み取るアプリを主な対象とします。仮想ネットワークインターフェースモードはネットワーク層でより広い範囲を引き継ぐため、プロキシ設定に対応しないプログラムに適していますが、ルートの優先順位、除外ルール、クライアントの実装に左右されます。Windows、macOS、Android、iOS、Linuxではネットワークスタックと権限モデルが異なるため、同じサブスクリプションを別のクライアントに読み込んでも、利用できるシステムプロキシ、仮想ネットワークインターフェース、アプリごとの振り分け、DNS引き継ぎ機能が異なることがあります。
サブスクリプションURLは、ノードと関連設定をクライアントへ提供するだけです。読み込みに成功したことは、クライアントが設定を取得したことを示しますが、OSがトンネルの作成を許可したことや、振り分けルールが現在のプラットフォームに適用されることを意味しません。初回読み込み後は、ノードを選択し、正しいモードを有効にして、システムに表示されるネットワーク設定の許可を処理してください。サブスクリプションを更新したのに古いノードが使われている場合は、クライアント内で更新してから経路を選び直します。
グローバル、ルール、直通モードが結果に与える影響
グローバルモードではより多くの通信先がプロキシに入りますが、LAN、クライアント自身の通信、必要なシステムサービスは除外される場合があります。ルールモードでは、ドメイン、アドレス、地域、プロセスに応じてプロキシと直通を決めるため、「一部だけ機能している」ように見えやすくなります。直通モードはノード設定を保持しながら通常の通信を転送しません。プロキシを一時停止する用途には適していますが、誤って選ぶとクライアントが動作していても出口は変わりません。
ルールには適用順序もあります。あるドメインが先に直通ルールへ一致すると、その後のプロキシルールでは処理されません。DNS解決後にアドレスへ直接接続するアプリは、ドメインだけで作られたルールを迂回することもあります。確認時は、いったんより広い範囲を対象にするモードへ切り替えて比較してください。そこでアプリが復旧するなら、ノード自体は利用できる可能性が高く、元の振り分けルールを重点的に確認すべきです。比較後はルールモードに戻し、一致項目を修正します。
接続しているように見えてプロキシを経由しない典型的な原因
クライアントがローカルプロキシポートだけを起動している
一部のデスクトップクライアントでは、コアを単独で動作させられます。この場合、ノード接続は確立し、ローカルにも利用可能なプロキシポートがありますが、システムプロキシが有効でないため、通常のブラウザーやアプリは直通します。ノードを変更するのではなく、システムプロキシを有効にする、アプリにローカルプロキシアドレスを入力する、または仮想ネットワークインターフェースモードへ切り替えるのが解決策です。
複数のネットワークツールが同時にルートを変更している
2つのクライアントを同時に実行すると、後から起動したソフトがシステムプロキシを上書きし、仮想ネットワークインターフェースのルートも優先順位を競合させることがあります。見た目には両方が正常に接続していても、実際の通信が別の経路へ入る場合があります。確認時は他のプロキシ、フィルター、ネットワークデバッグツールを終了し、現在のクライアントだけを残して出口を再比較してください。
ブラウザーのキャッシュと長時間接続が再構築されていない
経路を切り替えた後も、開いたままのページが既存の接続を再利用し、DNS結果がキャッシュに残っていることがあります。そのため、新しく開いた確認ページには新しい出口が表示されるのに、古いタブは以前の状態を保つことがあります。対象タブまたはブラウザーを閉じてから再テストする方が、更新ボタンを連打するより確実です。長時間接続を維持するデスクトップアプリも、完全に終了してから再度開いてください。
IPv4とIPv6の経路が一致していない
ネットワークがIPv4とIPv6の両方を提供していても、クライアントが一方の経路しか引き継がないことがあります。対象サイトが引き継がれていないプロトコルファミリーを優先すると、出口が想定と異なる結果になります。確認時は、確認ページがそれぞれ報告するアドレスの種類を見て、クライアントが現在OSで有効なプロトコルファミリーに対応し、引き継いでいるかを確認してください。特定のプロトコルを無効にするだけの方法を長期対策にせず、クライアントとルート設定を優先して修正します。
ルールによって対象ドメインが直通になっている
ルールモードでは、広告フィルター、LANの除外、地域別振り分け、自作ルールが結果に影響することがあります。IP確認サイト自体が直通の対象に含まれていると、確認ページには元の出口が表示される一方、他の対象はプロキシを経由します。別の確認方法で照合し、クライアントの接続ログでルールの一致情報を確認してください。ログではハンドシェイク成功の一行だけでなく、ドメインの一致と出方向の選択を確認します。
システム時刻または証明書検証に異常がある
Trojan、VLESSとTLSの組み合わせなどは、正しい証明書検証に依存します。その他のTLSまたはQUICベースの転送も、システム時刻の影響を受けることがあります。時刻のずれでハンドシェイクに失敗した場合、クライアントのログには通常、証明書、タイムアウト、ハンドシェイクのエラーが表示され、安定して転送可能な状態にはなりません。この場合はまずシステムの自動時刻合わせを復元し、その後、サーバー名、転送パラメーター、サブスクリプション設定が完全か確認します。
繰り返し使える最終確認チェックリスト
個別の確認が終わったら、決めた順番でもう一度検証します。抜け漏れを防げるだけでなく、ネットワーク、クライアント、経路を変更した後にも同じ手順を使えます。「接続済み」のスクリーンショットだけを保存するより、各手順の実際の結果を記録する方が診断に役立ちます。
- ✅ 経路を切断し、基準となる出口IP、ネットワークの所属、DNS解決経路を記録する。
- ✅ 対象の経路へ接続し、クライアントのモードがシステムプロキシ、仮想ネットワークインターフェース、ローカルポートのどれかを確認する。
- ✅ 確認ページを開き直し、テストリクエストの出口が想定どおり変わったことを確認する。
- ✅ DNS解決経路を確認し、ブラウザーの安全なDNSとシステム設定を照合する。
- ✅ ブラウザー、ターミナル、対象アプリをそれぞれテストし、単一のWebページで全通信を判断しない。
- ✅ 振り分けルールの一致結果を確認し、異常な対象が意図せず直通になっていないことを確認する。
- ✅ IPv4とIPv6が同じ引き継ぎポリシーで処理されているか確認する。
- ✅ 一度に一つの変数だけを変更して再テストし、変更前後の差を記録する。
- ❌ クライアントのアイコン、ノード名、サブスクリプションの読み込み成功を最終的な証拠にしない。
- ❌ 原因が明確でない段階で、ノード、プロトコル、DNS、クライアントを同時に変更しない。
出口IPが変わり、DNS経路も想定どおりなのに特定のアプリだけ使えない場合は、そのアプリに問題を絞り込みます。システムプロキシに対応しているか、UDPを使っているか、独自のプロキシ設定があるか、振り分けルールに一致しているかを確認してください。すべてのアプリで出口が変わらない場合は、クライアントの引き継ぎ方式、システム権限、ルートの書き込みに戻って確認します。出口が何度も変わる、または接続が頻繁に切れる場合は、クライアントログのタイムアウト、ハンドシェイク、ネットワーク切り替えの記録を確認してください。
IEPL専用線、中継経路、公衆網の直接接続は、ノード間またはユーザーから出口までの転送経路を表すもので、ここまで説明した確認原則を変えるものではありません。IEPLは通常、専用の国際転送を特徴とし、中継経路ではまず中継入口へ接続してから出口へ転送します。公衆網の直接接続ではリモートノードへ直接接続します。経路の構造にかかわらず、アクセス先から最終的に見えるのは出口ノードのアドレスです。デバイスが通信をその経路へ送っているかどうかは、出口IP、DNS、アプリのテストで確認する必要があります。