ノード、プロトコル、分割ルールとは？初心者向け用語ガイド

ノード・プロトコル・分割ルールとは何かは、初めてサブスクリプションを読み込むときによくある疑問です。これらは同じ階層の概念ではありません。サブスクリプションは設定を届け、ノードは選択可能な接続先を示し、回線は実際にデータが通るネットワーク経路を表します。プロトコルはクライアントとサーバーの通信方法を定め、分割ルールはリクエストごとにどの経路を使うかを決めます。これらを切り分ければ、クライアントにある多くの設定も理解しやすくなります。

初心者によくある誤解は、接続結果をすべて「ノードの良し悪し」のせいにすることです。実際の使用感は、ローカルネットワーク、プロトコルの対応状況、接続先の位置、ネットワーク間の経路、出口の位置、DNS、接続先サイトなどによって決まります。ノード名が同じでも基盤となる経路まで同じとは限らず、プロトコル名が違っても速度に一定の優劣があるとは限りません。

サブスクリプション、ノード、回線はそれぞれどの階層にある？

サブスクリプションURLは回線そのものではない

サブスクリプションURLは通常、サーバー側で生成された設定情報を指します。クライアントがこのURLにアクセスすると、ノード名、サーバーアドレス、ポート、プロトコル設定、認証情報、グループ、ルールなどを読み込み、選択可能な設定として表示します。クライアントによって対応フィールドが異なるため、同じサブスクリプションでもソフトウェアごとにグループや項目の表示が変わる場合があります。

サブスクリプションURL自体がウェブ通信を継続的に運ぶわけではありません。更新が完了すると、クライアントは読み込んだ設定に従って対応するサーバーへ接続します。つまり、サブスクリプションURLは「設定を取得する」ためのもので、ノードのアドレスは「接続を確立する」ためのものです。サブスクリプションの更新は設定を再取得する操作であり、クライアントの再インストールや、すべてのネットワーク問題の自動修復を意味しません。

サブスクリプションURLには設定を識別する認証情報が含まれる場合があるため、完全なURLを公開ページ、スクリーンショット、共有ドキュメントに掲載しないでください。URLが公開された場合は、サービス管理画面からサブスクリプションを再生成または変更し、ローカルの古い設定を削除するだけで済ませないようにします。ローカル記録を削除しても、漏えいしたURLは無効になりません。

ノードは接続先と出口設定の組み合わせ

クライアントに表示される「香港」「日本」「米国」などのノード名は、通常、出口地域を示します。ただし、名前はサービス提供側が付けたラベルにすぎません。ノード設定には少なくとも、接続先、使用するプロトコル、認証方法をクライアントへ伝える情報が必要です。サーバーは通信を受け取った後、自身のネットワーク経路で目的のサイトへアクセスするため、接続先サイトからは通常、サーバー側の出口アドレスが見えます。

ノードを単純に1台の固定マシンと考えることはできません。実際のサービスでは、入口・転送・出口の間で経路を振り分けたり、複数の入口を同じ出口に集約したりする場合があります。ノードの用途を判断するときは、名前の修飾語だけでなく、出口地域、回線タイプ、プロトコルの互換性、現在のネットワーク状況を優先して確認しましょう。

回線は途中の経路を表す

回線は、ユーザー側から出口までデータがどのように届くかに関わるものです。直接接続、中継、専用線はよく使われる分類ですが、プロトコル名ではありません。プロトコルは通信形式を決め、回線はネットワーク経路を決めます。両者は組み合わせて利用できます。同じプロトコルでも異なる回線で動作し、同じ回線でも複数のプロトコルを載せられます。

一般的なプロトコル名の読み方

プロトコルは、クライアントとサーバーの双方が理解する必要がある通信規則です。クライアントが対応していないプロトコルは、サーバーアドレス、認証情報、ネットワークが正常でも接続できません。プロトコルは転送方式、TLS、セキュリティ設定、偽装レイヤーなどと組み合わせて使われることもあるため、主なプロトコル名だけでは設定全体を判断できません。

Shadowsocks

Shadowsocks は暗号化プロキシプロトコルで、設定には通常、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。構成が比較的シンプルで、対応クライアントも幅広いのが特徴です。暗号化方式はサーバー側と一致している必要があり、古いクライアントがサブスクリプションで使われている方式に対応していないと、接続できなかったり、読み込み後に利用できなかったりします。

Shadowsocks が担うのは、クライアントとプロキシサーバー間のデータ転送と認証です。複雑な分割機能が自動的に提供されるわけではなく、ルールは通常クライアント側で別途実装されます。「Shadowsocks ノード」と表示されていても、プロトコルの互換性と実際の回線は分けて判断しましょう。

