VPN用語解説:サブスク、ノード、回線種別、プロトコルを一度に整理

サブスク、ノード、回線種別、プロトコル、ルーティング、グローバル/ルールモード。この6つの言葉はクライアントの画面やプラン説明に何度も出てくるのに、まとめて説明してくれる場所はほとんどありません。本記事では「契約から接続まで」の順に一つずつ分解し、それぞれに一言定義・見分け方・実際につまずきやすいポイントを添えます。

この用語解説はアルファベット順ではなく、1回の接続で起きる順番に沿って書いています。まずノード一覧を受け取り、次にどのサーバーへ接続するかを決め、そのうえでデータがどの経路を通るかを決め、最後に暗号化の話になります。この順番で理解すれば、6つの言葉が混ざることはありません。

なぜこの6つの用語は混同されるのか

どのクライアントを開いても、「サブスク」と「ノード」は並んで表示され、「回線種別」はプランページに書かれ、「プロトコル」はノードの詳細に隠れ、「ルーティング」は1画面分のスイッチになっています。言葉は知っていても、トラブル時にどの層の問題か言えないと、「ノードを変えてみる」を繰り返すしかなくなり、10個目でも直らないまま疲れてしまいます。

接続を4つの層に分けると、ぐっと整理しやすくなります。

  • アカウント層:サブスク。クライアントがどのノードを取得できるかを決めます。
  • 入口層:ノード。どのサーバーに、どのパラメータで接続するかを決めます。
  • 経路層:回線種別。データがローカルから接続先までどう進むかを決めます。
  • ハンドシェイク層:プロトコル。どう暗号化し、TCP と UDP のどちらを使うかを決めます。

ルーティングとグローバル/ルールモードはこの4層には入りません。これらはルーティング層の2つのスイッチで、前者は「どの通信をプロキシ経由にするか」、後者は「そのルールを有効にするかどうか」を決めます。

6つの用語早見表:一言定義と、困ったときに最初に見るポイント
用語一言定義困ったらまず見るもの
サブスククライアントがノード一覧を取得するためのリンクリンクが欠けていないか、他人に転送していないか
ノード1台のサーバーに接続するためのパラメータ一式アドレス・ポート・プロトコル・パスワードが設定と一致しているか
回線種別データがローカルから接続先までどう進むか夜のピーク時間に揺れないか、途中区間が公衆網かどうか
プロトコルクライアントとノードの間のハンドシェイクと暗号化の方式システム時刻、TLS、UDP が制限されていないか
ルーティングどの通信をプロキシ経由にし、どれを直結にするかルールの順序と、最後のフォールバックルール
グローバル/ルールモードクライアント全体のルーティングスイッチ誤ってグローバルにして、ルールが全部効かなくなっていないか

以下、この順番で見ていきます。

サブスク:1本のリンク、その実体はアカウント情報

サブスク(subscription)は1本の URL です。クライアントは一定間隔でこの URL にリクエストを送り、ノード一覧を受け取ります。base64 でエンコードされた ss://、vmess://、trojan://、vless://、hysteria2:// のリンク群か、Clash / mihomo がそのまま読める YAML 設定です。「サブスクをインポートする」とは、この URL をクライアントに渡すことで、あとはクライアントが自分で処理します。

見落としやすい3つのポイント:

  • サブスクの更新は丸ごと置き換えです。クライアントがリンクを再取得し、サーバーが返した内容で上書きされます。手動で変えたノード名・並び順・メモは、更新1回で消えます。
  • サブスクにはアカウント状態が含まれることがあります。一部のサーバーはレスポンスヘッダに有効期限と使用済み通信量(subscription-userinfo)を付け、クライアントがそれをトップ画面に表示します。このヘッダへの対応度はクライアントごとに違い、表示されないからといって無いとは限りません。
  • 取得失敗と接続できないは別の問題です。サブスクの取得失敗は、リンクがチャットアプリで途中で切れた、端末の時刻のずれが大きくて TLS ハンドシェイクに失敗した、現在のネットワークからパネルのドメインに到達できない、といった原因がほとんどです。ノードに接続できないのは別の層の問題です。
