ネットワークプロキシクライアントを使い始めるとき、難しいのはインストールよりも、画面に並ぶサブスクリプション、ノード、回線、プロトコル、システムプロキシ、TUN、分割ルーティング、グローバルモード、ルールモードの違いです。それぞれ設定の取得元、接続先、通信方式、トラフィック処理の方針を表しており、互いに置き換えられるものではありません。役割を整理すれば、ノードの選択やサブスクリプションの取り込み、接続トラブルの確認がずっと簡単になります。
基本用語早見表：それぞれが制御するもの
次の表は、クライアント画面を読み解くための早見表です。見慣れない設定項目があれば、まず設定、接続先、通信、ルーティング、システム制御のどの層に属するかを確認してから変更しましょう。
| 用語 | 実際の意味 | よくある誤解 | 初心者が確認するポイント |
|---|---|---|---|
| サブスクリプション | サービス側が管理するノードと各種パラメータのセット。クライアントはサブスクリプションURLから取得・更新する | サブスクリプションを1つの固定ノードだと考える | 更新が正常に完了したか、信頼できる入手元か |
| ノード | クライアントから選択できる接続先。通常はサーバーアドレス、ポート、プロトコル、認証情報を含む | ノード名が完全なネットワーク経路を示すと考える | 地域、プロトコル、回線情報、現在接続できる状態かどうか |
| 回線 | ローカル環境から出口まで、データが通るネットワーク経路とその提供方式 | 回線とプロトコルを同じものだと考える | 直結、中継、IEPL専線のどれが現在のネットワークに適しているか |
| プロトコル | クライアントとサービス側がデータを交換する際のカプセル化、認証、転送のルール | プロトコル名だけで速度を判断する | クライアントの互換性、トランスポート層、ローカルネットワークの制限 |
| 分割ルーティング | ドメイン、IP、アプリ、ルールセットに基づき、リクエストをプロキシ経由にするか直接接続にするか決める仕組み | 分割ルーティングがあらゆる利用場面を自動判別すると考える | ルールが一致したか、DNSがルールと整合しているか |
| グローバルモード | クライアントが制御できる範囲のトラフィックを、優先的に選択したノードで処理するモード | グローバルモードですべての端末通信を制御できると考える | システムプロキシとTUNでは制御できる範囲が異なる |
| ルールモード | ルールに基づいて、リクエストごとの出口を決めるモード | ルールは多いほど正確になると考える | ルールの順序、マッチ結果、最後のフォールバック方針 |
| 直結 | 選択したプロキシノードを経由せず、現在のローカルネットワークから対象へ直接アクセスすること | 直結をサーバーへの直結回線だと解釈する | クライアントの動作とサービス側の回線ラベルを区別する |
表にある「直結」は特に誤解されやすい項目です。クライアントのルールにおける直結は、特定のリクエストがプロキシを経由しないことを意味します。一方、ノード詳細にある直結回線は、通常、ローカルネットワークから海外サーバーへ直接接続し、サービス側が設置した中継拠点を経由しない構成を指します。意味を判断するときは、どの画面のどの設定層に表示されているかを確認してください。
サブスクリプション、ノード、回線が別物である理由
サブスクリプションは設定の入口であり、継続的な通信経路ではない
サブスクリプションURLは通常、クライアントが解析できる設定の集合を返します。複数のノードに加え、グループ、ルール、更新情報が含まれることもあります。クライアントは読み込んだ内容をローカルに保存します。普段のアクセス通信は通常、「サブスクリプションURL」を経由せず、選択したノードへ直接接続します。
そのため、サブスクリプションの更新失敗とノードの接続失敗は別の問題です。前者はURLの無効化、設定を取得できないネットワーク、クライアントの解析形式などが原因になり得ます。後者はノードの状態、プロトコルの互換性、システム時刻、ローカルUDP環境、ルーティング経路などが関係する可能性があります。サブスクリプションを一時的に更新できないからといって、まだ使えるローカル設定をすぐ削除しないでください。
ノードは設定オブジェクト、回線は基盤となる経路
ノードには通常、サーバーアドレス、接続ポート、プロトコルの種類、認証パラメータ、トランスポート層、暗号化関連の設定が記録されています。クライアントはノードを選ぶと、これらのパラメータに従って接続を確立します。ノード名に含まれる地域、用途、回線のラベルは識別しやすくするための説明にすぎず、実際の接続方法を決めるのは設定項目です。
回線は、より下位のネットワーク経路を表します。直結回線はローカルの通信事業者ネットワークから遠隔の接続先へ直接つながるため構成は単純ですが、パブリックネットワークのルーティングに左右されやすい傾向があります。中継回線は近隣の接続拠点へつないだ後、サービス側のネットワークを通じて遠隔の出口へ転送します。パブリックネットワークで変動の大きい区間を避けるために使われます。IEPLは国際イーサネット専線の一般的な呼び方で、通信経路とネットワーク分離方式に関するものであり、プロキシプロトコルではありません。
サブスクリプションはこの順番で取り込む
- サービスパネルからサブスクリプションURL全体をコピーし、URL内の認証パラメータを手動で削除・変更しないでください。
- クライアントで「URLからインポート」「サブスクリプションを追加」など同等の項目を選び、単一ノード用のアドレス欄にURLを貼り付けないでください。
- 更新を実行してノード一覧が表示されたことを確認し、対象サービスの地域に近い出口を選んで接続します。
- クライアントのログまたは接続詳細を開き、ハンドシェイクの完了を確認してから、ブラウザで出口アドレスとDNSの名前解決結果を確認します。
- 今後ノードの変更を同期するときは「サブスクリプションを更新」を使い、同じ内容の項目を何度も作成しないでください。
- ✅ サブスクリプション名、ノード一覧、更新時刻が正常に表示される
- ✅ ノードのプロトコルが現在のクライアントに対応しており、不明なフィールドがない
- ✅ 接続後に出口アドレスが想定どおり変わり、対象サイトが正常に読み込まれる
- ❌ サブスクリプションURLをフォーラム、スクリーンショット、オンライン変換ページに公開して貼り付ける
- ❌ 更新に失敗したとき、同じURLを連続してインポートし、重複した設定を複数残す
プロトコル名はどう見ればよいか
プロトコルは、クライアントとサーバーがデータを認証、カプセル化、転送する方法を定めます。ただし、プロトコル名そのものが速度ランキングではありません。同じプロトコルでも、回線、ローカルの通信事業者、クライアントの実装によって結果は大きく変わります。初心者は、サービス側が提供し、クライアントが完全に対応している設定を優先してください。名称だけを見て手動で項目を置き換えるのは避けましょう。
Shadowsocks
Shadowsocksは軽量な暗号化プロキシプロトコルで、一般的な実装では事前共有鍵と指定した暗号化方式を使い、クライアントとサーバー間のデータを保護します。設定は比較的シンプルで、対応クライアントも多いのが特徴です。ただし、Shadowsocksが提供するのはプロキシ通信であり、従来の意味で端末全体のネットワークを制御するVPNとは異なります。すべてのアプリを対象にできるかは、クライアントでシステムプロキシ、VPNインターフェース、TUNモードのどれを有効にするかによって決まります。
VMessとVLESS
VMessはV2Rayエコシステムで早くから使われてきた認証・通信プロトコルで、さまざまなトランスポート層と組み合わせられます。VLESSは認証とデータ転送をよりシンプルに設計しており、単体で完全な通信暗号化を提供するものではありません。通常はTLS、REALITY、その他の安全な通信方式と組み合わせて利用します。VLESSノードでは、サーバーアドレスと認証情報だけでなく、トランスポート種別、サーバー名、公開鍵、パスなどもサービス側の設定と一致させる必要があります。
Trojan
Trojanは通常TLS上で動作し、パスワードで認証します。接続の外観は一般的なTLS通信に近く、クライアントでは証明書とサーバー名を正しく検証する必要があります。端末の時刻が大きくずれている、ドメインの名前解決に問題がある、サーバー名が一致していないといった場合、TLSハンドシェイクに失敗することがあります。証明書検証を無効にするのは通常の修復方法にすべきではありません。接続の検証が弱くなるためです。
Hysteria2とTUIC
Hysteria2とTUICはいずれもQUICとUDPを基盤とし、高遅延、パケットロス、帯域幅の変動がある環境で転送効率を高める設計です。UDP通信が正常に許可されるネットワークでは有利な場合がありますが、企業、学校、公共のネットワークや一部のルーターではUDPが制限されることがあります。接続がタイムアウトしたりハンドシェイクに繰り返し失敗したりする場合は、TCPとTLSを基盤とする利用可能なノードに切り替えて比較し、原因がプロトコル設定かローカルネットワーク方針かを切り分けます。
| プロトコル | 主な通信特性 | 設定時の確認ポイント | よくある確認方向 |
|---|---|---|---|
| Shadowsocks | 軽量な暗号化プロキシ | 暗号化方式、パスワード、プラグインパラメータ | クライアントが該当する暗号化方式に対応しているか |
| VMess | 認証プロトコル。複数のトランスポート層と組み合わせ可能 | 認証情報、トランスポート種別、パス、サーバー名 | パラメータが完全か、システム時刻が正常か |
| VLESS | シンプルな認証。通常は安全なトランスポート層と併用 | TLSまたはREALITY関連のフィールド | サーバー名、公開鍵、トランスポートパラメータ |
| Trojan | TLSベースの認証と通信 | パスワード、証明書のドメイン、サーバー名 | 証明書検証、DNS、端末時刻 |
| Hysteria2 | QUICとUDPベース | 認証、TLS、帯域幅関連の設定 | ローカルネットワークがUDPを制限していないか |
| TUIC | QUICとUDPベース | 認証情報、パスワード、TLS、輻輳制御 | UDPの到達性とクライアントバージョンの互換性 |
分割ルーティング、グローバル、ルールモードの選び方
クライアントが最終的に解決するのは「プロキシを有効にするか」ではなく、「どのトラフィックをどの出口で処理するか」です。グローバルモードとルールモードは、クライアントがノードへの接続に成功していることが前提です。これらが変えるのはトラフィックの判断であり、ノードのハンドシェイク失敗やサブスクリプションの解析エラーを直すものではありません。
グローバルモードは一時的な切り分けに向く
グローバルモードでは通常、クライアントが制御できるリクエストを現在のノードへ渡します。ロジックがわかりやすく、複雑なルールを介さずに特定サイトへ接続できるか確認したり、ルールの誤判定を調べたりするのに適しています。一方、国内サイト、ダウンロードや更新、不必要に国際出口を使わないアプリまで遠隔回線を経由し、迂回や通信量が増えることがあります。
「グローバル」が端末上のすべてのデータを意味するとは限りません。クライアントがシステムHTTPプロキシだけを設定している場合、システムプロキシを読み取らないアプリは直接接続することがあります。TUNやシステムVPNインターフェースを有効にすると通常は対象範囲が広がりますが、除外ルート、ローカルネットワークの通信、アプリ独自のネットワーク実装の影響を受ける場合があります。
ルールモードは日常利用に向く
ルールモードはドメイン、IPアドレス、アプリのプロセス、ルールセットを順番に照合し、リクエストをプロキシ、直結、ブロック、特定のノードグループへ振り分けます。ルールには通常、順序があります。前方のルールに一致すると、後続のルールが処理されないことがあります。そのため、広範囲なルールを追加するときは、より具体的な項目を先に覆っていないか確認してください。
ドメインルールとIPルールでは解決する問題が異なります。ドメインルールはドメイン情報が見えている段階で判定に参加する必要があり、IPルールは名前解決の結果に依存します。DNS処理がクライアントの外部で行われる場合や、アプリが独自の暗号化DNSを使う場合、クライアントからは対象IPしか見えず、想定したドメインルールに一致しないことがあります。
直結モードはローカルネットワークの基準確認に向く
直結モードではリクエストがプロキシノードを経由しません。クライアント設定が原因かどうかを確認する際によく使われます。直結でもローカルサービスに接続できない場合は、ローカルDNS、ルーター、システムファイアウォール、通信事業者のネットワークを確認します。直結は正常でルールモードだけ異常なら、ルールの一致、ノード接続、DNS処理を調べるのが効果的です。
- ✅ 日常の閲覧では、適切に管理されたルールモードを優先し、不要な遠隔経路への迂回を減らす
- ✅ 特定の対象に接続できないときは、一時的にグローバルモードへ切り替えて比較する
- ✅ ローカルサービスに問題があるときは直結へ戻し、基盤ネットワークが正常か確認する
- ❌ グローバルモードをノードの帯域幅向上やハンドシェイク失敗の修復用スイッチだと考える
- ❌ 一致ログを確認せず、複数のルールを何度も変更する
システムプロキシ、TUN、DNSリーク
システムプロキシは、プロキシ設定を読み取るアプリだけを対象にする
システムプロキシは、OSにHTTP、HTTPS、SOCKSプロキシのアドレスを書き込みます。ブラウザや多くのデスクトップアプリはこれらの設定を読み取りますが、一部のゲーム、コマンドラインプログラム、独自のネットワークスタックを持つアプリ、UDPリクエストを直接送るソフトウェアはシステムプロキシを無視することがあります。クライアントに「接続済み」と表示されても、それらのアプリの通信がノードに入ったとは限りません。
TUNモードは仮想ネットワークインターフェースから通信を制御する
TUNモードは仮想ネットワークインターフェースを作成し、システムルートを通じてより多くのIP通信をクライアントに渡します。単純なシステムプロキシより対象範囲が広く、プロキシ設定に対応していないアプリにも適しています。一方、システムのネットワーク権限が必要で、他のVPNソフト、仮想マシン、コンテナネットワーク、セキュリティソフトとルートが競合することがあります。
TUNを有効にした後、ローカル端末に接続できない、LANサービスが停止する、特定のアプリだけネットワークにつながらないといった問題が出た場合は、まずLANのバイパス、プライベートアドレスへの直結、デフォルトルートが正しく設定されているか確認してください。仮想インターフェースを作成してデフォルトルートを変更するクライアントを複数同時に起動しないでください。
DNSリークは名前解決のリクエストが誤った出口を通る状態
DNSリークとは通常、業務通信はプロキシを通っているのに、ドメインの名前解決だけがローカルネットワークのDNSサーバーから直接行われる状態を指します。これにより、名前解決の場所と出口の場所が一致しなくなり、ローカルネットワークから検索したドメインを見られる可能性もあります。完全な通信断として現れるとは限らず、対象が誤った地域の内容を返す、ルールに一致しない、一部のドメインだけ不適切なアドレスに解決されるといった症状がよく見られます。
確認時は、クライアントがDNSを制御しているか、ルールモードがどの名前解決方式を使っているか、ブラウザで独立したセキュアDNSが有効になっていないか、他のネットワークインターフェースのDNSがシステムに残っていないかを確認します。接続後は、当サイトのネットワークチェックページを開き、出口アドレスとDNSの解決場所を比較してください。両者が明らかに一致しない場合は、クライアントに戻ってDNSの制御方式を調整します。
プラットフォームごとにクライアントの違いが生じる理由
同じサブスクリプションでも、プラットフォームによって表示される項目が異なることがあります。これは通常、サブスクリプションの内容ではなく、OSが提供するネットワークインターフェース、バックグラウンド制限、クライアントのコア機能が異なるためです。端末を移行するときはモードと権限を改めて確認し、取り込めばすべての設定が自動的に同じになるとは考えないでください。
Windows
Windowsのクライアントでは、システムプロキシとTUNを同時に使えることがよくあります。システムプロキシはブラウザや一般的なデスクトップアプリに向き、TUNはコマンドライン、ゲーム、プロキシ設定を読み取らないソフトウェアの制御に適しています。ネットワークに接続できない場合は、システムプロキシの設定が残っていないか、仮想ネットワークアダプターが正常に読み込まれているか、ファイアウォールがクライアントの通信を許可しているかを確認します。
macOS
macOSのクライアントは、システムプロキシ、ネットワーク拡張、システムVPNインターフェースを通じて動作する場合があります。関連モードを初めて有効にするときは、システムによるネットワーク権限の承認が必要です。クライアントが接続済みなのにアプリがノードを経由しない場合は、ネットワーク拡張が有効か、システム設定に他のネットワークフィルターが存在しないかを確認します。クライアントを終了する前にシステムプロキシを元に戻しておくと、終了後のアプリが閉じたローカルポートを参照し続けるのを防げます。
Android
Androidでは通常、システムVPNインターフェースを使って通信を制御し、アプリごとにトンネルへ入れるかを決められます。省電力設定によって、バックグラウンドでの接続維持が制限されることがあります。ネットワークを切り替えた後は、セッションの再確立が必要になる場合もあります。特定のアプリだけに問題があるなら、サブスクリプション全体を変更する前に、アプリ単位の分割ルーティングを確認してください。
iOSとiPadOS
iOSとiPadOSのクライアントは、システムが提供するVPNとネットワーク拡張の機能に依存し、バックグラウンド動作もシステムが一元管理します。サブスクリプションを取り込んだ後も、システムはVPN構成の作成を求めます。ノードを切り替えてもすぐに反映されない場合は、いったん切断して再接続し、現在有効な構成が実際に使用中のクライアントのものか確認してください。
| プラットフォーム | 一般的な通信制御方式 | 主な確認項目 |
|---|---|---|
| Windows | システムプロキシ、TUN | プロキシ設定の残留、仮想ネットワークアダプター、ファイアウォール |
| macOS | システムプロキシ、ネットワーク拡張 | ネットワーク権限、フィルターの競合、システムプロキシの状態 |
| Android | システムVPNインターフェース、アプリ単位の分割ルーティング | バックグラウンド制限、アプリの除外、ネットワーク切り替え |
| iOSとiPadOS | システムVPN、ネットワーク拡張 | 構成の承認、現在有効な構成、再接続の状態 |
接続失敗からルール異常までの確認手順
初心者によくあるのは、ノード、プロトコル、DNS、TUN、ルールを一度に変更し、どの設定が有効だったのか分からなくなることです。より確実なのは、データの流れに沿って、サブスクリプションの入力から対象アプリの出口まで層ごとに確認する方法です。
- サブスクリプションを更新でき、ノード設定にプロトコルや認証フィールドの欠落がないことを確認する。
- 1つのノードを固定し、クライアントのログで接続とハンドシェイクが完了したか確認する。
- ルールの少ないモードで基本的なアクセスをテストし、複雑な分割ルーティングの影響を除外する。
- 対象アプリがシステムプロキシを読み取るか確認する。読み取らない場合は、TUNまたはシステムVPNインターフェースをテストする。
- 出口アドレスとDNSの解決場所を照合し、名前解決が想定した経路に入っているか判断する。
- 通常のルールモードに戻し、一致ログで対象ドメインまたはIPに正しい方針が適用されたことを確認する。
- 最後に異なるノードと回線を比較し、ローカル権限の問題を回線の問題と取り違えないようにする。
クライアントに「接続済み」と表示されるのは、特定の接続処理が確立したことを示すだけです。サブスクリプションの更新、アプリの通信制御、DNSの名前解決、分割ルーティングの一致、対象サービスへのアクセスがすべて正常とは限りません。切り分けでは各工程を個別に確認してください。
これらの用語を理解すると、クライアント画面は明確な経路に分けて考えられます。サブスクリプションが設定を提供し、ノードが接続先を示し、プロトコルが通信を担い、回線がデータを運び、システムプロキシまたはTUNがアプリの通信を制御し、分割ルーティングのルールが出口を決め、DNSがドメイン名に対応するアドレスを提供します。異常があればどの層にあるか特定でき、すべての設定を手当たり次第に切り替える必要はありません。