このVPN初心者向け用語集では、まず結論を簡潔に説明します。サブスクリプションは更新可能な接続設定の集合、ノードはクライアントで選べる接続先、回線はデータが実際に通るネットワーク経路、プロトコルはクライアントとサーバーが接続を確立・維持する方法を定めるものです。ルーティングは、どのリクエストを選択した回線に通し、どれをローカルネットワークのまま処理するかを決めます。

これらの用語はクライアント画面に同時に表示されることが多い一方、意味する層は同じではありません。混同すると、「サブスクリプションの更新」を「回線の切り替え」と取り違えたり、ノードが使えないときにクライアントを何度も再インストールしたりしがちです。正しくは、まずクライアントがサブスクリプションを読み込めることを確認し、次にノードで接続を確立できるかを確認します。その後、用途に応じて回線を選び、ルーティングとDNS設定が想定どおりかを確認します。

サブスクリプションリンクとは何か

サブスクリプションリンクは、クライアントが設定を読み込むためのアドレスです。サーバー側では、このアドレスを通じて複数のノード情報が提供され、クライアントがインポートすると選択可能な一覧に整理されます。ノード名、サーバーアドレス、ポート、プロトコルのパラメータ、認証情報などは通常サブスクリプションに含まれるため、ユーザーが一つずつ手入力する必要はありません。

サブスクリプションは継続的な接続そのものではありません。インポートに成功したのは、クライアントが設定を読み取れたという意味にすぎず、実際に接続ボタンを押したときに、クライアントがその中のノードを使ってセッションを確立します。また、サブスクリプションは通常のウェブページのブックマークでもありません。ブラウザに直接貼り付けると、エンコードされたテキストが表示されたり、設定ファイルがダウンロードされたり、読みにくい内容が返されたりしますが、これはリンクが無効だという意味ではありません。

インポート・更新・切り替えの違い

  • ✅ サブスクリプションをインポート:設定一式をクライアントに追加します。通常は初回利用時や再インストール後に一度行います。
  • ✅ サブスクリプションを更新:サーバーが公開したノード名、アドレス、パラメータを再取得し、回線の変更を同期します。
  • ✅ ノードを切り替え:すでにインポートした一覧から別の接続先を選びます。サブスクリプションを作り直すことはありません。
  • ✅ 接続を開始:現在のノードとルーティングモードに従い、条件に合うネットワークリクエストをクライアントで処理します。
  • ❌ サブスクリプションリンクをフォーラム、スクリーンショット、共有ドキュメントなどに公開して貼り付けること。サブスクリプションを識別する認証情報が含まれている可能性があります。

サブスクリプションを更新すると、クライアントが古いノードを残す場合もあれば、新しい一覧で上書きする場合もあります。具体的な動作はソフトウェアの実装によって異なります。一覧が明らかに古い場合は、すべての設定を削除して何度もインポートするのではなく、まずクライアント内蔵の更新機能を使ってください。削除する前に、カスタムルーティングルールがサブスクリプション設定と同じファイルに保存されていないかも確認し、一緒に失わないようにします。

結論:サブスクリプションは「設定をクライアントに届ける」もので、ノードは「選択可能な接続先」を提供します。インポートに成功してもアクセスできない場合は、サブスクリプションのアドレスだけでなく、ノード、システムプロキシ、ルーティング、DNSも確認しましょう。

ノード・サーバー・回線の違い

ノードは、ユーザー向けの接続項目です。通常はサーバーアドレス、プロトコル、必要なパラメータを含みますが、必ずしも独立した物理サーバー1台に対応するわけではありません。複数のノードが同じ基盤上で提供されることもあれば、異なる入口から異なる出口へ接続することもあります。そのため、ノード数を物理サーバー数と同一視したり、ノード数だけで利用感を判断したりすることはできません。

