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

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

プロトコル名は速度ランクではありません

Clashクライアントにおけるプロトコル種別は、クライアントとサーバーが接続を確立し、認証し、データをカプセル化し、輻輳を処理する方法を示すもので、特定の速度を直接保証するものではありません。同じプロトコルでも、サーバー、回線、デバイスが異なれば結果は大きく変わります。実際の使い勝手は、プロトコル名よりもサーバーまでの距離、出口帯域、往復遅延、パケットロス、サーバー負荷、ローカルネットワークの品質に左右されることが多いものです。「新しいプロトコルは必ず速く、古いプロトコルは必ず遅い」と単純に並べると、誤った結論につながり、ノード変更後に回線差をプロトコル差と誤認しやすくなります。

選定時は問題を3層に分けて考えます。第1層はトランスポート層で、TCP、UDPのどちらを使うか、複数の方式を組み合わせられるかを確認します。第2層はプロトコル層で、認証、暗号化、接続の多重化方法を見ます。第3層は実装層で、現在のクライアントがどのコアを使い、サブスクに記載されたフィールドを完全にサポートしているかを確認します。3層がすべて一致して初めて、ノードを正しく読み込み安定して動作させられます。クライアント画面にプロトコル名が表示されても、すべての拡張パラメータが対応しているとは限りません。サブスク変換ツールがYAMLを出力できても、対象コアが各フィールドを理解できるとは限りません。

制約を確認してから、好みを比較する

実際の選択は4つの制約から始めます。まず、サービス提供者が用意したノード種別を確認します。プロトコルは接続する双方が対応する必要があり、クライアント側だけでVMessノードをVLESSやTrojanに変更することはできません。次にクライアントのコアを確認します。オリジナル版Clashは、初期から広く使われてきたプロトコルと基本的なルール体系を安定してサポートしますが、新しいプロトコルや拡張機能には通常Clash Metaまたは後継プロジェクトのmihomoが必要です。さらにデバイス環境も確認します。デスクトップは追加のメモリ使用や常時接続に比較的耐えられますが、モバイルではバックグラウンド維持、無線モジュールの起動回数、弱いネットワークでの切り替えに注意が必要です。最後にネットワーク特性を確認します。安定してパケットロスの少ない回線と、高遅延または軽度のパケットロスがある回線では適した方式が異なります。

これらの制約を確認して初めて、起動速度、持続スループット、同時接続性能、リソース使用量、設定の複雑さを比較できます。Web閲覧と大容量ファイル転送で重視すべき指標も異なります。WebアクセスではDNS、ハンドシェイク回数、TTFBが重要で、大容量ファイルでは持続スループットと輻輳制御、リアルタイム音声・動画ではジッター、パケットロスからの復旧、キューイング遅延が重要です。1回の速度テストで分かるのは、その時点における1経路の結果だけであり、1日の負荷変動を捉えたり、実際の用途テストに代えたりすることはできません。

再現可能なテスト方法を作る

2つのノードを比較する場合は、サーバーの地域、テスト時間、クライアントのコア、DNS設定、ルールモードをできるだけ揃えます。まず他の大容量通信を停止し、接続確立、Webページの初回表示、連続ダウンロード、動画のシーク、待機後の復帰をそれぞれ確認します。各方式を少なくとも数回繰り返し、最良値ではなく中央値を記録します。プロトコルを切り替えると同時にサーバーも変更した場合、改善がプロトコルによるものか回線によるものか判断できません。モバイルでは、画面ロック後の復帰、Wi-Fiとモバイル通信の切り替え、低電力モードも加えてテストします。これらはフォアグラウンドの速度測定より問題が見つかりやすい場合があります。

本ページの結論は、環境を無視してプロトコルを絶対順位付けするためのものではなく、設計上の選択を理解するためのものです。設定が簡潔で、サーバーが安定し、コアが完全対応している従来型プロトコルは、パラメータが複雑でも導入条件が合わない新しいプロトコルより信頼できることがあります。適切な選定の目的は不要な変数を減らし、対象デバイスと日常のネットワークで予測可能な接続を維持することであり、単一のテストで最高値を追い求めることではありません。

2. SS、VMess、Trojan、VLESSの設計上の違い

Shadowsocks：コンパクトな構成で、実装品質に左右される

Shadowsocksは通常SSと略され、比較的軽量な方式でTCPとUDPの通信を暗号化して転送します。設定項目は少なく、サーバーアドレス、ポート、パスワード、暗号化方式が主な必須情報です。構造がコンパクトで実装も広く普及しているため、デスクトップ、モバイル、リソースの限られたデバイスにも導入しやすいプロトコルです。安定した転送だけを必要とし、設定の複雑さを抑えたい用途では、SSは今も明確な価値があります。実行時の負荷はプロトコル自体だけでなく、選択した暗号化アルゴリズムがデバイスのハードウェアアクセラレーションを利用できるかにも左右されます。

SSでよくある互換性の問題は、暗号化方式の名称と拡張プラグインに関係します。新しいAEAD方式と旧来の方式では、安全性と実装対応に違いがあります。サブスクにプラグインパラメータが含まれる場合、対象コアはプラグインの種類とオプションも理解できなければなりません。サーバー、ポート、パスワードだけをコピーしてプラグインのフィールドを省くと、ノードの読み込みには成功しても通信できないことがあります。移行時は画面で目立つ4項目だけでなく、ノードオブジェクト全体を比較してください。