サブスクリンクはアカウント情報そのもの この URL のトークンは、通常は二段階認証なしで全ノードを取得できます。他人に転送することは、アカウントごと渡すのと同じです。端末を変えるときは同じサブスクを使えばよく、個々のノードをコピーする必要はありません。

ノード:名前ではなく、接続パラメータの集合

ノード(node)とは、クライアントが接続先サーバーに接続するために必要なパラメータ一式です。アドレス、ポート、プロトコル、暗号化方式、パスワードまたは UUID、トランスポート層(TCP / WebSocket / gRPC)、TLS の有無と SNI、パス。どれか1つ欠けてもハンドシェイクは成立しません。

つまり「ノード名」と「ノード」は別物です。名前はラベルにすぎず、何に変えても接続できます。つながるかどうかを決めるのは上記のパラメータです。同じ接続先サーバーから複数のノードを派生させることもでき(ポート違い、トランスポート違いなど)、これが「ノード数」と「回線数」がよく合わない理由です。

ノードが使えるかどうかは、1回の速度測定だけで判断しないでください。連続で何度ハンドシェイクしても成功するか、夜のピーク時間に目立って速度が落ちないか、長時間接続(ビデオ会議や SSH セッション)が途中で切れないか。この3点のほうが単発のピーク値よりずっと参考になります。

回線種別:直結・中継・専用線の違い

回線種別が表すのは経路です。データがローカルを出てから接続先サーバーに届くまで、途中をどう通るかということです。

  • 直結:クライアントが接続先サーバーに直接つなぎ、全区間が公衆インターネットを通ります。コストは最も低く、夜のピーク時間には公衆網の混雑の影響を最も受けます。
  • 中継:まず中継入口に接続し、中継サーバーが接続先へ転送します。入口アドレスは差し替えられ、接続先はそのままです。直結よりは安定しますが、途中区間はやはり公衆網です。
  • IEPL 専用線:通信事業者グレードの国際イーサネット専用線で、途中区間は公衆インターネットを通らず、帯域は実質専有です。遅延と揺れを制御しやすく、コストは最も高くなります。
3つの回線種別の経路と向いている用途
種類経路特徴向いている用途
直結ローカル → 接続先、全区間が公衆網低コスト;夜のピーク時間は変動が大きい一時的な調べもの、軽いブラウジング
中継ローカル → 中継 → 接続先入口は差し替え可能で直結より安定;途中区間は公衆網日常のWeb閲覧、SNS、一般的なダウンロード
IEPL 専用線ローカル → 専用線入口 → 接続先、途中区間は公衆網を通らない遅延と揺れを制御しやすく、夜のピーク時間も比較的安定ビデオ会議、長時間接続、ストリーミング
まず回線、次にプロトコル。夜のピーク時間に重いかどうかは主に経路で決まります。プロトコルが解決するのは「どう暗号化し、どうハンドシェイクするか」であり、途中の公衆網の混雑は解決しません。逆に、良い回線でもプロトコルの設定を間違えればつながりません。

当サイトの回線とプラン情報はそのまま照合できます。90+ の国・地域、190+ の回線、同時接続端末は台数無制限、初回のお支払いから7日以内は理由を問わず返金を申請できます。

90+対応国・地域
190+回線
無制限同時接続端末
7日間理由を問わない返金

プロトコル:6つの主要なハンドシェイク方式の選び方

プロトコルは、クライアントとノードの間でどうハンドシェイクし、どう暗号化し、TCP と UDP のどちらを使うかを決めます。これは「暗号強度」の話とは別です。主要なプロトコルは外側の暗号化で十分ですし、体感を左右するのは伝送の特徴が、利用しているネットワーク環境に合っているかどうかです。

6つの主要プロトコル:伝送基盤・特徴・注意点
プロトコル伝送基盤特徴注意点
ShadowsocksTCP / UDP、AEAD 暗号化軽量でオーバーヘッドが小さく、対応クライアントが多い通信の特徴が出やすく、狙って識別されやすい
VMessTCP / WebSocket / gRPC、TLS を重ねられるV2Ray 系では定番のプロトコルで、多重化に対応検証が時刻に依存し、両端の時刻のずれが大きいとハンドシェイクに失敗する
VLESS通常は TLS(Reality を含む)を重ねる自身は暗号化せず、外側の TLS に任せるので1層分の負荷が減る設定項目が多く、SNI と偽装先を正しく組み合わせる必要がある
TrojanTLS通常の HTTPS 通信に偽装し、パスワード認証を使うドメインと証明書が必要で、パスワードが違うと即座につながらない
Hysteria2QUIC(UDP)弱い回線やパケットロスが多い環境でも動作するUDP に依存するため、UDP を制限・劣化させるネットワークでは不利
TUICQUIC(UDP)多重化によりハンドシェイクが速く、遅延が小さい同じく UDP の品質に左右される