サーバーは、計算処理とネットワーク機能を提供する機器またはインスタンスです。回線は、クライアントから入口を経由して出口に至るまでのデータ経路を指します。同じ出口地域でも、直接接続、中継、IEPL専用線など異なる経路が存在します。表示される地域が同じでも、ネットワーク間の安定性、混雑時の挙動、障害時の切り替え方法は異なる場合があります。

用語 主な意味 ユーザーに通常表示されるもの これだけでは直接判断できないこと
ノード クライアントで選択できる接続設定 地域、名前、プロトコル、回線の表示 実際の物理サーバー数
サーバー 接続と転送を処理する基盤 基盤の構成全体が表示されるとは限らない 国境をまたぐ経路の安定性
回線 ローカルから入口・出口までのデータ経路 直接接続、中継、専用線などの種類 すべての時間帯で一定の速度が出ること
出口 対象サイトから見たリクエストの送信元ネットワーク位置 出口地域と検出されたグローバルIP クライアントから入口までの完全な経路

直接接続、中継、IEPL専用線

直接接続は、クライアントから遠隔サーバーの入口へ直接つなぐ方式です。経路がシンプルで追加の転送段階も少ない一方、実際の挙動はローカル通信事業者や国際ネットワークの状況に左右されます。ネットワーク間のルート変更や混雑時には、同じノードでも状態が変動することがあります。

中継回線では、まず近い、または相互接続条件のよい入口に接続し、そこから中継ネットワークを経由して出口へ送ります。価値は前半部分の経路を調整し、ローカルネットワークから遠隔地へ直接接続する際に起こる不安定なルーティングを減らせる点にあります。中継がすべての直接接続より速いとは限らず、入口の位置、処理能力、その時点のネットワーク状況によって変わります。

IEPLは通常、企業向けの国際イーサネット専用線接続を指します。一般的な公衆ネットワーク経由の直接接続と比べ、管理しやすい国境をまたぐ伝送経路を重視します。ただし、クライアントから接続ポイントまでのローカルネットワークも利用感に影響し、サービス提供者の接続方法やトラフィックの割り当ても重要です。そのため、「専用線」という表示は回線構成の説明として理解し、どの環境でも変動しないという保証とは考えないでください。

よくあるプロトコル名の読み方

プロトコルは、クライアントとサーバーがデータをカプセル化、認証、転送する方法を定めます。初心者がすべての項目を暗記する必要はありませんが、プロトコルが互換性、接続方式、通信特性、ネットワークへの適応性に影響することは知っておきましょう。同じプロトコル名でも、サーバー構成、ルーティング、設定はサービスごとに異なるため、回線品質が同じとは限りません。

プロトコル 基本的な理解 主な確認ポイント
Shadowsocks 軽量な暗号化プロキシプロトコルで、幅広いクライアントに対応し、設定構造も比較的シンプル 暗号化方式をサーバー側と一致させる必要があり、古いクライアントでは新しい設定に対応していない場合がある
VMess V2Rayエコシステムでよく使われ、設定には認証、通信方式、安全性に関するパラメータが含まれる トランスポート層の設定を一致させる必要があり、サーバーアドレスだけをコピーしても接続できない
Trojan 通常はTLSと組み合わせて接続し、正しい証明書とドメイン設定が必要 システム時刻、証明書検証、サーバー名の設定がハンドシェイクに影響する
VLESS 比較的簡潔な認証・通信フレームワークで、他の通信方式やセキュリティ機構と組み合わせて使われることが多い 単独のパラメータではなく、クライアントが対応する組み合わせ全体をサポートしている必要がある
Hysteria2 QUICを基盤とする通信方式で、複雑なネットワーク環境でも有効な伝送を維持することを重視 ネットワークによるUDP制限が接続状況に直接影響する
TUIC 同じくQUICとUDPを基盤とし、並列転送と接続管理を重視 クライアントとサーバーのバージョン、認証、通信パラメータに互換性が必要

