サブスクリプション・ノード・プロトコルとは何か。これは、多くの初心者がクライアントに設定をインポートした後に直面する最初の疑問です。簡単に言えば、サブスクリプションは設定をクライアントへ渡し、ノードは選択可能な接続先を示し、プロトコルはクライアントとサーバーの通信方法を定めます。回線、分流、動作モードによって、データの経路や接続を利用するアプリも決まります。これらは同じ接続経路を構成しますが、互換できる名称ではありません。
これらの用語を理解するには、定義を暗記するより、実際の利用順に確認するのが近道です。まずサブスクリプションURLを取得し、対応クライアントにインポートします。クライアントがノードを解析し、ノードを選択すると、対応するプロトコルで接続を確立します。接続後は、グローバルモードや分流ルールによって、どのリクエストを接続経由にするかが判断されます。最後に、DNS設定がドメイン名をアドレスへ変換します。DNSも分流方針と整合させる必要があります。
サブスクリプションURLには何が含まれる？
サブスクリプションURLは通常、サーバー側で生成され、クライアントが読み取るためのアドレスです。クライアントがURLへアクセスすると、エンコードまたは構造化された設定一式を取得します。設定には、サーバーアドレス、ポート、プロトコル、認証情報、ノード名、更新情報などが含まれる場合があります。ユーザーに見えるのは1本のURLですが、クライアントが受け取るのはノード一覧へ変換できるデータです。
そのため、「サブスクリプションを購入する」と「サブスクリプションをインポートする」は別の操作です。前者はサービスの利用権を取得すること、後者はすでにある設定をクライアントへ追加することを意味します。インポートに成功しても、回線への接続が完了したわけではありません。クライアントが設定を読み取り、解析できたことを示すだけです。ノードを選択して接続を開始し、対象アプリが想定どおりプロキシやトンネルを利用しているか確認する必要があります。
サブスクリプションURLは機密性の高い認証情報として扱いましょう。URLを入手した人は、通常そこに含まれるノード設定を読み取れるため、公開投稿、スクリーンショット、共有ドキュメントに載せるべきではありません。問題を調べる際は、クライアントのエラーメッセージを共有しても構いませんが、完全なURL、認証項目、サーバー設定は隠してください。URLの漏えいが疑われる場合は、ローカルのクライアントから履歴を削除するだけでなく、サービスパネルで認証情報を更新します。
インポート・更新・ローカル設定の違い
「インポート」はサブスクリプションを初めて読み込むこと、「更新」は元のURLから最新設定を再取得すること、「ローカル設定」は現在の端末だけに保存される設定を指します。サブスクリプションを更新すると、ノードが追加・削除・調整されたり、同名項目の一部フィールドが上書きされたりする場合があります。サブスクリプションから生成されたノードを直接編集すると、次回更新時に変更が失われることがあります。長く使うカスタムルールは、クライアントが対応するオーバーライド、ルールセット、または独立した設定領域に保存するのが適切です。
- サービスパネルからサブスクリプションURL全体をコピーし、URL内の文字を手動で削除・変更しないでください。
- 対応クライアントで「URLからインポート」または同様の項目を選択します。
- インポート後に一度更新し、クライアントが設定を正常に取得できることを確認します。
- ノードを1つ選択して接続を開始し、実際のアプリでアクセス結果を確認します。
- 後からノード一覧に変化があった場合は、まずサブスクリプションを更新してから接続障害かどうかを判断します。
ノード、サーバー、回線の違い
ノードとは、クライアント上で選択できる設定項目です。通常は特定のサーバー入口を指し、プロトコル、ポート、認証情報、表示名などを伴います。同じサーバーが異なるプロトコルや入口を提供することもあるため、クライアントに表示される複数のノードが、同じ数の物理マシンに対応するとは限りません。反対に、同じ地域のノードが異なるサーバーで運用される場合もあります。
サーバーはネットワークサービスを稼働させる計算リソース、ノードはユーザーが接続できる設定上の入口、回線はローカルから対象ネットワークまでのデータ経路を表します。ノード名に地域が含まれていても、出口または主な入口がその地域に関係することを示す場合が多いだけで、経路全体を名前だけから判断することはできません。実際の経路は、現地の通信事業者、入口の位置、バックボーン回線、対象サイトのネットワーク方針にも左右されます。
| 用語 | 主な意味 | ユーザーが直接確認できるもの | よくある誤解 |
|---|---|---|---|
| サブスクリプション | クライアントへ設定を配布・更新するもの | サブスクリプション名、更新日時、ノード一覧 | インポート成功を接続成功と考える |
| ノード | 選択可能なサーバー入口の設定 | 地域、プロトコル、名称、状態 | すべてのノードが独立した物理サーバーだと考える |
| サーバー | 接続サービスを実際に稼働させる計算リソース | 基盤の詳細情報は通常表示されない | サーバー所在地だけで経路全体を判断する |
| 回線 | ローカル、入口、バックボーン、出口間の伝送経路 | 直結、中継、専用線などサービス側のラベル | 回線ラベルを固定速度とそのまま結び付ける |
直結・中継・IEPL専用線
直結は通常、ローカルネットワークから海外サーバーの入口へ直接接続する方式です。構成はシンプルですが、通信品質は現地の通信事業者や国際出口の状況に左右されやすくなります。中継では、まず近い、またはローカルネットワークに適した入口へ接続し、そこから目的の出口へ転送します。ネットワーク環境によっては経路選択を改善できますが、転送が1段増えるため、サービス側では入口・中継・出口間の連携を管理する必要があります。
IEPL専用線は通常、企業向けの国際イーサネット専用線系の伝送を指します。個人向けサービスでは、管理された伝送経路の一部を説明するラベルとして使われることが多く、ユーザーの端末から対象サイトまでの全区間が同じ専用線になることを意味しません。ユーザー側から接続拠点まで、また出口から対象サイトまでは通常のネットワークを通る可能性があります。そのため、「専用線」をどの場所・時間でも同じ性能が出るものと理解しないでください。
回線を選ぶ際、地域は条件の一つにすぎません。アクセス先の場所、アプリが遅延と継続的なスループットのどちらを重視するか、ローカルネットワークでUDPが制限されているか、現在の入口が混雑しているかによって結果は変わります。安定して選ぶには、まず目的地域で候補を絞り、同じ利用シーンで使いやすさを比較しましょう。ノード名の形容詞だけを見るのは避けてください。
プロキシプロトコルが決めること
プロトコルは、クライアントとサーバーがセッションを確立し、身元を認証し、データをカプセル化してネットワーク上で伝送する方法を定めます。ノード設定はサーバー側が対応するプロトコルやパラメータと一致していなければならず、Trojanノードを手動でVLESSに変更しても動作するとは限りません。プロトコルだけで速度が決まるわけでもありません。回線品質、混雑、端末性能、トランスポート層の設定、対象サイトが総合的に通信体験へ影響します。
Shadowsocks、VMess、Trojan、VLESS
Shadowsocksは、よく使われる暗号化プロキシプロトコルです。設定は通常、サーバー、ポート、パスワード、暗号化方式を中心に構成されます。実装が成熟しており対応クライアントも多い一方、具体的な安全性や互換性は、選択した暗号化方式とクライアントの実装に左右されます。プロキシ通信を主に担うもので、複雑な分流管理画面を自動的に提供するわけではありません。
VMessはV2Rayエコシステムで早くから広く使われてきたプロトコルです。認証とトランスポートの設定には、ユーザー識別子、通信方式、時刻同期などが関係します。端末の時刻が大きくずれていると、一部の設定で認証エラーが発生する場合があります。VLESSはより軽量な認証設計を採用し、暗号化自体は担当しません。通常はTLS、REALITYなどの安全なトランスポート機構と組み合わせて使用します。VLESSと表示された場合は、プロトコル名だけでなく、組み合わせられたトランスポート層とセキュリティ層も確認してください。
Trojanは通常、TLSで保護された接続上で動作します。設定では、サーバー名、証明書検証、パスワード、トランスポート設定が重要です。クライアントで証明書検証を無効にすると、一部の設定ミスを回避できる場合はありますが、サーバーの身元確認が弱くなるため、通常のトラブルシューティング手段にすべきではありません。システム時刻、サーバー名、証明書の状態、設定の一致を確認するのが正しい対応です。
Hysteria2とTUIC
Hysteria2とTUICはいずれもQUICおよびUDP通信を重要な基盤とし、輻輳制御、マルチプレクシング、接続移行などの機能を組み合わせて設計されています。パケットロスや変動が大きいネットワークでは、TCPベースの方式より適応しやすい場合がありますが、ローカルネットワークでUDPを安定して利用できることが前提です。オフィス、公衆ネットワーク、ルーターがUDPを厳しく制限している場合、接続に失敗したり性能が低下したりすることがあります。その場合は関係のないパラメータを繰り返し調整せず、サーバー側が提供する別のプロトコルへ切り替えてください。
| プロトコル | 通信上の特徴 | 設定時に重点的に確認する項目 |
|---|---|---|
| Shadowsocks | 暗号化プロキシで、対応クライアントが多い | 暗号化方式、パスワード、ポートが一致しているか |
| VMess | 複数の下位トランスポートを組み合わせられる | ユーザー識別子、通信パラメータ、システム時刻 |
| Trojan | 通常はTLSと組み合わせて接続を確立する | サーバー名、証明書検証、パスワード |
| VLESS | 軽量な認証で、安全なトランスポート層と併用することが多い | TLSやREALITYなどの関連パラメータ |
| Hysteria2 | QUICベースで、変動するネットワークへの適応性を重視 | UDPの利用可否、認証、帯域幅パラメータ |
| TUIC | QUICベースで、マルチプレクシングに対応 | UDPの利用可否、輻輳制御、認証設定 |
グローバルモード、ルールモードと分流
接続を確立した後、クライアントはどの通信をノード経由にするかも決める必要があります。グローバルモードは通常、クライアントが処理できるリクエストを、選択したノードへできるだけ一括して通します。ルールモードでは、ドメイン、IP、アプリ、ルールセットに応じて、プロキシ、直結、遮断を個別に選択します。これが分流です。目的はすべての通信を遠回りさせることではなく、リクエストごとに適した出口を使うことです。
ルールモードでは、リクエストがまずローカルネットワークへの直結ルールに一致し、次に特定ドメインのルール、最後にデフォルトルールへ進むことがあります。ルールの順序は重要です。具体的なルールは通常、より広いルールより前に置きます。広範な直結ルールが先に一致すると、後続のプロキシルールは実行されません。反対に、広すぎるプロキシルールは、ローカルサービス、プリンター、内部システムまで不要な遠隔経路へ送る可能性があります。
システムプロキシ、TUN、アプリ内プロキシ
システムプロキシは、OSのプロキシ設定に従うアプリへHTTPまたはSOCKSの入口を提供します。設定を読み取るアプリもあれば、独自に接続して無視するアプリもあります。TUNモードは仮想ネットワークインターフェースを通じて、より広範なIP通信を引き受けます。システムプロキシを読み取らないプログラムも対象にできますが、ファイアウォール、仮想マシン、企業向けネットワークソフト、他のトンネルツールと経路が競合しやすくなります。
アプリ内プロキシは、特定のソフトウェアだけにプロキシアドレスとポートを入力する方式です。影響範囲が最も小さく、切り分けもしやすくなります。「ブラウザはアクセスできるのに、他のソフトは使えない」という場合、ノードが無効なのではなく、ブラウザだけがシステムプロキシに従い、他のソフトが従っていないことがよくあります。この場合は、すぐにサブスクリプションを削除せず、クライアントの動作モードを確認してください。
- ✅ ブラウザだけを国際回線経由にしたい場合は、システムプロキシまたはブラウザが対応するプロキシ設定を優先します。
- ✅ システムプロキシを読み取らないデスクトップアプリも対象にしたい場合は、TUNモードを有効にするか検討します。
- ✅ ルールモードを使う場合は、ローカルネットワーク、普段使う国内サービス、対象の国際サービスが、それぞれ想定したルールに一致しているか確認します。
- ✅ モードを切り替えた後は対象アプリを再起動し、古い接続が以前の経路を使い続けないようにします。
- ❌ システム通信を引き受けるクライアントを複数同時に起動しないでください。ルーティングやDNS設定が互いに上書きされる可能性があります。
- ❌ 「接続済み」アイコンだけで、すべてのアプリがノード経由になったと判断しないでください。
DNSリークとドメイン名の名前解決
アプリがドメインへアクセスする前に、通常はDNSへ問い合わせて対応するアドレスを取得します。DNSリークとは、本来トンネル内または指定したリゾルバーで処理したい問い合わせが、想定経路を通らず、ローカルネットワークのDNSへ送られる状態です。その結果、名前解決の場所とアクセス出口が一致しなかったり、ローカルの解決結果の違いによって、サイトにアクセスできない、地域判定が不自然になる、ルールが誤って一致するといった問題が起こる場合があります。
DNSの問題は分流と密接に関係します。ドメイン名で経路を決めるクライアントでは、接続の早い段階でドメイン情報を取得する必要があります。アプリが先にドメインをIPへ解決すると、クライアントはIPルールだけで判断する可能性があります。一部のクライアントは、Fake IP、リモートDNS、暗号化DNSを使ってドメインと接続の対応関係を維持しますが、プラットフォームやコアによって実装は異なります。
DNSを確認するときは、「ウェブページを開けるか」だけを見ないでください。クライアントがDNSを管理しているか、ルールモードでどのリゾルバーを使うか、システムに古い手動DNSが残っていないか、ブラウザが独自のセキュアDNSを有効にしていないか、TUNモードとシステムプロキシモードで異なる設定を使っていないかを同時に確認します。ブラウザが独自に名前解決すること自体は必ずしも誤りではありませんが、クライアントが想定するドメイン分流の流れを迂回する可能性があります。
プラットフォームごとにクライアントの設定が違う理由
Windows、macOS、Android、iOS、Linuxでは、システムプロキシ、仮想ネットワークインターフェース、バックグラウンド動作、権限管理の方法が異なります。そのため、同じサブスクリプションを異なるクライアントへインポートしても、画面や利用できる機能は完全には一致しません。サブスクリプションが提供するのはサーバー設定であり、ルール、DNS、TUN、自動更新をどう実装するかは、ローカルのコアとOSの機能に依存します。
Windowsクライアントでは、システムプロキシとTUNを同時に提供することがよくあります。前者は設定が簡単で、後者は対象範囲が広い一方、TUNを有効にするには仮想ネットワークコンポーネントのインストールと必要な権限が求められる場合があります。macOSもシステムプロキシやトンネル方式に対応しますが、ネットワーク拡張の権限、システムファイアウォール、他のネットワーク拡張が接管結果に影響することがあります。
Androidクライアントは通常、システムVPNインターフェースを使って通信を管理し、アプリごとの分流に対応する場合もあります。バッテリー管理によってクライアントのバックグラウンド動作が制限されると、長時間の待機後に接続が停止することがあります。iOSクライアントはシステムのネットワーク拡張機構の制約を受けるため、機能名がデスクトップ版と異なる場合があります。サブスクリプションの更新やバックグラウンド接続の動作も、システムのスケジューリングに左右されやすくなります。
Linuxでは、デスクトップ環境、ネットワーク管理ツール、実行方法による違いが大きくなります。コマンドラインのコアがローカルプロキシポートを開くだけの場合、システムがそのポートを自動利用するには、環境変数、デスクトッププロキシ、透過転送を別途設定する必要があります。コアに「実行中」と表示されても、プロセスが起動していることを示すだけで、すべてのプログラムの通信が通過しているとは限りません。
初心者が最初に確認すべき設定
- ✅ クライアントが、サブスクリプションで使用されているプロトコルと通信方式に対応しているか。
- ✅ サブスクリプションの更新が正常か、ノード一覧が完全に表示されているか。
- ✅ 現在有効なのがシステムプロキシ、TUN、アプリ内プロキシのどれか。
- ✅ ルールモードのデフォルト出口が、現在の利用目的に合っているか。
- ✅ DNS設定が分流モードと連動しているか、ブラウザに独自の名前解決設定がないか。
- ✅ システム時刻が正確か。証明書の検証や時刻同期が必要な認証は、いずれも時刻に依存します。
- ❌ 不明な情報源から「最適化パラメータ」をむやみにコピーしないでください。パラメータはサーバー側とローカルネットワークの条件に適合している必要があります。
接続障害を用語ごとに切り分ける方法
用語を実際に理解する価値は、問題が起きたときに、どの層を確認すべきか判断できることです。サブスクリプションを更新できない場合は、URLの状態、ネットワークアクセス、クライアントの解析能力を確認します。更新はできるのにすべてのノードへ接続できない場合は、プロトコル対応、認証パラメータ、システム時刻、ローカルネットワークの制限を確認します。一部のノードだけが異常なら、特定の入口、回線、プロトコル設定に関係している可能性が高くなります。
クライアントが接続済みと表示されても、特定のアプリがローカルネットワークを使い続ける場合は、そのアプリがシステムプロキシまたはTUNの管理対象か確認します。グローバルモードは使えるのにルールモードが使えない場合は、ルールの一致とDNSを確認します。ドメインは開けないが既知のアドレスへは接続できる場合、問題は名前解決経路にある可能性が高くなります。ドメインを解決できても接続がタイムアウトする場合は、ルーティング、ノード、対象サービスの応答を引き続き確認します。
トラブルシューティングでは、一度に1つの要素だけを変更します。たとえば同じプロトコルとモードを維持してノードだけ切り替える、または同じノードを維持してルールモードからグローバルモードへ切り替える方法です。サブスクリプションの更新、プロトコルの変更、TUNの有効化、DNSの変更を同時に行うと、問題が解消しても何が効いたのか分からず、同じ問題を再現できなくなります。