3つの使い分け

  • ネットワークが UDP に寛容な場合:Hysteria2 と TUIC はパケットロス時に安定し、モバイル回線や長距離の国際回線に向いています。
  • ネットワークが UDP を制限している場合:TLS 系を優先してください。VMess + TLS、VLESS + Reality、Trojan はいずれも 443 番ポートを使えます。
  • 古い端末・古いクライアント:Shadowsocks の互換性が最も高く、ほぼすべてのクライアントが対応しています。
時刻同期は軽視できない VMess のハンドシェイクはタイムスタンプを検証するため、クライアントとサーバーの差が大きいとそのまま失敗します。症状は「ノードは利用可能と表示されるのに、いつまでもつながらない」というものです。この場合はまず端末の時刻を自動同期に設定し、そのうえで設定を見直してください。

ルーティング:どの通信をプロキシ経由にし、どれを直結にするか

ルーティング(routing)は順序付きのルール群です。クライアントは上から順に照合し、1つ一致した時点で止まります。そのため数より順序が重要です。

よく使うルールの種類:

  • DOMAIN / DOMAIN-SUFFIX / DOMAIN-KEYWORD:ドメインで照合します。
  • IP-CIDR / GEOIP:IP 範囲や地理的な所属で照合します。
  • PROCESS-NAME:プロセス名で照合します。デスクトップ版のみ対応です。
  • RULE-SET:外部のルールセットを参照し、まとめて管理できます。
  • MATCH(一部のクライアントでは FINAL):フォールバックルールで、必ず最後に置きます。
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,github,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

このルールの意味は次のとおりです。example.com とそのサブドメインは直結、ドメインに github を含むものはプロキシ経由、中国大陸の IP に解決されるものは直結、残りはすべてプロキシ経由。MATCH を1行目に移すと、それ以降のルールは一切実行されず、「ルールを書いたのにまったく効かない」という症状になります。

DNS リーク:ルーティングのもう半分

DNS リークとは、ドメイン名の解決リクエストがプロキシ経路を通らず、ローカルネットワークに渡ってしまうことです。影響は2つあります。どのドメインにアクセスしたかがローカル DNS に露出すること、そして解決結果が汚染され、誤ったアドレスを受け取る可能性があることです。

一般的な対策は、DNS の解決をプロキシ側に任せることです。fake-ip モードでは、クライアントがローカルで偽のアドレスを合成してアプリに返し、実際の解決は接続先側で行われます。代わりに、実 IP に依存するソフト(LAN 内の機器検出や一部のオンラインゲーム)が異常になることがあるため、そうしたドメインには直結ルールを追加するか、fake-ip-filter に入れる必要があります。

ルーティングのセルフチェック

  • ✅ 中国本土のサイトを開き、接続詳細が直結と表示されれば、ルールが正しく一致しています。
  • ✅ 海外のサイトを開き、接続詳細がプロキシ経由と表示されれば、フォールバックルールが効いています。
  • ❌ すべての通信がプロキシ経由と表示される場合、モードがグローバルのままでルールが照合に参加していないのが典型です。
  • ❌ 海外サイトが直結になっている場合、ルールの順序が逆か、フォールバックルールが欠けている可能性が高いです。
  • ❌ ドメイン解決が依然としてローカルの回線事業者側で行われている場合、DNS リークが疑われるので DNS 設定を確認してください。

グローバルとルールモード:2つのスイッチを混同しない

クライアントは通常3つのモードを用意しています:

  • グローバル:すべての通信がプロキシ経由になり、ルーティングルールはまったく効きません。
  • ルール:ルーティングルールに従って振り分けます。日常使いはこれ。
  • 直結:すべての通信がプロキシを通りません。

