VPNの基本用語:ノード・回線種別・プロトコル・グローバル/ルールモード

サブスクリプション、ノード、IEPL 専用線、プロトコル、通信の振り分け、グローバルモードとルールモード。初心者が混同しやすい用語をまとめて解説します。

サブスクリプションを読み込んだ後、なぜノードやルールモードを選ぶ必要があるのでしょうか。VPN用語の要点は、サブスクリプションが設定を提供し、ノードが接続先を指定し、回線が通信経路を示し、プロトコルが通信方式を定め、振り分けルールが通信の行き先を決めることです。それぞれ役割が異なり、互いに置き換えることはできません。

日常会話では、プロキシのサブスクリプションもシステム全体のVPNも、まとめてVPNと呼ばれることがありますが、技術的な範囲は同じではありません。プロキシクライアントが扱うのは、システムプロキシに従うアプリだけの場合もあれば、仮想ネットワークインターフェースを通じてより多くの通信を扱う場合もあります。そのため、画面に「接続済み」と表示されても、端末上のすべての通信が同じ経路を通っているとは限りません。

サブスクリプション、ノード、クライアントとは?

クライアントは、設定を読み込み、接続を確立し、通信を振り分けるソフトウェアです。ノードは通常、クライアントで選択できる接続設定のひとつで、サーバーアドレス、ポート、認証情報、プロトコルのパラメーターなどが含まれます。ノード名は識別しやすくするためのラベルであり、実際のネットワーク経路をすべて示すとは限りません。

サブスクリプション URLは、ノード一覧や設定一式を取得するための入口です。クライアントがURLを読み込むと、対応する情報を取得できます。接続成功を証明するものでも、特定の回線そのものでもありません。サーバー側で設定が変更された場合、変更後のアドレスやルールを反映するには、通常クライアントでサブスクリプションを更新する必要があります。

設定の取得元・接続先・実行ツールを区別する
用語 役割 これだけでは判断できないこと
サブスクリプション URL ノードや設定情報をクライアントに提供する プランの有効性や現在の接続状態を示すものではない
ノード 接続先と認証情報、プロトコルのパラメーターを指定する 名前だけでは物理的な所在地や実際の速度はわからない
クライアント 接続、プロキシの入口、振り分け設定を実行する インストールしただけでは、端末の通信がクライアントに取り込まれたとは限らない
ポリシーグループ ノードをまとめ、設定に応じて手動または自動で選択する 自動選択でも、対象サイトで最適な使用感が得られるとは限らない

「サブスクリプション」は、プランの利用契約を指す場合もあります。文脈に応じて意味を確認しましょう。「サブスクリプションを更新」は通常、設定の再読み込みを指し、契約の更新ではありません。一方、「サブスクリプションの期限切れ」はアカウントの利用権が終了したことを指す場合があります。このような表示が出たら、クライアントでの更新結果とアカウントのプラン状態をそれぞれ確認してください。

サブスクリプション URLにはアクセス用トークンが含まれることが多いため、認証情報と同様に扱ってください。フォーラムへの投稿、スクリーンショットへの掲載、見知らぬオンライン変換ツールへの入力は避けましょう。漏えいが疑われる場合は、アカウントのリセット機能でURLを再発行し、各端末の設定を更新してください。無効になる範囲はサービスの案内をご確認ください。

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

直接接続は通常、端末が利用中の通信事業者のネットワークを経由して、海外サービスの入口へ直接接続する方式を指します。国内の転送用入口は追加しません。経路の混雑状況や国際接続の品質は、利用中のネットワークや通信事業者のルーティングにも左右されます。直接接続だから暗号化されない、という意味ではありません。暗号化方式は接続プロトコルとその設定によって決まります。

中継接続では、接続経路に転送サーバーを加え、端末からまず入口に接続し、そこから次のサーバーへ通信を転送します。変わるのは経路の構成です。入口が近ければ一部の通信が改善することもありますが、中継ノードの負荷や帯域、以降の経路も重要です。入口までの距離だけで判断しないようにしましょう。

IEPLは一般に、国際イーサネット専用線を指し、通信を運ぶ回線の概念です。サービス事業者が一部の国際経路にこうした専用線を利用することはありますが、クライアント上の「IEPL」という表示だけでは不十分です。回線の説明も確認してください。端末から入口まで、また出口から接続先サイトまでの各区間が、すべて専用線とは限りません。

「接続地域」と「出口地域」も区別が必要です。前者は端末が接続する入口の所在地、後者は通常、接続先サイトに表示される送信元ネットワークの所在地を指します。地域ラベルが両方を示すとは限りません。また、サイトへのアクセス可否はアカウントの地域、コンテンツの利用許諾、出口アドレスの判定などにも左右されます。

