Clashのプロトコルとコア技術リファレンス

01 / DECISION MODEL

まず、プロトコル選びを4つの問いに分ける

プロトコル名だけでは実際の使用感は決まらない

ClashクライアントでSS、VMess、Trojan、VLESS、Hysteria2、TUICを見かけると、どれが「新しいか」「速いか」を比べたくなります。しかし、この順番では判断を誤りがちです。プロトコルが定めるのは、セッションの確立方法、データのカプセル化、認証、転送処理です。実際の使用感は、サーバーの出口、利用者からサーバーまでの経路、ノードの負荷、輻輳制御、クライアントのコア、接続先サイトまでの経路にも左右されます。経路が短く負荷が低い従来型プロトコルのノードが、設定の粗い新しいプロトコルのノードより安定することも十分にあります。プロトコルは要因の一つであり、結果を単独で決めるラベルではありません。

より確実なのは、4つの問いに分けて考える方法です。第一に、基盤がTCPかUDPか、現在のネットワークのパケットロスやジッターに適しているか。第二に、クライアントのコアがプロトコルと追加パラメータを完全に認識できるか。第三に、端末を長時間バックグラウンドで動かす必要があるか、CPUのウェイクアップ、継続的な送受信、接続移行の負荷を許容できるか。第四に、サブスクリプション提供元が対応するサーバー実装とパラメータを用意しているか。どれか一つでも成立しなければ、机上の利点は実際の接続に反映されません。

トランスポート層がトラブルの形を決める

SS、VMess、Trojan、VLESSの一般的な構成はTCPを基盤とし、TLS、WebSocket、gRPCなどを組み合わせる場合があります。TCPは信頼性のある転送、順序制御、輻輳制御を備え、Web閲覧、ダウンロード、コードホスティングなど多くの用途に適しています。一方、内側のアプリケーションもTCPを使う場合、パケットロスによって複数層の再送やヘッドオブラインブロッキングが起こることがあります。単純に「TCP over TCPは必ず遅い」と決めつけることはできません。実際のプロキシ実装は通常バイトストリームを転送しており、2つの完全なTCP状態機械を機械的に入れ子にしているとは限らないためです。ただし、帯域遅延積が大きい環境やパケットロスの多い回線では、復旧速度が制限される可能性があります。

Hysteria2とTUICはUDPを使用し、QUICまたはそれに近い仕組みで信頼性のあるストリーム、多重化、暗号化を提供します。高遅延、ランダムなパケットロス、TCPの輻輳制御からの復旧が遅い回線で、特に強みを発揮します。一方で、UDPを制限するネットワークもあります。ルーターのUDPセッション保持時間が短い場合もあり、モバイルネットワーク切り替え後に接続をスムーズに移行できるかは実装次第です。「UDPプロトコルは速い」ではなく、「UDPが利用でき、回線特性が合っている場合にスループットを維持しやすい」と理解してください。

ノード、プロトコル、トランスポート、コアは別の層

ノードは接続可能なサーバーインスタンス、プロトコルは認証とデータのカプセル化、トランスポートまたは伝送方式はTCP、UDP、TLS、WebSocketなどの経路、コアはサブスクリプションの項目を実際の接続へ変換する役割を担います。クライアントの画面ではこれらが一つのノード名に圧縮されるため、「特定のノードに接続できない」ことを「プロトコル全体が使えない」と誤解しやすくなります。切り分けでは、まず同じプロトコルの別ノード、次に同じノードグループの別プロトコルへ切り替え、最後にクライアントのコアとサブスクリプション項目を確認します。一度に一つの変数だけを変更すると、結論が明確になります。

たとえばVLESSノードには、TLS、フロー制御、サーバー名、トランスポート種別が同時に設定されていることがあります。そのうち一つを削除すると、表示上のプロトコル名はVLESSのままでも、ハンドシェイクの動作は変わります。Hysteria2でも、認証、サーバー名、ポートホッピングの範囲、帯域幅のヒントは具体的な実装パラメータです。ノード名にある「高速」「専用線」といった文字だけでは技術的な判断材料になりません。設定を開いて実際の項目を確認するか、クライアントのノード詳細でプロトコル種別を確認してください。

テスト対象と時間帯を固定する

プロトコルを比較する際は、ノードの地域、テスト対象、クライアントのモード、時間帯を固定します。まずクライアントの遅延テストで到達性を確認し、実際のWeb閲覧、継続ダウンロード、動画のシーク、ネットワーク切り替えで使用感を確認します。遅延値は通常、テストURLまでの一度のハンドシェイク経路を測ったもので、帯域幅を示すものではありません。詳しい仕組みは「Clashの遅延テスト値はどう算出されるのか」を参照してください。同じノードを3～5回連続で測定し、変動幅を記録するほうが、一度だけ出た最低値を追うより有効です。

最終的な選択を一つのプロトコルに固定する必要もありません。サブスクリプションには、日常用の安定したノード群、高パケットロス環境向けの予備ノード群を残し、url-testまたは手動選択グループで管理できます。ルールはトラフィックの行き先を決め、プロトコルはグループ内のノードがどのように通信するかを決めます。役割は別です。この関係を理解すれば、プロトコル選びは「どれかに肩入れする」問題ではなく、検証可能なエンジニアリング上の判断になります。

02 / TCP FAMILY

SS、VMess、Trojan、VLESSの設計上の選択

Shadowsocks：シンプルな構成と成熟した運用実績

Shadowsocksは通常SSと略されます。事前共有鍵で暗号化プロキシを実現するのが基本的な考え方で、プロトコル構造は比較的コンパクトです。サーバーとクライアントの実装が多く、必要なリソースも管理しやすい特徴があります。一般的なWeb閲覧、ダウンロード、長時間のバックグラウンド接続では、突出した最高速度よりも、構成要素が少なく設定項目が絞られ、運用実績が豊富である点が強みです。ノード情報には通常、サーバー、ポート、パスワード、暗号化方式が含まれます。現代の実装では、クライアントとサーバーが共に対応するAEAD系の暗号化方式を使用し、古いストリーム暗号の設定は新規構築の基準にしないことを推奨します。

