ネットワーク知識 約9分

サブスク・ノード・プロトコルとは？VPN初心者向け用語集

サブスクリプション、ノード、IEPL専線、中継と直結、プロトコル、ルール分割、グローバルモードとルールモード。クライアントで頻繁に見かける一方、詳しく説明される機会は多くありません。本記事では利用の流れに沿って一つずつ解説し、読み終えた時点で自分で設定できる状態を目指します。

VPNを初めて設定するとき、ボタンの位置より混乱しやすいのが「サブスクリプション・ノード・プロトコル」の違いです。簡単に言えば、サブスクリプションは設定をクライアントへ渡す仕組み、ノードは選択できる接続先、プロトコルはクライアントとサーバーの通信方式を指します。IEPL専線、中継、直結、ルールモード、DNS設定によって、データの経路や適用対象、ドメインの名前解決先も変わります。

これらは関連していますが、互いに置き換えられるものではありません。サブスクリプションの取り込みに成功しても、現在のノードが必ず接続できるとは限りません。ノード名が同じでも経路構成が同じとは限らず、新しいプロトコルが常にあらゆるネットワーク環境に適しているわけでもありません。それぞれの役割を理解するほうが、クライアントを何度も変えたり、設定を手当たり次第に変更したりするより効果的です。

サブスク・ノード・プロトコルはそれぞれどの層にある？

1回の接続を「設定を取得する」→「接続先を選ぶ」→「決められた方式でデータを送る」という流れとして考えると分かりやすくなります。サブスクリプション、ノード、プロトコルは、それぞれこの過程に対応します。クライアントは設定を実行するツールで、回線はデータが実際に通るネットワーク経路です。

用語 実際の意味 よくある誤解 利用時の確認ポイント
サブスクリプション サービス側が提供する設定情報の集合。クライアントはサブスクリプションURLからノードや関連パラメータを読み込みます。 サブスクリプションを通信プロトコルの一種だと思う。 URLが正しいか、更新できるか、安全に管理されているか。
ノード クライアントで選択できる接続設定。通常はサーバーアドレス、ポート、プロトコル、認証情報を含みます。 ノード名がサーバーの完全な物理的位置を示すと思う。 対象地域、経路の種類、現在のネットワークでの接続状況。
プロトコル クライアントと遠隔サービスの間で使う通信方式と認証ルール。 プロトコル名だけで速度や安定性を判断する。 クライアントの対応状況、ネットワークとの互換性、伝送層とセキュリティ設定。
回線 ローカルネットワークから遠隔側の出口まで、データが実際に通るルートと伝送方式。 回線とノードを完全に同じ概念として扱う。 直結・中継・専線の構成、夜間の混雑、ルートの変化。
クライアント 設定を読み込み、接続を確立し、トラフィックを振り分け、DNSを処理するローカルプログラム。 すべてのクライアントで項目名と初期動作が完全に同じだと思う。 システム権限、カーネル対応、ルールモード、更新方法。
要点：サブスクリプションは設定の入口、ノードは接続対象、プロトコルは通信の取り決め、回線はデータが実際に通る経路です。トラブル時は、まずどの層で問題が起きているかを確認します。

サブスクリプションURLの取り込みと更新方法

サブスクリプションURLは、通常サービス側で発行される専用アドレスです。クライアントがアクセスすると、ノード一覧、プロトコルのパラメータ、グループ情報を取得し、選択可能な設定へ変換します。人が読む通常のウェブページというより、「設定情報の取得元」に近いものです。

サブスクリプションURLにはアカウント設定を識別する認証情報が含まれることがあるため、フォーラムやスクリーンショット、共有ドキュメントに公開するのは避けてください。URLを入手した第三者がノード情報を読み取る可能性があります。別の端末で使う場合は信頼できる方法で共有し、使わなくなったクライアントからは古い設定を削除しましょう。