判断のポイント:回線種別は通信経路、プロトコルは通信方式を表します。専用線の名称だけから、速度やプライバシー保護の向上、特定サイトへの対応を判断することはできません。回線を選ぶ際は、用途に合わせて経路全体と実際の通信状況を確認しましょう。

Shadowsocks などのプロトコルが決めること

プロトコルは、クライアントとサーバーがどのように認証し、データをカプセル化して送信するかを定めます。接続を確立するには、クライアントが対象のプロトコルと個別のパラメーターに対応している必要があります。プロトコル名は速度のランクでも、プライバシー保護の総合評価でもありません。実装のバージョンやサーバー設定、ネットワーク環境によって結果は変わります。

  • Shadowsocks:暗号化プロキシプロトコルです。クライアントとサーバーでアドレス、ポート、パスワード、暗号化方式を一致させる必要があります。実装によって、拡張機能への対応状況は異なる場合があります。
  • VMess:認証と暗号化の仕組みを備えたプロキシプロトコルで、複数の通信方式と組み合わせて利用できます。ノード設定をコピーする際に通信パラメーターが抜けると、接続できないことがあります。
  • Trojan:通常、TLSを使ってプロキシ接続を確立します。証明書の検証、サーバー名、認証パラメーターを正しく設定してください。証明書の検証を無効にすることを、一般的な修復方法として扱わないでください。
  • VLESS:軽量なプロキシプロトコルで、単体ではペイロードを暗号化しません。通常はTLSなどの安全な通信方式と組み合わせて利用します。名称だけでは、接続全体がどのように保護されているか判断できません。
  • Hysteria2 と TUIC:どちらもQUICベースの通信方式を採用しており、UDP通信が利用できる環境を必要とします。ネットワークでUDPが制限されている場合は、利用可能な別の接続方式への切り替えが必要になることがあります。

ここで紹介したのは一般的なプロトコルの説明であり、VPNCGがすべてのプロトコルを提供するという意味ではありません。実際に利用できる設定は、アカウントで提供される内容とクライアントの対応状況をご確認ください。読み込み時に「未対応の形式」と表示されたら、ノードが無効だと判断する前に、クライアントのコアとサブスクリプション形式を確認しましょう。

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

ルールモードでは、ドメイン名、接続先アドレス、アプリなどの条件に応じて、通信をプロキシ、直接接続、拒否などに振り分けます。クライアントによって利用できる条件は異なります。また、多くの場合ルールは上から順に適用されるため、先にある広い条件のルールが、後続の詳細なルールより優先されることがあります。

グローバルモードでは通常、クライアントがすでに取り込んだ通信を、選択中のプロキシポリシーにまとめて渡します。重要なのは「すでに取り込んだ」通信だけが対象という点です。システムプロキシに従わないアプリ、除外対象のアプリ、仮想ネットワークインターフェースに入っていない通信は、引き続きこのモードの対象外となる場合があります。グローバルモードでも、端末全体の通信が必ずプロキシ経由になるわけではありません。

直接接続モードでは通常、クライアントが取り込んだ通信を、リモートプロキシを経由せず接続先へ直接送ります。「直接接続モード」と「直接接続回線」は別の概念です。前者はルーティングの動作、後者は端末からサービスの入口までの経路種別を指します。画面に「直接接続」と表示された場合は、どの項目にある表示なのかも確認しましょう。

普段は用途に合ったルール設定を使うとよいでしょう。特定のサイトで問題が起きた場合は、一時的にグローバルモードへ切り替えて比較できます。グローバルモードでは接続でき、ルールモードでは失敗するなら、適用されたルールや名前解決の結果を確認してください。どちらでも失敗する場合は、ノード、ネットワーク、接続先サービスを引き続き確認します。比較は原因の範囲を絞るのに役立ちますが、それだけで故障原因を特定できるわけではありません。

DNSリークと出口アドレスの関係

DNSはドメイン名をアドレスに変換する仕組みです。Webの通信がプロキシ経由でも、名前解決の通信まで同じ経路を通るとは限りません。名前解決はシステム、ブラウザー、クライアント、アプリ自身が行う場合があり、それぞれ異なるDNSリゾルバーや通信経路を使うことがあります。

一般にDNSリークとは、本来想定したトンネルやプロキシ経路を通るはずのDNSリクエストが、別の経路でリゾルバーに届く状態を指します。検索したドメイン名が露出したり、通信の振り分けが想定と異なったりする可能性があります。ただし、検査ページでDNSリゾルバーの地域と出口地域が異なっていても、それだけでリークがあるとは断定できません。設定とリクエストの経路も確認しましょう。

暗号化DNSが保護するのはDNSリクエストの通信経路であり、そのリクエストがプロキシ経由になることまで自動的に保証するものではありません。ブラウザーで個別に暗号化DNSを有効にすると、クライアントが想定する名前解決の流れを通らない場合もあります。原因を調べる際は、ブラウザー、クライアントのDNSポリシー、システムの設定をあわせて確認してください。Webページに表示される出口アドレスだけで判断しないようにしましょう。

