Clashプロトコルとカーネルのリファレンス

01 · DECISION MODEL

まずプロトコル選びの枠組みを作る

プロトコル名は速度ランキングではない

Clash Plus、Clash Verge Rev、FlClashなどのクライアントでノードの横に表示されるSS、VMess、Trojan、VLESS、Hysteria2、TUICは、まずクライアントとサーバー間のデータ交換に使うプロトコル構造を示すもので、速度順に並べられる製品一覧ではありません。実際の接続性能は、サーバーの処理能力、回線の往復遅延、パケットロス、混雑状況、トランスポート層、暗号化実装、クライアントのカーネル、端末性能などに左右されます。同じプロトコルでも回線やサーバー負荷によって結果は大きく異なり、異なるプロトコルでも安定したネットワークでは近いウェブ閲覧体験になることがあります。

したがって、プロトコルはまず「互換性があるか」を確認し、次に「現在のネットワークに合うか」を見て、最後に速度を比較します。互換性には、クライアントのカーネルがプロトコルをサポートしているか、サブスク変換で必要なフィールドが保持されるか、トランスポート層の組み合わせが実装されているか、端末のOSがUDPやQUICセッションを正常に確立できるかが含まれます。インポート時点で重要なフィールドが失われていれば、その後の速度測定に意味はありません。一般ユーザーには、サブスク提供元が検証した完全な設定を使うほうが、手作業で別プロトコルへ書き換えるより安全です。プロトコル名を1か所変更するだけでは変換できません。

影響要因を4つの層に分ける

第1層は基礎ネットワークです。固定回線は遅延やパケットロスが比較的安定し、TCP系の方式で滑らかな通信になりやすい一方、モバイルデータ、公共Wi-Fi、異なる通信事業者をまたぐ回線では瞬間的なパケットロスやネットワーク切り替えが起こります。この場合、UDPベースで輻輳制御に対応するHysteria2やTUICが適応しやすいことがありますが、UDPを安定して通せることが前提です。第2層はサーバーと回線です。同じプロトコルでも、サーバーのCPU飽和、出口の混雑、遠回りなルーティングがあれば、クライアント側のパラメータ変更でボトルネックは解消できません。

第3層はプロトコルとトランスポートの組み合わせです。VMessやVLESSはTCP、WebSocket、gRPCなどと組み合わせられ、VLESSはTLSやREALITYなどのセキュリティ層と併用されることもあります。SSは比較的シンプルな暗号化プロキシ構造、TrojanはTLSの仕組み、Hysteria2とTUICはQUICやUDPを軸とした方式です。第4層はクライアント実装です。mihomoは新しいプロトコルやルール機能をより広くサポートしますが、古い公式Clashでは設定機能に制限があります。プロトコルを選ぶときは4層をまとめて考え、ネットワーク、回線、カーネルの問題をすべてプロトコル名のせいにしないことが重要です。

テスト時に記録する項目

クライアントの遅延テストは通常、1回の探測リクエストしか反映せず、長時間接続のスループットや安定性を十分に示しません。実用的なテストには、複数サイトを初めて開いたときの応答、一定時間ダウンロードした際の速度変動、動画や会議中の途切れ、画面ロックから復帰した後の再接続速度を含めます。毎回変える要素は1つにします。たとえば同じネットワークとサーバーでプロトコルだけ比較する、またはプロトコルを固定してWi-Fiとモバイルデータを比べます。ノード、ネットワーク、クライアント、プロトコルを同時に変えると、改善した層を特定できません。

さらに、ログで失敗箇所を確認します。ドメイン名解決エラー、接続タイムアウト、認証失敗、TLSハンドシェイクエラー、UDP到達不能は、それぞれ異なる問題を示します。ログが認証失敗を示している場合、グローバルモードを何度切り替えても解決しません。DNS解決に異常がある場合も、プロトコル変更が有効とは限りません。ログ画面とプロキシ・設定画面の対応関係は、Clash Vergeの画面と機能を一覧で確認できます。このように層ごとに確認すれば、プロトコル選びは「どの名前を試すか」ではなく、再現可能で検証できる技術的判断になります。

03 · CURRENT OPTIONS