取り込み方法はクライアントによって異なります。一般的な項目には「URLから取り込む」「リモート設定を追加」「サブスクリプション管理」「クリップボードから取り込む」などがあります。サービスがQRコードを提供している場合も、単一ノードではなくサブスクリプション設定を読み取るものか確認してください。単一ノードの取り込みでは、その後の回線変更が自動反映されないことがありますが、サブスクリプションを更新すればサービス側の変更を同期できます。

  • ✅ サービスの管理画面からサブスクリプションURL全体をコピーし、先頭やパラメータ、末尾の文字が欠けないようにする。
  • ✅ クライアントでリモートサブスクリプションまたはURL取り込みを選び、不完全なノードを手動で作成しない。
  • ✅ 取り込み後に更新を実行し、選択可能な地域と回線が一覧に表示されることを確認する。
  • ✅ ノードを選んで接続を開始し、通常のウェブページで基本的なアクセスが正常か確認する。
  • ✅ サービス側で回線が変更された場合は、古い設定のポートを繰り返し変更する前にサブスクリプションを更新する。
  • ❌ サブスクリプションURLを公開ページに掲載したり、出所の不明なオンライン変換ツールに渡したりしない。

クライアントがサブスクリプションを更新すると、サブスクリプション内のローカル変更がリモート側の内容で上書きされることがあります。ルールだけを調整したい場合は、クライアントのローカル上書き、ルールセット、独立した設定機能を優先してください。サブスクリプションから生成されたノードのパラメータを直接編集すると、次回更新時に元へ戻ることがよくあります。

ノードと回線が別の概念である理由

クライアント一覧の各項目は、通常ノードと呼ばれます。ノード設定には少なくとも遠隔アドレス、ポート、プロトコル、認証情報が必要で、伝送方式、TLSドメイン、サーバー名表示、輻輳制御、UDP設定などが含まれる場合もあります。ノード名は識別しやすくするためのラベルにすぎず、技術仕様の全体を示すものではありません。

回線が示すのはネットワーク上の経路です。同じ地域でも異なる経路のノードを提供でき、1つの入口からサービス側で別の出口へ転送されることもあります。そのため「特定地域のノードを選んだ」ことは、想定される出口またはサービス上の地域を示すだけで、途中でどの通信事業者やネットワークを通るかを名前だけから判断することはできません。

ノードを選ぶときは、まず対象サービスの地域を確認し、次に現在の接続が安定しているかを見ます。ウェブ閲覧ではハンドシェイクの成功率と応答の継続性、動画再生では持続的なスループットと揺らぎ、音声・会議・リアルタイム通信ではパケットロス、揺らぎ、迂回経路の影響を重視します。1回だけ測った遅延値は参考にとどまり、継続利用時の実性能に代わるものではありません。

遅延が低くても通信が不安定になる理由

クライアントの遅延テストは通常、特定の測定先や1回のハンドシェイクだけを確認します。対象サイト、DNS名前解決、実際の通信負荷、長時間接続の維持までは反映されないことがあります。短時間の測定では高速でも継続通信中に混雑する回線がある一方、測定値は普通でも対象サービスへの経路が安定している場合があります。

したがって回線選びは、対象地域に合っているか、安定して接続できるか、対象アプリを継続利用できるかを確認したうえで、最後に表示された遅延を比較する順番がおすすめです。一覧の最小値だけを追うと、目的に合わないノードへ頻繁に切り替えることになりかねません。

回線選びの結論：ノードはクライアント内の設定項目、回線はその背後にあるネットワーク経路です。名称と遅延表示は初期選別に使い、最終的には対象アプリでの安定性を基準にします。

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICの違いを理解する

プロトコルはクライアントとサーバーがデータを認証・カプセル化・転送する方法を決めます。ただし実際の使い心地は、サーバー負荷、ルート品質、伝送層、クライアントの実装、ローカルネットワークにも左右されます。プロトコル名だけで「速い」「安全」と決めつけたり、サービス側の設定を把握せずに項目を置き換えたりしないでください。

