プロキシプロトコルとコアの解説.

クライアント、コア、プロトコルを分けて考える

クライアントは操作画面として、ノードの表示、設定の読み込み、システムプロキシの管理、必要な権限の取得を担います。コアは設定の解析やルール判定、接続の確立を担当し、プロトコルはクライアントとサーバー間の認証、データのカプセル化、転送方法を定めます。同じ画面で複数のコアを切り替えられる場合もあれば、同じコアを複数の画面から使う場合もあります。そのため、クライアント名に「Clash」とあっても、すべてのClash設定に対応するとは限らず、特定のノードが必ず接続できるとも限りません。

ノードはプロトコルの種類だけで決まるものではありません。通常、接続設定にはサーバーアドレス、ポート、認証情報、通信方式、暗号化やTLSの設定に加え、パス、ホスト名、追加オプションが含まれます。同じVLESSのノードでも、TCPとWebSocketの違いがあったり、証明書やサーバーの構成が異なったりします。比較する前にノードの詳細を開き、設定項目を確認してください。種類のラベルだけを見ると、回線の違いをプロトコルの違いと取り違えるおそれがあります。

まず利用可能な範囲を確認し、その後で性能を比較する

最初に、サービス提供元がどの方式を提供しているか、mihomoでそのまま読み込める設定かを確認します。次に、アプリストアの説明だけでなく、クライアントが現在どのコアを使っているかを調べます。さらに、現在のネットワークで該当する通信方式が利用できるか確認しましょう。特にQUICを使う方式では、UDP通信が可能である必要があります。この3点を確認してから、Webページの表示待ち時間、大容量ダウンロードの安定性、ビデオ会議の途切れにくさ、スマホのスリープ後の復帰を比べましょう。

この順番で確認すれば、無駄な試行錯誤を減らせます。コアがある方式を認識しない場合、速度測定先を変えても設定の解析エラーは解消しません。サーバーがTCPのみを待ち受けている場合、クライアントでUDPを有効にしてもサーバー側に対応が加わるわけではありません。証明書のホスト名が一致しない場合、ルールグループを変更してもTLSのハンドシェイクは直りません。まず失敗が設定の読み込み、解析、接続、アプリのリクエストのどの段階で起きているかを見極め、その段階に対応する設定を変更しましょう。一度に変更する項目を一種類に絞るほうが、クライアントを何度も再インストールするより効果的です。

接続モードとプロトコルの種類を混同しない

ルール、グローバル、ダイレクトの各モードは通信の経路を決めます。システムプロキシとTUNは、どのアプリの通信をコアに渡すかを決めるもので、ノードのプロトコルとは別の設定です。TUNを有効にすれば、システムプロキシを参照しないアプリの通信もルール処理に渡せますが、SSがHysteria2に変わるわけではなく、サーバー側にUDP転送が自動で追加されるわけでもありません。通信を取り込む範囲を広げると、これまで表面化していなかったDNS、LANアクセス、ほかの仮想ネットワークインターフェースとの競合が起こることもあります。

一般ユーザーは、まず読み込み済みの設定で安定した接続を確認し、その後、通信を取り込む範囲を段階的に広げるのがおすすめです。デスクトップやモバイルでクライアントを選ぶときは、まずClash Plusを確認してください。Linuxデスクトップでは、ダウンロードページからClash Verge RevまたはFlClashを選べます。プラットフォーム別のリンクとインストール形式はクライアントのダウンロードページをご覧ください。ここでのおすすめは操作画面の選択肢です。同じ名前のノードでも、使うクライアントによって回線品質が変わるわけではありません。

比較する前に、何を重視するかも決めておきましょう。日常的なWeb閲覧なら初回応答と失敗率、大容量ファイルなら持続的な転送速度、リモート端末なら操作時の遅延、モバイル機器ならネットワーク切り替え後の復帰に注目します。目的を定めずに総合ランキングを追うと、不要な機能のために保守の手間を増やしかねません。プロトコルは通信経路の一部にすぎず、サーバーの負荷、出口回線の混雑、DNSの解決場所、アプリ自体がボトルネックになることもあります。

Shadowsocks：シンプルなプロトコル構成