VMess と VLESS

VMess は V2Ray エコシステムでよく使われ、認証、時刻確認、複数の転送方式に対応しています。端末の時刻が大きくずれていると、確認処理により接続に失敗する場合があります。VMess はさまざまな転送方式と組み合わせられるため、同じ VMess と表示されるノードでも、具体的なネットワーク特性が異なることがあります。

VLESS は比較的軽量な認証設計を採用しており、それ自体で完全なデータ暗号化機能を提供するものではありません。通常は TLS などの安全な転送レイヤーで接続を保護します。設定に含まれるサーバー名、証明書検証、転送方式、パスの各パラメーターは、相互に一致している必要があります。証明書検証を無効にすると一部のエラーを回避できる場合がありますが、サーバーの身元確認が弱くなるため、長期的な対処方法には適しません。

Trojan

Trojan は通常 TLS 接続上で動作し、設定ではサービスアドレス、パスワード、サーバー名、証明書検証が重要になります。接続の外観は一般的な TLS 通信に近いものの、すべての Trojan 設定で速度や安定性が自動的に向上するわけではありません。証明書、ドメイン、サーバー名の不一致は、接続失敗のよくある原因です。

Hysteria2 と TUIC

Hysteria2 と TUIC は、UDP ベースの QUIC 転送の考え方を採用することが多く、輻輳制御、多重化、変動の大きいネットワークでの転送性能を重視します。高遅延またはパケットロスが起きやすいネットワークでは良好に動作する場合がありますが、現在のネットワークが UDP を安定して通せることが前提です。公共ネットワーク、企業ネットワーク、ルーターによっては UDP が制限され、ハンドシェイク失敗、断続的な切断、フォールバック不能などが起きます。

この2種類のプロトコルでは、クライアントのバージョンとパラメーターの互換性も重要です。プロトコル名が同じでも実装バージョンの差が大きいと、通信できない場合があります。問題が起きたら、まずサブスクリプションとクライアントを更新し、サーバー側の要件を確認してください。別のプロトコルのパラメーターを無闇にコピーしてはいけません。

分割ルールは何を決めているのか

分割ルールは、クライアントが経路を選択するための仕組みです。ブラウザーやアプリがリクエストを送ると、クライアントはドメイン、宛先アドレス、アプリのプロセス、ネットワーク種別、ルールセットなどに基づき、そのリクエストをプロキシ、直接接続、拒否のどれにするか判断します。分割処理は端末側で行われるため、同じノードでもウェブサイトごとに異なる経路を使えます。

ルールモード

ルールモードでは、リクエストを順番にルールへ照合します。一般的には、国内サービスやLANリソースを直接接続し、国際回線が必要なドメインをプロキシ経由にし、広告、トラッキング、不審なアドレスには拒否ルールを適用します。不要な迂回を減らし、出口地域の変化による国内サイトの追加認証も避けやすいため、日常利用にはルールモードが適しています。

ルールが照合するのは、ブラウザーのアドレスバーに入力した文字だけではありません。ウェブページは画像、スクリプト、API、動画、外部ログイン用ドメインも読み込みます。メインサイトはプロキシ経由なのに依存先のAPIが誤って直接接続されると、ページは開いても機能が一部動かないことがあります。このような問題では、メインドメインだけでなく関連ドメインも確認してください。

グローバルモード

グローバルモードでは通常、クライアントが制御する大部分の通信を選択したノード経由にします。「ルールの抜けが原因か」を短時間で確認したいときに便利です。ルールモードでは開けず、グローバルモードでは開ける場合は、ルール照合またはDNSの問題である可能性が高いでしょう。両方で失敗する場合は、ノード、プロトコル、システムプロキシ、接続先サービスを引き続き確認します。

グローバルモードにしても、端末上のすべてのデータが必ず制御されるとは限りません。システムプロキシ、仮想ネットワークインターフェース、アプリ内プロキシのどれを使うかで対象範囲が変わります。システムプロキシを読み込まないアプリや、独自のDNS・ネットワークスタックを使うアプリもあるため、通常のシステムプロキシを迂回する場合があります。

直接接続モード

直接接続モードはプロキシ経路を使わず、LAN機器やローカルサービスへのアクセス、または問題がプロキシ設定にあるかの確認に使います。直接接続とプロキシの両方が失敗するなら、まずローカルネットワークと接続先を確認します。直接接続は正常でプロキシだけ失敗するなら、ノードとプロトコルを確認します。プロキシは正常で直接接続だけ失敗するなら、ローカルネットワークの経路やアクセス地域の違いが原因かもしれません。