VMess：機能は豊富だが、設定フィールドが多い

VMessは比較的早い時期に整備されたエコシステムを持つプロトコルで、UUIDによる識別、トランスポート層のオプション、TLS設定、パスのパラメータと組み合わせて使われることが多い方式です。TCPやWebSocketなど複数のトランスポート上で利用できるため、同じVMessと表示されるノードでも内部構成が大きく異なる場合があります。クライアントでは、アドレス、ポート、UUID、ネットワーク方式、Host、パス、TLSサーバー名、証明書検証方針を正しく処理する必要があります。重要なフィールドがサブスク変換で失われると、ハンドシェイクに失敗する可能性があります。

VMessの強みは、長年のツールチェーンとサブスクエコシステムが成熟しており、多くのクライアントが一般的なリンク形式を認識できる点です。一方でパラメータの組み合わせが多く、トラブルシューティングでは「プロトコルに対応しているか」だけを確認しても不十分です。たとえばWebSocketを使うノードでは、パスとHostがサーバー設定によって決まります。TLSを有効にした場合は、サーバー名と証明書の対応も正しくなければなりません。古い設定には、現代の実装で重視されなくなった互換性フィールドが含まれることもあります。mihomoへ移行する際は、クライアントまたは信頼できるサブスク生成側に現在の形式を出力させ、長年蓄積した古いフィールドをそのまま継ぎ足すのは避けてください。

Trojan：TLSを利用して認証と転送を行う

Trojanの典型的な設定はTLS接続を中心に構成され、サーバー、ポート、パスワード、サーバー名、証明書検証設定などが含まれます。クライアントから見ると通常のTCPプロトコルより完全なTLSハンドシェイクと証明書確認が加わるため、名前解決、システム時刻、SNI、証明書チェーンが接続結果に影響します。設定が正しければTrojanの扱いは比較的分かりやすい一方、誤りがあるとTLSハンドシェイク失敗、証明書名の不一致、リモートによる切断として現れることがよくあります。

Trojanだからといって、すべての接続コストが同じになるわけではありません。初回のTLSハンドシェイクには追加の往復通信と暗号処理が必要で、その後の性能は接続再利用、セッション再開、サーバー実装に左右されます。高遅延環境でアプリが短い接続を頻繁に作ると、ハンドシェイクのコストが目立ちやすくなります。継続的な通信では、この固定コストの割合は低下します。ノードにWebSocketやgRPCなどのトランスポートを組み合わせる場合は、ネットワーク方式と対応パラメータも確認し、Trojanのパスワードとサーバー名だけを残さないようにしてください。

VLESS：プロトコル層を簡潔にし、組み合わせで機能を実現する

VLESSはUUIDで識別することが多いものの、プロトコル自体は従来の意味でのコンテンツ暗号化を担いません。実際の安全性は通常、TLSなど対応するトランスポートとの組み合わせによって確保されます。プロトコル層の重複処理を減らし、トランスポート、暗号化、拡張機能を組み合わせ側に委ねる設計です。そのため拡張性が高い一方、互換性の判断は具体的な組み合わせに依存します。ノード種別がVLESSと表示されるだけでは、特定のClashコアで使えるか判断できません。ネットワーク方式、TLS、フロー制御、その他の拡張フィールドも確認が必要です。

mihomoでVLESSを使う場合、基本ノードと一般的なトランスポートは比較的よくサポートされていますが、特定実装に依存する新しい拡張については、コアのドキュメントとクライアントの更新状況を確認してください。サブスク提供側が別のコア専用のフィールドを出力すると、読み込み後に無視されたりエラーになったりする可能性があります。トラブルシューティングでは、まず複雑な組み合わせをサーバーが許可する基本形まで簡略化し、認証情報とTLSが機能することを確認します。その後、トランスポートと拡張パラメータを1つずつ戻します。複数の項目を同時に変更するより、この順番の方が問題を特定しやすくなります。

3. Hysteria2とTUIC：高遅延・パケットロス向けのUDP方式

UDPを利用する理由

従来のTCP接続は信頼性の高い転送と成熟した輻輳制御を備えていますが、プロキシトンネルの外側とアプリケーションの内側が同時にTCPを使うと、パケットロスからの復旧、再送、輻輳制御が互いに影響することがあります。特に往復遅延が大きい、または断続的なパケットロスがあるネットワークでは、外側の1パケットの損失によって複数の内側の接続が同時に待たされる場合があります。UDPを基盤とする最新プロトコルは、ユーザー空間でストリーム、多重化、確認応答、輻輳制御を組み立てられるため、さまざまなネットワーク条件に柔軟に対応できます。Hysteria2とTUICはいずれもこの方向性に属しますが、実装目標、パラメータの表現、コア対応の細部は完全には同じではありません。

UDP方式の価値は「信頼性を省く」ことではありません。アプリケーションデータの確認、再送、順序制御は設計に従って必要であり、それらをユーザー空間のプロトコルスタックが組み立てるだけです。帯域を突然生み出すこともありません。サーバーの出口帯域が不足していたり、無線信号が弱かったり、経路が慢性的に混雑していたりすれば、どのプロトコルも物理的な制約を受けます。主な利点は、より適した輻輳制御、ヘッドオブラインブロッキングの影響軽減、複数ストリームを同時に扱う際の柔軟なスケジューリングにあります。