Shadowsocksは一般にSSと呼ばれ、暗号化プロキシ転送を中心とする比較的シンプルな設定方式です。主な必須項目はサーバー、ポート、パスワード、暗号化方式です。包括的なトンネル管理システムのように、あらゆるルーティング設定を担うわけではありません。どのドメインを直接接続し、どの通信を転送するかは、通常クライアントのルールで決めます。この役割分担により基本設定を理解しやすく、リソースの限られた機器にも導入しやすくなります。ただし、実際のリソース消費は実装、暗号方式、同時接続数、通信量によって変わります。

SSの設定を確認するときは、旧式のストリーム暗号、一般的なAEAD方式、Shadowsocks 2022系を区別しましょう。単に名称が新しくなっただけではなく、鍵の形式や実装要件も異なります。特に2022方式では、パスワードに対応するアルゴリズム固有の形式や長さが求められることがあり、覚えやすい文字列に自由に置き換えられるわけではありません。コアが暗号化方式に対応していないと表示された場合は、方式名とコアの対応状況を確認してください。リスト内の別の方式に置き換えるだけでは解決しません。

SSにはプラグインを使う構成もあります。サーバー側で特定のプラグインが必要な場合、アドレス、パスワード、ポートだけを読み込んでも不十分で、クライアントが該当プラグインとパラメーターに対応している必要があります。スマホアプリで共有リンクを読み込めても、リンク内の拡張機能すべてに対応するとは限りません。UDP転送にもクライアント、サーバー、ネットワーク経路のすべてで対応が必要です。ゲームや音声通話が使えずWebページは表示できる場合は、すぐにパスワードの誤りと決めつけず、UDP転送と通信の取り込み範囲を確認しましょう。

VMess：認証と通信方式の組み合わせ

VMessはV2Rayエコシステムに由来し、ノード設定では通常UUIDをユーザー識別子として使い、プロトコル認証と下位の通信方式を組み合わせます。TCP、WebSocketなどの対応する通信方式と組み合わせ、さらにTLSを使う構成もあります。柔軟なぶん設定項目は多く、アドレスとユーザー識別子だけでなく、通信方式の名前、WebSocketのパス、リクエストのホスト名、TLSのサーバー名がサーバー側と一致しているか確認が必要です。項目が一つ欠けているだけでも、接続が待ち続けることがあります。

古い資料には、ゼロ以外のalterIdを使う旧式のVMess認証が記載されていることがあります。現在の設定ではAEAD方式が一般的で、mihomoでは通常alterId: 0と記述します。読み込みを通すためだけに、古い設定の値を機械的にゼロへ変更してはいけません。サーバー側の認証方式も一致させる必要があります。VMessでは時刻の同期も重要です。システム時刻が大きくずれていると認証に失敗することがあります。認証情報が正しいのに同じ種類のノードがすべて失敗する場合は、自動時刻設定とタイムゾーンの表示を確認しましょう。

互換性と負荷の考え方

すでに安定したSSまたはVMessのノードがあり、クライアントで設定を正しく読み込めて、普段使うアプリも問題なく動作しているなら、プロトコルの登場時期が古いという理由だけで移行する必要はありません。長く使われている設定は想定される動作を確認しやすく、問題が起きたときのチェック項目も明確です。移行を検討する理由は、コアの開発終了、必須機能の不足、サーバー側の変更、現在のネットワークで繰り返し確認できる性能問題などです。一度の速度測定の順位変動だけを理由にする必要はありません。

SSなら必ず省電力、VMessなら必ず高負荷というわけではありません。TLS、外側の通信方式、多重化、接続数、ハードウェアの暗号化機能によって結果は変わります。アイドル中に頻繁な接続確認を行うシンプルなプロトコルのほうが、適切にスリープする複雑な設定より電池を消費することもあります。近距離のVMessノードが、混雑したSSノードより速く応答する場合もあります。異なる回線での速度測定はノード選びの参考にはなりますが、プロトコルの優劣を単独で証明するものではありません。

QUICが解決するのはどの層の問題か