• ✅ 日常のブラウジングではルールモードを優先し、国内サービスと国際回線に適した経路を使い分けます。
• ✅ ページの一部リソースが読み込めないときは、一時的にグローバルモードへ切り替え、ルール漏れの有無を確認します。
• ✅ ルーター、ストレージ、LANサービスへアクセスするときは、関連アドレスが直接接続になっていることを確認します。
• ❌ グローバルモードを長期利用して、ルール修正の代わりにしないでください。
• ❌ 出所や用途が不明な設定ファイルを読み込み、既存のルールを上書きしないでください。

直接接続・中継・IEPL専用線の違い

ここでいう「直接接続」は回線構成を指し、クライアントの直接接続モードとは異なります。回線の直接接続では、クライアントが目的地域のプロキシサーバーへ直接接続し、サービス側が用意した追加の中継入口を経由しません。構成はシンプルですが、事業者間・地域間の経路は公共ネットワークのルーティングに左右されやすく、夜間の混雑や迂回が接続品質に直接表れます。

中継回線では、まず近い、または到達しやすい入口へ接続し、そこから目的の出口へ転送します。ユーザー側から入口までと、入口から出口までを分けて最適化できます。中継により一部の不安定な公共経路を避けられる場合がある一方、保守が必要な区間が1つ増えます。入口は正常でも出口に問題がある場合や、入口から出口までの転送で障害が起きた場合は、ノードが利用できなくなることがあります。

IEPL は国際イーサネット専用線を表す一般的な略称で、もともとは通信事業者が提供する企業向けのポイントツーポイント接続を指します。サブスクリプションサービスの文脈で「IEPL専用線」と表示される場合、入口と出口の間で専用線または同様に管理された伝送経路を使うことを示すのが一般的です。ただし、ユーザー端末から入口までの区間はローカルアクセスネットワークを経由します。端末から目的サイトまでの全経路が公共ネットワークの影響を受けないことや、どの時間帯でも影響を受けないことを意味しません。

したがって、回線ラベルは構成を理解する手がかりにすぎず、実際の判断の代わりにはなりません。自分のネットワークに合う入口を選び、継続接続、ウェブページの初回表示、動画のバッファリング、ファイル転送が安定するかを確認してから、回線同士を比較するのが確実です。短時間のテストで分かるのはその時点の状態であり、長期的な結論には使えません。

DNSリークと名前解決が結果に影響する理由

ユーザーがドメイン名を入力すると、端末はまずドメインをネットワークアドレスへ変換する必要があります。この処理をDNSが担います。ウェブ通信はプロキシ経由なのに、名前解決だけがローカルネットワークのDNSサーバーで行われると、DNSリークが起きる場合があります。ローカルのDNS事業者に検索したドメインが見え、解決結果もプロキシの出口地域と一致しない可能性があります。

DNSリークは必ずしも「まったく開けない」状態になるとは限りません。より一般的なのは、適切でないCDNノードへ解決される、サイトの地域判定が一致しない、トップページは開くのにAPIだけ失敗する、ルールモードで判定がループするといった症状です。クライアントには通常、システムDNS、プロキシ経由のDNS、暗号化DNS、仮想マッピングなどの方式があり、互換性や分割精度への影響がそれぞれ異なります。

ルールでドメイン情報が必要な場合、名前解決の順序は特に重要です。アプリが先にドメインをアドレスへ変換し、クライアントが宛先アドレスしか受け取れないと、ドメインベースのルールが一致しないことがあります。仮想ネットワークインターフェースモードに対応するクライアントは、通信と名前解決をより完全に制御できる一方、セキュリティソフト、企業ネットワークのポリシー、他のネットワークツールと競合しやすくなります。

DNSの問題を確認するときは、出口アドレスだけを見ないでください。DNSサーバーの地域、ブラウザーが独自の暗号化DNSを有効にしているか、クライアントがDNSを制御しているか、ルールにDNSリクエストを誤って直接接続する項目がないかを同時に確認します。変更後はシステムとブラウザーのDNSキャッシュを消去し、接続を再確立してテストします。

プラットフォーム別サブスクリプションの読み込みとクライアント更新

サブスクリプションの読み込み手順は基本的に共通しています。サービス管理画面からURLを取得し、対応クライアントにリモート設定として追加し、ノードの取得を待ってから、グループ、ノード、動作モードを選択します。実際に失敗しやすいのは「貼り付け」操作ではなく、クライアントがサブスクリプション形式、プロトコル、すべてのパラメーターに対応しているかどうかです。

デスクトッププラットフォーム

Windows と Linux のクライアントは通常、システムプロキシ、仮想ネットワークインターフェース、ルーティングルール、接続ログを比較的幅広く提供します。システムプロキシの影響を受けるのは、プロキシ設定を読み込むアプリだけです。仮想ネットワークインターフェースモードでは、より広い範囲の通信を制御できますが、対応するシステム権限が必要です。特定のアプリがプロキシを使わない場合は、ノードが無効だと決めつけず、まず現在の制御方式を確認してください。