プロトコル 主な特徴 設定時の確認点 適用場面の目安
Shadowsocks 構成が比較的シンプルで、事前共有鍵と指定された暗号方式を使ってプロキシ通信を転送します。 暗号方式、パスワード、サーバーアドレス、ポートをサービス側と一致させる必要があります。 対応クライアントが多く、設定が明確でネットワーク互換性に問題がない環境に適しています。
VMess 認証機能と豊富な伝送構成を備え、WebSocket、TCP、TLSなどと組み合わせて使われることがあります。 ユーザーID、伝送方式、パス、ホスト名、TLS設定を完全に一致させる必要があります。 サーバー側の設定が整っている場合は安定して使えます。パラメータの一部だけをコピーしないでください。
Trojan 通常はTLS上で動作し、パスワードで認証します。証明書とドメインの検証が接続の重要な要素です。 サーバー名、証明書の有効性、パスワード、ポートを正しく設定する必要があります。 標準的なTLS接続との互換性が高いネットワーク環境に適しています。
VLESS 認証とプロトコル構成が軽量で、セキュリティは通常、TLS、REALITYなどの伝送セキュリティ層との正しい組み合わせに依存します。 ユーザーID、フロー制御、伝送層、セキュリティ層、サーバー名を混在させないでください。 サービス側から完全なパラメータが配布される、最新のクライアント環境に適しています。
Hysteria2 QUICとUDPを基盤とし、不安定な回線を想定した輻輳制御を備えています。 ローカルネットワークでUDPを安定して利用できるか、認証情報、TLSドメイン、帯域幅ポリシーを確認します。 UDP経路が良好な環境では高い性能を示す可能性がありますが、制限のあるネットワークでは接続できないことがあります。
TUIC 同じくQUICを基盤とし、低遅延の同時通信を想定した方式です。UDPへの到達性が前提になります。 クライアントのカーネルバージョン、認証パラメータ、証明書検証、UDP環境を確認します。 サーバーとクライアントが完全に対応し、UDP経路が安定しているネットワークに適しています。

プロトコルは名前を変更するだけでは変換できません。たとえばVLESSノードの種類をTrojanに変えても、サーバーが新しいハンドシェイクを自動的に受け入れることはありません。TLS検証を無効にすることも、一般的なトラブル解決策ではありません。サブスクリプションで配布されたパラメータは、通常そのまま使うべきです。サーバー設定を明確に把握している場合に限り、ノードを手動で作成・変更してください。

Hysteria2とTUICはいずれもUDPに依存しますが、「UDP対応」だからといって、どのネットワークでも安定して使えるわけではありません。オフィスネットワーク、公共ネットワーク、一部のルーターではUDPセッションが制限されることがあります。その場合は、TCPとTLSを使うノードのほうが接続しやすいことがあります。プロトコルは実際のネットワーク互換性を基準に選びましょう。

IEPL専線・中継・直結の違い

直結は通常、クライアントが遠隔ノードへ直接接続し、途中の経路を主に公衆ネットワークのルーティングに任せる方式です。構成はシンプルですが、通信事業者や地域をまたぐ際に迂回することがあり、公衆網の混雑やルート変更の影響も受けやすくなります。直結だから必ず経路が短いわけではなく、サービス側に追加の中継入口を設定していないことを指します。

中継回線は通常、近い場所やネットワーク条件のよい入口へ接続し、そこから対象の出口へ転送します。中継のメリットは、公衆網の一部の経路を最適化し、異なる通信事業者間で接続品質を安定させられる点です。一方で処理地点が1つ増えるため、入口と出口のどちらかに問題があれば接続へ影響します。

IEPLは国際イーサネット専線系サービスの一般的な呼称で、管理された専用伝送と拠点間接続を重視します。サービス上の「IEPL専線ノード」は、国際区間の一部に専線リソースを使うことを示す場合がありますが、端末から入口までのローカル接続や、出口から対象サイトまでの末端経路は通常のネットワークを通ることがあります。端末からすべてのサイトまで物理的に占有された専用経路だと考えないでください。

経路の種類 代表的な経路 主な特徴 選び方の目安
直結 ローカルネットワークから遠隔入口へ直接接続 構成がシンプルで、公衆網のルーティングの影響を受けやすい。 現在の通信事業者から対象地域への経路が良好な場合に、まず試します。
中継 ローカルネットワークから接続拠点へ進み、そこから出口へ転送 一部のネットワーク間経路を最適化できますが、接続拠点と出口の両方が安定している必要があります。 直結で迂回が発生する、揺らぎが大きい、通信事業者間で品質がばらつく場合に試します。
IEPL専線 ローカル接続後、管理された専線区間を通って遠隔ネットワークへ接続 基幹経路は比較的管理しやすい一方、ローカル接続と対象サイト側の末端経路も重要です。 継続的な接続と経路の安定性を重視する場合、ほかの回線と実際に比較します。

グローバルモード・ルールモード・直結の選び方