Hysteria2とTUICはどちらもQUICを基盤とし、通常はUDPで通信します。QUICは信頼性のある転送、安全なハンドシェイク、多重ストリームの管理をユーザー空間で実装できます。TCPの単一バイトストリームでパケットロスが起き、すべての論理ストリームが同じ順序で待たされる問題を避けられる場合があります。ただし、ネットワークの帯域は共有され、送信速度は輻輳制御の影響を受けます。多重ストリームでも各接続に専用帯域が割り当てられるわけではなく、パケットロス後の再送コストがなくなるわけでもありません。

最初に確認すべきなのはUDPの通信経路です。ゲスト用ネットワークなどでは、利用できる通信方式が限られていたり、長時間のUDPセッションが不安定になったりすることがあります。その場合、あるネットワークでは使えるノードが、別のネットワークではタイムアウトを繰り返すことがあります。システムプロキシとTUNの切り替えで変わるのは端末側の通信の取り込み方であり、外部ネットワークでUDPが許可されるわけではありません。検証済みのTCP系ノードを一つ残しておくほうが、同種のQUICノードを増やし続けるより切り分けに役立ちます。

Hysteria2：帯域設定は大きければよいわけではない

Hysteria2は、パケットロスや遅延の変動がある接続環境を想定し、認証、TLS、輻輳制御に関する機能を備えています。設定にある帯域パラメーターは、コアの実装とサーバーとのネゴシエーション方法を踏まえて解釈してください。サブスクリプションサービスが保証する帯域ではなく、数値を大きくすれば速度が上がるわけでもありません。帯域推定に基づく送信方式を使う場合、実際の回線能力を大幅に超える値を設定すると、キューイングやパケットロスが増え、同じネットワーク上のほかのアプリにも影響することがあります。

サーバーとコアが帯域情報のネゴシエーションに対応している場合は、まず提供元の設定に従いましょう。手動設定が必要なら、現在の接続ネットワークで持続的に利用できる帯域を基準にし、操作やほかの機器のための余裕を残してください。スマホがWi-Fiからモバイル回線に切り替わると、以前の推定値が適切とは限りません。HysteriaとHysteria2は、種類の名前だけを変更すれば使える同一のプロトコルではありません。読み込み時にサーバー側の世代とクライアントの実装が一致しているか確認してください。

TUIC：認証、輻輳制御、セッション管理

TUICもQUICを利用してプロキシ通信を行い、一般的な設定にはUUID、パスワード、TLSサーバー名、ALPN、輻輳制御のオプションが含まれます。プロトコルの世代や実装によって互換性に差があり、共有リンクの見た目が似ていても、クライアントとサーバーが対応するとは限りません。読み込みには成功してすぐ切断される場合は、ハートビート間隔を短くする前に、プロトコルの世代、認証情報、ALPNを確認してください。誤ったセッションを維持しようとしても、認証の問題は解決しません。

どちらのプロトコルにもUDPリレー方式、接続維持、ハンドシェイクの最適化に関するオプションがあります。0-RTT方式は確立済みのセッション情報と両端の対応に依存し、リプレイ攻撃のリスクも考慮する必要があるため、汎用的な高速化スイッチとして使うものではありません。接続の移行機能も実装やネットワーク経路に左右されます。Wi-Fiからモバイル回線に切り替えた後も、すべてのアプリの通信がそのまま維持されるとは限りません。アプリ側で再接続が必要になることもあります。

UDPが利用でき、実際にパケットロスや遅延の変動がある環境では、この2種類の方式を既存ノードと並行して試す価値があります。ただし、暗号化、タイマー、ユーザー空間でのパケット処理も必要なため、端末の負荷と電池消費は実測してください。一度の大容量ダウンロードが速かっただけで、Web閲覧、音声通話、スリープ中の動作、ネットワーク切り替えもすべて改善すると判断しないようにしましょう。性能は具体的な用途ごとに評価してください。

待ち時間を段階ごとに見る