Hysteria2：設定を集約し、弱いネットワークでのスループットを重視

Hysteria2はQUIC関連の機能を基盤として構築され、一般的な設定にはサーバーアドレス、ポート、認証パスワード、TLSサーバー名、証明書検証オプションが含まれます。導入環境によっては、上下り帯域の目安や輻輳制御に関するパラメータも指定します。高遅延で一定のパケットロスがある経路でも実用的なスループットを維持することが設計上の重点の1つであり、地域をまたぐ接続、モバイルネットワーク、品質変動の大きい回線で使われることがあります。ただし、帯域パラメータは大きければよいわけではありません。実際に利用できる帯域を大きく上回る値を設定すると、送信側でキューイングや余分なパケットロスが発生する可能性があります。低すぎる値ではスループットを自ら制限してしまいます。

Hysteria2を使う際は、まずUDP経路が利用できることを確認し、その後に認証とTLSを確認します。ノードがまったく接続できない場合は、ドメイン名の解決、サーバーポート、システム時刻、SNI、証明書を順にテストします。接続できても速度変動が大きい場合は、実際の上下り帯域、ルーターのキュー、無線ネットワーク品質を確認します。ネットワークによっては長時間のUDPセッションに対するマッピング保持時間が短く、アイドル後の最初のリクエストに失敗したり、頻繁に再接続したりすることがあります。その場合は、システムのバックグラウンド制御、ルーターのNAT状態、クライアント接続ログを合わせて判断してください。

TUIC：多重化と接続管理に注目する

TUICもUDPベースの最新トランスポート機能を利用し、ノード設定には通常、サーバー、ポート、UUID、パスワード、TLSサーバー名、輻輳制御やUDP転送方式などのパラメータが含まれます。実装段階によって異なるフィールド表現が使われてきたため、サブスクの提供元とコアの間に形式の違いがあると、ノードは認識されても任意パラメータが期待どおりに反映されないことがあります。TUICを移行する際は type だけでなく、認証フィールド名、輻輳制御名、UDPリレーモード、証明書設定も確認してください。

TUICの多重化は、重複したハンドシェイクを減らし、複数のアプリケーションストリームで基盤接続を共有するのに役立ちます。ただし、共有は多ければよいとは限りません。1本の基盤接続が継続的に混雑すると、集中しすぎた構成ではより多くのリクエストが影響を受けます。逆に独立接続を作りすぎると、ハンドシェイク、メモリ、NATマッピングのコストが増えます。クライアントとコアには通常、妥当なデフォルト値が用意されています。ログでボトルネックを確認していない限り、ネット上の断片的な設定例だけを根拠に大幅な調整を行うことはおすすめしません。

UDPプロトコルのネットワークとデバイス上の制約

安定して低遅延で、ほとんどパケットロスのない有線ネットワークでは、Hysteria2やTUICが単純なTCP方式より明確に改善するとは限りません。ユーザー空間のプロトコルスタック、暗号化、タイマー処理にもCPU資源が必要だからです。一方、高遅延または軽度から中程度のランダムなパケットロスがある環境では、より滑らかなスループットを維持できる可能性があります。深刻な混雑が原因のパケットロスに対して送信速度をむやみに上げると、キューイングが悪化します。その場合は、まず帯域の目安を下げ、ルーターのバッファを確認し、同時実行タスクを減らしてください。

企業、学校、公共Wi-FiではUDPの扱いが異なる場合があり、ネットワークを切り替えると結果も変わります。モバイルデバイスでは、モバイル通信のNAT、バックグラウンド停止、無線モジュールの省電力制御も影響します。そのためUDPプロトコルを使う場合も、比較用として利用可能なTCP方式を1つ残しておきましょう。接続に問題があるときに、コア、DNS、ルールを同時に変更するのは避けてください。比較用ノードがあれば、問題がプロトコル経路にあるのか、設定環境全体にあるのかを判断しやすくなります。

proxies:
  - name: "Hysteria2-Test"
    type: hysteria2
    server: test.example.com
    port: 443
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

  - name: "TUIC-Test"
    type: tuic
    server: test.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    password: "your-password"
    sni: test.example.com
    skip-cert-verify: false

以下の断片はmihomoの設定構造を説明するためのもので、アドレスと認証情報は例示値です。実際に接続することはできません。実際の設定はサーバーから提供されたものを使い、サーバー名と証明書を一致させてください。手入力後はまずクライアントの設定チェック機能を使い、フィールド名とインデントが正しいことを確認してから、プロキシグループに追加してテストします。

4. 接続速度、スループット、リソース使用量を比較する方法

「速度」を4つの指標に分ける

ユーザーが感じる速度には、少なくとも接続確立時間、TTFB、持続スループット、同時接続時の安定性が含まれます。接続確立時間はDNS、TCPまたはQUICのハンドシェイク、TLSハンドシェイク、プロトコル認証の影響を受けます。TTFBには対象サイトの応答とルールの照合も含まれます。持続スループットは主に回線帯域、輻輳制御、パケットロスからの復旧、CPU性能に左右されます。同時接続時の安定性は、接続再利用、ファイルディスクリプタ、メモリ、サーバー負荷に関係します。速度測定ページのピーク値だけでは、Webページの初回表示が遅い、動画のシークが止まる、大量の小さなリクエストが待たされるといった現象を説明できません。