グローバルモードの最大の用途は切り分けであり、日常使いではありません。「このサイトだけ開けない」というときは、まずグローバルに切り替えます。グローバルで開けるなら、ノード・回線・プロトコルに問題はなく、原因はルール側です。グローバルでも開けないなら、原因はノードかネットワーク自体にあります。この順番で見れば、ノードを延々と替え続ける時間を大幅に減らせます。

各プラットフォームのクライアント:同じサブスクでも挙動は同じではない

サブスクは共通ですが、クライアントは共通ではありません。同じノード一覧でも、OS が違えば挙動がまったく違うことがあります。

  • Windows:Clash Verge Rev(mihomo コア)や v2rayN がよく使われ、システムプロキシと TUN モードを選べます。
  • macOS:ClashX Meta、Surge など。TUN モードにはシステム拡張の許可が必要です。
  • iOS:Shadowrocket、Stash などがシステム VPN 設定を通じて通信を引き受けます。バックグラウンド維持はシステムの制限を受け、長時間バックグラウンドに置くと切断されることがあります。
  • Android:Clash Meta for Android、v2rayNG など。初回接続時には VPN サービスの許可が必要です。
  • Linux:mihomo や sing-box のコアを systemd で動かす構成が一般的です。TUN モードには root または相当のネットワーク権限が必要です。

違いは4点に集約されます。対応プロトコルの範囲、ルーティングルールの書式、DNS の扱い方、TUN の権限です。クライアントを変える前に、いま使っているプロトコルに対応しているかを確認してください。QUIC 系プロトコルへの対応が遅いクライアントもあり、Hysteria2 のノードで試してつながらないとしても、ノード側の問題とは限りません。

6つの言葉をつなげる:1回の接続の全体像

  1. クライアントがサブスクリンクからノード一覧を取得します。
  2. 利用者がノードを選ぶと、クライアントがアドレス・ポート・プロトコル・パスワードを読み出します。
  3. 通信はまずルーティングルールを通り、プロキシ経由か直結かが決まります。グローバル/ルールモードは、そのルールを有効にするかどうかを決めます。
  4. プロキシ経由になった通信はプロトコルに従って暗号化され、回線種別が決めた経路を通って接続先に届きます。
  5. 接続先サーバーが復号して目的のサイトへアクセスし、データは同じ経路を戻ってきます。

この順番で切り分ければ、ほぼ回り道をせずに済みます。まずサブスクでノードを取得できるかを確認し、次にノードのパラメータが正しいかを見て、そのうえでモードが誤ってグローバルになっていないかを確認し、最後に回線とプロトコルを疑います。

よくある質問

サブスクを更新したらノードが全部変わったのですが、エラーですか?

いいえ。サブスクの更新は丸ごと置き換えなので、サーバー側でノード一覧が変わればそのとおりに反映されます。手動で変えた名前や並び順が上書きされるのも正常な動作です。

同じノードなのに、PC ではつながり、モバイルではつながらない?

まず両端のプロトコルとトランスポート層の設定が一致しているかを確認し、次にモバイル側のネットワークが UDP を制限していないかを見てください。QUIC 系プロトコルは UDP に依存しています。同じサブスクでも、クライアントによって解釈されるパラメータが微妙に違うことがあります。

グローバルモードでは開けるのに、ルールモードでは開けない?

ノード自体に問題はなく、原因はルーティングルールです。ルールの順序、フォールバックルールの有無、そして対象ドメインが誤って直結リストに入っていないかを確認してください。

TUN モードは必ず必要ですか?

いいえ。システムプロキシはシステムプロキシ設定に従うアプリしか扱えません。TUN モードはネットワーク層で引き受けるため、システムプロキシを認識しないプログラムもカバーできますが、より高い権限が必要で設定も複雑です。用途に合わせて選べば十分です。

6つの言葉、4つの層と2つのスイッチ。サブスクはアカウント、ノードは入口、回線種別は経路、プロトコルはハンドシェイクを担当します。ルーティングはどの通信をプロキシ経由にするかを、グローバル/ルールモードはルールを有効にするかどうかを決めます。トラブル時は層を順に下りていくほうが、ノードを替え続けるよりはるかに効率的です。
初月無料