VPNが有効かどうかは、クライアントの「接続済み」表示だけでは判断できません。この表示は通常、ローカルのクライアントとリモートノードのハンドシェイクが完了したことを示すだけで、ブラウザー、コマンドラインツール、その他のアプリの通信がすべてその経路を通るとは限りません。確実に確認するには、出口IP、DNSの名前解決経路、ルーティングモード、各アプリのアクセス結果をあわせて確認します。
実用的な手順は、接続前のネットワーク情報を記録し、接続後に出口IPを確認してからDNSを検証し、最後にプロキシを回避しやすいアプリを一つずつテストする流れです。これにより、原因をノード、システムプロキシ、仮想ネットワークインターフェース、振り分けルール、アプリ側の設定に絞り込めます。
まず「接続済み」が何を意味するのかを理解する
クライアントが接続を確立すると、まずノードのアドレスを解決し、サーバーとプロトコル、暗号化、認証情報をネゴシエートします。Shadowsocks、VMess、Trojan、VLESSなどを使用する場合、ハンドシェイクに成功すれば通常は接続済みと表示されます。ただし、その時点で通信がどのように接続経路へ入るかは、クライアントのトラフィック取り込み方式によって決まります。
主な取り込み方式には、システムプロキシと仮想ネットワークインターフェースがあります。システムプロキシは、OSがアプリに提供するプロキシ設定を変更します。この設定に従うブラウザーやデスクトップアプリは通常、経路を利用できますが、システムプロキシを参照しないプログラムは直接接続を続ける場合があります。仮想ネットワークインターフェースは、システムのルーティング層でより多くの通信を受け取ります。対象範囲は広い傾向にありますが、除外ルール、ローカルネットワークのルーティング、アプリ独自のネットワークスタックの影響を受けることがあります。
| 確認できる状態 | そこから分かること | それだけでは分からないこと |
|---|---|---|
| ノードとのハンドシェイクに成功 | クライアントがリモートサービスに接続できる | すべてのアプリが経路を利用している |
| システムプロキシが有効 | システムプロキシの設定が反映されている | アプリが必ずシステムプロキシに従う |
| 仮想ネットワークインターフェースが有効 | クライアントがルーティング層で通信を取り込める | 振り分けルールによって対象が除外されていない |
| ウェブページを開ける | 現在のウェブページへのリクエストが完了できる | DNSと他のアプリが同じ経路を利用している |
IEPL専線、中継回線、直接接続回線は、ノードから対象ネットワークまでの通信方式を表します。IEPLはより安定した国際通信に使われることが多く、中継ではいったん中継入口へ通信を送り、直接接続ではローカルネットワークからリモートノードへ直接接続します。これらの違いは接続品質に影響しますが、確認方法は変わりません。最終的には出口、DNS、アプリのリクエストが実際にどの経路を通ったかを確認します。
出口IPの確認：ウェブ通信の行き先を確かめる
出口IPは最初に確認すべき項目です。テストリクエストがどのネットワーク出口から外部サービスへアクセスしたかを直接示すためです。テスト前にクライアントを切断し、パブリックな出口情報を表示できる確認ページを開いて、事業者、地域、ネットワーク組織などの結果を記録します。その後、対象回線に接続し、先ほどのページを閉じてから新しく開き、2回の結果を比較します。
- 接続を切断し、現在の出口地域とネットワーク組織を記録する。
- 確認に使ったページを完全に閉じ、古い結果がキャッシュされないようにする。
- 対象ノードに接続し、クライアントが再接続を繰り返したりエラーを表示したりしていないことを確認する。
- 確認ページを新しく開き、出口地域とネットワーク組織が変わったか比較する。
- 別のブラウザーまたはコマンドラインからのリクエストでも確認を繰り返し、結果が一致するかを見る。
接続後に出口情報が選択した回線に対応する地域へ変わった場合、現在のテストツールのリクエストがその回線を通ったと判断できます。結果がまったく変わらない場合は、まずシステムプロキシが反映されているか、仮想ネットワークインターフェースが有効か、現在の振り分けモードが確認サイトを直接接続と判定していないかを確認します。
出口が変わっても、すべての通信が取り込まれたとは限りません。ブラウザーはシステムプロキシを使っていても、ターミナルツール、ゲームプラットフォーム、同期プログラムは直接接続する場合があります。そのため、出口IPの確認で分かるのは「このリクエストが経路を通ったか」であり、デバイス上のすべての接続が同じ経路を使っていることを単独で証明するものではありません。
ブラウザーに古い接続が残っている場合もあります。回線を切り替えても、既存タブの長時間接続が以前のセッションを一時的に使い続けることがあります。確認時は新しいタブを開き、必要に応じてブラウザーを完全に終了してから再起動してください。プライベートブラウジングも、拡張機能、キャッシュ、持続接続による影響を減らすのに役立ちますが、システムのルーティングを自動的に変更するものではありません。
DNSの確認：ドメインの名前解決が接続経路を回避していないか
ウェブサイトへアクセスする際は通常、まずDNS問い合わせを行い、ドメイン名を接続可能なアドレスへ変換します。ウェブコンテンツが国際回線を通っていても、DNS問い合わせまで同じ経路を通るとは限りません。DNSリクエストがローカルネットワークに任されていると、解決結果と出口地域が一致しない、特定ドメインだけ解決できない、接続済みでもサイトがタイムアウトし続けるといった状況が起こります。
DNSを確認するときは、ページに「リーク」と表示されるかだけでなく、名前解決サービスの所属ネットワークと地域に注目します。検査ページによって判定基準は完全には同じではありません。より確実なのは接続前後の解決結果を比較することです。接続後もローカルネットワークの標準サービスだけが表示され、出口は変わっている場合は、クライアントのDNS取り込み設定を確認してください。
- クライアントでリモートDNSまたは暗号化DNSが有効になっているか確認する。
- 振り分けルールによってDNSリクエストが仮想ネットワークインターフェースを迂回していないか確認する。
- ブラウザーで独自のセキュアDNSが有効になり、別の名前解決サービスを使っていないか確認する。
- システムに手動入力した固定DNS設定が残っていないか確認する。
- 回線を切り替えた後、システムとブラウザーのDNSキャッシュを削除して再テストする。
DNSリークとは通常、接続経路で処理されるはずの名前解決リクエストが、実際にはローカルネットワークや想定外の別サービスへ送信されることを指します。ウェブページが開けなくなるとは限りませんが、出口経路と名前解決経路の不一致を招きます。地域に応じた名前解決に依存するコンテンツサービスでは、この不一致により現在の出口に適さないアドレスが返されることもあります。
ブラウザーのセキュアDNSは、よくある干渉要因です。OSの標準的な名前解決設定を迂回し、ブラウザーが指定したサービスへ直接接続することがあります。特定のブラウザーだけDNS検査の結果が異なり、他のアプリが正常なら、まずブラウザー自身の設定を確認します。すべてのアプリで同じ結果になる場合は、クライアントとシステムのDNS取り込みを確認してください。
アプリごとの検証：経路を利用していないプログラムを見つける
アプリごとの検証は、ブラウザーのテストは正常なのに、コマンドライン、ダウンロードツール、ゲームランチャー、デスクトップクライアントが元のネットワークを使い続けるという、よくある状況に対応するものです。原因は通常、ノードの障害ではなく、アプリによってプロキシ設定の読み取り方が異なることにあります。
まず、出口IPの確認を済ませたブラウザーを基準にします。その後、他のアプリを一つずつ開き、同じ対象へアクセスできるか、表示地域が一致するか、クライアントの接続ログに該当するリクエストが出ているかを確認します。複数のバックグラウンド通信が混ざってログの判定を難しくしないよう、毎回1つのアプリだけをテストしてください。
| アプリの種類 | 一般的な取り込み方式 | 起こりやすい問題 |
|---|---|---|
| 一般的なブラウザー | システムプロキシまたはブラウザーのプロキシ | 拡張機能がプロキシ設定を上書きし、セキュアDNSが独自に名前解決する |
| コマンドラインツール | 環境変数、明示的なプロキシ、または仮想ネットワークインターフェース | システムプロキシを標準では無視し、直接接続を続ける |
| デスクトップアプリ | システムプロキシ、アプリ内プロキシ、または仮想ネットワークインターフェース | アプリ独自のネットワーク設定がシステム設定を上書きする |
| ゲームプラットフォームとリアルタイム通信 | 仮想ネットワークインターフェースまたは専用の転送ルール | 一部のデータグラム通信がシステムプロキシの取り込み対象にならない |
クライアントにグローバル、ルール、直接接続などのモードがある場合は、一時的に対象範囲の広いモードへ切り替えて比較テストします。取り込み範囲を広げるとアプリが正常に戻るなら、ノード自体は利用可能で、問題は振り分けルールにある可能性が高いです。その後は無条件のグローバル転送に頼り続けず、対象ドメイン、アドレス範囲、アプリのプロセスが誤って直接接続に分類されていないか確認します。
振り分けルールは通常、ドメイン、対象アドレス、地域データベース、アプリのプロセス、プロトコル種別などに基づいて経路を決めます。ルールの順序も重要です。先にある広範な直接接続ルールが先に一致すると、後続のプロキシルールが実行されません。変更後は関連アプリを再起動してください。すでに確立された接続は、新しい経路へ自動的に移行しないためです。
サブスクリプションURLは、クライアントへノードと設定の更新を提供するだけで、システム通信がすでに取り込まれていることを意味しません。インポート後は、ノードを選択し、接続を有効にして、プロキシモードを決める必要があります。更新に成功しても出口が変わらない場合は、何度もサブスクリプションを再インポートするのではなく、通常はローカルの取り込み設定を確認します。
クライアントは接続済みなのに通信できない場合の確認手順
「接続済みなのにアクセスできない」場合は、ローカルからリモートへ順番に確認する方が、手当たり次第にプロトコルを切り替えるより効果的です。まずデバイス自体が正常にネットワークへ接続できることを確認し、次にクライアントが再接続を繰り返していないか確認します。基礎ネットワークが利用できないと、クライアント画面に前回の状態が残っていても、有効な転送は行われません。
- 基本接続を確認：クライアントを切断して通常のウェブサイトへアクセスし、現在のネットワーク自体が切断されていないか確認する。
- ノードを選び直す：サブスクリプションを更新し、別の利用可能な回線を選んで、特定ノードの設定が期限切れになっていないか確認する。
- 時刻を確認：システム時刻のずれにより証明書検証や認証に失敗することがあります。システムの自動時刻合わせを有効にしてください。
- 取り込みモードを確認：システムプロキシはプロキシ設定に従うアプリに適しており、より広く取り込む必要がある場合は仮想ネットワークインターフェースをテストする。
- 振り分けを確認：一時的に取り込み範囲を広げ、対象が誤って直接接続と判定されていないか確認する。
- DNSを確認：クライアントが提供するリモート名前解決方式へ切り替え、古いキャッシュを削除する。
- 競合を確認：プロキシ、ルーティング、ネットワークリクエストのフィルタリングを変更する他のプログラムを終了して再試行する。
プロトコルの切り替えは、基本的な確認の後に行います。Shadowsocksは主に暗号化されたプロキシ転送を提供し、VMessとVLESSはクライアントがルールに従って接続を転送する用途で使われます。Trojanは認証と暗号化通信を組み合わせ、トランスポート層のセキュリティ設定と併用されることがあります。各プロトコルはクライアントとサーバーの設定が一致している必要があり、互換性のないポート、転送方式、認証情報を残したままクライアント側のプロトコル名だけを変更しても機能しません。
接続ログも、どの段階で問題が起きたかを特定する手がかりになります。ドメインの名前解決失敗はDNSまたは基本ネットワークを示すことが多く、リモートへの接続タイムアウトはノードへの到達性、経路品質、ローカルネットワークの制限が関係する場合があります。認証失敗は、サブスクリプションの期限切れや設定不一致の可能性が高く、ハンドシェイクは成功しているのにアプリのリクエストがない場合は、システムプロキシ、仮想ネットワークインターフェース、振り分けルールを確認します。
確認中は、ノード、プロトコル、DNS、振り分けを同時に変更しないでください。一度に1項目だけ変更し、その後に出口とDNSの確認を繰り返すことで、どの設定が影響したか分かります。複数箇所を同時に変更すると、一時的に直っても再利用できる設定を作りにくくなります。
Windows、macOS、iOS、Androidで異なる確認ポイント
Windowsのデスクトップアプリは、システムプロキシへの対応が統一されていません。ブラウザーは通常システム設定を読み取りますが、一部のコマンドラインプログラムや独自のネットワーク機能を持つアプリでは、明示的なプロキシパラメータや仮想ネットワークインターフェースが必要です。ブラウザーの出口は変わったのにターミナルで変化がない場合は、まずこの違いを確認します。
macOSにもシステムプロキシがありますが、アプリが独自のネットワーク実装を選ぶこともあります。仮想ネットワークインターフェースを有効にした後は、ネットワーク拡張の許可が表示されていないか、クライアント拡張が有効なままかを確認してください。OSの更新やクライアントの再インストール後は、関連する許可を再確認する必要があります。
iOSのクライアントは通常、システムが提供するVPN構成を通じて通信を取り込みます。ステータスバーのアイコンは、システム構成が接続状態にあることしか示さないため、ブラウザーで出口とDNSを確認することをおすすめします。特定のアプリだけ結果が異なる場合は、オンデマンド接続、アプリ別ルール、ローカルネットワークの除外などが有効になっていないか確認します。
Androidのクライアントは通常、システムのVPN権限を使って仮想インターフェースを確立します。常時接続、迂回を許可する設定、省電力機能、バックグラウンド制限が継続的な接続に影響することがあります。バックグラウンドへ移ると回線が切れる場合は、リモートノードの障害と決めつけず、システムがクライアントの動作を制限していないか確認してください。
プラットフォームごとにクライアント画面は異なりますが、検証の流れは同じです。まずハンドシェイク、次に出口、続いてDNS、最後にアプリごとの通信を確認します。プラットフォームによる違いは、通信がどのように経路へ入るかであり、検査基準そのものではありません。
確認が完了したかを判断する方法
完全な検証では、すべてのアプリで画面表示が完全に同じになる必要はありません。期待した経路の結果になっていることが重要です。国際アクセスに使うアプリは選択した回線に対応する出口を示し、直接接続する予定のローカルサービスはローカル経路を使い続ける必要があります。DNSの名前解決が設定と矛盾するサービスへ意図せず送られず、回線切り替え後に新しく確立した接続が新しい出口を使っていれば問題ありません。
- 接続前後の出口情報に明確な変化がある。
- 出口地域が現在選択している回線と一致している。
- DNSの名前解決経路がクライアント設定と一致している。
- ブラウザー、ターミナル、対象アプリでそれぞれ検証が完了している。
- どのリクエストが直接接続され、どれが経路を利用するかを振り分けルールで説明できる。
- ノード切り替え後に古い接続を閉じて再テストしても、一貫した結果が得られる。
出口、DNS、対象アプリがすべて想定どおりなら、接続が実際に有効になったと判断できます。いずれか1つだけ異常がある場合は、該当する層を確認します。出口が変わらなければ取り込み方式、DNSに異常があれば名前解決設定、特定アプリだけ異常ならアプリのプロキシと振り分けルールを確認してください。接続状態をこのように分けて考えると、クライアントのボタンだけを見続けるより原因を見つけやすくなります。