VLESS、Hysteria2、TUICの適用範囲

VLESS：認証層と暗号化層を分けて考える

VLESSはUUIDなどでクライアントのIDを示しますが、プロトコル自体はVMessと同じ内蔵暗号化の仕組みを提供せず、実際の通信の安全性は通常TLS、REALITYなどの外側の仕組みによって担保されます。VLESSを理解するには、プロトコル、トランスポート層、セキュリティ層を分けて考える必要があります。VLESSは認証と転送構造の一部を、TCP、WebSocket、gRPCなどは搬送方式を、TLSやREALITYは対応する安全なハンドシェイクを決めます。クライアント一覧にVLESSとだけ表示されていても、設定を展開してnetwork、tls、servername、reality-opts、flowなどを確認してください。

VLESS設定のflowは、自由に入力できる性能スイッチではありません。特定の組み合わせでは決められたフロー制御値を使うため、クライアント、サーバー、基盤実装が一致している必要があります。誤った値は通常、ハンドシェイクやデータ転送の失敗につながります。REALITY設定にはpublic-key、short-id、servernameが含まれることがあり、これらは連動しています。サブスク変換でフィールド名が書き換えられたり、空値の削除時に必要なパラメータまで消えたり、古いクライアントが構造を認識できなかったりすると、「ノードはあるのに接続できない」状態になります。そのためVLESSは、mihomo対応の現代的なクライアントで完全な設定をインポートするのが適しており、古いClashのサンプルをコピーして手作業で組み立てる方法は避けてください。

Hysteria2：パケットロスの多い回線を想定したQUIC方式

Hysteria2はUDPベースのQUICトランスポート上で動作し、現代的な輻輳制御と多重化によって、遅延、ジッター、パケットロスが目立つ回線への適応を目指します。ただし、すべてのネットワークで速くなるわけではありません。UDP経路が安定し、サーバー帯域が十分で、パラメータも適切なら継続通信で良好なスループットを保てます。一方、ローカルネットワークがUDPを制限したり、経路品質が悪かったり、中間機器がUDPセッションを頻繁に破棄したりすると、接続タイムアウト、速度変動、復帰の遅延が起こる可能性があります。

代表的な設定フィールドには、サーバーアドレス、ポート、認証情報、TLS server name、証明書検証、帯域幅関連のパラメータがあります。帯域幅の値は輻輳制御が送信ペースを判断するための補助であり、数字を大きくするほど速くなるわけではありません。実際の回線能力を大幅に上回る値はキューイングやパケットロスを招き、低すぎる値はスループットを制限します。新しい実装ではモードに応じて自動調整されることもあるため、サブスクで配布された値を使うほうが安全です。ログにUDP timeoutが出た場合は、帯域幅を何度も増やすのではなく、まず別のネットワークで試し、システムのファイアウォール、ルーター、サーバー側ポートを確認してください。

TUIC：低遅延セッションとUDPトランスポート

TUICもQUICとUDPを基盤とし、接続の素早い確立、多重化、ヘッドオブラインブロッキングの軽減を重視します。設定には通常、UUID、パスワード、サーバー名、輻輳制御オプション、UDPリレー方式などが含まれます。実装や設定世代によってフィールドが異なることがあるため、サブスクのプロトコル識別子、バージョンの意味、認証構造をサーバーと一致させる必要があります。mihomoは一般的なTUIC設定を認識できますが、古いカーネルやクライアントでは解析できない場合があります。インポート後に無視されてもサブスクが空とは限らず、カーネルがそのノード種別をサポートしていない可能性があります。

TUICは、セッションを頻繁に確立し、ネットワーク品質に変動があり、UDPを利用できる環境に適していますが、TCPプロトコルの全面的な代替ではありません。企業Wi-Fi、ゲストネットワーク、一部のモバイルネットワーク、厳格に設定されたルーターではUDPが制限されることがあります。その場合、TUICとHysteria2が同時に使えなくなる可能性があります。実際の設定ではSS、TrojanなどのTCPトランスポートノードをフォールバックとして残してください。音声、ゲーム、リアルタイム通信では、「クライアントからサーバーまでUDPを使うこと」と「対象アプリがUDP転送されること」を分けて考える必要があります。前者が利用できても、後者のルールやポリシーが正しいとは限りません。