SSはプロトコル処理が比較的コンパクトで、ハードウェアアクセラレーションが適切に働くデバイスでは追加負荷が低い傾向にあります。TrojanやTLSを有効にしたVMess、VLESSではTLSハンドシェイクを考慮する必要がありますが、接続を確立して長時間通信すれば、固定のハンドシェイクコストは分散されます。Hysteria2とTUICはユーザー空間の転送処理が複雑で、CPUやメモリを多く消費する可能性があります。その一方、高遅延またはパケットロスのあるネットワークでは、柔軟な輻輳制御によって実効スループットが安定することがあります。最終的な結果はネットワーク条件に左右され、プロトコル層だけで決まるものではありません。

暗号化とCPU性能

現代のデスクトップCPUやモバイルチップは、一般的な暗号処理にハードウェア最適化を提供していることが多いものの、アルゴリズム、ランタイム、コア実装によって利用度は異なります。低消費電力ルーター、古いスマートフォン、エントリーサーバーでは、高速通信時に単一コアがボトルネックになりやすくなります。この場合、ネットワーク帯域には余裕があるのに、コアプロセスの使用率が上がり続け、デバイス温度が上昇し、スループットが伸びないという状態になります。プロトコル変更で改善することもありますが、ログを増やしすぎていないか、複雑なルール、トラフィック解析、大量の接続再利用を有効にしていないかも確認してください。これらの機能も同様にリソースを消費します。

メモリ使用量は、コアの基本動作、ルールセット、DNSキャッシュ、接続状態、バッファによって主に決まります。プロトコル自体の静的な差より、ルールセットの規模や同時接続数による差の方が大きいことがよくあります。複数の大規模なルールプロバイダーを読み込み、長すぎるログを保持し、複数のサブスクと複雑なDNS分岐を同時に使うと、SSからTrojanに切り替えるより大きな差が生じることがあります。サーバーやルーターでmihomoを動かす場合は、システムのネットワークスタックとキャッシュのために十分なメモリを残し、メモリ圧迫による頻繁な回収を避けてください。

TCPとQUIC系プロトコルのパケットロスへの挙動

TCPは安定したネットワークで効率が高く、実装も成熟しており、OSカーネルも長年最適化されています。弱点は高遅延とパケットロスが組み合わさったときに現れやすく、特に複数のアプリケーションストリームを1本の外側TCP接続に包むと、1つのセグメントの損失が後続データの受け渡しを阻害することがあります。QUIC系の方式はストリームごとに状態を分けて管理し、1ストリームの損失が他のストリームに与える影響を軽減できます。またユーザー空間で適切な輻輳制御を採用できます。ただしUDPパケットもルーターのキューとネットワーク経路を通るため、深刻な混雑時には同様に速度を落とす必要があります。

パケットロスの影響を判断するために、接続テストを1回行うだけでは不十分です。連続リクエスト、安定したダウンロード、リアルタイム通信で一定間隔の停止が発生していないか観察します。Hysteria2やTUICに切り替えて持続スループットが改善した一方、デバイスが明らかに発熱するなら、ネットワーク上の利益とデバイスコストが同時に存在しています。利用時間を基準に判断してください。短時間の速度測定だけ改善し、長時間の転送で徐々に低下する場合は、サーバー側の速度制限、熱によるクロック低下、誤った帯域パラメータが関係している可能性があります。

より信頼できる比較手順

まず同じ地域で、回線条件が近い2つのノードを選び、同じクライアントと同じルールモードでテストします。第1ラウンドでは初回接続とWebページの表示を記録します。第2ラウンドでは数分間の連続通信を行い、ピークではなく平均スループットを観察します。第3ラウンドではよく使うアプリのリクエストを複数同時に実行し、操作時の遅延を確認します。第4ラウンドでは接続をアイドル状態にしてから復帰させ、セッションが安定しているか確認します。テスト中はコアプロセスのCPU、メモリ、デバイス温度を記録し、時間帯を変えて繰り返します。結論が大きく変わる場合は、すぐにプロトコルパラメータを変更せず、まず回線負荷の影響を疑ってください。

5. モバイルの電池消費、バックグラウンド接続、ネットワーク切り替え

電池消費は暗号計算だけで決まらない

モバイルの電池消費は、CPU処理、無線モジュールの稼働時間、バックグラウンド復帰、データ再送、システムVPNサービスによって決まります。プロトコルの暗号処理負荷はその一部にすぎません。接続を維持しながら活動頻度が低い構成は、頻繁に切断と再接続を繰り返す構成より省電力になる場合があります。理論上は処理効率が高くても、ネットワークが不安定で再送を続ける方式は、より多くの電力を消費する可能性があります。プロトコルを評価するときは、数分間の速度測定後の電池残量だけでなく、フォアグラウンドでの閲覧、画面ロック中の待機、メッセージ受信、ネットワーク切り替え、動画通信を含む少なくとも1回の完全な使用サイクルを観察してください。

SSは設定が比較的簡単で、モバイルデバイスでも安定した動作を得やすい傾向がありますが、最終的にはUDP、DNS、システムVPNの実装に左右されます。Trojan、VMess、VLESSでTLSやトランスポート接続を頻繁に確立すると、復帰処理とハンドシェイクのコストが増えます。クライアントが接続を適切に再利用し、セッションを維持できれば、このコストは抑えられます。Hysteria2やTUICは弱いネットワークで長時間の待機や再送を減らし、実効的な電力効率を改善する可能性がありますが、ユーザー空間のプロトコル処理、タイマー、継続的なUDPセッションがバックグラウンド活動を増やすこともあります。すべてのスマートフォンとネットワークに共通する電池消費の順位はありません。

