この記事のVPN用語解説では、サブスクリプション、ノード、プロトコル、ルール分岐という4つの基本から、クライアント画面の各項目が何を制御するのかを説明します。まず覚えておきたい原則は、サブスクリプションが設定をクライアントへ渡し、ノードが通信経路の入口を決め、プロトコルがクライアントとサーバーの通信方法を定め、ルール分岐がどのリクエストに回線を使うかを決めるということです。互いに関係していますが、同じ設定ではありません。
接続トラブルの多くは、用語の混同から起こります。たとえば、サブスクリプションの読み込みに成功しても、すべてのノードがその時点で接続できるとは限りません。ノード名に地域が含まれていても、ネットワーク全体が専用回線だとは限らず、プロトコルを切り替えても誤ったDNS設定が自動的に直るわけではありません。それぞれの役割を理解すれば、ボタンを何度も押すのではなく、通信経路を段階ごとに確認して切り分けられます。
サブスクリプション、設定ファイル、サブスクリプションURLとは
サブスクリプションは、サーバー側で管理される設定一覧と考えるとわかりやすいでしょう。一覧には、ノードのアドレス、ポート、認証情報、プロトコルのパラメータ、通信方式、表示用のノード名などが含まれる場合があります。対応クライアントにサブスクリプションURLを読み込ませると、クライアントが一覧を取得して選択可能なノードを作成します。単に通常のウェブページを開く仕組みではありません。
サブスクリプションURLと単一ノードの設定の違いは、管理方法にあります。単一設定は1つの接続入口だけを記述するため、回線が変更されると再読み込みが必要になることがあります。一方、サブスクリプションは同じ入口から複数の設定を更新できます。クライアントが「サブスクリプションを更新」を実行すると、サーバーが提供する一覧を再取得しますが、ローカルのグループ、速度測定結果、カスタムルールが保持されるかどうかは、クライアントの統合処理によって異なります。
サブスクリプションURLには、アカウントやプラン権限を識別する情報が含まれることがあります。そのためアクセス認証情報として扱い、公開ページ、共有ドキュメント、スクリーンショットに掲載しないでください。クライアントからサブスクリプションを削除しても、サーバーが発行した認証情報そのものは変わりません。URLを誤って公開した場合は、ローカルで再読み込みするだけでなく、サービスの管理画面からリセットしてください。
- ✅ 読み込む前に、クライアントがサブスクリプションで使われているプロトコルと設定形式に対応しているか確認する。
- ✅ 更新前に、ローカルで作成したグループやルールがリモート設定で上書きされないか確認する。
- ✅ サブスクリプションURLはアカウント認証情報として管理し、公開環境で転送しない。
- ❌ 「サブスクリプションの読み込みに成功した」ことを、すべてのノードの接続テストが完了したことと混同しない。
読み込み後、クライアントで行われる処理
読み込み処理では通常、サブスクリプション内容の取得、設定の解析、プロキシグループの作成、ルールの読み込みが行われます。これらが完了して初めて、クライアント画面にノードが表示されます。読み込み段階でエラーが出る場合は、URLの有効性、ネットワークへのアクセス、設定形式、クライアントの互換性に原因があることが多いでしょう。ノードは表示されるのに接続できない場合は、プロトコルのパラメータ、システム時刻、ネットワーク環境、サーバー側の状態を確認します。
QRコードによる読み込みとURLの貼り付けは、本質的には同じです。QRコードは文字列を受け渡しやすい画像に変換したものにすぎません。読み込み後は、サブスクリプション名、ノード一覧、更新日時を確認し、期限切れの設定をクライアントの故障と誤認しないようにしましょう。
ノード、サーバー、回線の違い
ノードは、クライアント上で選択できる接続設定です。通常はサーバー側の接続入口を指し、プロトコルや認証パラメータを伴います。ノード名には国、地域、都市、入口の種類、用途を示すラベルなどが含まれることがありますが、名前は識別のための情報にすぎず、実際のネットワーク経路全体を示すものではありません。
サーバーは、よりインフラ寄りの概念です。物理機器、仮想インスタンス、プロキシサービスを稼働させる実行環境などを指します。1台のサーバーで複数のノード設定を提供することもあれば、1つのノードがスケジューリングによって異なるバックエンドを指すこともあります。そのため、ノード数だけで物理サーバーの規模を推測したり、画面上の各行を完全に独立したハードウェアと考えたりすることはできません。
回線は、ユーザーのネットワークから入口、出口、目的のサービスまで、データが通る経路を表します。ローカルの接続、通信事業者間の接続、国際通信、中継入口、最終出口などが関係します。ノードはユーザーがクリックして選ぶ設定入口であり、回線は実際に通信が通過するネットワーク経路です。
| 用語 | 主な意味 | よくある誤解 | 確認するポイント |
|---|---|---|---|
| ノード | クライアント内にある接続可能な設定項目 | すべてのノードが独立した物理機器に対応している | 地域、プロトコル、入口、現在の接続状況 |
| サーバー | プロキシサービスを支える計算資源とネットワーク資源 | サーバーの所在地が必ず最終出口の場所になる | 実際の出口、ルーティング、サーバー側の構成方法 |
| 回線 | ローカル環境から目的のサービスまで通信が通る経路 | ノード名だけで経路全体の品質がわかる | 入口の方式、中継経路、出口、接続先ネットワーク |
| 出口 | 目的のウェブサイトから見えるネットワーク上の発信元 | 入口の地域と出口の地域は常に同じである | 出口アドレス、DNSの解決場所、目的のサービスの方針 |
ダイレクト、中継、IEPL専用回線
ダイレクト回線は通常、クライアントがサービス事業者の追加入口を経由せず、海外のサーバーへ直接接続する方式です。構成は比較的シンプルですが、国内の通信事業者、ネットワーク間接続、国際インターネットの経路変動から大きな影響を受けます。距離が近いからといって安定するとは限りません。ネットワーク経路は地図上の直線ではないためです。
中継回線では、まず近い場所や接続条件のよい入口へ接続し、そこから入口が通信を目的の出口へ転送します。一部の不安定な公衆ネットワーク経路を避けたり、サーバー側で出口を調整したりできる一方、経路上の区間は増えます。入口、中継区間、出口のいずれかで混雑が起きると、最終的な通信品質に影響する可能性があります。
IEPL専用回線は通常、特定のネットワーク拠点を接続する国際イーサネット専用回線の能力を指します。一般的な国際インターネットとは、経路の構成やリソースの確保方法が異なりますが、「専用回線」だからといって、ユーザーの端末から目的のウェブサイトまでの全区間が完全に専有されるわけではありません。入口までのアクセス網、出口から目的のサービスまでのネットワーク、ローカルの無線環境も最終的な接続に関係します。
プロキシプロトコルの名称が示すもの
プロトコルは、クライアントとサーバーがどのようにセッションを確立し、権限を認証し、データをカプセル化して転送するかを定めます。プロトコル名は回線品質を意味しません。同じプロトコルを異なるネットワークに配置することも、異なるプロトコルで同じ出口を共有することもできます。実際の使用感は、ネットワーク経路、サーバー負荷、クライアント実装、トランスポート層、目的のアプリにも左右されます。
| プロトコル | 主な特徴 | 設定時に確認する点 |
|---|---|---|
| Shadowsocks | 軽量な暗号化プロキシプロトコルで、対応クライアントが幅広い | 暗号化方式、認証情報、クライアントの対応状況 |
| VMess | V2Rayエコシステムでよく使われ、認証と複数のトランスポートを組み合わせられる | ユーザー識別子、トランスポート方式、TLS、パスのパラメータが一致しているか |
| Trojan | TLSと組み合わせることが多く、通常の暗号化通信に近い形で接続できる | ドメイン、証明書の検証、パスワード、トランスポート設定 |
| VLESS | 認証とトランスポート層が比較的分離され、TLSなどのセキュリティ層と組み合わせることが多い | ユーザー識別子、フロー制御、トランスポート方式、セキュリティ層の設定 |
| Hysteria2 | QUICとUDPをベースに、複雑なネットワークでも輻輳制御を活用して通信を維持することを重視 | UDPの利用可否、認証、TLS、サーバー側のパラメータ |
| TUIC | QUICベースのプロキシプロトコルで、多重化とUDP転送に対応 | クライアントのバージョン互換性、輻輳制御、証明書の検証 |
プロトコルのパラメータを完全に一致させる理由
プロキシ接続で確認するのは、サーバーアドレスだけではありません。クライアントとサーバーは、ポート、認証情報、トランスポート方式、TLS設定、ドメイン、パスなどのパラメータも一致させる必要があります。重要な項目が1つでも異なると、タイムアウト、ハンドシェイク失敗、証明書エラー、接続確立後にデータが流れないといった症状が出ることがあります。
TrojanやTLSを使用するVLESS、VMessの設定では、ドメインと証明書の検証を正しく扱う必要があります。検証を無効にすると証明書設定の問題を一時的に回避できる場合がありますが、クライアントがサーバーの身元を確認する能力を弱めるため、通常のトラブル対処として推奨できません。システム時刻、ドメイン、証明書チェーン、サブスクリプション内容が一致しているかを確認するのが適切です。
Hysteria2とTUICはQUICとUDPに依存します。一部のオフィスネットワーク、公衆ネットワーク、ルーターではUDPが制限されるため、設定が正しくても安定して通信できない場合があります。TCPベースの互換設定への切り替えは問題の切り分けに使えますが、どのネットワークでも特定のプロトコルが本質的に優れていることを意味しません。
プロトコル選びで重要なのは、新しいものを追うことではありません。まずクライアントが完全に対応しているかを確認し、次に現在のネットワークがその通信方式を利用できるかを見て、最後に実際のアプリで継続接続を検証します。プロトコル名だけで速度や安定性を保証することはできません。
システムプロキシ、TUN、VPNインターフェースの仕組み
デスクトップクライアントの「システムプロキシ」は通常、OSのプロキシ設定を変更し、その設定に従うアプリからHTTPまたはSOCKSのリクエストをクライアントへ渡します。導入は簡単ですが、すべてのプログラムがシステムプロキシを読み取るわけではありません。ゲーム、コマンドラインツール、独立したアップデーター、独自のネットワーク処理を実装したアプリなどは、直接接続を続ける場合があります。
TUNモードは仮想ネットワークインターフェースを作成し、よりIP層に近い位置で通信を受け取り、ルールに応じてプロキシまたはダイレクト経路へ転送します。システムプロキシに対応しないプログラムも広くカバーでき、UDPの処理にも適していますが、通常は追加のシステム権限が必要です。また、セキュリティソフト、他のネットワークツール、企業ネットワークのポリシーと競合することがあります。
AndroidやiOSのプロキシクライアントは通常、OSが提供するVPNインターフェースを使って通信を引き受けます。ここでいう「VPN」は、OSが開放するネットワークトンネル機能を指すことが多く、インターフェース内のデータはShadowsocks、Trojanなどのプロキシプロトコルで運ばれる場合があります。macOSではネットワーク拡張機能で同様の処理を行うことが多く、WindowsクライアントではシステムプロキシとTUNを併用できる場合があります。両モードでは対象範囲と必要な権限が異なります。
- ✅ ブラウザーは使えるのに独立したアプリが通信できない場合、そのアプリがシステムプロキシに従うか確認する。
- ✅ UDPの利用やプロキシ設定を読み取らないプログラムをカバーする必要がある場合は、TUNモードを検討する。
- ✅ TUNを有効にしてネットワークに異常が出た場合は、ルーティングの競合、権限、他のネットワークツールを確認する。
- ❌ ネットワークを制御するクライアントを複数同時に有効にし、自動的にルートを調整できると期待しない。
「LAN接続を許可する」とは
この項目は通常、同じLAN内にある他の機器から、現在のクライアントが開いているプロキシポートへの接続を許可します。他の機器に設定を自動で渡したり、アクセス制御を自動で行ったりする機能ではありません。有効にした後は、待ち受けアドレス、ファイアウォール、認証設定を確認し、信頼できないネットワーク環境にローカルのプロキシポートを公開しないよう注意してください。プロキシを共有する必要がなければ、このPCだけからアクセスできる設定のほうが管理しやすくなります。
グローバルモード、ルールモード、ダイレクトモードの選び方
グローバルモードでは通常、クライアントが引き受けた通信を現在のプロキシノードへ一律に通します。ルール分岐が原因でアプリがプロキシを使っていないかを確認したり、出口を短時間検証したりするのに適しています。ただし、OS上のすべてのデータが必ず引き受けられるわけではありません。システムプロキシだけを有効にしている場合、システムプロキシに従わないプログラムは直接接続する可能性があります。
ルールモードでは、ドメイン、IP、アプリ、ポート、ルールセットなどの条件に応じて、プロキシ、ダイレクト、拒否の経路を選びます。不要な迂回を減らせるため、日常利用では最も一般的な選択肢です。ルールは継続的なメンテナンスが必要です。ドメインの変更、コンテンツ配信ネットワークの調整、アプリへの新しい接続先の追加などで、古いルールの判定が不完全になることがあります。
ダイレクトモードでは通常、通信をプロキシ経由にしません。ローカルネットワーク自体が正常かを確認したり、ローカルネットワーク限定のリソースへアクセスしたりするのに適しています。ダイレクトは「クライアントを終了する」ことと完全に同義ではありません。クライアントがDNS、仮想インターフェース、ルール処理を引き続き扱う場合があり、具体的な挙動は実装によって異なります。
| モード | 通信の処理方法 | 適した場面 | 注意点 |
|---|---|---|---|
| グローバル | 対象範囲内のリクエストを一律にプロキシへ通す | ノードの検証とルール分岐の漏れの確認 | ローカルサービスが遠回りになり、対象外のアプリは直接接続する可能性がある |
| ルール | ドメイン、アドレス、アプリの条件に応じて経路を選ぶ | 日常のアクセスでローカル通信と国際通信を使い分ける | ルールセットを更新し、誤ったマッチングに注意する |
| ダイレクト | リクエストをプロキシノードに通さない | ローカルリソースへのアクセスと基本ネットワークの切り分け | クライアントのDNSや仮想インターフェースは動作し続ける場合がある |
ルール分岐はどの順番でマッチするか
多くのルールエンジンは上から順に確認し、マッチすると後続の判定を停止します。最後に、どのルールにも一致しなかったリクエストをフォールバックルールで処理します。そのため、より具体的なアプリやドメインのルールは、広範囲を対象とする地域ルールより前に置くのが一般的です。広いルールが先にマッチすると、後ろにある精密なルールは適用されません。
目的のアプリ専用ドメイン → 指定プロキシグループ
ローカルサービスのドメイン → ダイレクト
LANアドレス → ダイレクト
その他の未マッチリクエスト → デフォルトグループこの例が示しているのは優先順位であり、そのままコピーできる設定構文ではありません。クライアントによってYAML、JSON、GUIルール、独自形式などを使い、フィールド名も統一されていません。変更前に、設定がローカル管理なのかリモートのサブスクリプションから生成されるのかを確認し、更新後にカスタム内容が失われないようにしましょう。
DNSリーク、名前解決、出口の場所
ドメインへアクセスする前に、端末は通常DNSを使ってドメインをIPアドレスへ変換します。ウェブ通信はプロキシ経由なのにDNSクエリだけがローカルネットワークから直接送信されると、名前解決のリクエストが想定した経路を使っていません。この状態はDNSリークと呼ばれることがあります。検索中のドメインが知られたり、ローカルの解決結果とプロキシ出口の地域が一致せず、アクセスに問題が起きたりする可能性があります。
クライアントでよく使われるDNS処理には、システムリゾルバーを使う方法、クエリをリモートへ転送する方法、暗号化DNSで結果を取得する方法、ルールエンジンがドメインごとに解決経路を選ぶ方法があります。暗号化DNSはクエリの転送を保護できますが、リクエストがローカルネットワークから直接送られているなら、自動的にプロキシ出口から名前解決されるわけではありません。確認するときは、どこからクエリが送信され、誰が応答し、その結果がどの経路へ渡されるのかを同時に見ます。
クライアントによっては仮想アドレス機能を使い、ドメインをいったん予約アドレスへ割り当て、内部でドメインを復元してからルール分岐を適用します。システムへIPアドレスだけを要求するプログラムの処理に役立ちますが、一部のLANサービス、企業ソフト、実際のアドレスによる判定に依存するアプリでは例外ルールが必要になることがあります。Fake IP、リモートDNS、DNSハイジャックなどの項目は、名前だけで有効・無効を決めず、クライアントのドキュメントと現在のモードを確認して判断してください。
- ✅ 目的のウェブサイトが開けない一方、既知のアドレスを直接入力するとアクセスできる場合は、まずDNS解決を確認する。
- ✅ 出口の地域は正しいのにコンテンツの地域判定が異常な場合は、DNSとアプリのキャッシュを確認する。
- ✅ ノードを切り替えた後はDNSキャッシュとアプリの接続を更新し、古いセッションを再利用しないようにする。
- ❌ DNSを変更すればすべての接続問題が解決すると考えない。
クライアント設定の基本的な確認順序
プラットフォームによってクライアント画面は大きく異なりますが、確認の順序は共通化できます。まずサブスクリプションが正常に更新されるかを確認し、次にノードのパラメータで接続を確立できるかを見ます。その後、システムが通信を引き受ける方式を確認し、最後にルールとDNSを調整します。この順序なら、基本接続が成立していない段階で複雑なルール分岐を変更する事態を避けられます。
- サブスクリプションの状態を確認：サブスクリプションが有効で、直近の更新に解析エラーがなく、必要なノードが一覧に表示されていることを確認します。
- 互換性のあるノードを選択：クライアントが明確に対応しているプロトコルを使い、システム時刻とTLS関連情報を確認します。
- 基本接続を検証：一時的にグローバルモードで目的のサービスへアクセスし、ノードの障害とルールの漏れを切り分けます。
- 通信の対象範囲を確認：ブラウザーは使えるのに他のアプリが使えない場合、TUNまたはシステムVPNインターフェースが必要か判断します。
- DNSを確認：名前解決の経路がルール分岐の対象と一致しているか確認し、回線を切り替えた後は再利用されている古い接続を破棄します。
- 日常のルールへ戻す：基本接続が安定してからルールモードを有効にし、目的のリクエストが実際にどのグループへマッチしたか確認します。
ログも重要な手がかりになります。サブスクリプションの解析エラー、接続タイムアウト、TLSハンドシェイクの失敗、DNSクエリの失敗、ルールのマッチングは、それぞれ異なる記録を残すことが多いでしょう。ログを読むときは、最初に現れた重要なエラーを探し、後から大量に繰り返される再試行に惑わされないようにします。サポートへ問い合わせる際は、エラーの種類、クライアント名、プラットフォーム、使用モード、問題が起きたノードの種類を伝えられますが、サブスクリプションURL、認証情報、完全な設定内容は隠してください。
日常利用だけであれば、通常は基礎パラメータを頻繁に変更する必要はありません。サブスクリプションを更新し、現在のネットワークと互換性のあるノードを選び、ルールモードで使い、特定のアプリが対象にならないときにTUNとDNSを確認すれば、多くの一般的な状況に対応できます。設定を手動で編集する必要がある場合は、1つの問題に絞って項目ごとに調整し、一度に1つの変数だけを変更すると結果を判断しやすくなります。