ネットワーク高速化ツールを初めて使うと、VPN サブスクリプション、ノード、プロトコル、ルーティング、グローバルモードがクライアント内に一度に表示されることがあります。これらは同じ階層の設定ではありません。サブスクリプションは設定を提供し、ノードは選択可能な接続先を示します。プロトコルはクライアントとサーバーの通信方法を定め、回線はデータが通る経路を表し、ルーティングモードはどのリクエストをプロキシに渡すかを決めます。この5つを分けて考えると、クライアントの多くの項目が理解しやすくなります。
日常会話では「VPN」がネットワーク高速化サービス全般を指すことがありますが、クライアントが実際に使う技術は従来型の VPN プロトコルとは限りません。一部のツールはシステムの VPN インターフェースで仮想ネットワークアダプターを作成し、通信を Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUIC などのプロトコルで処理します。そのため、システムのステータスバーに VPN と表示されても、システムの通信制御機能が有効になっていることを示すだけで、基盤プロトコルまでは判断できません。
サブスクリプション、サブスクリプションリンク、設定ファイルの違い
サブスクリプションは、サーバー側で管理される設定一覧です。通常はノード名、サーバーアドレス、ポート、プロトコルパラメーター、認証情報、その他クライアントが認識できる項目が含まれます。互換性のあるクライアントに取り込むと、一覧が解析されてノードリストが作成されるため、項目を一つずつ手入力する必要はありません。
サブスクリプションリンクは、この設定一覧を取得するためのアドレスです。一般的な案内ページではなく、アカウント識別情報を含む設定への入口です。このリンクを入手した人はノード設定を読み取れる可能性があるため、公開グループ、スクリーンショット、公開ドキュメントに掲載しないでください。リンクの流出が疑われる場合は、ローカルのノードを削除するだけでなく、サービスの管理画面でサブスクリプションを再発行してください。
設定ファイルは、サブスクリプションの内容をローカルに保存した静的なコピーです。テキスト形式や構造化形式などがあります。ファイルの直接取り込みはオフライン移行に適していますが、サーバー側の変更は自動反映されません。一方、サブスクリプションリンクはクライアントから更新できます。ノードの追加、入口の変更、ルールの調整があった場合は、クライアントを再インストールするよりサブスクリプションを更新するほうが効果的です。
サブスクリプションの取り込み時にクライアントが行っていること
- クライアントがサブスクリプションのアドレスにアクセスし、設定内容をダウンロードします。
- プロトコル、サーバーの入口、認証項目、ノード名を解析します。
- 複数のノードを、選択可能なプロキシグループまたはリストに整理します。
- ローカルルールに基づいて、デフォルトノード、更新方法、通信処理モードを決定します。
- 接続時にローカルプロキシポートまたは仮想ネットワークアダプターを作成し、条件に一致するリクエストを選択したノードへ渡します。
取り込みに成功しても、接続が有効になったとは限りません。サブスクリプションがクライアントに読み込まれたことを示すだけで、利用可能なノードの選択、システムプロキシまたは仮想ネットワークアダプターの有効化、実際のアクセスと DNS の確認が必要です。更新成功と表示されてもウェブページが元のネットワークを使う場合は、同じリンクを繰り返し取り込むのではなく、モード、プロキシグループの選択、システム権限を確認してください。
ノード、サーバー、回線は同じものではありません
ノードは、クライアントで選択できる接続設定です。1台のサーバーに直接対応する場合もあれば、入口、負荷分散用アドレス、回線の組み合わせを示すだけの場合もあります。ノード名に含まれる国名や都市名は、通常、出口の場所や回線の用途を表すもので、サーバー機器の実際の設置状況と必ずしも一致しません。
サーバーは接続を処理する計算リソースで、認証、転送、プロトコル終端などを担います。一般の利用者がサーバー内部の構成を知る必要はほとんどありません。対象地域、現在のネットワーク、利用するアプリにノードが適しているかを確認すれば十分です。
回線は、ローカル環境から入口へ、さらに出口へ至るデータの経路に焦点を当てた概念です。出口の地域が同じ2つのノードでも、入口の位置、通信事業者間の接続、中継方法が異なれば、実際の使用感は変わります。逆に、同じ回線が複数のノード名で提供され、プロトコルや用途だけが異なる場合もあります。
| 回線タイプ | 接続経路 | 主な特徴 | 選ぶ際のポイント |
|---|---|---|---|
| 直接接続 | クライアントが海外の入口へ直接接続 | 経路がシンプルで、ローカルネットワークと国際接続の影響を受けやすい | 現在の接続ネットワークから入口へ安定して到達できるか確認する |
| 中継 | 近い入口へ接続してから出口へ転送 | ネットワーク間の経路を調整できる一方、転送が1段増える | 入口の品質、転送経路、出口の用途を確認する |
| IEPL 専線 | 国際イーサネット専線で指定区間を転送 | 一般的な公衆網の直接接続とは経路管理の方法が異なる | サービス提供者の表示が実際にどの接続範囲を指すか確認する |
直接接続が必ず中継より速いとは限らず、中継が常に優れているわけでもありません。適切な経路は、ローカルの通信事業者、接続地域、出口の方向、その時点のネットワーク状況で決まります。中継の価値は経路の一部を組み直すことにあり、すべての混雑を解消するものではありません。IEPL は国際イーサネット専線サービスの業界用語ですが、クライアントの「IEPL」表示はサービス説明と合わせて確認してください。専線が全体の経路の特定区間だけを担う場合もあります。
初心者がノードを選ぶ際は、クライアントに表示される遅延だけを見ないことが大切です。遅延は通常1回の測定値であり、入口への到達性は示せても、ウェブページの読み込み、継続的な転送、特定アプリの動作を完全には表しません。まず対象地域で絞り込み、実際の利用環境で接続確立、ページの応答、継続転送が安定しているかを比較するのが確実です。
代表的なプロトコル：Shadowsocks、VMess、Trojan、VLESS
プロトコルは、クライアントとサーバーがデータをカプセル化、認証、転送する方法を定めます。プロトコル名は回線品質を意味しません。同じプロトコルが異なる回線で動作することも、同じ回線で複数のプロトコルを提供することもあります。選択時は、クライアントの互換性、現在のネットワークが対応する転送方式、サービス側が提供する設定を総合的に確認してください。
Shadowsocks
Shadowsocks は暗号化プロキシプロトコルで、構成が比較的シンプルでクライアントの対応環境も成熟しています。事前共有鍵によって暗号化と認証を行い、幅広いクライアント互換性が必要な場面に適しています。暗号化方式は自由に混在できず、サーバーとクライアントで同じパラメーターを使う必要があります。サブスクリプション取り込み後に暗号化方式を変更すると、ポートには到達できても認証に失敗することがあります。
VMess と VLESS
VMess は識別情報とプロトコル項目を使ってクライアントとサーバー間で通信し、WebSocket、TCP などの転送方式と組み合わせて使われます。VLESS は軽量な認証を重視し、完全な転送暗号化は単独では提供しません。通常は TLS、REALITY、または保護された下位チャネルと併用します。VLESS ノードではプロトコル名だけでなく、転送方式、安全層、サーバー名、クライアントコアの互換性も確認してください。
VMess と VLESS は名称が似ていますが、設定項目をそのまま相互利用することはできません。VLESS ノードを VMess として手入力したり、TLS 関連の項目を省略したりすると接続に失敗します。サブスクリプションを使う利点の一つは、関連する項目を手入力する際のミスを減らせることです。
Trojan
Trojan は通常 TLS 上で動作し、パスワードで認証します。クライアントではサーバー名、証明書の検証、転送パラメーターを正しく処理する必要があります。証明書エラーが出ても、「証明書の検証をスキップする」ことを恒久的な解決策にしないでください。まずシステム時刻、サーバー名、サブスクリプションの有効性、クライアントコアの対応状況を確認します。
Hysteria2 と TUIC
Hysteria2 と TUIC は、UDP と QUIC を利用した転送を重視し、パケットロスや変動のある環境で、それぞれの輻輳制御や多重化によって転送を改善できます。ただし、現在のネットワークが UDP に対応している必要があります。公衆ネットワーク、企業ネットワーク、ルーターの設定によっては UDP が制限されることがあります。設定が正しく見えてもハンドシェイクが長時間完了しない場合は、診断手順として TCP ベースの互換ノードへ切り替えるほうが適しています。
グローバルモード、ルールモード、直接接続モードの選び方
クライアントの「モード」は通信の振り分け方法を決めます。ノードの選択とは別の概念です。ノードはプロキシ対象の通信をどこへ送るかを決め、モードはどの通信を送るかを決めます。海外のノードを選択しても、端末上のすべてのリクエストが自動的にそのノードを経由するわけではありません。
| モード | 処理方法 | 適した場面 | よくある問題 |
|---|---|---|---|
| ルールモード | ドメイン、アドレス、アプリのルールに応じてプロキシと直接接続を選択 | 日常利用で、ローカルサービスは元の経路を維持したい場合 | ルールに一致しない、ルールが古い、ルールの順序が競合している |
| グローバルモード | 制御可能なリクエストを一律で選択したプロキシへ渡す | ルールがアクセス失敗の原因か一時的に確認する場合 | ローカルサービスの経路が遠回りになる、LAN リソースにアクセスできない |
| 直接接続モード | リクエストをプロキシノードに通さない | プロキシを一時停止する、元のネットワークの状態と比較する | ノードに接続したつもりでも、実際には使われていない |
ルールモードは通常、日常利用に適しています。クライアントはドメイン、IP アドレス、地域別の集合、アプリのプロセスなどに基づいてリクエストを判定し、プロキシ、直接接続、ブロックのいずれかへ振り分けます。ルールには順序があり、具体的な条件は一般的なフォールバックルールより前に置くのが基本です。先に広いルールがあると、リクエストを先に処理してしまうことがあります。
グローバルモードは診断に適しており、常時オンにする必要はありません。ルールモードで失敗したウェブサイトがグローバルモードで復旧する場合、原因はノード自体ではなく、ルール判定、DNS 解析、プロキシグループの選択にある可能性が高いです。グローバルモードではローカルサイト、LAN 機器、システムサービスも遠回りになることがあるため、確認後は必要に応じてルールモードへ戻してください。
直接接続モードでは、通信が元のネットワーク経路を使います。プロキシの有無による違いを比較したり、クライアントを終了せずに転送を一時停止したりする用途に使えます。ただし、一部クライアントの「直接接続」はルール上の判断だけに影響し、仮想ネットワークアダプターは有効なままの場合があります。完全に通信制御を停止できたか確認するには、システムプロキシ、仮想ネットワークアダプター、クライアントの動作状態を確認してください。
ルーティングルールに含まれる主な条件
- ドメインサフィックス：特定のサイトとサブドメインに指定したポリシーを適用します。
- 完全修飾ドメイン名：特定のホストだけに一致させ、細かな制御に適しています。
- IP アドレス範囲：宛先アドレスに応じてプロキシまたは直接接続を選びます。
- アプリのプロセス：指定したソフトウェアだけを特定のプロキシグループへ送ります。
- 地域ルールセット：管理されたドメインまたはアドレスの集合に基づいて分類します。
- フォールバックルール：それまでの条件に一致しなかったリクエストを処理します。
ルーティングはウェブページのアドレスだけで決まりません。1つのページが、メインサイト、画像用ドメイン、API ドメイン、コンテンツ配信用ドメインへ同時にリクエストすることがあります。これらが異なる出口に振り分けられると、ページは開くのに画像だけ表示されない、ログインが繰り返される、認証画面に問題が出るといった現象が起きます。トラブル時はメインドメインだけに例外を追加せず、クライアントの接続ログで各ドメインがどのルールに一致したか確認してください。
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,local.example,DIRECT
GEOIP,LAN,DIRECT
MATCH,PROXYこの例のルールは、指定したドメインサフィックスをプロキシへ送り、ローカルドメインと LAN アドレスは直接接続にし、それ以外をフォールバックポリシーで処理することを示しています。クライアントによって構文、ルール名、対応範囲は異なるため、1つの設定をすべてのソフトウェアへそのままコピーすることはできません。変更前に元の設定をバックアップし、クライアントのドキュメントでサポートされている項目を使用してください。
システムプロキシ、TUN モード、仮想ネットワークアダプターの違い
システムプロキシは、HTTP または SOCKS プロキシのアドレスを OS に登録する機能です。システムプロキシに従うブラウザーやアプリはリクエストをクライアントへ渡しますが、一部のソフトウェアは設定を無視したり、独自のネットワークスタックを使ったり、UDP リクエストを直接送信したりします。そのため、システムプロキシを有効にしても、制御されないアプリの通信が残ることがあります。
TUN モードは通常、仮想ネットワークアダプターで IP 層の通信を受け取り、クライアントがルールに従って転送します。システムプロキシに対応しないアプリも広くカバーでき、UDP の処理にも適していますが、より高いシステム権限が必要です。また、他のネットワークフィルタリングソフト、企業のセキュリティポリシー、既存の仮想ネットワークアダプターと競合することがあります。
仮想ネットワークアダプターは通信をクライアントへ入れる方式にすぎず、すべての通信が必ずリモートノードを通ることを意味しません。クライアントは TUN モードでも、直接接続、プロキシ、ブロックのルールを適用できます。システムに VPN 表示が出ても、ステータスアイコンだけで出口を判断せず、クライアントの接続ログでルールの一致結果を確認してください。
DNS リークとは何か、ルーティングにどう影響するか
ドメインへアクセスする前に、端末は通常 DNS を使ってドメイン名をアドレスへ変換します。ウェブ通信はプロキシを経由していても、DNS クエリが元のネットワークのリゾルバーへ送られると、DNS リークが発生する可能性があります。検索中のドメイン情報が漏れるだけでなく、現在の出口に適さないアドレスが返され、通信の遠回り、到達不能、ルール判定のずれにつながることもあります。
ルールモードは DNS の設計に大きく左右されます。ドメインを先に解析して IP ルールで判定するクライアントもあれば、ドメイン情報を保持してドメインルールで判定するクライアントもあります。TUN 実装によっては仮想アドレスへのマッピングを使います。「DNS が有効」という項目だけで判断せず、解析リクエストの送信元、通過するインターフェース、解析結果がプロキシの出口と一致しているかを確認してください。
DNS 経路を確認する実践的な手順
- クライアントで内蔵 DNS またはリモート解析機能が有効になっているか確認します。
- システムに、他のネットワークツールが書き換えた解析設定が残っていないか確認します。
- ルールモードとグローバルモードで、同じドメインをそれぞれテストします。
- システムとブラウザーの DNS キャッシュを消去してから再接続します。
- ブラウザーがクライアントのポリシーとは別の暗号化 DNS を個別に有効にしていないか確認します。
- 接続ログを確認し、DNS リクエストと宛先接続が想定したポリシーに一致しているか確認します。
ブラウザーの暗号化 DNS 自体に問題があるわけではありません。ただし、クライアントのルーティング用 DNS を迂回すると、2種類の解析結果が生じる可能性があります。トラブル対応では、まずブラウザーをシステム設定に従わせ、クライアントの経路が正常であることを確認してから、ブラウザー独自の解析方式を戻すか判断してください。重要なのは、ドメイン解析と後続の接続で、一貫性があり説明可能な出口ポリシーを使うことです。
プラットフォームごとにクライアントの見え方が違う理由
Windows クライアントでは、通常、システムプロキシと TUN モードの両方を利用できます。システムプロキシは設定が簡単ですが、すべてのアプリが従うとは限りません。TUN はより広範囲をカバーする一方、仮想ネットワークアダプターのドライバーと管理者権限が必要です。有効化後に通信できなくなった場合は、仮想ネットワークアダプター、ルーティングテーブル、DNS 設定、他のネットワークフィルタリングプログラムの競合を確認してください。
macOS クライアントは、システムのネットワーク拡張機能または VPN 設定を通じて通信を制御することがよくあります。初回の有効化時には、システム設定で権限を許可する必要があります。システム更新後、クライアントは開けるのにトンネルを確立できない場合は、サブスクリプションを再インストールする前に、ネットワーク拡張機能の許可が維持されているか確認してください。Apple シリコン搭載端末と Intel 端末ではビルドが異なる場合があるため、ダウンロード時はクライアントのリリースノートに従います。
Android クライアントは通常、システムの VPN サービスを呼び出してローカルトンネルを作成し、アプリ単位でプロキシ経由にするか選択できます。省電力設定によってバックグラウンド動作が制限され、画面ロック後に接続が切れることがあります。バックグラウンド実行の権限、データセーバー設定、アプリのルーティングリストを確認してください。
iOS と iPadOS のクライアントは、システムのネットワーク拡張機能の仕組みに制約され、設定は通常それぞれのアプリ内に保存されます。同じサブスクリプションを取り込んでも、ルールセット、スクリプト、プロトコルコアへの対応はクライアントごとに異なる場合があります。デスクトップでは使えるノードをモバイルで取り込めない場合は、サブスクリプションが無効だと判断する前に、プロトコルと転送方式への対応を確認してください。
Linux 環境では、デスクトップクライアントを使うことも、コマンドラインのコアを動かすこともあります。デスクトップアプリはシステムプロキシで一般的なソフトウェアの通信を制御できますが、コマンドラインプログラムでは環境変数を個別に設定するか、TUN とルーティングルールで統一的に処理する必要があります。トラブル対応では、「コアが動作している」「ローカルポートが待ち受けている」「アプリがプロキシを使っている」という状態を区別してください。
取り込みから接続までの確認手順
初心者は、サブスクリプションをダウンロードできない、ノードのハンドシェイクに失敗する、ルールに一致しない、アプリがシステムプロキシを使っていない、といった問題を一つにまとめてしまいがちです。結果としてすべて「開けない」と表示されます。層ごとに確認すれば、不要な操作を減らせます。
- サブスクリプションを確認：リンクがサービスの管理画面から取得したものか、クライアントが正常に更新できるか、ノードリストに想定した変化があるか確認します。
- 互換性を確認：クライアントコアが、ノードで使われるプロトコル、転送方式、安全層に対応しているか確認します。
- ノードを確認：まず用途が明確なノードを選び、遅延の表示だけに頼らず、ハンドシェイクや接続ログを確認します。
- 通信制御を確認：システムプロキシまたは TUN が有効で、対象アプリが実際にクライアントの管理下にあるか確認します。
- モードを確認：ルールモードとグローバルモードを一時的に比較し、障害の原因がルーティングにあるか判断します。
- DNS を確認：解析経路と接続ポリシーが一致しているか確認し、古いキャッシュを消去してから再テストします。
- 競合を確認：他のプロキシ、仮想ネットワークアダプター、ネットワークフィルタリングツールを一時停止し、ルートが重複して変更されないようにします。
- ログを保存：エラーの種類、使用プロトコル、接続モード、発生段階を記録してからサポート担当者へ伝えます。
エラーログの「タイムアウト」は、規定の待機時間内に接続が完了しなかったことを示しますが、入口に到達できない、UDP が制限されている、DNS 解析に異常がある、経路が混雑しているなど、原因はさまざまです。「認証失敗」は鍵、パスワード、識別項目、サブスクリプションの状態に関係することが多く、「証明書エラー」ではサーバー名、システム時刻、TLS 設定を確認します。エラーごとに対処は異なり、ノードを繰り返し切り替えてもログの確認の代わりにはなりません。
トラブル対応では、一度に1つの変数だけを変更してください。まずクライアントとモードを固定してからノードを変更し、次にノードを固定してルールとグローバルを比較します。プロトコル、ノード、DNS、クライアントを同時に変更すると、復旧しても本当の原因を特定しにくくなります。
用語を理解した初心者が設定を選ぶ際の結論
サブスクリプションは設定をクライアントへ渡し、ノードは選択可能な接続の組み合わせ、プロトコルは通信方式、回線は基盤経路、ルーティングはプロキシを通すリクエストを決めます。システムプロキシと TUN は端末の通信をクライアントへ取り込む役割を担います。DNS はドメイン解析の段階にあり、解析経路とルーティングが一致しないと、正しそうなノードでもアクセスに異常が出ることがあります。
日常利用では、まずルールモードを選び、ローカルサービスは直接接続のまま、国際アクセスはルールに従って適切なノードへ送るのがおすすめです。特定のウェブサイトで問題が起きたら、グローバルモードへ短時間切り替えてルールを確認します。プロトコルはクライアントの互換性と現在のネットワークを優先し、回線は実際の経路の状態で選びます。名称が複雑だから適しているとは限りません。安定して取り込め、正しく通信を制御でき、ルーティングが明確で、トラブル対応もしやすい組み合わせが、長期的に管理しやすい設定です。