SSがシンプルでも、あらゆる伝送上の問題を解決するわけではありません。プラグインを組み合わせるか、UDPを使うか、サーバーでUDP転送を正しく有効にしているかは構成次第です。同じSSでも、暗号化方式、プラグイン、サーバー実装が異なれば使用感は大きく変わります。Clashへのインポート後、TCPのWeb閲覧は正常なのに音声やゲームだけ不安定な場合は、DNSをすぐ変更するのではなく、ノードのUDP対応とクライアントのTUN設定を確認してください。

VMess：高機能だが項目の組み合わせが多い

VMessはV2Rayエコシステムで広く使われてきたプロトコルで、ユーザーID、認証、時刻に関する検証を備え、TCP、WebSocket、HTTP/2系の伝送、TLSなどと組み合わせて利用されます。複数の伝送方式を統一された設定体系に取り込んだ点に歴史的な価値があり、多くのサブスクリプションサービスで現在もVMessノードが提供されています。一方で項目が多く、ユーザーID、alterId、暗号化項目、伝送種別、パス、Host、TLS、サーバー名などのどれか一つが一致しないだけでも、ハンドシェイクに失敗することがあります。

古い解説では、過去の項目を必須設定として扱っていることがあります。しかし現代のサーバーは異なるデフォルト値を採用している場合があります。VMessでは、手作業でパラメータを推測するより、サーバーが生成した完全なサブスクリプションを使い、変換時にnetwork、ws-opts、servernameなどが失われていないことを確認するのが確実です。あるクライアントでは使えるのに、Clash YAMLへ変換すると動かない場合は、まずプロトコル自体ではなく変換器の項目マッピングを疑います。

Trojan：TLSセッションを利用したシンプルな認証

Trojanは通常TLS上で動作し、パスワードでクライアント認証を行います。成熟したTLSスタックで通信を保護するため、設定の中心は証明書のドメイン、サーバー名、ポート、パスワードです。独自の伝送項目が多い構成と比べ、標準的なTrojanノードは理解しやすい一方、「TLSを使うから証明書検証は不要」という意味ではありません。クライアント設定のsniまたはservernameは、サーバー証明書と実際の構成に一致している必要があります。システム時刻が大きくずれていてもハンドシェイクに失敗します。

一部のサブスクリプションでは証明書検証をスキップする設定が用意されています。この項目は証明書チェーンの問題を切り分けるためのもので、長期的なデフォルト設定には適しません。有効にすると接続できる場合は、証明書名、サーバー側の証明書チェーン、システム時刻に戻って原因を確認してください。TrojanはgRPCやWebSocketと組み合わせることもあり、その場合はパスやサービス名などの項目も増えます。「Trojanには固定されたカプセル化方式が一つだけある」と考えないことが大切です。

VLESS：軽量な認証フレームワークと組み合わせによる機能

VLESSは軽量なプロトコル層を採用し、暗号化や伝送の安全性をTLSなど外側の仕組みに委ねる設計です。VLESS自体が有効にするだけで自動的に速くなる機能ではなく、実際の性能はTLS、Reality系のセキュリティ層、フロー制御、具体的な伝送方式の組み合わせで決まります。Clashユーザーにとって重要なのは組み合わせ名を暗記することではなく、現在のmihomoがサブスクリプションの全項目に対応しているか確認し、手動でYAMLを簡略化する際にflow、reality-opts、client-fingerprint、サーバー名を削除しないことです。

VLESSでよくある問題は、「プロトコル名は認識されたが、追加機能は認識されていない」という状態です。古いコアの中には基本的なVLESSは読み込めても、新しいセキュリティ層やフィンガープリント項目を処理できないものがあります。画面にはノードが表示されても、クリックした時点でエラーになることがあります。そのため互換性の判断はインポート成功だけで終わらせず、少なくとも接続、DNSリクエスト、実際のHTTPSアクセスまで確認してください。継続的に保守されているmihomoコアを使うほうが、古いClash本体の設定構文で項目を削り続けるより手間が少ないことが多いです。

4種類に共通する絶対的な最適解はない

パケットロスが少なく経路が安定した有線またはWi-Fi環境では、TCPベースの4種類の一般的な方式で近いWeb体験を得られることがあります。差が出やすいのは、初回ハンドシェイク、接続の再利用、サーバー負荷、複雑な項目に対する耐性です。SSは設定項目が少なく故障点も少なめです。VMessは既存ノードが多い一方、変換時に完全な項目を残す必要があります。Trojanでは証明書チェーンが重要です。VLESSは組み合わせの自由度が高く、新しいコアへの依存も大きくなります。

サブスクリプションに4種類すべてのノードがある場合は、まず回線を基準に同じ地域でグループ化し、安定性を比較します。高負荷のSSノードと低負荷のVLESSノードを比べて、プロトコルの結論を出してはいけません。名前が新しいという理由だけで安定したノードを削除する必要もありません。クライアントについては、Windowsユーザーはダウンロードページで推奨しているClash Plusを優先するか、Clash Verge Rev、FlClash、Clash Nyanpasuを選べます。これらのグラフィカルクライアントの実際の機能は、統合されているコアと設定の更新状況に左右されます。

03 / UDP TRANSPORT

Hysteria2とTUIC：パケットロスの多い回線での選び方

なぜどちらもUDPを重視するのか

従来のTCPは安定したネットワークで非常にうまく機能しますが、往復遅延が大きく、ランダムなパケットロスがあり、帯域幅が急変する環境では、輻輳ウィンドウの回復が慎重になりがちです。Hysteria2とTUICはいずれもUDP上に暗号化、信頼性のある転送、多重化を構築し、アプリケーションの通信を単一TCPバイトストリームのヘッドオブラインブロッキングから解放します。信頼性を捨てているのではなく、QUICまたはプロトコル自身のセッション層で信頼性のある転送を処理しています。

この設計は、「利用可能な帯域は残っているのに、TCPがパケットロスで速度低下を続ける」状況に特に適しています。複数のWebリクエスト、動画の分割データ、DNSクエリを同じ接続内の独立したストリームに分けられるため、一つのストリームのパケットロス復旧が他のすべてをブロックしにくくなります。接続確立時の余分な往復を減らせる場合もあります。ただし、基盤となるUDPが家庭内ネットワーク、ルーター、通信事業者のネットワーク、サーバーのファイアウォールを安定して通過できなければなりません。どこか一箇所でもUDPを制限したりセッション保持時間を短くしたりすると、利点が頻繁な再接続に変わってしまいます。