proxies:
  - name: "VLESS-Reference"
    type: vless
    server: node.example.invalid
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: tcp
    tls: true
    servername: node.example.invalid

  - name: "Hysteria2-Reference"
    type: hysteria2
    server: node.example.invalid
    port: 443
    password: "your-password"
    sni: node.example.invalid

上記の断片は、mihomo YAMLにおけるフィールド階層を示すためのものです。アドレス、ID、パスワードは説明用の値であり、そのまま接続には使えません。実際のサブスクでは、VLESSにREALITYパラメータが追加されたり、Hysteria2にポート範囲や帯域幅設定が加わったりするなど、異なる組み合わせが使われます。設定を編集したら、まずクライアントの設定検査機能を実行し、ログにunsupported、missing field、authentication、handshakeなどが出ていないか確認してください。サブスク由来の設定は、提供元で修正するか、対象形式に明確に対応した変換方法を優先し、更新のたびにローカル変更が上書きされる状態を避けます。

05 · MOBILE AND PLATFORM

モバイルの電池、ネットワーク切り替え、プラットフォーム差

電池消費は継続動作の仕方で決まる

モバイル端末の電池消費を、暗号化の強さだけで判断することはできません。主な要因は、無線モジュールがアクティブでいる時間、接続の再確立頻度、バックグラウンドのキープアライブ方法、総データ通信量、DNS問い合わせ数、ルール照合の負荷、CPU処理時間です。あるプロトコルが短時間で処理を終えて無線モジュールを低消費電力状態に戻せるなら、一時的なCPU使用率が少し高くても総消費電力は低くなることがあります。逆に不安定なネットワークで再送や再接続を続けるプロトコルは、1回の処理が軽くても電池を多く消費する可能性があります。

SSは設定がシンプルで回線が安定している場合、処理負荷を低く抑えやすい方式です。Trojan、VMess、VLESSをTLSと組み合わせるとハンドシェイクと暗号化のコストが発生しますが、長時間接続を正常に再利用できれば、継続利用での差は目立たないことがあります。Hysteria2とTUICはUDPまたはQUICセッションを維持するため、ネットワークが安定していれば待ち時間を減らせます。一方、基地局の切り替え、ルーターによるUDPマッピングの破棄、バックグラウンド制限が頻発すると、セッション再構築による復帰回数が増えます。実際の電池消費はAndroidメーカーのバックグラウンド制限、iOSのネットワーク拡張機構、クライアント実装にも左右され、プロトコル名だけでは予測できません。

Android：バックグラウンド制御とVPNサービス

Androidクライアントは通常、システムのVPNサービスを通じて通信を引き受けます。Clash Plus、Clash Meta for Android、FlClash、Surfboardは画面や機能範囲が異なりますが、いずれもシステムの省電力設定、バックグラウンド権限、メーカー独自のプロセス管理の影響を受けます。画面ロック後に通信が切れる場合は、まずクライアントが動作し続けているか、VPNアイコンが残っているか、システムがバックグラウンドの電池使用を制限していないかを確認し、その後でプロトコルを調べます。アプリのプロセスがシステムに停止された場合、別のプロトコルへ変えても根本原因は解決しません。

AndroidではIPv6、プライベートDNS、アプリごとのプロキシ、テザリングにも注意が必要です。一部のアプリがIPv6を直接利用し、設定がIPv4だけを処理していると、特定のアプリだけ接続できないことがあります。プライベートDNSとクライアントのDNSハイジャック設定が併用されると、想定と異なる名前解決経路になる場合があります。アプリごとのプロキシはカーネルに入る通信範囲を変えるため、プロトコルをテストする際は対象アプリが実際に含まれているか確認してください。モバイルデータでHysteria2やTUICに異常がある場合はWi-Fiに切り替えて再テストし、Wi-Fiでは正常でモバイル回線だけタイムアウトが続くなら、UDP経路とネットワークポリシーを優先して確認します。

iOS：システムのネットワーク拡張と前後切り替え