Androidのバックグラウンドと電池管理

Androidクライアントは通常、システムVPNインターフェースを通じて通信を引き継ぎます。メーカーごとのバックグラウンド管理によって、アプリプロセス、VPNサービス、ネットワーク活動が制限されることがあり、画面ロック後の切断が必ずしもプロトコル障害とは限りません。Clash Plus、Clash Meta for Android、FlClash、Surfboardを使う場合は、まずシステムのステータスバーでVPN接続が維持されているか確認し、次にアプリが電池最適化によって停止されていないか確認します。画面ロック後に特定のプロトコルだけ復帰が遅い場合は、接続のキープアライブとセッション復帰を比較します。すべてのプロトコルが同時に停止するなら、システムのバックグラウンド制御またはアプリプロセスの終了が原因である可能性が高いでしょう。

Androidではネットワーク切り替えも個別にテストする価値があります。Wi-Fiからモバイル通信へ切り替えると、ローカルIP、NATマッピング、経路が変わります。従来のTCP接続は通常再確立が必要ですが、QUIC系プロトコルは実装によってより柔軟に対応できる場合があります。ただし、クライアント、システムVPN、サーバーが連携して動作しなければなりません。切り替え後に接続済みと表示されても通信できない場合は、まずクライアントの接続を一時停止してから再開し、その後DNSが以前のネットワーク環境を参照していないか確認します。頻繁に自動切り替えが起こるデバイスでは、不要な同時接続を減らし、切り替えのたびに大量のセッションを再構築しないようにします。

iOSにおけるシステムVPNのライフサイクル

iOSクライアントも、システムのNetwork Extensionのライフサイクルとメモリ制限の影響を受けます。Clash Plusはシステムが提供するネットワーク拡張を通じて通信を処理し、バックグラウンド状態はシステムが一元的に管理します。複雑なノードパラメータ、大きすぎるルールセット、DNSキャッシュ、過剰な接続数は、拡張機能のメモリ負荷を高めます。モバイルの設定をリソースに余裕のあるデスクトップ用設定からそのまま流用するのは避け、特に重複した大規模ルールセットを同時に読み込まないでください。プロトコルが接続できない場合は、まず設定自体が解析を通ることを確認し、その後に単一ノードの失敗なのか、VPN拡張全体の終了なのかを確認します。

iOSで電池消費を比較する場合は、画面の明るさ、アプリの使い方、ネットワーク種別をできるだけ揃え、システムのバッテリー画面で一定時間観察します。フォアグラウンドの速度が高くてもバックグラウンド活動が明らかに増える場合は、常時接続を減らす、不要なトラフィック解析を無効にする、ルールを調整するといった対策を試してください。プロトコル変更だけで解決しようとしないことが大切です。iOSクライアントをインストールする場合は、iOSダウンロードコーナーでClash PlusのApp Store入口と公式サイトclashplus.ioを確認できます。

弱いネットワークでの電池と使い勝手のバランス

安定した家庭のWi-Fiでは、軽量なTCP方式で十分なことが多く、Hysteria2やTUICを常時使っても体感できる改善がない場合があります。通勤中、モバイル通信、アクセスポイントを頻繁に切り替える環境では、最新のUDP方式によって動画のバッファリングや接続停止が減るか比較できます。スマートフォンの温度、バックグラウンド活動、通信量が明らかに増えるなら、デフォルトパラメータに戻し、実際の帯域を超える上り・下り値を設定しないでください。送信速度を上げすぎて発生するキューイングと再送は、体感を悪化させるだけでなく、無線モジュールの稼働時間も延ばします。

モバイルでは2つの切り替え先を用意するのがおすすめです。1つは日常的に検証した安定ノード、もう1つは高遅延またはパケットロスのあるネットワーク向けのノードです。異常が発生したら、全設定をすぐに再読み込みするのではなく、まず切り替え先を変更します。これにより単一ノードの問題か、クライアント全体の問題かを素早く判断でき、設定を頻繁に変更することによる変数も減らせます。サブスク更新後にプロトコルフィールドが変わった場合は、新しいノードを手動でテストしてから自動選択やフェイルオーバーのグループに追加してください。

6. オリジナル版Clash、Clash Meta、mihomoの系譜

オリジナル版Clash：設定体系の基盤

オリジナル版Clashは、広く利用されるYAML設定構造、ルールシステム、プロキシグループ、コントロールインターフェースを確立しました。一般的な proxies、proxy-groups、rules、DNS、ポートのフィールドはいずれもこの体系に由来します。多くのクライアントはコアを変更した後も、画面や設定の概念にオリジナル版Clashの構成方法を引き継いでいます。そのため、オリジナル版の設定モデルを理解する価値は今もあります。ノードは接続を記述し、プロキシグループは選択と自動テストを担い、ルールはリクエストを適切なポリシーへ渡し、DNSはドメイン解決とルール照合に影響します。