Hysteria2：スループット重視だが、帯域幅の値は速度測定結果ではない

Hysteria2の設計で重視される点の一つは、高スループット回線での輻輳制御と信頼性のある転送です。設定には上り・下りの帯域幅ヒントが含まれることがありますが、これは輻輳制御が回線能力を把握するためのもので、クライアントがその速度を保証する値ではありません。実際の回線を大きく上回る値を設定すると、過剰送信、キューの滞留、ジッターを招く可能性があります。低すぎる値ではスループットを自ら抑えてしまいます。サブスクリプションにパラメータが含まれている場合は、まずサーバーの推奨値をそのまま使い、継続テストでキューの滞留や速度制限を確認してから調整してください。

Hysteria2では、認証文字列、TLSサーバー名、証明書検証、任意のポートホッピングも関係します。ポートホッピングはサーバー、ファイアウォール、クライアントすべてで設定する必要があり、クライアントだけにポート範囲を入力しても自動的には機能しません。接続を切り分ける際は、まず単一ポートに固定して基本接続を確認し、その後で追加機能を戻します。モバイルネットワークで単一ポートは使えるのにポートホッピングが不安定な場合は、ルーターやネットワークがUDPマッピングをどう処理しているかを確認してください。

TUIC：QUICセッション、並列ストリーム、接続移行

TUICもUDPとQUICの考え方を基盤とし、一般的な設定にはユーザーID、パスワード、サーバー名、輻輳制御アルゴリズム、UDPリレー方式、接続保持パラメータなどが含まれます。並列接続の転送に適しており、QUICによるストリームとセッション管理の恩恵を受けられます。スマートフォンでは接続移行が注目点です。Wi-Fiからモバイル回線へ切り替えた際、クライアント、コア、サーバーの実装がうまく連携すれば、複数のTCP接続を再確立するより既存セッションを速く復旧できる可能性があります。

ただし、接続移行がすべての環境で自動的に成功するわけではありません。端末のスリープ、OSによるバックグラウンド通信権限の回収、NATマッピングの変化、VPNインターフェースの再構築によって既存セッションが無効になることがあります。実際のテストでは、デスクトップで一度ダウンロードするだけでなく、画面ロック後の復帰、Wi-Fiとモバイル回線の切り替え、電波の弱い場所での短時間の切断も含めてください。TUICの輻輳制御オプションも他人の設定をそのまま流用せず、サーバーの対応状況、回線特性、実装バージョンを一致させる必要があります。

UDPが通らない場合、症状はTCPより直接的に現れる

典型的な症状には、ノードの遅延テストがタイムアウトする、接続直後に切断される、短時間だけ使えてその後速度が落ちる、ネットワーク切り替え後に長時間復旧しない、といったものがあります。まず同じネットワーク上で他のUDPアプリが正常に動くか確認し、次にルーターのファイアウォール、サーバーのポート、クライアントのTUN、サブスクリプション項目を確認します。別のWi-Fiに移るとすぐ正常になるなら、原因はローカルネットワーク経路にある可能性が高いです。すべてのネットワークで失敗するなら、サーバーの待受、証明書名、認証項目に戻って確認します。

「プロトコル接続がUDPを使うこと」と「プロキシがUDPアプリのトラフィックを転送すること」は区別してください。Hysteria2とTUICの基盤セッション自体はUDPに依存しますが、クライアントがゲーム、音声、QUICサイトの通信を正しく取り込めるかどうかは、TUNモード、システムVPNインターフェース、ルール、UDP転送機能にも左右されます。Webページを開けても、一部のTCPアプリ通信が成功したことを示すだけで、UDPアプリの経路全体が正常とは限りません。

選ぶ順番：まず到達性、次に継続負荷

実際の選定は3段階で行えます。第1段階では接続確立、DNS、通常のHTTPSをテストします。第2段階では数分間の継続通信を行い、スループットが突然ゼロにならないか、頻繁に再接続しないかを確認します。第3段階では、画面ロック、ネットワーク切り替え、弱い電波、複数アプリの同時利用など、実際の端末動作を再現します。Hysteria2はパケットロスの多い長距離回線で明確なスループット上の強みを示すことがあり、TUICはマルチストリームとセッション管理に魅力があります。ただし、両者の優劣はサーバー実装やローカルネットワークから切り離して判断できません。

proxies:
  - name: HY2-Example
    type: hysteria2
    server: example.invalid
    port: 443
    password: "your-password"
    sni: example.invalid
    skip-cert-verify: false

proxy-groups:
  - name: UDP-Fallback
    type: select
    proxies:
      - HY2-Example
      - DIRECT

上記の断片はmihomoでよく使われる項目構造だけを示したもので、ドメイン名と認証値は明確なサンプルです。実際の設定はサーバーから提供されたものを使用してください。現在のサブスクリプションにHysteria2またはTUICのノードがない場合、typeだけを変更して無理に変換してはいけません。プロトコルはサーバーとクライアントが対で対応する必要があり、ノード種別を変えてもサーバーが別のプロトコルになるわけではありません。

04 / PERFORMANCE

接続速度、スループット、リソース使用量は分けて測定する

「速さ」には少なくとも4つの指標がある

クライアント上の遅延は最初の指標にすぎません。性能を総合的に判断するには、接続確立時間、最初の1バイトまでの時間、継続スループット、ジッターを少なくとも確認します。接続確立時間はDNS、TCPまたはQUICのハンドシェイク、TLS、プロトコル認証の影響を受けます。最初の1バイトまでの時間には接続先の処理時間も加わります。継続スループットは輻輳制御、パケットロス、サーバーの出口、CPUに左右されます。ジッターは音声、ゲーム、リアルタイム操作の滑らかさを決めます。遅延が低くてもスループットが低いノードや、初回表示はやや遅くても継続ダウンロードが安定するノードがあります。

多重化も多ければよいとは限りません。重複するハンドシェイクを減らし、複数の論理接続で基盤セッションを共有できますが、すべてのストリームを一つの不安定な接続に詰め込むと、基盤セッションの輻輳やリセットの影響範囲が広がります。Web閲覧では多重化によって多数の短い接続のコストを下げられることが多い一方、長時間の大容量通信では単一セッションがボトルネックにならないか確認が必要です。プロトコル実装、クライアントのコア、サーバーのパラメータをまとめて評価してください。