プロキシ接続とWebサイトのHTTPSは、それぞれ異なる区間を保護します。重要なアカウントにアクセスする際は、ドメイン名と証明書の警告を確認してください。出口アドレスが変わっても、ログイン済みのアカウントがサイトに識別されなくなるわけではありません。また、すべてのアプリの通信がプロキシに入ることを意味するものでもありません。

プラットフォームによって接続結果が異なる理由

WindowsやmacOSのクライアントには、システムプロキシの設定機能がよくあります。一部のクライアントではTUNモードも利用できます。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、通常は必要な権限を求めます。ルーティングやDNSに影響することもあります。通信を取り込む範囲は広がりますが、除外対象、プロトコル対応、ルーティングの挙動は実装によって異なります。

Androidのクライアントは、システムのVPNインターフェースを通じて通信を取り込み、アプリごとの振り分けに対応する場合があります。iOSやiPadOSのクライアントは通常、システムのネットワーク拡張機能を使って動作します。似た名前のスイッチでも、各プラットフォームで同じルール機能を利用できるとは限りません。バックグラウンド動作の制限、ネットワークの切り替え、ほかのネットワークツールも接続に影響することがあります。

Linuxでは、GUIクライアントを使う場合もあれば、コマンドラインのコアを実行する場合もあります。コアを起動しただけでは、デスクトップのプロキシやシステムルートが自動設定されないことがあります。複数のプラットフォームで問題を調べる際は、ノード名だけを比べるのではなく、「通信がどのようにクライアントへ入るか」を確認してください。クライアントの入手先と設定方法は使い方ガイドをご覧ください。

サブスクリプションの読み込みから接続確認まで

  1. 設定の入手元を確認する。アカウントにログインし、公式の提供ページからクライアントに対応したサブスクリプションを取得します。プランの状態、サブスクリプションの形式、クライアントの対応状況は、それぞれ個別に確認してください。
  2. 読み込んだ結果を確認する。クライアントが設定を読み込めたか、選択可能なノードが表示されているかを確認します。「URLを保存しました」という表示を「設定のダウンロードに成功した」と取り違えないようにしましょう。
  3. ノードとモードを選ぶ。用途に合ったノードとルール設定を選び、システムプロキシまたはプラットフォームに対応した通信の取り込み方法を有効にします。複数のネットワークツールが同時にルーティング設定を変更しないようにしてください。
  4. 実際のアプリで動作を確認する。Webページと対象アプリがそれぞれ利用できるか確認し、必要に応じて接続ログでルールの適用状況、名前解決の失敗、ハンドシェイクエラーを調べます。ログを共有する前に、認証情報とサブスクリプション URLを削除してください。
  5. 症状から原因の範囲を絞る。ノードが表示されない場合はサブスクリプションを確認します。ノードはあるのにハンドシェイクに失敗する場合は、ネットワークとプロトコルを確認します。Webは使えるのに特定のアプリが使えない場合は、通信が取り込まれているかを確認します。特定のサイトだけで問題が起きる場合は、ルールと接続先サービスを確認しましょう。

クライアントに表示される「遅延」は、特定の測定先と方法に基づく値であり、ダウンロード速度やビデオ会議の品質にそのまま換算できるものではありません。測定に成功しても確認できるのは、そのテストを通過したことだけです。連続通信の状態、パケットロス、ジッター、接続先サービスの状況によって、実際の使用感は異なる場合があります。

  • ✅ サブスクリプションの更新は設定の同期です。プランの変更が必要かどうかは、アカウントの利用権を確認してください。
  • ✅ ノードを切り替えたら、同じアプリと近いネットワーク環境で比較し、複数の設定を同時に変更しないようにしましょう。
  • ❌ ノード名に地域、専用線、プロトコルの名称が含まれていても、あらゆる用途に適しているとは限りません。
  • ❌ サブスクリプションの認証情報を公開したり、証明書の検証を無効にすることを標準のトラブルシューティング手順にしたりしないでください。

初心者向けの確認順:まずサブスクリプションが正しく読み込まれているか、次にノードが接続できるか、続いてアプリの通信がクライアントに入っているかを確認し、最後にルールとDNSを調べます。すべての設定を何度も変更するより、段階ごとに確認するほうが問題を特定しやすくなります。

サービスを選ぶ際は、回線の説明、料金ルール、サポート窓口もそれぞれ確認しましょう。用語は仕組みを説明するものであり、根拠の代わりにはなりません。接続の問題をさらに調べる場合は、まずヘルプセンターをご確認ください。その後、アカウントの問い合わせフォームから、個人情報を伏せたエラー情報と再現手順を送信できます。

無料で始める