オリジナル版Clashのプロトコル対応は、主にそのメンテナンス時期に一般的だった用途を基準としています。SS、VMess、Trojanなどの基本設定では、安定して広く互換性のある構文を形成しましたが、Hysteria2、TUIC、VLESSの拡張、ルール機能、最新のDNS機能を扱うには、通常は後継コアが必要です。オリジナル版コアだけをサポートする古いクライアントを使い続けると、サブスクは追加できても新しいノードがスキップされたり、未知のフィールドでエラーになったり、機能が通知なく無視されたりする可能性があります。

Clash Meta：既存モデルを拡張

Clash MetaはClashの設定体系との互換性を基盤に、より多くのプロトコル、トランスポート方式、ルール機能、DNSオプションを追加しました。重要なのはノード種別を増やしたことだけではなく、既存のプロキシグループとルールモデルで新しいプロトコル実装を扱えるようにした点です。使い慣れた設定構造の大部分を維持しながら、VLESS、Hysteria2、TUICなどを利用できます。ただし「オリジナル版との互換」は、基本フィールドと構成方法の多くを引き継げるという意味であり、任意のMeta設定をオリジナル版Clashへ逆方向に渡せるという意味ではありません。

設定でMeta固有のプロトコルや拡張フィールドを使った時点で、互換性は一方向になります。mihomoは多くのオリジナル版Clash設定を理解できますが、オリジナル版Clashはmihomoの設定をすべて理解できません。移行前に、プロキシ種別、ルール種別、DNSモード、トラフィック解析、ルールプロバイダー形式、プロキシグループのオプションなど、拡張点を確認してください。新旧クライアントを同時に維持する必要がある場合は、双方が対応するフィールドの共通部分を使うか、サブスクシステムで対象ごとに2種類の設定を生成します。複雑な1つの設定をすべてのコアに無理に対応させるのは避けてください。

mihomo：プロジェクト名の継承と現在の実装

mihomoはClash Metaの後継プロジェクト名として使われるようになったもので、多くのクライアント画面やドキュメントにはMeta、Clash Meta Core、mihomoが併記されています。判断時はクライアント名だけでなく、実際に使われているコアを確認してください。Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuなどのGUIクライアントは、設定管理、システムプロキシ、ログ、更新操作を画面にまとめられますが、ノードプロトコルの解析と実行は最終的にコアが担当します。クライアント本体とコアの更新が別々に行われることもあるため、画面の機能が正常でも、コアがサブスク内の新しいフィールドすべてに対応しているとは限りません。

当サイトのダウンロードページでは、GUIクライアントとmihomoコアパッケージを分けて掲載しています。一般的なデスクトップ・モバイルユーザーにはGUIクライアントをおすすめします。Clash Plusは全プラットフォーム向けの第一候補で、統一された画面からサブスク追加、ポリシー選択、システムプロキシ管理を行いたいユーザーに適しています。mihomoコアを直接ダウンロードする方法は、サーバー、ルーター、自分で設定とプロセスを管理する環境に向いています。コア単体は完全なデスクトップアプリではないため、システムプロキシ、起動時実行、設定編集、更新は外部ツールで処理する必要があります。

クライアントが使用中のコアを確認する方法

まずクライアントの「About」「コア」「実行状態」などの画面で、アプリ名とコア名を区別します。次に設定チェックまたは起動ログを確認します。コアは読み込み時に未知のフィールド、プロキシ解析失敗、ルールエラーを報告することがあります。さらにmihomoだけが対応するノードを1つ選んでテストします。追加時にノードが除外されるなら、サブスク変換先または現在のコアが一致していない可能性があります。インストールパッケージのファイル名だけで判断しないでください。一部のクライアントではコアを切り替えたり、コアファイルだけを個別更新したりできます。

古いクライアントから移行する際は、唯一の利用可能な設定を上書きせず、まず新しいクライアントにサブスクのコピーを追加します。ノード数、プロキシグループ、ルールが期待どおりであることを確認してから、DNSとプロトコル接続をテストします。mihomoとオリジナル版Clashの詳しい違いは、mihomoとオリジナル版Clashの違いでも確認できます。起動時に設定エラーが出る場合は、最初に表示された解析エラーから対処してください。後続のエラーは、最初の構造上の問題による連鎖反応である可能性があります。

7. サブスク形式、YAMLフィールド、移行時の互換性

ノードリンク、サブスク一覧、完全な設定は異なる3つの階層

単一ノードのリンクは通常、プロトコル、サーバー、ポート、認証パラメータなど、1つのプロキシに必要な情報だけを記述します。サブスク一覧は複数ノードの集合で、Base64テキスト、専用リンク一覧、サーバー生成形式などが使われます。完全なClash設定にはノードだけでなく、プロキシグループ、ルール、DNS、ポート、その他の実行パラメータも含まれます。サブスクをクライアントへ追加すると、解析、変換、統合、上書きが行われることがあり、最終的に読み込まれるYAMLは遠隔の元データと完全には一致しません。

互換性の問題は変換段階でよく発生します。元のサブスクに対象コアが認識できないプロトコルが含まれていると、変換ツールが未知のフィールドを破棄することがあります。別のエコシステムのフィールドをClash構文へ変換できても、拡張パラメータの一部まで対応していない場合があります。ノード数が正しく見えても、すべてのノード構造が完全だとは限りません。移行後は、異なるプロトコルから各1ノードを抽出して確認してください。特にWebSocket、gRPC、TLS、Reality系の拡張、UDPパラメータを含むノードでは、重要なフィールドが失われていないか確認が必要です。