ハンドシェイクの負荷と接続の再利用

SSの基本ハンドシェイクは比較的コンパクトで、標準構成のCPU負荷と往復コストを予測しやすい傾向があります。TrojanはTLSに依存するため初回接続でTLS処理が必要ですが、その後に接続を再利用できるかどうかで実際のコストは大きく変わります。VMessとVLESSの性能は外側の伝送方式次第です。WebSocket、TLS、gRPCなどの組み合わせには、それぞれ独自のハンドシェイクとカプセル化のコストがあります。Hysteria2とTUICはUDPベースのセッションとマルチストリーム機能を利用し、短い並列接続の再確立を減らせる可能性がありますが、初回の証明書検証とQUICセッションにもコストはあります。

したがって、プロトコルヘッダーのサイズだけで実速度を順位付けすることはできません。Webアクセスは数十の並列リソースで構成されることが多く、接続プールと再利用の方針が、個々のパケットに加わる数バイトより大きく影響する場合があります。一方、性能の低いルーターでは、高並列の暗号化、ユーザー空間のネットワークスタック、複雑なルール照合がCPUを消費します。理論上のスループットがNICの上限に達する前に、CPUが先に飽和することもあります。

CPU、メモリ、ルール規模

リソース使用量の主な要因は、暗号化、データコピー、ネットワークスタック、DNSキャッシュ、ルールセット、接続状態です。プロトコルの違いは暗号化やセッション処理に影響しますが、設定の規模も同じくらい重要です。大規模なルールセットを複数読み込み、TUN、トラフィックのスニッフィング、大量の接続履歴保存を有効にすると、基本的なシステムプロキシだけを動かす構成よりメモリ使用量が増えることがあります。「特定のプロトコルはメモリを多く使う」と判断する前に、ルールセット、DNS、ログレベル、動作モードを揃えてください。

デスクトップ端末では、数種類のプロトコルによるリソース差よりサーバー回線の差のほうが目立つことが多いです。低消費電力ルーターや古いスマートフォンでは差が拡大します。Hysteria2とTUICのユーザー空間による信頼性転送、タイマー、継続的なUDPセッションはCPUのウェイクアップを増やす可能性があります。複雑なVLESS構成でも、追加のTLS処理や伝送処理が発生することがあります。SSのシンプルな構造はリソース制約のある端末に適しやすいものの、必要なサービス品質を満たすことが前提です。

測定の順番が結論の信頼性を左右する

第一に、変数を減らします。クライアント、コア、DNSモード、ルール、対象を固定し、ノードだけを切り替えます。第二に到達性をテストし、ハンドシェイクに失敗するノードや変動が極端なノードを除外します。第三に、近い地域・近い回線の中でプロトコルを比較します。第四に、普段使う時間帯にもテストを繰り返し、ネットワークが空いている時間だけで結論を出さないようにします。最後に端末の温度、CPU、バッテリーを確認します。プロトコルのテストは複数回行うものであり、遅延を一度測って最小値を選ぶだけでは不十分です。

ダウンロードテストでは、マルチスレッド、OSアップデート、クラウド同期が同時に走らないようにします。ブラウザーがHTTP/3を使用している場合、対象の通信自体がUDPを使う可能性があります。クライアントがUDPを完全に取り込めなければ、通常のHTTPSとは結果が異なります。プロキシプロトコルを比較するなら、TCPを明確に使うテスト対象と、実際の動画またはリアルタイムアプリのシナリオを用意してください。ツールの出力は一部分にすぎず、最終判断は実際の作業で行います。

ログは切り分けに必要な範囲だけ有効にする

接続を調べる際は、一時的にログレベルをdebugへ上げ、DNS、ルール照合、プロキシハンドシェイク、接続先のどこで失敗したかを確認できます。高いログレベルを長時間維持すると、ディスク書き込み、画面更新、CPUのウェイクアップが増えます。特にスマートフォンやルーターには不向きです。原因を特定したらinfoまたはクライアント推奨のレベルに戻してください。ログに証明書名、認証失敗、UDPタイムアウトが現れた場合は該当する層を確認し、設定全体を一度にリセットしないでください。

log-level: info
mode: rule

profile:
  store-selected: true
  store-fake-ip: true

unified-delay: true
tcp-concurrent: true

unified-delayは遅延テストの基準を統一された接続プロセスに近づけるための項目です。tcp-concurrentは、名前解決で得られたアドレスへの接続を並列に試し、一部の接続待ち時間を短縮できます。これらはプロトコルを高速化する機能ではなく、サーバー障害を修復するものでもありません。設定項目が有効になるかはmihomoコアの対応状況に依存します。古い原版コアでは、未知の項目が無視されたり読み込みエラーになったりすることがあります。

05 / MOBILE POWER

モバイルのバッテリー、バックグラウンド、ネットワーク切り替え

バッテリー消費は暗号化だけでなく、継続的なウェイクアップから生じる

スマートフォンのプロキシクライアントは通常、システムVPNインターフェースを通じて通信を取り込みます。データは仮想インターフェースに入り、コアがルール照合、ドメイン解決、プロキシ接続の確立を行い、システムのネットワークスタックへ書き戻します。消費電力には、暗号化計算、データコピー、ルール検索、DNS、接続維持、ログ、画面更新、無線モデムのウェイクアップなど複数の要因があります。暗号化アルゴリズムだけではバッテリー持続時間を正確に予測できません。小さなパケットを継続的に送受信したり、短すぎる間隔で接続を維持したりすると、大容量通信を一度行うより端末が低消費電力状態へ移行しにくくなることがあります。

Wi-Fiでの結果をそのままモバイル回線に当てはめることはできません。モバイルモデムがスリープからアクティブ状態へ戻る際には追加コストがあり、頻繁なキープアライブは高消費電力状態の余韻を長引かせます。Hysteria2とTUICはUDPセッションを維持するため周期的な通信を行うことがあり、TCPプロトコルもハートビート、接続プール、アプリのバックグラウンドリクエストで通信状態を保つ場合があります。測るべきなのはプロトコル名ではなく、「固定したアプリ負荷における端末全体の消費電力」です。

システムのバックグラウンド制御はデスクトップより厳しい