グローバルモードでは通常、クライアントが制御できる大部分の通信を現在のプロキシノードへ送ります。「特定のアプリがノード経由でなければ正常に使えないか」を確認しやすい一方、ローカルサービスやLAN機器、プロキシが不要なサイトまで遠隔経路を通ることがあるため、常用の初期設定に適しているとは限りません。

ルールモードでは、ドメイン、IP、アプリ、ルールセットに応じて、ノード経由、直結、拒否のいずれかを決めます。一般的には、ローカルやLANアドレスは直結、特定の国際サービスはノード経由、広告やリスクのあるドメインは拒否、どのルールにも一致しない通信は既定のポリシーへ渡す、といった構成です。日常利用に向いていますが、ルールの品質とDNS設定に左右されます。

直結モードは通常、リクエストをプロキシノード経由にしない設定です。ローカルネットワークのリソースへのアクセスや、クライアントが元のネットワークへ影響しているかの確認に使えます。ただし直結にしても、仮想ネットワークアダプター、DNS制御、システムプロキシ設定が残る場合があります。完全に停止するには、クライアントの接続停止機能を使ってください。

ルールが誤って適用される理由

ドメインルールは、ドメイン名が見えている段階で判定する必要があります。IPルールは名前解決の結果とアドレスデータベースに依存します。現在のウェブサイトは、メインドメインのほか、コンテンツ配信ネットワーク、ログイン用ドメイン、API用ドメインを同時に読み込むことが多いため、トップページだけをルール対象にすると、ページは開くのに画像、ログイン、動画が失敗することがあります。

このような場合は、一時的にグローバルモードへ切り替えて比較します。グローバルモードでは正常でルールモードだけ異常なら、ルールの適用状況、DNS名前解決、関連ドメインを重点的に確認します。両方で異常が出る場合は、ノード接続、プロトコルパラメータ、対象サービス自体を引き続き確認します。

モードの使い分け：日常利用では、適切に管理されたルールモードを優先します。トラブル時はグローバルモードと直結モードを比較に使いましょう。モード切り替えは原因を絞るための手段であり、回線品質の代わりにはなりません。

DNSリークと名前解決の異常とは？

DNSはドメイン名をネットワークアドレスへ変換します。DNSリークとは一般に、ドメイン検索をプロキシ経路や指定のリゾルバーで処理する想定なのに、リクエストがローカルネットワーク上の別の名前解決経路から送信される状態です。アクセス先ドメインの検索活動が露出したり、ローカルと遠隔側で異なる結果が返って地域判定の誤り、迂回接続、リソース読み込み失敗につながったりすることがあります。

DNSの問題は「まったく開けない」場合だけではありません。メインページは表示できても、API、画像、ログイン用ドメインが適切でないアドレスへ解決されることがあります。ノードを切り替えてもシステムキャッシュが結果を保持したり、ルールはドメインで判定するのにアプリが先にIPへ解決してしまい、想定したルールに一致しなかったりする場合もあります。

クライアントにある「リモートDNS」「プロキシDNS」「ローカルDNS」「システムDNS」「Fake IP」などの動作は、クライアントの実装によって異なります。リモートDNSは通常、プロキシ経由または遠隔側で名前解決する方式です。ローカルDNSは現在のネットワークが提供する解決経路に近い動作をします。Fake IPモードでは、まず対応するマッピングアドレスを返し、クライアントがドメインを復元してルールを適用します。ドメイン情報を保ちやすい一方、一部のLANサービスや特殊なアプリと互換性がないことがあります。

  • ✅ システムプロキシ、仮想ネットワークアダプター、クライアントのDNSモードが現在の設定目的と一致しているか確認する。
  • ✅ ノード切り替え後にクライアントの接続状態をリセットし、必要に応じてシステムのDNSキャッシュを更新する。
  • ✅ ページの一部リソースだけ失敗する場合は、関連ドメインに誤ったポリシーが適用されていないか確認する。
  • ✅ LAN機器にアクセスできない場合は、プライベートアドレスとローカルドメインが直結になっているか確認する。
  • ❌ システムDNSや仮想ネットワークアダプターを制御するネットワークツールを複数同時に起動しない。
  • ❌ トラブル対応のために証明書検証を長期間無効にしたり、出所の不明なDNSアドレスを無作為に使ったりしない。

各プラットフォームのクライアントで設定が異なる理由