macOS のクライアントでも、システムプロキシと仮想ネットワークインターフェースモードを利用できる場合があります。システムアップデート、セキュリティポリシー、ネットワーク拡張機能の権限によって、仮想インターフェースが起動できるかどうかが変わります。クライアントに「接続済み」と表示されても、それはローカルサービスが動作していることを示すだけで、リモートノードのハンドシェイク成功を保証しません。接続ログまたは実際のアクセス結果も確認しましょう。

モバイルプラットフォーム

Android のクライアントは通常、システムのVPNインターフェースを使って端末の通信を制御し、アプリごとにプロキシを経由するかどうかを指定できます。アプリ分割とドメイン分割は別の軸です。前者はどのアプリをクライアントに渡すか、後者は渡された後にどの経路を使うかを決めます。両者の設定が競合すると、ブラウザーは正常なのに特定のアプリだけ接続できないことがあります。

Apple のモバイルプラットフォーム向けクライアントも、システムのネットワーク拡張機能に依存します。バックグラウンド制御、省電力状態、ネットワーク切り替えが接続維持に影響する場合があります。Wi-Fiからモバイルネットワークへ切り替えた後、接続中に見えてもリクエストが停止するなら、まず再接続し、その後にサブスクリプション更新の必要性を確認してください。

1. サービス管理画面から、現在のクライアントに対応するサブスクリプションURLをコピーし、チャット履歴のスクリーンショットを見ながら手入力しないでください。
2. クライアントにリモート設定を追加し、読み込み結果にノードとポリシーグループが表示されることを確認します。
3. クライアントに対応するノードを選び、初回テストではプロトコルの既定パラメーターを維持します。
4. ルールモードを有効にし、一般的なウェブページを開いて基本接続を確認してから、特定のアプリをテストします。
5. ルールの問題を確認するときは、短時間だけグローバルモードへ切り替えて比較し、完了後にルールモードへ戻します。
6. サーバー設定が変更されたらサブスクリプションを更新します。更新に失敗した場合は、URLが完全か、ネットワークから設定サーバーへアクセスできるかを確認してください。

接続に失敗したときの切り分け方法

効果的なトラブルシューティングには、すべての項目を連続して変更するのではなく、比較しながら確認することが重要です。一度に1つの変数だけを変更すれば、問題の層を特定できます。まずローカルネットワーク、次にサブスクリプションとクライアント、その後にノード、プロトコル、回線、分割、DNSの順で確認します。クライアント、ノード、モードを同時に変更すると、接続が戻っても本当の原因が分かりません。

• ✅ プロキシを無効にし、ローカルネットワークから普段使うサービスへ正常にアクセスできることを確認します。
• ✅ サブスクリプションを更新し、ノード一覧が完全か確認します。クライアントに表示される読み込みエラーにも注意してください。
• ✅ クライアントが、ノードで使われているプロトコル、暗号化方式、転送パラメーターに対応していることを確認します。
• ✅ 同じクライアントで異なる回線へ切り替え、単一ノードの問題か設定全体の問題かを切り分けます。
• ✅ ルールモードとグローバルモードを比較し、ルール漏れの有無を判断します。
• ✅ システム時刻、証明書検証、DNS制御、仮想ネットワークインターフェースの権限を確認します。
• ✅ クライアントログにある名前解決、ハンドシェイク、タイムアウト、証明書エラーを確認してから、次の対応を決めます。
• ❌ エラーを消すために、証明書検証を長期的に無効にしないでください。
• ❌ 用途が分からないまま、輻輳制御、転送経路、基盤ルーティングのパラメーターを変更しないでください。

ログの「名前解決に失敗」は、通常DNSまたはドメイン設定を示します。「接続タイムアウト」は、ネットワーク到達不可、ポート制限、回線異常などが考えられます。「証明書エラー」では端末の時刻、サーバー名、証明書チェーンを確認します。「認証失敗」では、サブスクリプションの有効性、設定の完全性、クライアントが認証フィールドを誤って変更していないかを確認してください。

あるノードが一方のネットワークでは使えるのに、別のネットワークでは使えない場合は、通信事業者の経路、UDP対応、端末側の設定を重点的に比較します。同じクライアントで全ノードが失敗し、同じサブスクリプションが別の対応クライアントでは使えるなら、クライアントのバージョン、権限、制御方式の問題である可能性が高いでしょう。すべてのクライアントでサブスクリプションを更新できない場合は、まずURLと設定サーバーへの到達性を確認します。