YAMLの構造と型を正確に保つ

YAMLはインデントで階層を表すため、リスト項目、オブジェクト、文字列の型を正確に記述する必要があります。ポートは通常数値、真偽値は true または false とし、特殊文字を含むパスワードや名前には引用符を使うのが適しています。Tab文字、全角の句読点、誤ったインデント、重複キーは設定の解析失敗につながります。クライアントに構文チェックがある場合は、メイン設定を置き換える前に使用してください。手動編集では一度に小さな範囲だけを変更し、直前の読み込み可能なコピーを残します。

proxies:
  - name: "SS-Test"
    type: ss
    server: test.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "SS-Test"
      - DIRECT

rules:
  - MATCH,手動選択

この設定例は、ノード、プロキシグループ、ルール間の参照関係を示しています。プロキシグループ内の名前はノード名と完全に一致し、ルール末尾で参照するプロキシグループも存在しなければなりません。例示されたアドレスとパスワードで直接接続することはできません。実際のサブスクでノード名にカンマ、特殊記号、重複名が含まれる場合、変換ツールが名前を変更することがあります。手動で記述したプロキシグループの参照も合わせて更新してください。

基本フィールドの互換性は、動作が完全に同じという意味ではない

同じフィールドでも、コアによってデフォルト値が異なる場合があります。古いフィールドが引き続き受け付けられていても、推奨されなくなっていることがあります。移行時に最も安全なのは、対象クライアントで基本設定を作り直し、ノード、プロキシグループ、必要なルールだけを移す方法です。古いクライアントが出力した実行パラメータをすべてコピーするのは避けてください。システムプロキシのポート、コントロールインターフェース、キャッシュパス、外部リソースディレクトリはデバイス環境に依存するため、異なるプラットフォームでそのまま再利用するのには適していません。

DNSもリスクの高い領域です。オリジナル版Clash、Meta、mihomoではDNS機能と利用可能なフィールドが進化しており、古い設定のnameserver、fallback、fake-ipの範囲、フィルタールールは現在のコアに合わせて再確認する必要があります。ノードは接続できるのに一部のドメインだけ名前解決に失敗する場合は、「システムのリクエストがクライアントへ入っているか」「Clashがどのリゾルバーを使っているか」「解決結果がどのようにルール照合へ渡るか」の3段階に分けて確認します。詳しいリクエスト経路はClash DNS設定詳解をご覧ください。

サブスク更新の失敗とローカル上書き

クライアントは通常、サブスクURL、遠隔設定のキャッシュ、ローカル上書きを保存します。遠隔設定から生成されたファイルを直接編集すると、次回更新で変更が上書きされる可能性があります。上書きルールの範囲が広すぎる場合も、更新後に新しいノードフィールドが削除されることがあります。元のサブスクは保持し、クライアントが対応する上書きレイヤーにプロキシグループやルールを追加する方法がおすすめです。更新に失敗したら、URLにアクセスできないのか、取得内容が空なのか、認証情報が無効なのか、ダウンロードは成功したものの解析に失敗したのかを切り分けます。前2つは取得段階、後2つは内容段階の問題であり、調査方法が異なります。

定期更新では、間隔を短くしすぎないでください。頻繁なリクエストを行ってもノードが速くなり続けるわけではなく、重複解析、プロキシグループの再構築、モバイルのバックグラウンド復帰を増やす可能性があります。サブスク提供者が更新間隔を指定している場合は、その推奨に従います。指定がなければ、実際の変更頻度に合わせて適切な周期を選びます。更新後にノード数が急に減った場合は、まず古いキャッシュを残し、利用可能な設定をすぐに削除しないでください。詳しい手順はClashのサブスク更新に失敗する原因と自動更新間隔の設定を参照してください。

8. デバイスとネットワークの用途に合わせて最終選定する

安定したデスクトップ回線：互換性と保守コストを優先

Windows、macOS、Linuxのデスクトップで安定したブロードバンドに接続する場合、プロトコル差よりサーバー回線の差の方が大きいことがよくあります。信頼できるSS、Trojan、VMess、VLESSノードをすでに使えているなら、プロトコル名が古いという理由だけで変更する必要はありません。現在のクライアントが完全に対応し、サブスクのフィールドが明確で、サーバーが安定して保守されている方式を優先します。GUIが必要なら、まずダウンロードページからClash Plusを選び、その後プラットフォームに応じてClash Verge Rev、FlClash、Clash Nyanpasuなど掲載クライアントを比較してください。

デスクトップで初めて設定するときは、複雑な上書きをすぐに重ねるのではなく、ルールモードを使うことをおすすめします。まずノードの直接接続テスト、プロキシグループの切り替え、DNSを確認し、その後に追加ルールを読み込みます。同じサービスが複数のプロトコルを提供している場合は、同じ地域のノードを選んで1つの変数だけを比較します。安定したネットワークでは、ピーク値だけでなく、初回表示、長時間の安定性、リソース使用量を重視してください。SSは設定が簡潔で、TrojanとVLESSはTLSパラメータに依存することが多く、VMessではトランスポートフィールドを完全に保持する必要があります。いずれも設定と回線がより成熟していれば、日常利用に適した選択肢になります。

高遅延または軽度から中程度のパケットロス：Hysteria2とTUICを比較