Android端末のメーカーは、バックグラウンドプロセス、バッテリー最適化、自動起動権限に独自の制限を加えることがあります。クライアントがシステムに停止させられると、VPNアイコンがしばらく表示されていても、コアが新しい接続を処理できなくなっている場合があります。画面ロック後にアクセスできず、ロック解除後に復旧する場合は、クライアントのバッテリー設定、バックグラウンド実行権限、省電力モードを確認してください。Clash Plus、Clash Meta for Android、FlClash、Surfboardは画面上の手順が異なりますが、いずれもシステムVPNとバックグラウンド制御の影響を受けます。

iOSのネットワーク拡張はシステムが管理します。Clash PlusをApp Storeからインストールした場合も、接続やバックグラウンド動作はシステムのスケジューリングに従います。デスクトップのように「プロセスが常に動いている」と考えないでください。ネットワーク変化時にトンネルを再構築したり、ネットワーク拡張のメモリや実行時間を制御したりすることがあります。ノード数が多すぎる、ルールセットが大きすぎる、ログを継続的に更新するといった状態は、ネットワーク拡張の負荷を高める可能性があります。

モバイル体験に対するプロトコルの実際の影響

SSは接続構造が比較的シンプルで、CPUとメモリの負荷を管理しやすく、モバイルでの安定した基準に適しています。TrojanやTLSを使うVLESS、VMessではTLS処理が発生しますが、現代のモバイルプロセッサは一般的な暗号化を十分に処理できるため、日常的なWeb閲覧で差が目立たないこともあります。より重視すべきなのは、複雑な伝送、多層カプセル化、多数の並列接続です。同じノードグループで体感が近いなら、故障点が少なくネットワーク切り替え後の復旧が安定する方式を優先してください。

Hysteria2とTUICは、弱いネットワーク、多重ストリーム、回線変化のある環境で滑らかに動く可能性がありますが、継続的なUDPセッションが一部のモバイルネットワークに適さないこともあります。UDPのNATマッピングをすぐ回収するネットワークや、大容量UDP通信の制御が慎重なネットワークもあります。Wi-Fiからモバイル回線へ切り替えた後、ノードが長時間「接続中」のままなら、まずTCPのフォールバックノードへ切り替え、プロトコルのセッション移行に失敗したのか、システムVPNインターフェースの再構築が遅れているのかを切り分けてください。

再現可能なバッテリーテストの方法

まず、回線が近く負荷も安定したノードを2つ選び、ルール、DNS、アプリ、画面輝度を揃えます。充電完了後、端末の温度が戻るまで待ち、同じ時間だけWeb閲覧、バックグラウンド音声、ショート動画、待機の各シナリオを実行します。システムのバッテリー統計でクライアント、ネットワーク、画面の割合を記録し、端末が頻繁にウェイクアップしていないかも確認します。一度のテストではアプリのバックグラウンド動作を排除できないため、少なくとも似た時間帯で2回以上再測定してください。

テスト中はサブスクリプションやルールセットを同時に更新しないでください。ルールのダウンロード、展開、解析は一時的なCPUとネットワークのピークを生み、それをプロトコルの消費電力として扱っても意味がありません。常時最大速度のダウンロードを日常の待機状態の代わりに使うのも避けてください。最大速度のシナリオはスループット効率、待機シナリオはキープアライブとシステムのスケジューリングを測るものです。結果は分けて記録します。

端末負荷を減らす設定手順

第一に、ルールセットは実際に必要なものだけにし、同じ役割の大規模リストを重複して読み込まないようにします。第二に、ログは通常レベルに保ち、切り分けが終わったらリアルタイムデバッグを無効にします。第三に、ノードの自動テスト間隔を短くしすぎないでください。数十秒ごとに多数のノードをスキャンすると、ネットワークとCPUを継続的にウェイクアップさせます。第四に、オンデマンド接続を有効にする場合はシステムの動作を確認し、複数の自動ルールが互いに発火しないようにします。第五に、DNS nameserverの数は適切に保ちます。並列名前解決を増やしても速度は比例して向上しません。

クライアントにTUNスタック、トラフィックのスニッフィング、IPv6、UDP転送などのスイッチがある場合は、必要に応じて有効にし、すべてをオンにしないでください。無効にする前には用途を確認します。ゲームや音声には通常UDPが必要です。ドメインベースのルールに依存するアプリでは、対象情報を補うためにスニッフィングが必要になることがあります。IPv6ネットワークではDNSとルールが完全に対応しているか確認してください。省電力とは機能を削除することではなく、実際の通信に必要な機能だけを使うことです。

モバイルでは最終的に2つの経路を残すことを推奨します。一つはシンプルで安定したTCPノードを常用の基準とし、もう一つは弱いネットワークやパケットロスの多い環境向けにHysteria2またはTUICを用意します。実際のネットワーク切り替え、画面ロック、待機テストでデフォルトを決めてください。プロトコルが複雑になるほど、前面の速度測定画面だけでなく、システムのバックグラウンド動作を検証する必要があります。

06 / CORE FAMILY

原版Clash、Clash Meta、mihomoの関係

まずクライアントの外殻とプロキシコアを区別する

Clashエコシステムでは、「クライアント」と「コア」が混同されがちです。グラフィカルクライアントは、設定管理、サブスクリプション更新、システムプロキシ、トレイメニュー、ログ画面を担当します。コアはポートの待受、DNS、ルール照合、プロトコル接続、TUNを担当します。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどはグラフィカルクライアントで、mihomoを統合している場合もあれば、コアを切り替えられる場合もあります。画面が似ていても、基盤のプロトコル対応が完全に同じとは限りません。

互換性の問題を調べる際は、まずクライアントの概要画面または起動ログでコア名を確認し、その後に設定ファイルを確認します。アプリ名だけで判断すると誤ることがあります。たとえば、あるクライアントのバージョンではコアのビルド方式が変わり、別のクライアントでは互換オプションが残されている可能性があります。本サイトが特定のバージョン番号を固定していないのは、コアとクライアントが継続的に変化するためです。実際にインストールされているパッケージのコア識別子こそが、現在の事実です。

原版Clash：基本構文の出発点

原版Clashは一般的なYAML構造を確立しました。proxiesでノード、proxy-groupsで選択とテストのロジック、rulesでトラフィックを順番に照合し、DNS、待受ポート、動作モードをトップレベルに置きます。多くの解説とサブスクリプション形式がこのモデルを引き継いでいます。SS、VMess、Trojanなどの基本プロトコルや従来型のルール構文にも、現在なお影響が残っています。