ノード一覧の遅延は、特定の条件で行った接続確認の結果であり、あらゆるWebサイトへのアクセスにかかる時間とは異なります。実際のリクエストでは、DNSの名前解決、サーバーへの接続、プロトコル認証、TLSハンドシェイク、接続先への通信、応答待ちが発生します。接続確認によって既存接続を再利用する場合も、毎回新しい接続を作る場合もあります。ルールグループを経由する場合もあれば、ノードへ直接接続する場合もあります。クライアント間で測定条件が違う数字を、同じ基準でそのまま比較することはできません。

短いWebリクエストでは初回のハンドシェイクや接続先の応答が影響しやすく、大容量ダウンロードでは帯域、パケットロス、継続的な輻輳が表面化しやすくなります。リモート端末は、一時的なキューイングや操作の引っかかりに敏感です。多重化で接続の繰り返しを減らせても、複数のリクエストが一つの外側の接続に集中する場合があります。混雑時に使い勝手が改善するかどうかは、通信方式と実装によって異なります。最初の表示、再アクセス、継続的なデータ転送をそれぞれ確認し、ダウンロード速度一つで日常の使い勝手を評価しないようにしましょう。

リソース消費はプロトコル名だけでは決まらない

プロセッサの暗号化命令への対応、OSのネットワークスタック、コアの実装、接続数、ログレベルは、いずれもリソース消費に影響します。デスクトップでは目立たない設定が、古いスマホやルーターではボトルネックになることもあります。QUICではユーザー空間の処理やタイマーが負荷になる一方、従来型のプロトコルもプラグイン、多重のカプセル化、多数の同時接続によって負荷が増える場合があります。すべての機器に共通するメモリ使用量や消費電力を、プロトコルごとに一つの数値で示すことはできません。

タスクマネージャーを見るときは、クライアントの画面とコアのプロセスを分けて考えましょう。画面のアニメーション、ログの更新、サブスクリプションの解析、バックグラウンド更新は画面側のプロセスに負荷をかけることがあります。一方、実際の転送処理は別のプロセスで実行される場合があります。測定前に不要なリアルタイムログを停止し、サブスクリプションの更新が終わるのを待って、アプリのタスクを統一してから、CPU使用率とメモリ使用量の推移を確認してください。起動直後のピークだけでは長時間利用時の負荷を判断できません。

スマホの電池消費は起動頻度が影響する

モバイル機器では暗号化の負荷に加えて、無線モジュールが動作している時間も重要です。頻繁な稼働確認、短い間隔のハートビート、繰り返される接続失敗、複数のルールグループによる同時測定は、端末を何度もスリープから起こすことがあります。通信量が少なくても省電力になるとは限りません。不要な確認を減らし、重複するサブスクリプション更新を避けたうえで、実際の切断状況に応じて接続維持を調整するほうが、プロトコルを変えるだけより効果を検証しやすくなります。

AndroidのVpnServiceは、クライアントがシステムの通信を受け取るために使われます。権限を許可しても、システムがアプリのバックグラウンド動作を常に認めるとは限りません。バッテリー最適化、メーカー独自のバックグラウンド管理、自動起動の設定が、復帰の速さに影響する場合があります。詳しくはAndroidのバックグラウンド動作に関する設定をご覧ください。バックグラウンド動作の許可で解決するのはプロセスの維持であり、電池消費の問題すべてがこの権限に起因するわけではありません。検証のためにシステムの省電力機能をすべて長期間無効にする必要もありません。

比較するときは候補のノードを順番に使い、ネットワーク、時刻、接続先、失敗状況を記録します。普段使う用途を少なくとも一通り試してください。ノードごとにサーバーが異なる場合、結論は「現在の条件ではこのノードが適している」とし、特定のプロトコルが常に速いとは判断しないようにしましょう。スマホの評価では、モバイル回線の電波強度と画面の電池消費にも注目してください。こうした条件が大きく変わる場合、システムの電池使用量の統計だけではプロトコルによる差を独立して証明できません。

URL、ノード一覧、完全な設定ファイル

サブスクリプションURLはリソースを取得するための入口であり、返される内容に統一規格があるわけではありません。完全なClash YAMLが返る場合もあれば、複数の共有リンクをエンコードした一覧が返る場合や、リクエストヘッダーによって形式が変わる場合もあります。完全な設定には通常、ノード、プロキシグループ、ルール、DNS設定が含まれます。一方、ノード一覧はノード情報のみを提供します。この2つを取り違えると、ノードは表示されても想定したプロキシグループがない、または読み込み時に必須の構造が不足していると表示されることがあります。