ShadowsocksはSSと略されることが多く、プロキシ通信の暗号化と転送を担います。VMessとVLESSはV2Rayまたは互換エコシステムでよく使われますが、認証方式とデータ構造が異なるため、名前が似ているからといって互換利用はできません。Trojanの設定ではTLSが関係することが多く、証明書のドメイン、サーバー名、システム時刻の異常が接続失敗の原因になる場合があります。

Hysteria2とTUICは、UDPを基盤とするQUIC技術を使用します。高遅延やパケットロスのある一部のネットワークでは適応しやすい可能性がありますが、会社や学校のネットワーク、ルーター、ローカルの通信環境がUDPを厳しく制限していると、正常に接続できないことがあります。その場合は、接続を何度も繰り返すより、TCPを使用する互換設定へ切り替えるほうが有効です。

プロトコルを選ぶ実用的な順番

  1. まずはサブスクリプションで標準推奨されているプロトコルを使いましょう。通常は現在のサーバー設定と一致しているためです。
  2. 接続に失敗したら、単一ノードの障害なのか、同じプロトコルの全ノードが接続できないのかを切り分けます。
  3. UDP系プロトコルが全般的に失敗する場合は、サブスクリプション内にあるTCPベースの互換回線を試します。
  4. TLSハンドシェイクのエラーが出る場合は、端末の時刻、証明書検証、ドメインパラメータ、クライアントのバージョンを確認します。
  5. 意味を理解しないまま通信方式、安全性、認証の項目を変更しないでください。どちらか一方でも一致しないと、接続に失敗する可能性があります。
結論:プロトコルは「どう送るか」、回線は「どこを通るか」を決めます。プロトコルを選ぶときは、まずネットワークとの互換性、次に実際の安定性を確認し、名称の新旧だけを基準にする必要はありません。

ルーティング・グローバルモード・ルールモードの選び方

ルーティングは、ドメイン、IP、アプリ、その他の条件に応じてリクエストの行き先を決める仕組みです。クライアントには通常、グローバル、ルール、ダイレクトなどのモードがありますが、ソフトウェアによって名称は多少異なります。重要なのはボタンの位置を覚えることではなく、「どの通信をプロキシで処理するか」を明確にすることです。

グローバルモードでは通常、クライアントが処理できるリクエストを現在のノードにまとめて通します。一時的な切り分けに適しており、ルールモードでは開けないサイトがグローバルモードで開ける場合、原因はノードよりもルールのマッチングやDNS解決にある可能性が高くなります。ただし、グローバルモードでも端末上のすべての通信が必ず対象になるわけではなく、クライアントの動作方式、システム権限、アプリ独自のネットワーク実装によって異なります。

ルールモードでは、条件に一致するリクエストをノードへ送り、それ以外はローカルから直接接続します。日常利用では通常、ルールモードのほうが適しています。ローカルサービスは迂回せず、海外サイトや特定のアプリはルールに従って処理できるためです。正確に動作するかどうかは、ルールセットの更新、ドメイン分類、DNS解決結果に左右されます。

ダイレクトモードは通常、プロキシ転送を一時的に停止するために使います。ただし、一部のクライアントではシステムプロキシや仮想ネットワークインターフェースが有効なままの場合があります。切り分け時はモード名だけでなく、ステータスバー、システムプロキシのスイッチ、仮想ネットワークインターフェースの状態も確認してください。

モード 通信の処理 適した場面 注意点
グローバルモード 処理対象のリクエストを現在のノードにまとめて送る 短時間のテスト、ルール漏れの切り分け ローカルサービスも迂回する可能性があり、長期的なルール管理の代わりにはならない
ルールモード ドメイン、IP、アプリの条件に応じてプロキシと直接接続を選ぶ 日常のブラウジング、開発ツール、ストリーミングの振り分け 古いルールでは新しいドメインやコンテンツ配信ドメインが漏れる可能性がある
ダイレクトモード リクエストをローカルネットワークで処理する 利用の一時停止、ローカルネットワークとの比較テスト クライアントの通信処理がモード変更だけで完全に停止するとは限らない