ただし、原版コアはすでにメンテナンスが終了しています。Hysteria2、TUIC、新しいVLESSセキュリティ構成、ルールセット形式、現代的なTUN機能に対して、原版の機能範囲を新しい設定の基準にすると多くの不足に直面します。古い設定は構文の出発点として利用できますが、古いコアを新しいプロトコルの互換性目標にしてはいけません。Clash for Windowsもメンテナンスが終了しており、ダウンロードページではアーカイブ扱いです。古い環境向けには使えますが、新規インストールの第一候補には適しません。

Clash Meta：互換性を拡張した段階

Clash Metaは原版の設定モデルを基に、プロトコル、DNS、ルールプロバイダー、TUN、ネットワーク機能を拡張しました。多くの原版YAMLをそのまま読み込み、Metaの拡張項目を段階的に追加できます。この段階で新しいプロトコルや複雑な設定に対するエコシステムの需要が満たされ、「Meta設定」という呼び方も定着しました。設定ファイルにrule-providers、より詳細なDNS項目、sniffer、新しいプロトコル項目がある場合、原版Clashの安定した機能範囲を超えていることが多いです。

互換性は一方向に傾いています。Meta系コアは多くの原版設定を読み込めますが、原版コアはすべてのMeta拡張を理解できません。mihomo用の設定を古い原版コアにそのまま渡すと、未知のプロキシ種別、未知の項目、ルールプロバイダーの読み込み失敗が発生する可能性があります。エラー行を削除すれば起動できる場合もありますが、DNS、ルーティング、ノードのセキュリティ項目まで意図せず変わることがあります。「起動できる」ことを完全互換と考えないでください。

mihomo：現在も保守が続く後継コア

mihomoはClash Metaプロジェクトの後継名称であり、継続的に保守されているコアです。Clashの設定思想を引き継ぎながら、新しいプロトコル、ネットワークスタック、DNS、ルール機能に対応しています。多くのクライアント画面ではClashやMetaという用語が使われていますが、実際にはmihomoが動作していることがあります。新規インストールでは、mihomoを統合し継続的に更新しているクライアントを優先するのがわかりやすい選択です。Windowsでは本サイトはClash Plusを第一候補とし、画面やプラットフォームの要件に応じてClash Verge Rev、FlClash、Clash Nyanpasuも選べます。

mihomoは多機能ですが、すべてのスイッチを有効にする必要はありません。TUN、スニッフィング、Fake-IP、ルールプロバイダー、外部コントロールAPIはそれぞれ別の問題を解決します。ネット上の大規模な設定を丸ごとコピーすると、項目の上書き、DNSループ、ルール順序の誤り、リソース使用量の増加が起こりがちです。より安全なのは、サブスクリプションから生成された動作確認済みの設定を出発点にし、モジュールを一つずつ追加して、ログと通信経路を確認しながら進める方法です。

設定互換性は構文だけでなく動作を見る

互換性の第1段階はYAMLを解析できること、第2段階はノード項目を完全に認識できること、第3段階はDNS、ルール、TUNの動作が期待どおりであることです。未知の項目が無視されても設定は起動する場合がありますが、通信経路に差が出ることがあります。たとえば、プロキシノードからサーバー名が欠けるとTLSに失敗することがあります。ルールプロバイダーが読み込まれなければ、通信が最終ルールへ流れる可能性があります。Fake-IPの除外設定が不足すると、LAN内ドメインの名前解決に影響します。コアを更新したら、ログ、ノード接続、重要なルールのヒット状況を確認してください。

移行時は3つのコピーを残します。元のサブスクリプション、クライアントで現在動作している設定、変更予定の新しい設定です。まずトップレベルの項目を比較し、次にノードのプロトコルとプロキシグループ、最後にルールとDNSを比較します。複数のクライアントが同じ設定ディレクトリを書き換えないようにしてください。自動更新で手動変更が上書きされる可能性があります。長期的に維持するカスタムルールは、サブスクリプション生成ファイルを直接編集せず、クライアントが対応するオーバーライドまたはmerge機能に置くのが適切です。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

この最小構成は階層関係だけを示しており、実際のノードは含みません。設定が解析できたら、サブスクリプションまたはクライアントのオーバーライドでプロキシノード、DNS、ルールプロバイダーを追加します。最小構成は起動するのに完全な構成で失敗する場合は、モジュールを分割して段階的に戻してください。画面いっぱいのログを眺めて項目を推測するより、この二分法のほうが速く切り分けられます。ルーターでmihomoコアを直接動かす構成については、「ルーターでmihomoコアを直接動かす透過プロキシ構成」も参照してください。

07 / PROFILE FORMAT

サブスクリプション形式、ノード項目、変換互換性

サブスクリプションリンクはClash設定ファイルそのものではない

サブスクリプションリンクはデータを取得する入口にすぎず、返される内容は完全なClash YAML、複数の共有リンクをまとめたテキスト、base64でエンコードされたリスト、サービス独自の形式などさまざまです。完全なProfileにはノードだけでなく、プロキシグループ、ルール、DNS、TUN、ルールプロバイダーが含まれることがあります。一般的なサブスクリプションはノードだけを含むことが多いです。インポート後にノードだけ表示され、期待していたルールがない場合でも、インポート失敗とは限りません。元のサブスクリプションが完全なポリシーを提供していない可能性があります。

逆に、完全なClash YAMLでも、すべてのクライアントにそのまま適しているとは限りません。クライアントがmihomoを使っていても、オーバーライド、スクリプト、外部ルールセットのパスを独自に管理している場合があります。インポート前にファイル形式を確認してください。proxies:、proxy-groups:、rules:の3つがあれば、通常は完全な設定です。複数行のss://、vmess://などのリンクが並んでいれば、ノード集合に近い形式です。

共有リンクに含まれる内容はプロトコルによって異なる

SSの共有リンクには通常、暗号化方式、パスワード、サーバー、ポートが含まれ、クエリパラメータでプラグインが追加されることもあります。VMessの共有形式では、ユーザーID、伝送方式、Host、パス、TLSなどがエンコードされるのが一般的です。Trojanリンクでは、パスワード、サーバー、ポート、SNI、伝送パラメータが中心です。VLESSリンクには、セキュリティ種別、flow、フィンガープリント、公開鍵識別子、サーバー名、伝送項目が含まれる場合があります。Hysteria2とTUICでも、認証、SNI、輻輳制御、UDP関連のパラメータが必要です。

