出口IP：最初に確認できる項目
接続したら、まずサイト内のIP確認ページを開き、現在の出口IPと所在地を見ます。判断基準は1つだけです。所在地がノードの設置場所になっていれば合格で、地元のプロバイダであれば不合格です。所在地が地元の都市のままで、組織名も地元のブロードバンド事業者のままなら、通信はトンネルに入っていません。クライアントのステータスランプは、プロセスが動いていることしか示していないのです。
出口IPでは、もう2点に注目します。1つ目はIPv6です。ブラウザとOSは既定でIPv6を優先するため、クライアントがIPv4しか引き受けていないと、ページには地元のIPv6アドレスがそのまま表示されることがあります。「IPが変わった」ように見えても、半分しか変わっていない状態です。2つ目はWebRTCです。一部のブラウザはWebRTC経由で端末のアドレスやローカルネットワークのアドレスを露出します。これはプロキシが効いているかどうかとは別の話で、ブラウザの設定で制限するか無効にする必要があります。
IPv4でしか効いていない接続は、IPv6に対応した接続先にアクセスするとローカル回線へそのまま落ちてしまいます。確認の際は、まずIP確認ページにIPv4とIPv6の両方の結果が出ているかを見て、そのうえで両者の所在地が一致しているかを確かめます。
同じ端末にブラウザのプロキシ拡張機能が入っていると、拡張機能のほうがシステムプロキシより優先されるのが一般的です。この場合、OS側はすでに引き受けているのに、ブラウザは拡張機能側の回線を使い続けており、出口が2つに分かれて誤った結論を導きやすくなります。検証時はまず拡張機能を無効にするか、拡張機能を一切入れていないブラウザプロファイルで一度照合してください。
DNSリークのセルフチェック
DNS問い合わせは「アクセス先のドメインを誰が解決するか」を決めます。既定ではOSが地元のプロバイダに問い合わせを送りますが、プロキシが効いていれば、問い合わせはノード側から出るべきです。問い合わせが地元のDNSに届いたままだと、解決リクエストそのものがアクセス先を明かしてしまいます。さらに、地元に近いだけで接続先には適さないCDNの結果を受け取る可能性もあります。
確認方法は、DNSリーク検出ページを開くことです。ページには解決に関わったサーバのIPと所在地が一覧で表示されます。合格の状態は、リゾルバがノードの所在地にあるか、少なくとも出口IPと同じ地域にあることです。地元プロバイダのリゾルバばかりが並んでいるなら、解決はプロキシを通っていません。
クライアント側の該当スイッチは、通常「リモートDNS」「DNSをプロキシ経由に」「リーク防止」といった名前で、呼び方はクライアントごとに違っても役割は同じです。解決リクエストをトンネルの向こう側のリゾルバに渡します。有効にしたら一度再接続してから検出結果を見てください。設定を変えただけでは反映されないことがほとんどです。
ルールモードでは、国内ドメインをローカルDNSで解決して直接接続するのは、それ自体が設計上の狙いです。リークかどうかは、プロキシ対象になっているドメインで判断します。接続先はプロキシを通っているのに解決だけがローカルに残っている、という状態こそ対処が必要です。
もう1つは、アプリ側が独自に持つ暗号化DNSです。ブラウザやOSでDoH / DoTを有効にすると、解決リクエストは独立したHTTPS接続を通るため、クライアントが設定したDNSを迂回することがあります。こうした項目はブラウザのプライバシー設定にあるので、検証時はいったんオフにし、基準となる状態を確認してから元に戻すかどうかを決めます。
アプリ別と振り分けの検証
出口IPとDNSが正しくても、一部のアプリだけプロキシを通っていないことがあります。原因は2種類です。アプリがシステムプロキシの設定を読まないか、振り分けルールが接続先ドメインを直接接続と判定しているかです。
システムプロキシ（HTTP / SOCKSプロキシ）は、アプリが自分からOSの設定を読むことが前提です。ブラウザやOSの更新、多くのコマンドラインツールは読みますが、一部のデスクトップアプリやゲームクライアントは読みません。こうしたプログラムまで対象にするには、クライアントがTUNまたは仮想NICモードを提供している必要があり、ネットワーク層で通信を引き受けます。代わりに高い権限が必要で、一部のOSではネットワークコンポーネントの追加インストールも求められます。
振り分けの検証は次の順で行います。まずグローバルモードで基本的な経路が通っていることを確認し、そのあとルールモードに戻して、実際に使うサービスを1つずつ開きます。グローバルでは正常なのにルールモードで特定のサービスだけ不調なら、問題は回線ではなくルールにあります。ルール一覧には通常、一致した項目とその振り分け先が表示されるので、ドメインかIPレンジでルールを1本追加すれば済みます。
アプリ別プロキシは一部のプラットフォームで利用できます。有効にすると、チェックしたアプリだけがトンネルを通り、それ以外は直接接続になります。仕事用ソフトを対象外にしたい場面に向きますが、検証時は誤解しやすいモードです。チェックしていないアプリがローカルIPを表示するのは想定どおりの動作で、不具合ではありません。
サブスクリプションの読み込みも合わせて確認します。購読リンクを更新したら、クライアントのノード一覧もそれに追随して更新されるはずです。ノード名と数が長い時間変わらない場合は、購読の取得に失敗しているか、クライアントが古い設定ファイルを使い続けています。ノード一覧のレイテンシがタイムアウト表示ならハンドシェイクが完了していないので、別の回線に切り替えて再測定してください。
接続済みに見えてプロキシを通らない6つのケース
次のケースは切り分けで最もよく出てくるもので、共通しているのはクライアント画面が「接続済み」と表示している点です。
- システムプロキシが書き込まれていない。クライアントによっては「システムプロキシを設定」を手動で有効にする必要があります。回線につなぐだけではOSの設定は変わらず、ブラウザ以外の通信はすべて直接接続になります。
- ブラウザ拡張がシステムプロキシを上書きしている。拡張のほうが優先度が高く、出口が2つ同時に存在する状態です。IP確認の結果は、そのときどちらを使っているかで変わります。
- IPv6が優先されている。トンネルがIPv4しか引き受けていないと、IPv6対応の接続先にはブラウザがローカル回線で直接つないでしまいます。
- 振り分けルールが直接接続に一致している。ルールはドメインで照合されるため、接続先ドメインが直接接続のグループに入っていれば、出口は当然ローカルのままです。
- アプリがシステムプロキシを無視している。デスクトップアプリ、ゲームクライアント、一部の同期ツールはシステムプロキシの設定を読まないため、TUNモードでカバーする必要があります。
- アプリが独自の暗号化DNSやネットワークスタックを持つ。名前解決も接続もOSの設定を通らないため、システムプロキシは効きません。
プラットフォーム別クライアントの違い
Windows：システムプロキシとTUNの2モード
システムプロキシモードはOSのプロキシ設定を書き換える方式で、ブラウザや多くのアプリがそれに従います。TUNモードは仮想NICを作成し、システムプロキシを読まないプログラムまで引き受けられますが、管理者権限が必要です。モードを切り替えたら必ず再接続してください。再接続しないと、前のモードの設定が残ったまま有効になります。
macOSとiOS：許可しなければ接続していないのと同じ
macOSでネットワーク拡張を使うクライアントは、システム設定で許可を求めます。許可していないと、接続は成功したように見えても通信を引き受けていません。iOSはNetwork Extensionを使うため、初回接続時はシステムのダイアログで確認する必要があります。ここで拒否すると、クライアント内のスイッチは効きません。
Android：アプリ別リストは自分で確認する
AndroidはOSのVpnServiceを使うため、こちらもダイアログでの許可が必要です。アプリ別プロキシはより細かく設定できるので、検証時は大元のスイッチだけを見るより、チェックリストを1項目ずつ確認したほうが確実です。
プロトコル別：TCPとUDPで挙動が違う
Shadowsocks、VMess、Trojan、VLESSは主にTCPを使い、UDPの対応状況は実装によって異なります。Hysteria2とTUICはQUICベースで、すべてUDPで通信します。クライアントで見かけるss://、vmess://、trojan://の接頭辞は、それぞれ別のプロトコルに対応しています。ネットワークがUDPに厳しい制限をかけている場合、ノードは選べるのにいつまでもつながらないという症状になります。TCP系のプロトコルに戻して試せば、どの層に問題があるかを切り分けられます。
セルフチェック表と判断基準
ここまでの確認項目を1枚の表にまとめたので、症状に合わせて照合してください。
| 症状 | 考えられる原因 | 対処 |
|---|---|---|
| IP確認が地元プロバイダを示す | システムプロキシが未設定、またはTUNが未起動 | プロキシモードを確認し、再接続する |
| IPは正しいがリゾルバがローカルのまま | DNSがプロキシを通っていない | リモートDNS / リーク防止を有効にして再接続 |
| ブラウザだけがプロキシを通る | システムプロキシモードでは他のプログラムをカバーできない | TUN / 仮想NICモードに切り替える |
| 接続先が依然としてローカル判定 | 振り分けルールが直接接続に一致 | ルール一覧を確認し、ドメインルールを追加する |
| IPv6アドレスがローカルのまま | トンネルがIPv4しか引き受けていない | OSのIPv6を無効にするか、IPv6プロキシを有効にする |
| ノードは選べるがずっとタイムアウト | プロトコルまたはポートが制限されている | 回線を変えるか、TCP系プロトコルに切り替える |
次の項目を順に照合し、すべて満たして初めて本当に効いていると判断できます。
- ✅ 出口IPの所在地がノードの設置場所で、IPv4とIPv6の結果が一致している。
- ✅ DNS検出ページのリゾルバが出口IPと同じ地域にある。
- ✅ グローバルモードで接続先サービスが正常に動き、ルールモードに戻しても正常なまま。
- ✅ システムプロキシを読まないデスクトップアプリも、TUNモードではノードのIPを表示する。
- ❌ ブラウザだけがノードIPを表示し、システム全体のアプリはローカルアドレスのまま——システムプロキシを書いただけで、通信全体を引き受けていない。
- ❌ 検出ページはプロキシ経由と出ているのに、リゾルバが地元プロバイダばかり——DNSが付いてきていない。
判断基準：クライアントのステータスランプを見る必要はありません。必要なのは、出口IPがノード側にあること、DNS解決がノード側で行われていること、実際に使うアプリがトンネルを通っていること、この3つの証拠が同時にそろうことだけです。どれか1つでも欠けたら、上の表に沿って項目ごとに切り分けてください。原因は多くの場合、プロキシモードと振り分けルールにあり、回線そのものではありません。
複数の回線を比較したいときは、100+ か国と 220+ 回線から選べます。台数無制限なので、パソコンとモバイル端末を同時に接続して見比べられます。片方は既定設定のまま、もう片方を振り分けモードにすれば、違いは一目で分かります。購読期間中に特定の回線が長くタイムアウトし続けるなら、クライアントを何度も入れ直すより、回線を替えたほうが時間の節約になります。
セルフチェックをすべて通過したのに接続先サービスが不調なときは、ローカル側の接続ではなく、接続先サイト側のポリシーが原因であることが多いものです。その場合は同じ地域の別回線に替えて相互に確認したほうが、クライアントの設定を何度も書き換えるより効率的です。操作を1つずつ再現したいときは、使い方ガイドのクライアント設定の説明を参照してください。