システムプロキシと仮想ネットワークインターフェースのモード

システムプロキシモードは、OSのプロキシ設定に従うアプリへ転送を提供します。ブラウザは通常利用できますが、一部のコマンドラインプログラム、ゲーム、独自のネットワークスタックを実装するアプリはシステムプロキシを無視することがあります。その場合は、アプリごとにプロキシ環境変数を設定するか、クライアントが提供する仮想ネットワークインターフェースモードを使います。

仮想ネットワークインターフェースモードは、TUNモードと呼ばれることが多い機能です。システムのネットワークインターフェースを通じて、より広範なIP通信を処理するため、システムプロキシ設定を読み取らないアプリにも適しています。一方で追加のシステム権限が必要になり、ファイアウォール、他のネットワークツール、企業のセキュリティソフト、既存の仮想ネットワークインターフェースとルーティングが競合しやすくなります。

DNSリークと名前解決の経路

DNSはドメイン名をネットワークアドレスに変換します。ノードに接続した後、ウェブリクエストは選択した回線を通っていても、ドメイン検索だけはローカルネットワークが提供するDNSで処理されることがあります。このように想定と異なる名前解決経路は、一般にDNSリークと呼ばれます。アクセスしたドメインの検索記録が露出する可能性があるほか、現在の出口に適さないアドレスが返され、アクセス異常につながることもあります。

ドメインに基づくルール振り分けでは、DNSが特に重要です。アプリが先にドメインをIPへ変換し、クライアントが最終的なIPしか確認できない場合、ルールが元のドメインに一致しない可能性があります。最近のクライアントには、DNSの引き受け、暗号化DNS、リモート名前解決、ルールに応じたリゾルバー選択などの機能がありますが、設定名は統一されていません。

DNSの問題を確認するときは、名前解決を誰が処理しているか、返されたアドレスが現在のネットワークに適しているか、ブラウザで独立したセキュアDNSが有効になっていないか、システム上で他のネットワークツールが同時に動作していないかを確認します。ブラウザ内蔵DNS、OSのDNS、クライアントのDNSが同時に存在すると、最終的な経路は画面上の一つのスイッチが示す内容と異なる場合があります。

  • ✅ クライアントのDNS設定が現在のルーティングモードに対応しているか確認します。接続スイッチをオンにするだけでは不十分です。
  • ✅ ブラウザが独自のDNS設定を使っていないか確認します。クライアントによるシステムレベルの設定を迂回する可能性があります。
  • ✅ ルールの適用結果に異常がある場合は、ルールとサブスクリプションを更新し、古いDNSキャッシュを削除してから再テストします。
  • ✅ グローバルモードとルールモードを比較します。ルールモードだけに異常がある場合は、まずドメインの一致条件と名前解決経路を確認します。
  • ❌ システムプロキシ、ルーティング、DNSを変更するクライアントを複数同時に有効にしないでください。競合により、切り分け結果を正しく評価できなくなります。

各プラットフォームのクライアントの違い

Windowsクライアントでは通常、システムプロキシと仮想ネットワークインターフェースの両方を利用できます。システムプロキシを使う場合は、ソフトウェア終了後にシステム設定が自動復元されるか確認してください。仮想ネットワークインターフェースを使う場合は、管理者権限、ファイアウォール、他の仮想ネットワークソフトに注意します。スリープ復帰やネットワーク切り替え後にアクセスできなくなった場合、古いルートやプロキシ状態が適切に復元されていない可能性もあります。

macOSはネットワーク拡張機能とシステム権限の管理が比較的厳格です。仮想ネットワークインターフェースやネットワーク拡張機能を初めて有効にするとき、権限の確認を求められることがあります。クライアントごとにネットワーク拡張機能の実装は異なり、同種のツールを複数同時に有効にするとルートが上書きされやすくなります。切り分け時は、現在使っているクライアントだけを一時的に起動してください。