地域をまたぐ接続、モバイルホットスポット、無線品質の変動が大きい環境では、Hysteria2とTUICをテストできます。まずクライアントがmihomoを使っていることを確認し、サブスクがノードの全フィールドを出力していることを確認します。テストでは高い帯域値を先に設定せず、デフォルトパラメータで基準値を作ります。連続ダウンロードが滑らかになり、動画のシークから速く復帰し、デバイスのリソース使用量も許容範囲なら、最新のUDP方式が現在の経路に適しています。アイドル後に接続が頻繁に切れたり、特定のネットワークでUDPセッションをまったく確立できなかったりする場合は、Trojan、VLESS、SSを代替の入口として残してください。

Hysteria2は、認証とTLSの設定を比較的集約し、弱いネットワークでのスループットを検証したい用途に向いています。TUICでは、認証フィールド、多重化、輻輳制御、UDPリレー方式が対象コアと一致しているかを重点的に確認します。どちらもサーバー設定を無視して独自に変換するものではありません。サーバーが一方しか提供していない場合は、その実装を中心にテストし、名称だけを根拠にもう一方が必ず速いと判断しないでください。

モバイルデバイス：ピーク速度より安定した復帰を優先

AndroidとiOSの選定では、画面ロック、バックグラウンド、ネットワーク切り替えのテストを含めます。家庭のWi-Fiを主に使うなら、安定したSS、Trojan、VLESSでバランスのよい動作を得やすいでしょう。モバイル通信で遅延が大きくランダムなパケットロスがある場合は、Hysteria2やTUICをテストできますが、電池消費、温度、バックグラウンド活動も同時に観察してください。画面ロック後にクライアントがシステムによって停止される場合は、まずシステムのバックグラウンド許可を調整し、すべての切断をプロトコルのせいにしないでください。

モバイル設定ではルールセットと同時接続数を抑え、デスクトップ設定をスマートフォンへそのままコピーしないようにします。検証済みの安定したポリシーと弱いネットワーク向けのポリシーを1つずつ残し、切り替え時はノードまたはプロキシグループだけを変更します。サブスク更新後はまずテストしてから自動選択グループへ追加します。これにより突然の互換性問題を減らし、異常がノード、プロトコル、システムVPNのライフサイクルのどこから生じたか判断しやすくなります。

ルーターとサーバー：リソース予算が上限を決める

ルーター、透過型ルーター、小型サーバーでmihomoを直接動かす場合は、CPUアーキテクチャ、使用可能なメモリ、ストレージ容量、システムサービスの管理方式を先に確認します。低消費電力デバイスでは、単純なプロトコルと適量のルールを使う方が安定しやすく、複雑なDNS、トラフィック解析、大規模なルールセット、最新のUDPプロトコルを重ねると、単一コアの使用率が上限に達したり、メモリが圧迫されたりすることがあります。導入前は少数のノードと基本ルールだけで動かし、長時間のリソース使用量を確認してから機能を1つずつ追加してください。

ルーターがLAN全体の通信を処理する場合、同時接続数は1台のPCよりはるかに多くなります。プロトコルの多重化、コネクショントラッキング、DNSキャッシュ、ログがリソース需要を増幅します。ピーク時間帯に速度が低下する場合は、CPU、メモリ、温度、ネットワークインターフェース、上流回線を同時に確認し、プロトコルだけを交換しないでください。mihomoコアを直接使う場合は、プロセス監視、設定権限、更新手順も自分で管理する必要があります。これらの操作に慣れていない場合は、デスクトップまたはモバイルのGUIクライアントの方が保守コストは低くなります。

移行と検証のチェックリスト

古いクライアントからmihomoクライアントへ移行する場合は、まずサブスクURLと現在利用できる設定をバックアップし、対象クライアントをインストールします。Clash Plusを優先的に選び、新しいクライアントにサブスクを再追加してください。古いアプリのデータは上書きしません。追加後はノード数とプロトコルの内訳を確認し、実際に存在するSS、VMess、Trojan、VLESS、Hysteria2、TUICのノードをそれぞれテストします。その後、プロキシグループ、ルールモード、DNS、システムプロキシを確認し、最後に自動起動やバックグラウンド権限などのアプリ設定を調整します。

ノードの検証は固定した順番で行います。設定を解析できるか、ノードが接続を完了できるか、ドメインを解決できるか、ルールが想定したポリシーを選べるか、継続通信が安定しているか、画面ロックまたはアイドル後に復帰できるかを確認します。最初の段階で失敗した場合は、速度測定のパラメータ調整へ進まないでください。ノードは接続できるのにWebページが開かない場合は、DNSとシステムプロキシを確認します。継続通信の段階だけで異常が出る場合に、輻輳、パケットロス、リソース使用量を重点的に比較します。インターネットに接続できない、サブスク更新に失敗する、起動時にエラーが出る場合は、トラブル対処で症状別に確認してください。

最終的な選定で、全環境に共通する唯一の答えを求める必要はありません。デスクトップ、スマートフォン、ルーターで異なるクライアントやプロトコルを使ってもよく、安定したネットワークと弱いネットワークを2つのプロキシグループに分けて必要に応じて切り替えることもできます。プロトコル選びの核心は、サーバーの機能、コアの対応、サブスクのフィールド、デバイスの条件を一貫した構成にすることです。この4つが一致していれば、従来型プロトコルも最新プロトコルも、適した用途で力を発揮できます。