問題は、変換器がこれらの項目を認識できるかどうかです。変換器がプロトコルの基本項目にしか対応していない場合、ノード名とサーバーは残っていても、flow、Reality設定、WebSocketヘッダー、gRPCサービス名、Hysteria2の帯域幅ヒントが失われることがあります。生成されたYAMLが整って見えても、実際のハンドシェイクは必ず失敗します。新しいプロトコルや複雑な組み合わせでインポート問題が起きたら、まずクライアントで元のサブスクリプションを直接読み込み、変換結果と項目ごとに比較してください。

YAML自体にも見落としやすい境界がある

YAMLはインデントに敏感です。Tab文字、階層のずれ、コロンの後にある特殊文字列だけでも解析に失敗することがあります。ノード名にコロン、シャープ、角括弧、前後の空白が含まれる場合は、引用符で囲むほうが安全です。真偽値はコアの要件に従ってtrueまたはfalseとし、ポートは数値で記述します。同じキーが重複した場合、パーサーによって処理が異なる可能性があるため、後のキーが前のキーを上書きする偶然の挙動に依存しないでください。

プロキシグループが参照するのはノード名なので、名前を変更したらグループ内の参照も更新する必要があります。ルールの最後には通常、MATCH,PROXYのようなフォールバック項目を置きます。ルールは上から順に照合されるため、前方の広いルールが後方の細かいルールを先に取り込むことがあります。サブスクリプション変換は構造を生成するだけで、業務上のルールが妥当かどうかを自動判断しません。設定ファイルの構造と複数設定の管理については、「Clashの設定ファイルとは」も参照してください。

インポート後に4層で受け入れ確認を行う

第1層は数量です。ノード数が元のサブスクリプションとおおむね一致し、プロトコル種別が揃っているか確認します。第2層は項目です。複雑なVLESS、TrojanまたはVMess、Hysteria2またはTUICを各1件抽出し、TLS、SNI、伝送、認証項目を確認します。第3層はポリシーです。プロキシグループが存在するノードを参照しているか、ルールセットが正常に読み込まれたか、最終ルールがあるかを確認します。第4層は動作です。DNS、通常のHTTPS、UDPアプリ、ノード切り替えをそれぞれテストします。

一部のノードだけ失敗する場合は、失敗したノードと同じプロトコルで正常なノードの項目構造を比較してください。同じプロトコル種別がすべて失敗するなら、コアの対応状況と変換器のマッピングを確認します。すべてのノードが正常なのにWebページを開けない場合は、サブスクリプション形式よりも、システムプロキシ、TUN、DNS、ルールの問題である可能性が高いです。障害を一つの層に限定してから変更し、何度もインポートして設定リストを複雑にしないでください。

サブスクリプション更新とカスタムルールは層を分ける

サブスクリプションから生成されたProfileを直接編集すると、次回の更新で変更が上書きされることが多いです。クライアントがオーバーライド、設定のマージ、拡張スクリプトに対応している場合は、ローカルルール、DNS調整、プロキシグループの変更を独立した層に置いてください。基本サブスクリプションはノードを提供し、オーバーライド層はサイトや端末のポリシーを担います。こうすればノード更新のたびにYAML全体を手で修正する必要がなく、問題のあるカスタムモジュールもすぐ無効にできます。

複数のサービスや用途の設定を併用する場合は、「日常」「モバイル予備」「テスト」のように、名前から出所と用途がわかるようにします。「設定1」「設定2」は避けてください。前回の更新日時とカスタムオーバーライドの有効状態も記録します。Profileを切り替えた後は、システムプロキシまたはTUNの状態を再確認してください。クライアントによっては設定だけを切り替え、以前の接続状態を自動復元しないことがあります。

proxy-providers:
  primary:
    type: http
    url: "https://example.invalid/subscription"
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 1800
      url: https://www.gstatic.com/generate_204

この例はmihomoのプロキシプロバイダー構造を示したもので、アドレスには明確なサンプルドメインを使用しています。intervalはサブスクリプションの更新間隔を制御し、ヘルスチェックには独立した間隔があります。両方を短くしすぎると、ネットワーク通信とモバイル端末のウェイクアップが増えます。実際のサブスクリプションアドレスはクライアント画面から保存し、記事、スクリーンショット、共有設定に公開して貼り付けないでください。

base64、YAML、一般的な形式の違いについて詳しくは、「Clashサブスクリプション形式の基礎」を参照してください。変換の目的はファイルを短く見せることではなく、意味を保つことです。新しいプロトコル項目がある場合、不要な形式変換を一度減らすだけで、互換性トラブルの原因を一つ減らせることが多いです。

08 / FIELD GUIDE

端末とネットワーク環境に合わせてプロトコルを選ぶ

Windows・macOSの日常的なデスクトップ利用

デスクトップ端末はバックグラウンドリソースに余裕があり、ネットワークも安定していることが多いため、クライアントの保守状況、ノード回線、設定互換性を重視します。Windowsの新規インストールではClash Plusから始め、画面の好みに応じてClash Verge Rev、FlClash、Clash Nyanpasuを検討してください。macOSでもClash Plusを優先でき、Clash Verge RevやFlClashも選択肢になります。Clash for WindowsとClashX Metaはメンテナンスが終了しており、ダウンロードページではアーカイブとして残しています。

プロトコルについては、まずサブスクリプション内の安定したSS、Trojan、VLESSノードで基準を作ります。地域を固定したうえで、Hysteria2またはTUICを追加し、パケットロスと継続スループットを比較します。デスクトップでは手動選択グループと自動テストグループを併用できますが、自動テストでわかるのは到達性とテストURLのハンドシェイク性能だけです。最終的なデフォルトノードは、実際のWeb閲覧、ダウンロード、動画再生で確認してください。

Android・iOSの長時間バックグラウンド利用

AndroidではClash Plus、Clash Meta for Android、FlClash、Surfboardから、画面や設定の要件に応じて選べます。iOSではClash Plusを使用します。モバイルではまず、バックグラウンド権限、VPN状態、ネットワーク切り替え後の復旧を確認してからプロトコルを比較してください。メッセージ、Web閲覧、音声が中心なら、シンプルで安定したSS、Trojan、VLESSがデフォルトに適しています。弱いネットワークやパケットロスの多い環境ではHysteria2やTUICへ切り替えられますが、画面ロックとモバイル回線での動作を必ず確認してください。