proxy-providersは外部リソースからノードを読み込み、プロキシグループから参照するために使います。rule-providersはルールセットを提供します。どちらも、完全なサブスクリプションURLを入れれば自動で内容が分割される機能ではありません。特にルールプロバイダーでは、宣言した動作とファイル形式を一致させる必要があります。ドメイン一覧、IP一覧、ルール一式を同じ形式として扱うことはできません。問題を調べる前に、実際に返されたリソースの構造を確認し、参照先と一致しているかチェックしましょう。

変換時に失われやすい情報

サブスクリプションを変換するには、元の形式を移行先のコアが認識できる項目に対応付ける必要があります。基本的なアドレスやパスワードは保持されやすい一方、新しいプロトコルのオプション、プラグインのパラメーター、ALPN、flow、REALITYの設定、一部のUDP通信オプションは非対応の場合があります。変換に成功したという表示は、移行先の形式を生成できたことを示すだけで、ノードの情報がすべて保持された保証にはなりません。特定の種類のノードがまとめて失敗する場合は、同じ内容を繰り返し変換するのではなく、元のノード情報と読み込み後の詳細を項目ごとに比較してください。

提供元がmihomo向けの設定を直接提供している場合は、中間変換を減らすためにその形式を優先しましょう。変換が必要な場合は、変換ツールが該当するプロトコルに対応しているか、ルールのテンプレートやDNS設定を置き換えていないかを確認してください。サブスクリプションURLに個人用のアクセス認証情報が含まれることがあります。データの取り扱いが分からないサービスに送信したり、公開スクリーンショット、問い合わせ、ログの添付にURL全体を含めたりしないでください。

小さな設定例で構造を把握し、未知の項目をつなぎ合わせない

以下はmihomoで読み込める、ダイレクト接続用の最小設定例です。待ち受けポート、プロキシグループ、ルールの関係を示しており、リモートノードを含まず、リモートプロキシへの接続も行いません。バックアップを取ったうえでテスト用ファイルに保存し、構文を確認する用途に適しています。使用中のサブスクリプション設定を上書きしないでください。実際のノードは信頼できる提供元から取得してください。この設定例の名前を変更しても、実在するノードにはなりません。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
proxy-groups:
  - name: Route
    type: select
    proxies:
      - DIRECT
rules:
  - MATCH,Route

YAMLではインデントが階層を表し、リストのハイフンや同じ階層のキーの位置も意味を左右します。複数のサブスクリプションを結合すると、同名のノードによってプロキシグループの参照先が分かりにくくなり、同名のグループが既存の定義を上書きすることがあります。ルールの順序が変われば、最初に一致するルールも変わります。2つのファイルを単純に連結してはいけません。取得元ごとに分かりやすい名前の範囲を設定し、参照先のグループがすべて存在することを確認して、最終ルールが想定したフォールバック項目で終わっているかチェックしましょう。

更新の失敗が必ずしも形式の問題とは限りません。リクエストのタイムアウト、認証の失効、ログインページの返却、リモートルールセットへの一時的なアクセス不能などが原因の場合もあります。まずダウンロード状態と応答の種類を確認し、その後で解析エラーを調べましょう。サブスクリプション更新の失敗とノードのハンドシェイク失敗を混同しないでください。更新に関するよくある問題はサブスクリプションに関する質問をご覧ください。設定の切り替えとバックアップについてはProfile入門も参照できます。

動作する設定のスナップショットを一つ保存しておくことも重要です。バックアップにはサブスクリプションURLだけでなく、ローカルルール、プロキシグループの選択、上書き設定も含めてください。トラブルシューティング用の情報を共有するときは、プロトコルの種類、項目名、失敗した段階を残しつつ、認証情報、個人用ドメイン名、サブスクリプションの認証情報は削除します。これなら設定構造の問題を再現しやすく、復旧作業で認証情報を再設定する手間も防げます。

デスクトップとLinuxでの普段使い