iOSクライアントはシステムが提供するネットワーク拡張機能に依存し、接続状態、メモリ予算、バックグラウンド動作はシステムが一元管理します。本サイトのダウンロード一覧ではiOS向けの推奨クライアントをClash Plusとしており、iOSダウンロード欄からApp Storeへ移動できます。使用時は、システム設定のVPN状態、クライアント設定が有効か、Wi-Fiとモバイルネットワークの切り替え後に自動復帰するかを確認してください。iOSでは一般ユーザーがデスクトップと同じプロセス制御の詳細を確認できないため、調査の中心はシステムVPNの状態、設定ログ、ネットワーク切り替え後の結果になります。

モバイル端末でUDP系プロトコルを使うと、ネットワーク切り替えによってローカルアドレスとNATマッピングが変わります。QUICには接続変化を扱う仕組みがありますが、スムーズに復帰できるかはクライアント、サーバー、ネットワーク経路次第です。切り替え後も長時間復帰しない場合は、クライアントを切断して再接続し、ログにtimeoutが繰り返し出ていないか確認してください。TCP系ノードはすぐ復帰するのにUDP系だけ失敗し続けるなら、現在のネットワークがUDPセッションに適していないため、一時的にTCPのフォールバックを使います。

デスクトッププラットフォームで重視する違い

Windows、macOS、Linuxでは通常、スマートフォンの電池やバックグラウンド停止の問題はありませんが、システムプロキシ、TUN権限、ファイアウォール、スリープ復帰が重要です。Windowsの一部アプリはシステムプロキシに完全には従わないため、TUNモードやアプリ側の設定が必要です。ストアアプリはループバック制限の影響を受けることがあり、Windows UWPアプリのループバック制限を確認できます。macOSではシステムプロキシと仮想ネットワークインターフェースを区別し、スリープ後に接続が不安定ならシステムプロキシまたはTUNを再起動します。Linuxではデスクトッププロキシ設定、ルーティング権限、systemdサービスの状態、DNS管理コンポーネントを重点的に確認してください。

モバイルの電池消費を評価する際は、数分間の瞬間的なパーセンテージではなく、システムの電池統計で1回の利用サイクル全体を観察することをおすすめします。画面使用時間、データ量、アプリのタスクを近い条件に揃え、候補プロトコルを個別にテストしてください。信号が弱いときに端末が発熱し続けたり、バックグラウンド動作時間が明らかに増えたり、復帰後に再接続を繰り返したりする場合は、安定したノードへ変更するかフォールバックを使います。電池性能はプロトコル、ネットワーク、クライアント、システムスケジューリングの結果であり、抽象的な最低負荷を追うのではなく、無駄な動作を減らすことが選定の目標です。

07 · SUBSCRIPTION

サブスク形式と設定互換性の確認

サブスクURLが固定形式を意味するわけではない

「サブスクURL」は設定を取得する方法を指すだけで、返却内容が常に同じ形式になるとは限りません。サーバーは完全なClash YAML、ノードだけのYAML、エンコードされたURI一覧、特定クライアント向けに生成された設定を返すことがあります。クライアントにインポートする際は、まず内容を取得し、レスポンス形式に応じて解析します。ブラウザでURLを開けても、サーバーがデータを返していることしか確認できず、現在のクライアントやカーネルに適合するとは限りません。

完全なClashまたはmihomo設定には通常、プロキシノード、ポリシーグループ、ルール、DNS、ポート設定が含まれます。ノードサブスクはproxiesデータだけで、ポリシーグループやルールをクライアントのテンプレートで補う場合があります。URI一覧では、ss://、vmess://、trojan://、vless://、hysteria2://、tuic://などの形式でノードを表します。URIごとに複雑なトランスポートパラメータの表現力や実装の一貫性が異なるため、変換時にはpath、SNI、ALPN、フィンガープリント、REALITY、輻輳制御のフィールドが失われやすくなります。

インポート前後に行う4つの確認