ノードグループを大きくしすぎないでください。数十のノードを自動テストすると、DNS、接続、バッテリーのコストが増えます。地域と用途で小さなグループに分けるとよいでしょう。日常グループには検証済みの少数ノードだけを置き、予備グループには異なるプロトコルと回線のノードを残します。旅行先、ホテルWi-Fi、臨時のゲストネットワークでUDPノードがすべてタイムアウトするなら、現場で証明書やDNSを何度も変更せず、TCPのフォールバックグループへ切り替えてください。

ルーターと低消費電力デバイス

ルーターでmihomoを動かす場合、デスクトップよりCPUアーキテクチャ、メモリ、冷却、ハードウェア転送能力が重要です。SSは実装が比較的軽く、リソースの基準に適しています。TLS、複雑なVLESS構成、Hysteria2、TUICではユーザー空間での処理が増え、実際のスループットがCPUの単一コア性能に制限されることがあります。公称のLANポート速度はプロキシのスループットを保証しません。TUN、透過プロキシ、ルールセット、DNSもリソースを消費します。

まず小さなルールセットと単一プロトコルで安定したスループットをテストし、その後に透過プロキシ、Fake-IP、スニッフィング、ルールプロバイダーを段階的に有効にします。ネットワーク速度が期待値に届かないのにCPUが飽和している場合は、プロトコルを変更する前にログを減らし、ルール規模を縮小し、ソフトウェアルーターで二重転送が発生していないか確認してください。複数端末にサービスを提供するルーターでは、単一接続のピーク速度より安定性が重要です。回線特性が合えばHysteria2やTUICでスループットを高められますが、UDPセッションテーブルとファイアウォールの容量も確認してください。

リアルタイム音声、ゲーム、動画

リアルタイム通信では、ジッター、パケットロスからの復旧、UDP転送が重要です。まずクライアントのTUNまたはシステムVPNが対象通信を取り込んでいるか、ルールがアプリを誤ってDIRECTやREJECTへ送っていないか確認します。次にノードから対象サービスまでの実際の経路を比較し、ノードサーバーまでの遅延だけを見ないでください。Hysteria2やTUICはパケットロスの多いネットワークでもマルチストリーム通信を滑らかに保てる可能性がありますが、追加の信頼性機構がすべてのリアルタイムUDPアプリの低遅延を保証するわけではありません。

動画では継続スループットと輻輳からの復旧が重要です。遅延が低くても出口が混雑しているノードは頻繁にバッファリングし、高遅延でもスループットが安定したノードのほうが適していることがあります。ノードを選ぶ際は、「Clashのノードの選び方」で紹介している遅延、倍率、地域、プロトコルの4項目を使って絞り込めます。倍率は通信量のコスト、地域はコンテンツと経路に影響し、プロトコルはそのうちの一項目です。

そのまま実行できる選定手順

1. コアを確認。クライアントの概要画面またはログでmihomoを使用していることを確認し、新しいプロトコル項目が古い原版コアに渡らないようにします。
2. サブスクリプションを確認。ノード数、プロトコル種別、複雑な項目を確認し、元のサブスクリプションを保存してから、何度も変換しないようにします。
3. TCPの基準を作る。SS、Trojan、VMess、VLESSから安定したノードを一つ選び、DNS、HTTPS、継続接続を確認します。
4. UDP経路をテスト。同じ地域のHysteria2またはTUICを追加し、UDPの到達性、継続スループット、ネットワーク切り替え、復旧を確認します。
5. 端末負荷を確認。デスクトップではCPUと安定性、スマートフォンでは待機とバックグラウンド、ルーターでは複数端末の同時接続と温度を確認します。
6. フォールバックグループを作る。異なる基盤伝送のノードを同じ手動選択グループに入れ、ネットワーク変化時に設定を変更せず素早く切り替えられるようにします。

あるプロトコルが一つのノードにしか存在しない場合、公平な比較条件ではありません。その場合はプロトコルの結論ではなく、ノード選びとして扱います。同じプロトコルの複数ノードが同じネットワークで失敗し、別のネットワークで復旧するなら、まずUDPまたは伝送経路を確認します。一つのクライアントだけが失敗するなら、コアと項目を確認します。すべてのクライアントで失敗するなら、サーバーとサブスクリプション元に戻って確認してください。層ごとに切り分ければ、同じ誤った設定を残したままクライアントだけを何度も変更する事態を避けられます。

結論：名前ではなく条件で選ぶ

SSの価値はシンプルさと成熟度にあり、汎用・低リソース環境の基準に適しています。VMessは既存ノードと豊富な伝送方式に現実的な価値があり、完全な項目を残すことが重要です。Trojanは標準TLS経路に依存するため、証明書とサーバー名を正しく設定する必要があります。VLESSの機能はセキュリティ層と伝送方式の組み合わせから生まれ、継続的に保守されるコアがより重要です。Hysteria2はパケットロスが多くスループットを重視する回線向け、TUICはQUICのマルチストリームとセッション機能を重視します。解決する問題が異なるため、回線、端末、サーバー実装を離れて固定の順位を付けることはできません。

コアについては、新しい設定ではmihomoを主な確認対象とし、原版Clashの構文は構造の基礎として扱います。Clash Metaの設定は通常、移行経路を通じてmihomoへ移行できます。サブスクリプションでは元の意味を優先して不要な変換を減らし、インポート後にノード、項目、ポリシー、動作の4層で確認します。クライアントは継続的に保守され、コアの状態を明確に表示できる製品を優先してください。WindowsとmacOSではClash Plusを優先し、その他のプラットフォームではダウンロードページの一覧から選びます。

選定が終わったら入門ガイドに戻り、サブスクリプションのインポート、モード選択、接続確認を行います。インストーラーが必要な場合はダウンロードページへ。インターネットに接続できない、DNSやルール照合に問題がある場合はヘルプセンターを確認してください。ここまでのプロトコル選びは、コアを確認し、元の設定を保存し、変数を固定し、実際の作業をテストし、フォールバック経路を残すという再現可能な手順になります。