Androidクライアントは通常、システムVPNインターフェースを通じて通信を処理します。システムのステータスアイコンはインターフェースが有効であることを示しますが、現在のノードが必ず接続できているという意味ではありません。省電力設定、バックグラウンド制限、ネットワーク切り替えによって長時間接続が中断されることがあるため、クライアントが必要なバックグラウンド動作を維持できるようにします。

iOSとiPadOSも、システムが提供するネットワーク拡張機能に依存します。アプリがバックグラウンドに入った後の接続状態は、システムとクライアントが共同で維持します。設定を正常にインポートできても接続できない場合は、まず設定が完全か、システムのネットワーク権限が許可されているか、別のネットワーク設定が同時に有効になっていないかを確認します。

Linuxでは、デスクトップ環境、ディストリビューションのネットワーク管理方式、コマンドラインツールによる違いが多くなります。ブラウザはデスクトップのプロキシ設定を読み取れても、端末プログラムでは独自のプロキシ環境変数が必要になることがあります。コンテナ、リモートセッション、サブシステムが独立したネットワーク名前空間を持つ場合もあり、ホストシステムのプロキシを自動的に引き継ぐとは限りません。

初心者向けの切り分け手順

  1. クライアントを有効にしていない状態で、ローカルネットワークから普段使うサービスへ正常にアクセスできることを確認します。
  2. サブスクリプションを更新し、同じ地域の別ノードを選んでテストし、単一ノードの状態を切り分けます。
  3. プロトコルの種類を切り替え、特定のプロトコルだけが非対応なのか、すべての接続が失敗するのかを確認します。
  4. グローバルモードで短時間の比較テストを行います。グローバルでは使えてルールでは使えない場合、ルールとDNSを確認します。
  5. 対象アプリがシステムプロキシを読み取るか確認します。読み取らない場合は、仮想ネットワークインターフェースやアプリ単位の設定を検討します。
  6. プロキシ、ルーティング、DNSを変更する他のツールを終了し、複数の設定が互いに上書きしないようにします。
  7. クライアントを再起動し、システムプロキシが復元されているか確認してから、クリーンな接続テストをもう一度行います。

用語を一連の流れとして理解する

正常な接続は次のように理解できます。クライアントがサブスクリプションリンクから設定を読み込み、一覧に複数のノードが表示されます。ユーザーがノードを選ぶと、クライアントはそのノードで指定されたプロトコルを使ってサーバーと接続します。回線がデータを対応する出口へ送り、ルーティングルールがどのリクエストをこの回線に通すかを決めます。DNS設定はドメインの解決方法を決め、ルールがリクエストを識別できるかどうかにも影響します。

サブスクリプションの更新に失敗すると、クライアントは新しい設定を取得できません。ノードの接続に失敗した場合は、ノードの状態、プロトコルの互換性、ローカルネットワークの制限が原因かもしれません。特定のサイトだけに異常がある場合は、ルーティング、DNS、出口地域、対象サイト自体を確認します。ブラウザは使えるのに他のアプリが使えない場合は、システムプロキシの処理範囲とプラットフォームの違いに注目します。

回線を選ぶときは、ノード名だけを見る必要はありません。ウェブ閲覧や開発ツールでは、接続の安定性、DNSの正確さ、長時間接続の維持が重視されます。動画視聴では帯域幅を継続的に消費し、対象プラットフォームのコンテンツ配信方針にも左右されます。オンライン会議では、ジッター、パケットロス、ネットワーク切り替えの影響を受けやすくなります。用途によって適した回線は異なります。

最終判断:サブスクリプションは設定の供給元、ノードは接続入口、プロトコルは通信方法、回線は実際の経路、ルーティングはリクエストの行き先、DNSはドメインの解決方法を決めます。問題が起きたときは、この流れに沿って段階的に確認するほうが、クライアントを何度も再インストールするより効果的です。