主にブラウザー、コード管理、デスクトップ作業で使う場合は、保守状況が明確で、サブスクリプションを正しく読み込めるクライアントを選び、手元にあるSS、VMess、Trojan、VLESSのノードから安定したものを一つ選びましょう。複数の機器で使う場合はClash Plus、Linuxデスクトップではディストリビューションに合わせてClash Verge RevまたはFlClashを確認してください。新しいプロトコルが必要かどうかは、実際の問題や機能要件に基づいて判断します。すべての種類をそろえることが、設定を完成させる条件ではありません。

Linuxでは、アプリがシステムプロキシの設定に従うかどうかも確認が必要です。ブラウザーではアクセスできてもターミナルのツールで失敗する場合、ターミナルがプロキシ環境変数を読み込んでいないことがあります。コンテナや独立したネットワーク名前空間にも、デスクトップの設定が自動で引き継がれるわけではありません。まず通信を取り込む入口を確認し、必要に応じてTUNモードのチュートリアルに沿って権限やルーティングを設定してください。リモートサーバーやルーターでは、サービス管理に慣れたユーザーならコアを直接実行できます。一般的なデスクトップ利用にはGUIクライアントが適しています。

モバイルネットワーク、リアルタイムアプリ、大容量ファイル

スマホがWi-Fiとモバイル回線の間を頻繁に切り替える場合は、最初の速度測定だけでなく、接続の復帰、バックグラウンドでの動作、電池消費を確認しましょう。UDPが安定して使えるなら、Hysteria2やTUICも候補に加えられます。特定の接続ネットワークでタイムアウトが頻発する場合は、検証済みのTCP系ノードを予備として残してください。サーバー側の対応を確認せずに、すべてのノードで多重化を強制したり追加の通信オプションを有効にしたりすると、別々だった問題が同時に発生することがあります。

音声通話、会議、ゲームでは、実際のUDP対応状況、ジッター、一時的な遅延を確認しましょう。プロトコル名にQUICが含まれていても、すべてのリアルタイムアプリで効果があるとは限りません。アプリのサーバーの場所、転送経路、システムが通信を取り込む範囲も影響します。大容量ファイルでは継続的な転送速度と端末の発熱を確認し、操作が必要なアプリの帯域も確保してください。回線速度を最大限に引き出せるノードでも、家庭で複数人が共有するときの最適な標準設定とは限りません。

一連のテストで継続利用する価値を判断する

現在使える設定を保存し、候補ノードを一つ選んで、接続ネットワークとテスト先を固定します。Webページへのアクセス、継続的なデータ転送、普段使う操作を一つずつ試し、接続ログでプロキシグループ、適用ルール、実際の出力先を確認してください。リクエストが候補ノードを通っていると確認できてから、使い勝手の差を結果として記録します。ルールによって接続先が直接接続されている場合、測定結果は選んだプロトコルと関係ありません。まずテスト条件を修正してください。

失敗したら段階ごとに確認し、そこで一度止めましょう。読み込みに失敗する場合は形式、起動に失敗する場合は設定項目と参照先、ハンドシェイクに失敗する場合はアドレス、認証、TLSを確認します。リクエストの応答がおかしい場合は接続先サービスとルールを、特定のアプリだけ失敗する場合はシステムが通信を取り込む範囲とDNSを調べてください。一度に一つの段階だけを修正し、成功してから次へ進みます。接続ログには宛先アドレスなどが記録されることがあります。確認が終わったら日常利用に適したログレベルへ戻し、詳細を収集するために高頻度のログ出力を続けないでください。

最終的に使う方式は、現在の用途に適している理由を説明できるものであるべきです。たとえば、既存のサブスクリプションと互換性がある、モバイルネットワークの切り替え後に安定して復帰する、大容量ダウンロードが安定する、保守項目が少ないといった理由です。比較方法やノードの速度測定については速度測定と動作確認のチュートリアルをご覧ください。クライアント画面の違いはクライアント比較ページで確認できます。プロトコル、コア、画面はそれぞれ異なる問題を解決します。この3つの層を分けて考えるほうが、単一のランキングを追いかけるより役立ちます。