WindowsとmacOSのクライアントでは、システムプロキシと仮想ネットワークアダプターの両方を提供することがよくあります。システムプロキシはOSのプロキシ設定に従うアプリへ主に作用しますが、一部のプログラムは迂回することがあります。仮想ネットワークアダプターはより広い通信を制御できる一方、対応するシステム権限が必要で、ほかのネットワークソフトとルーティングやDNSが競合しやすくなります。

Androidでは通常、システムのVPNインターフェースを使って通信を制御し、アプリ単位の振り分けを提供するクライアントもあります。省電力設定、バックグラウンド制限、ネットワーク切り替えは長時間接続に影響します。画面ロック後に接続が切れる場合は、ノードの障害と決めつける前にクライアントのバックグラウンド実行権限を確認してください。

Appleのモバイルプラットフォームも、システムが提供するネットワーク拡張機能に依存します。クライアントごとに対応プロトコルのカーネル、ルール形式、サブスクリプション変換方式が異なるため、デスクトップで取り込める設定をモバイル端末が完全に認識できるとは限りません。取り込み後にノードが欠けている場合は、まずクライアントが該当プロトコルと伝送方式に対応しているか確認します。

Linux環境では、GUIクライアント、コマンドラインのコア、環境変数によるプロキシ、透過プロキシを併用できます。ブラウザーではアクセスできるのに端末のコマンドが失敗する場合、両者が異なるプロキシ設定を読み込んでいることが一般的です。逆に、コマンドラインへプロキシ環境変数を設定しても、すべてのデスクトップアプリが同じ経路を通るわけではありません。

プラットフォーム間で移行する場合は、クライアント内部のデータベースをコピーするより、サブスクリプションを再度取り込む方法が安全です。ルール、証明書ストレージ、仮想ネットワークアダプターの権限、カーネルバージョンにはプラットフォームごとの差があります。まずクイックスタートガイドを読み、OSに合った接続方式を選びましょう。

接続できないときの確認手順

トラブル対応は、最も基本的な到達性から始め、範囲を少しずつ絞り込みます。一度に複数の項目を変更すると比較できなくなり、正常だったサブスクリプションを壊すこともあります。各操作の後には同じ対象へ再テストし、どの変更が結果に影響したか確認してください。

  1. ローカルネットワークを確認：クライアントを一時停止し、通常のウェブサイトにアクセスできるか確認します。基礎ネットワーク自体に問題がある場合、プロトコルを切り替えても解決しません。
  2. サブスクリプションを更新：サブスクリプションを更新できるか確認し、ノード一覧が完全に表示されるか確認します。更新に失敗する場合は、URL全体をコピーできているか、システム時刻が正しいかを確認してください。
  3. 同じ種類のノードに切り替え：まず同じプロトコルで別の地域または経路へ切り替え、問題が単一ノードに限られるのか、プロトコル全体に及ぶのかを判断します。
  4. 異なるプロトコルを比較：UDPベースの設定で接続できない場合は、サービス側が提供する別の互換プロトコルを試します。既存ノードを別のプロトコルへ手動で変更しないでください。
  5. ルールモードを切り替え：ルールモードで異常がある場合は、一時的にグローバルモードと比較します。グローバルモードだけ正常なら、通常はルールまたはDNSの確認が必要です。
  6. システム制御を確認：重複して動作しているプロキシ、仮想ネットワークアダプター、ネットワークフィルタリングツールを停止し、ルーティングとDNSが複数箇所で変更されないようにします。
  7. エラー情報を保存：クライアントログで、タイムアウト、認証失敗、証明書エラー、DNS失敗、UDP到達不可などの表示を確認します。サポートへ連絡する際は、単に「接続できない」と伝えるより、エラーの種類、プラットフォーム、ノード名を添えるほうが原因を特定しやすくなります。

用語を理解すると、設定の流れが明確になります。まずサブスクリプションを取り込んで更新し、ノード一覧から対象地域に合う回線を選びます。次にクライアントがサービス側から配布されたプロトコルパラメータで接続を確立し、ルールモードとDNS設定で通信の処理方法を決めます。異常が起きたら、サブスクリプション、ノード、プロトコル、回線、ルール、DNSの順に確認すると、クライアントを何度も再インストールするより効率的です。

初月無料