1つ目はレスポンス状態です。インポートに失敗したら、サブスクURLに余分な空白がないか、アクセス時にログインページ、エラーページ、空の内容が返っていないか確認します。2つ目はノード数とプロトコル種別です。想定していたHysteria2、TUIC、VLESSのノードが解析段階で消えていないか確認します。3つ目は重要フィールドです。ノードを1つ展開し、サーバー、ポート、認証、TLS、トランスポート設定を確認します。4つ目はポリシーグループです。ノードが正常に解析されても現在のポリシーグループに追加されなければ、プロキシ画面には古いノードしか表示されないことがあります。

サブスク更新は、設定を再取得してマージする処理です。更新後にローカル変更が消えるなら、その変更がサブスク管理範囲に含まれていたということです。毎回生成ファイルを直接編集するのではなく、クライアントのオーバーライドまたは設定マージ機能を使ってください。更新後にノードが重複する場合は、同じ内容のサブスクを複数有効にしているか、古い設定が置き換えられていない可能性があります。更新時刻が変わってもノード内容が変わらない場合は、ログとレスポンスキャッシュを確認し、サブスクサービスが新しい内容を返しているか確認します。入口の操作方法とエラー分類はClashサブスクURLのインポート方法も参照してください。

フィールドが欠落した場合の切り分け

まず、サブスクの元データとクライアントにインポートした後のノード詳細を比較します。元データの時点でフィールドが欠けていればサブスク生成側の問題です。元データが完全なのにクライアントで欠落するなら、クライアントのパーサー、サブスク変換、カーネル対応に原因がある可能性があります。VMessとVLESSではnetwork、servername、ws-opts、grpc-opts、reality-opts、flowを重点的に確認します。Trojanではpassword、sni、TLS、SSではcipher、password、plugin、Hysteria2とTUICでは認証、SNI、輻輳制御、UDP関連オプションを確認してください。

次に設定検査のエラーを確認します。YAMLはインデントに敏感で、リスト項目、マッピング、文字列の階層を誤ると設定全体を読み込めなくなります。ノード名にコロン、シャープ、特殊文字が含まれる場合は、引用符で囲むと曖昧さを減らせます。ブール値、数値、文字列も混同しないでください。たとえばポートは数値として扱い、UUID、パスワード、パスは通常文字列にします。手動編集後は、まずカーネルに構文チェックを行わせ、その後でシステムプロキシを起動して、形式エラーをネットワーク障害と誤認しないようにします。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: "プロトコル選択"
    type: select
    proxies:
      - "VLESS-Reference"
      - "Hysteria2-Reference"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,プロトコル選択
  - MATCH,プロトコル選択

この設定例は、ポリシーグループとルールがノード名を参照する仕組みを示しています。参照名は大文字・小文字や空白を含め、proxies内の名前と完全に一致させる必要があります。ノード名を変更すると、ポリシーグループ内の古い名前は無効になります。実際の設定にはDNS、ルールプロバイダー、より多くのポリシーグループも含まれますが、切り分けでは最小構成に絞り、まず1つのノードで接続を確立してから他の部分を戻すと安全です。内容不明の設定を大量にコピーすると、複数の変数が同時に増えて問題箇所を判断しにくくなります。

サブスク変換の限界

変換ツールはコンテナ形式を別の形式へ書き換えられますが、サーバー側のパラメータを新たに補ったり、プロトコルそのものを別のプロトコルへ変換したりはできません。可能なのは、フィールドのマッピング、ポリシーグループの生成、ノードの絞り込み、名前の調整です。新しいプロトコルや拡張トランスポートへの対応は変換ツール自体の実装に依存します。ツールがフィールドを認識しなければ、元のサブスクが正しくても出力は不完全になる可能性があります。VLESS REALITY、Hysteria2、TUICを扱う場合は、サーバーが直接提供するmihomo形式を優先し、更新後に重要フィールドを抜き打ちで確認してください。

サブスクが空、形式を認識できない、更新に失敗するといった場合は、まずよくある質問のインストール・設定カテゴリを確認してください。切り分けの順序は、URLにアクセスできる、レスポンス内容が正しい、形式を認識できる、カーネルがプロトコルに対応している、重要フィールドが揃っている、ノードがポリシーグループに入っている、接続ログが正常、の順に保ちます。この順で層ごとに確認するほうが、クライアントを何度も削除して再インストールするより根本原因を見つけやすくなります。