VPN初心者向けの用語は多く見えますが、まず理解したい関係は数えるほどです。サブスクリプションは設定をクライアントに渡し、ノードはクライアントから選べる接続先、回線種別はデータが出口に届くまでの経路、プロトコルはクライアントとサーバーの通信方法を示します。分割ルーティング、グローバルモード、ルールモードは、どの通信を接続経由にするかを決めます。これらを分けて考えると、インストールや回線選び、トラブル対応がずっとわかりやすくなります。
よくある誤解は、「ノード」「回線」「プロトコル」「クライアント」を同じものとして扱うことです。たとえば、1つのノードで VLESS を使いながら、中継回線として表示される場合があります。また、同じサブスクリプションを異なるプラットフォームの対応クライアントに取り込むこともできます。互いに関係はありますが、それぞれ解決する問題は異なります。
サブスクリプション、サブスクリプションURL、クライアントとは
サブスクリプションは料金期間ではなく、更新される設定リストです
プロキシクライアントの文脈でいう「サブスクリプション」とは、通常、サーバー側で管理される設定リストを指します。ノード名、サーバーアドレス、ポート、プロトコルパラメータ、認証情報、通信設定などが含まれることがあります。クライアントはサブスクリプションURLからこれらを取得し、選択可能なノード一覧に変換します。
したがって、「サブスクリプションを取り込む」ことは、ネットワークドライバーをインストールすることでも、接続が成功したことでもありません。完了するのは設定の読み込みだけです。その後、ノードを選び、接続を有効にし、システムの通信がクライアントに渡っているか確認する必要があります。取り込みはできるのにすべてのノードへ接続できない場合は、サブスクリプションの期限、クライアントのプロトコル対応、システム時刻、現在のネットワークによる通信制限を順に確認してください。
サブスクリプションURLには、アカウントやプランを識別できる認証情報が含まれることがあります。アカウントのパスワードと同じレベルで管理してください。完全なURLを公開スクリーンショット、フォーラム投稿、ブラウザーの同期メモ、共有ドキュメントに載せないでください。別の端末で使う場合は、公開経路で転送せず、信頼できるアカウント画面から再度コピーしてください。
サブスクリプションの更新と再取り込みの違い
「サブスクリプションを更新」は、クライアントが同じサブスクリプションURLへ再度アクセスし、サーバーが現在提供しているノードとパラメータを取得する操作です。回線名の変更、古いノードの削除、プロトコルパラメータの調整があった場合は、ローカル設定を手動で編集するより更新するほうが適しています。
「再取り込み」は、サブスクリプションを新しい設定元としてクライアントに追加する操作です。同名のサブスクリプションをどう扱うかはクライアントによって異なり、既存設定を上書きするもの、並べて保存するもの、ユーザーが作成したルールを残すものがあります。操作前に手動変更の有無を確認し、更新時にサブスクリプションの内容で置き換わらないようにしましょう。
- ✅ アカウント画面から完全なサブスクリプションURLをコピーし、URL内の文字を手動で削除・変更しない。
- ✅ クライアントで「URLから取り込む」または同等の項目を使用する。
- ✅ 取り込み後にまずサブスクリプションを更新し、ノード一覧が表示されるか確認する。
- ✅ ノード接続後、Webページ、DNS解決、よく使うアプリを個別に確認する。
- ❌ サブスクリプションのQRコード、完全なURL、認証情報を含む設定ファイルを公開しない。
- ❌ 「取り込み成功」を、そのまま「すべての通信が接続経由になった」と判断しない。
ノード、サーバー、出口IPの関係
ノードは、クライアントがユーザーに表示する論理的な接続項目です。少なくとも接続先とプロトコルパラメータを含みますが、ノード名が実際の物理サーバー名と一致するとは限りません。サービス提供者は地域、回線種別、用途に応じてノード名を付けたり、複数のノード入口でバックエンド資源を共有させたりできます。
サーバーは、接続受付、転送、出口などの機能を担う計算資源です。1回の接続が接続受付サーバーと出口だけを経由する場合もあれば、追加の中継を含む場合もあります。クライアントは通常、内部トポロジーをすべて表示しないため、ノード名だけでデータが何台のネットワーク機器を通るか判断することはできません。
出口IPは、アクセス先のWebサイトが最終的に認識する送信元アドレスです。通常は経路末端の出口に対応し、ユーザーのローカルネットワークアドレスとは異なります。また、入口サーバーと同じネットワークにあるとも限りません。地域が想定どおりか確認する際は、出口IPの地域判定を確認し、対象サービスの実際の挙動も合わせて見てください。データベースによって同じIPに異なる地域や通信事業者のラベルが付くことがあるため、1つの検索結果だけで判断しないでください。
遅延、帯域幅、安定性は同じ指標ではありません
遅延はデータの往復にかかる時間を示し、物理的な距離、経路の迂回、ネットワークの混雑、無線環境などの影響を受けます。帯域幅は単位時間に転送できるデータ量です。安定性は、ジッター、パケットロス、接続断、長時間利用時の変動に注目します。
低遅延のノードが必ずしも高速ダウンロードに向くとは限らず、帯域幅の大きい回線が安定した会議やリモート操作に適しているとも限りません。クライアント一覧の遅延テストは、接続ポイントや特定の測定先だけを確認していることが多く、対象サイトへの実際の性能を完全には示しません。回線は用途で選びましょう。Web閲覧やメッセージ通信では応答性と安定性、大容量ファイルの転送では持続的なスループット、リアルタイムの音声・映像ではジッターとパケットロスが重要です。
IEPL 専線、中継、直結の違い
回線種別は、ローカルネットワークから遠隔の出口までクライアントの通信が進む大まかな経路を示します。プロトコル名でも暗号化方式でもありません。Shadowsocks、VMess、Trojanは異なる回線上で動作でき、逆に同じ回線が複数のプロトコルを運ぶこともあります。
| 回線種別 | 基本経路 | 主な特徴 | 確認するポイント |
|---|---|---|---|
| 直結 | ローカルネットワークから遠隔の接続先へ直接接続 | 構成は比較的シンプルで、性能はローカルの通信事業者から遠隔地までの公衆ネットワーク経路に左右されやすい | 夜間の混雑、ネットワーク間の迂回、長時間接続時の挙動を確認する |
| 中継 | 近距離または経路の良い入口へ接続してから出口へ転送 | 一部の不安定な公衆ネットワーク経路を避けられる一方、中間の転送処理が増える | 入口の安定性、出口の地域、高負荷時の変動を確認する |
| IEPL専線 | 接続後、サービス提供者が表示する専線リソースを通じて両端を接続 | 経路を管理しやすく安定した伝送を重視することが多いが、具体的な実装はサービス提供者のネットワークによる | ラベルだけで判断せず、実際の接続と対象アプリで確認する |
直結の利点は経路の構造がわかりやすく、中継処理が1段少ないことです。一方で、公衆ネットワークの国際経路の変化を受けやすいという弱点があります。利用地域、接続する通信事業者、遠隔サーバーの位置によって結果は変わるため、同じ直結ノードでもネットワークによって性能が大きく異なることがあります。
中継回線では、まず入口へ通信を送り、サービス提供者の転送ネットワークを通して出口へ届けます。中継の価値は経路を組み直すことであり、すべての用途で自動的に速度が向上するわけではありません。入口とユーザー間が安定していても、出口までの中継経路が混雑すれば実際の利用感は低下します。
IEPLは国際イーサネット専線に関連する業界用語です。一般ユーザー向けのノード一覧で「IEPL専線」と表示されている場合、サービス提供者が該当する企業向けネットワーク資源を使っている、またはその回線種別として表示していることが一般的です。ただし、名称だけで完全なトポロジー、容量、制御方針を検証することはできません。契約やトラブル対応では、回線の説明として捉え、すべてのWebサイトで同じ性能が保証されるものとは考えないでください。
代表的なプロトコルの違い
プロトコルは、クライアントとサーバーがセッションを確立し、本人確認を行い、データをカプセル化して通信する方法を定めます。利用できるプロトコルは、サーバー側が対応設定を提供しているか、クライアントが該当機能を実装しているかによって決まります。あるプロトコルのリンクを、完全に非対応のクライアントへそのまま取り込むことはできません。
Shadowsocks
Shadowsocksは暗号化プロキシプロトコルで、設定には通常、サーバー、ポート、暗号化方式、パスワードが含まれます。実装が成熟しており、対応クライアントも多いため、一般的なプロキシ用途に適しています。対応する暗号スイートや拡張機能は実装によって異なるため、取り込みに失敗した場合は、パスワードやポートをむやみに変える前に、クライアントのバージョンと設定項目を確認してください。
VMessとVLESS
VMessはV2Rayエコシステムで広く使われるプロキシプロトコルで、設定にはユーザー識別子、通信方式、安全パラメータなどが含まれます。VLESSはより軽量な設計を採用し、通常はTLS、REALITY、その他の安全な通信設定と組み合わせて使います。名前は似ていますが、設定項目を相互に置き換えることはできません。クライアントに「V2Rayコア対応」と表示されていても、すべての通信方式の組み合わせに対応するとは限りません。
Trojan
Trojanは通常、TLS接続上で動作します。設定ではサーバードメイン、ポート、パスワード、証明書の検証、通信パラメータが重要です。証明書名の不一致、システム時刻の誤り、必要なドメイン設定の省略などにより、ハンドシェイクに失敗することがあります。証明書検証を無効にすると一時的にエラーが消える場合がありますが、サーバーの身元確認が弱くなるため、通常の解決策にはしないでください。
Hysteria2とTUIC
Hysteria2とTUICはいずれもQUICベースの通信機能を利用し、高遅延、ジッター、パケットロスがある環境での伝送効率を重視することがあります。UDP通信に依存するため、現在のネットワークがUDPを厳しく制限していると、ハンドシェイクに失敗したり、接続後に通信できなかったり、頻繁にフォールバックしたりします。その場合は、まずUDPを利用できるネットワークで確認し、ノード障害かローカル環境の制限かを切り分けてください。
この2種類のプロトコルが、すべてのネットワークで必ず高速になるわけでもありません。ネットワークが安定していて対象までの距離が近ければ、従来のTCPとTLSの組み合わせで十分なこともあります。プロトコルは名前の新旧だけで比較せず、接続成功率、継続的な通信、アプリとの互換性で選んでください。
| プロトコル | 通信で重視する点 | 主な確認項目 |
|---|---|---|
| Shadowsocks | 暗号化プロキシと幅広いクライアント互換性 | 暗号化方式、パスワード、ポート、クライアント実装 |
| VMess | 複数の通信方式の組み合わせとエコシステム互換性 | ユーザー識別子、トランスポート層、経路、安全パラメータ |
| VLESS | 軽量プロトコルと外部の安全な通信の組み合わせ | TLSまたはREALITYのパラメータ、ドメイン、通信方式の組み合わせ |
| Trojan | TLSベースのプロキシ接続 | 証明書、ドメイン、システム時刻、パスワード |
| Hysteria2 | QUICベースで変動のあるネットワークに対応 | UDPの到達性、認証情報、帯域幅パラメータ |
| TUIC | QUICベースのプロキシ通信 | UDP制限、証明書検証、輻輳制御の互換性 |
グローバルモード、ルールモード、直結、システムプロキシ
ノードに接続した後、クライアントはどの通信をプロキシコアへ渡すかも決めます。これが動作モードです。クライアントによって名称は多少異なりますが、通常はグローバルモード、ルールモード、直結モードに分類できます。
グローバルモード
グローバルモードでは、クライアントが取り込める通信をできる限り現在のノード経由にします。ノードが利用可能かをすばやく確認したい場合や、複数のドメインを使うアプリ、ルールをすぐに作れないケースに適しています。一方、ローカルサービス、日本国内のWebサイト、国際接続が不要なアプリまで遠隔地を経由し、遅延やプランの通信量が増えることがあります。
ルールモード
ルールモードでは、ドメイン、IP、アプリのプロセス、地域データベース、カスタム条件などに基づき、プロキシ、直結、拒否を決めます。長期利用に適していますが、精度はルールの品質に左右されます。現在のアプリはログイン、コンテンツ配信、更新、テレメトリなどで異なるドメインを呼び出すため、メインドメインだけを追加すると、ページは開いてもログイン、画像、ダウンロードが失敗することがあります。
ルールは通常、クライアントで設定された順番に照合されます。範囲の広いルールが先にあると、後ろの詳細なルールが一度も適用されない場合があります。切り分けでは一時的にグローバルモードへ切り替えてください。グローバルでは使えるのにルールモードで失敗するなら、原因はノードではなく、ルール、DNS、またはアプリの通信が取り込まれていない可能性が高いです。
直結モード
直結モードでは通信を遠隔ノードへ送らず、プロキシを一時停止してクライアントを終了しない場合、ローカルネットワークの確認、特定サイトがルールの影響を受けているかのテストなどに使います。一部のクライアントでは、「直結」でもローカルDNS、通信統計、仮想ネットワークインターフェースが残るため、ソフトウェアを完全に終了した状態と同じとは限りません。
システムプロキシとTUNモード
システムプロキシは、HTTP、HTTPS、SOCKSなどのプロキシアドレスをOSやアプリに提供します。システムプロキシ設定に従うブラウザーやオフィスアプリは通常取り込めますが、独自に接続を確立し、システムプロキシを参照しないプログラムは回避することがあります。
TUNモードは仮想ネットワークインターフェースを通じて、より広範なIP通信を取り込みます。システムプロキシに対応していないアプリ、ゲームランチャー、コマンドラインツールなどでよく使われます。対象範囲が広い分、ルーティングテーブル、ファイアウォール、他のネットワークソフト、権限設定の影響も受けやすくなります。TUNを有効にした後にLAN機器へ接続できない、通信ループが起きる、スリープ復帰後に通信が切れる場合は、LANのバイパス設定、仮想NICの状態、ルートの競合を確認してください。
アプリケーションのリクエスト
├─ 直結ルールに一致 → ローカルネットワーク
├─ プロキシルールに一致 → クライアント → ノード → 対象サービス
└─ ルールに一致しない → クライアントの最終ルールに従う
- ✅ ノードのテスト段階では、まずグローバルモードを使い、基本接続が成立するか確認する。
- ✅ 日常利用ではルールモードに切り替え、ローカルサービスと国際接続を分けて処理する。
- ✅ 特定のアプリが動作しない場合は、システムプロキシに従うか確認し、必要に応じてTUNを検討する。
- ✅ ルールを変更した後はクライアントの接続ログを確認し、実際にどのルールへ一致したか確かめる。
- ❌ 優先順位を理解しないまま、大量の重複ルールを追加しない。
- ❌ システムプロキシや仮想ネットワークインターフェースを変更するクライアントを複数同時に有効にしない。
DNS漏れ、名前解決の経路、分割ルーティングが影響し合う理由
DNSはドメイン名をIPアドレスへ変換します。Webサイトへアクセスする際、クライアントはまず対象のアドレスを知り、その後にルールに従って直結かプロキシかを決めます。DNSリクエストがローカルネットワークへ送られたまま、Web通信だけが遠隔ノードを経由すると、名前解決の経路とアクセス経路が一致しないことがあります。
DNS漏れとは一般に、プロキシ側や指定したリゾルバーで処理すべきDNSリクエストが、ローカルネットワークの名前解決サービスからも見える状態を指します。検索したドメインが知られたり、出口地域と合わないアドレスが返されたりして、コンテンツ配信先の判定異常、アクセス失敗、分割ルーティングの誤判定につながることがあります。
ルールモードは正しい名前解決に大きく依存します。ドメインベースのルールは解決前に照合できますが、IPや地域データベースに基づくルールには解決結果が必要です。ブラウザーで独自の安全なDNSが有効だと、クライアント設定を迂回することがあります。TUNモードがDNSを正しく取り込めていない場合も、Web通信はプロキシ経由なのにDNSだけがローカルへ送られることがあります。
DNSの問題を調べるときは、「Webページが開くか」だけを見ないでください。クライアントログのドメイン、リゾルバー、適用されたルール、出口を同時に確認します。ノードを変えても変化がなく、DNSモードを切り替えると復旧するなら、問題は回線そのものではない可能性があります。DNSが想定どおり処理されているのに接続先がタイムアウトし続ける場合は、ノード、プロトコル、ネットワークの到達性を確認してください。
プラットフォームごとのクライアントの違い
同じサブスクリプションでも、異なるプラットフォームで表示されるノードはおおむね同じですが、通信の取り込み方やバックグラウンド制限は異なる場合があります。「パソコンでは使えるのに別の端末では使えない」場合、すぐにサブスクリプションが無効だと決めつけず、クライアントコア、システム権限、プロキシモード、ネットワーク環境を比較してください。
Windows
Windowsクライアントは通常、システムプロキシとTUNを併用できます。システムプロキシはブラウザーやシステム設定に従うプログラムに適し、TUNはより多くのアプリ通信を取り込みたい場合に向きます。クライアント終了後もWebページを開けない場合は、システムプロキシが正しく元に戻っているか確認してください。TUNを起動できない場合は、仮想NIC、権限、ファイアウォール、他のネットワークツールとの競合を確認します。
Android
Androidクライアントは通常、システムのVPNServiceを通じて通信を取り込み、初回接続時にシステムの許可画面を表示します。一部のシステムではバックグラウンド動作が厳しく制限され、画面ロック後に接続が終了することがあります。端末のバッテリー管理でクライアントの継続動作を許可し、システムのVPNインターフェースを使用する別のアプリが同時に有効になっていないことを確認してください。
iOSとiPadOS
これらのプラットフォームのクライアントは、システムのネットワーク拡張機能に依存して接続を確立します。システムステータスバーに接続マークが表示されても、拡張機能が起動したことを示すだけで、対象ノードへ必ずアクセスできるとは限りません。実際のWebページ、クライアントログ、出口を確認して判断してください。サブスクリプション内の一部プロトコルが表示されない場合は、同じリンクを何度も取り込むのではなく、クライアントの対応範囲を確認しましょう。
macOS
macOSクライアントは、システムプロキシ、ネットワーク拡張機能、仮想インターフェースを使うことがあります。ブラウザーは正常なのにコマンドラインツールが動かない場合、後者がシステムプロキシの環境設定を読み込んでいないことがよくあります。TUN使用後にローカル開発サービスやLANへのアクセスに問題が出たら、ルーティングの除外設定とローカルアドレスのルールを確認してください。
取り込みから確認までの完全なチェック手順
用語を理解したら、次の順番で設定を整理できます。順序が重要です。まず設定元を確認し、次にプロトコルの互換性を確認してから接続を確立し、最後に経路とDNSを検証します。前の手順を飛ばすと、後で見つかるエラーが混ざってしまいます。
- サブスクリプションを取得する。サービス画面にログインし、サブスクリプションまたはクライアント画面からURLをコピーします。余分な空白までコピーしていないことを確認し、公開ツールでサブスクリプションを展開・変換しないでください。
- 対応クライアントを選ぶ。サブスクリプションに含まれるプロトコルを確認し、クライアントが該当プロトコルと通信方式に対応していることを確認します。Shadowsocksだけに対応するクライアントで、完全なVLESS、Trojan、Hysteria2設定を直接読み込むことはできません。
- 取り込んで更新する。URLの取り込み項目からサブスクリプションを追加し、更新後にノード名が完全に表示されるか確認します。更新時に認証エラーが出た場合は、アカウント画面に戻ってURLを再取得し、項目を推測したり変更したりしないでください。
- まず簡単なモードで確認する。現在のネットワークから無理のない距離にあるノードを選び、一時的にグローバルモードを使います。クライアントに接続ログがある場合は、DNS、ハンドシェイク、タイムアウトのどれが原因か区別できるよう、ログ画面を表示しておきましょう。
- 実際の出口を確認する。よく使うWebサイトを開き、出口地域がノードの説明と一致するか確認します。クライアント内の遅延テストだけに頼らないでください。測定が成功しても、対象アプリの一連のリクエストが成功するとは限りません。
- ルールモードへ切り替える。基本接続を確認した後、ルールによる分割ルーティングを有効にします。プロキシが必要なサービスと直結が必要なサービスを個別にテストし、リクエストがどのルールに一致したか確認してください。
- DNSを確認する。名前解決のリクエストが想定したコンポーネントで処理されているか確認します。ブラウザーと他のアプリで挙動が異なる場合は、ブラウザー独自のDNS、システムプロキシ、TUNの取り込み範囲を確認してください。
- 再現可能な設定を保存する。使用したクライアントのバージョン、モード、重要なスイッチを記録し、サブスクリプションの認証情報は記録しないでください。問題が出た場合は一度に1項目だけ変更し、どの変更が効いたのか分からなくならないようにします。
これらの用語を理解すると、クライアント画面が孤立したスイッチの集まりに見えなくなります。サブスクリプションは設定を配布し、ノードは接続先を提供し、回線は伝送経路を決め、プロトコルは通信を担い、動作モードは通信の振り分けを行い、DNSは名前解決とルール判定に影響します。障害が起きたら、この流れに沿って層ごとに確認するほうが、クライアントを何度も変えたり設定を繰り返し取り込んだりするより効果的です。