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

01 · SELECTION MODEL

まずプロトコル、トランスポート層、クライアントの機能を分けて考える

プロトコル名だけでは接続全体を表せない

Clashクライアントのノード一覧では、通常まず ss、vmess、trojan、vless、hysteria2、tuicといった表示を確認します。これらはプロキシセッションにおける認証、カプセル化、データ転送の方法を示す名称であり、接続環境全体を意味するものではありません。実際の性能は、基盤がTCPかUDPか、TLSを重ねるか、WebSocketやgRPCを使うか、サーバーとの距離、経路上のパケットロス、輻輳制御、DNSの解決方法、クライアントカーネルの実装などにも左右されます。

たとえば同じVLESSでも、TCP接続とWebSocketベースの接続ではハンドシェイクの負荷が異なります。同じShadowsocksでも、暗号化方式によって古い端末へのCPU負荷は変わります。Hysteria2とTUICはいずれもQUICを基盤としますが、セッション管理、認証フィールド、輻輳制御は同一ではありません。トランスポートの設定を無視してプロトコル名だけを比べると、サーバー品質、ネットワーク経路、プロトコル設計を混同しやすくなります。

したがって、設定は3層に分けて読み取ります。第1層はノードのプロトコルで、認証と基本的なカプセル化を決めます。第2層はトランスポートとセキュリティの設定で、たとえば network、tls、servername、ALPN、輻輳制御、UDPリレーなどです。第3層はクライアントの機能で、カーネルがフィールドを認識できるか、GUIで完全に編集できるか、Androidのバックグラウンド動作が安定するか、サブスクリプション変換で元の設定が保持されるかを確認します。3層すべてが満たされて初めて、ノードは想定どおり接続できます。

速度の結論には測定条件を紐づける

プロトコルに、環境から切り離した固定の速度ランキングはありません。短距離でパケットロスの少ない回線なら、TCPで十分安定し、速度差の主因はサーバー負荷である場合もあります。RTTが大きい、または変動の激しいモバイル回線では、QUIC系が転送をより速く回復できる可能性がありますが、通信事業者のUDP処理によって優位性を失うこともあります。ノードの遅延は探査リクエストの往復時間を示すだけで、Webページの初回表示、ファイル転送速度、動画のバッファリング性能と同じではありません。

比較するなら、クライアント、カーネル、サーバーの地域、測定時刻、ルールモードを固定し、初回接続時間、継続的なスループット、ネットワーク切り替え後の復旧時間、端末の電池消費をそれぞれ記録します。単発の無線揺らぎを除くため、少なくとも複数回測定してください。サブスクリプション内のプロトコルが異なるサーバーに割り当てられている場合、結果から判断できるのはノード全体の品質であり、プロトコル単体の性能ではありません。

プロトコルの流行ではなく、利用条件から考える

プロトコルを選ぶ前に、次の4点を確認します。クライアントのカーネルが対応しているか、サブスクリプションを完全に配布できるか、現在のネットワークでUDPが安定して使えるか、端末を長時間バックグラウンドで動かす必要があるかです。デスクトップでは多少のメモリ消費を許容できますが、モバイルでは無線モジュールのウェイクアップ、再接続頻度、バッテリー最適化も考慮します。ルーターはCPUアーキテクチャ、メモリ容量、ハードウェアアクセラレーションにも制約されます。PCで安定するノードが、低消費電力の端末で家庭全体の通信を長時間処理するのに適しているとは限りません。

信頼性と幅広い互換性を重視するなら、成熟したSSやTrojanは導入・移行が比較的容易です。新しいトランスポート構成が必要なら、カーネルの対応を確認したうえでVLESSを選べます。高遅延またはパケットロスのある回線ではHysteria2やTUICを試せますが、TCPノードも予備として残してください。VMessは既存サブスクリプションでよく使われており、継続利用に問題はありません。新規設定で採用するかは、名称の新旧ではなく、サーバー側の環境とクライアントの対応範囲で判断します。

以降の章では、プロトコルの系統、性能、カーネルの関係、用途別の判断を取り上げます。現在の問題が「接続済みなのにWebページが開けない」であれば、すぐにプロトコルを変更せず、まず8段階のネットワークトラブル対応チェックリストに沿ってノード、DNS、ルール、システム時刻を確認してください。接続障害とプロトコル選定は別の問題です。分けて対処するほうが、安定した結論にたどり着けます。

02 · SS / VMESS

ShadowsocksとVMess：成熟した実装と状態を持つセッション

Shadowsocksの設計上のポイント

Shadowsocksは設定上、通常 ss と表記されます。基本構造は比較的シンプルで、クライアントが事前共有パスワードから鍵を導出し、プロキシ通信を暗号化してサーバーへ転送します。現在の設定ではAEAD、または新しい2022シリーズの暗号化方式が一般的です。プロトコルヘッダーが軽く、対応クライアントも多く、TCP・UDPの転送経路が成熟しているため、互換性の基準として使われることが多い方式です。

SSの強みは「どの環境でも最速」であることではなく、実装が多く、設定項目が少なく、リソース消費を予測しやすい点です。一般的なWeb閲覧、ソフトウェア更新、長時間接続、通常のUDPアプリでは、安定した結果を得やすい傾向があります。低性能ルーターでは暗号化方式がCPU使用率に大きく影響します。ハードウェアアクセラレーションに対応したAES環境ではAES-GCMが適する場合があり、一部のモバイルプロセッサや異なるアーキテクチャではChaCha20-Poly1305のほうがバランスに優れることもあります。速度はアルゴリズム名だけで判断せず、実際の端末負荷を確認してください。

2022シリーズは鍵とセッションの処理方法を改良していますが、クライアントとサーバーの双方が対応している必要があります。サブスクリプションで新方式が誤って旧フィールドへ変換されると、速度低下ではなく認証エラーが直接発生することがあります。インポート後は cipher と password が完全に保持されているか、特にパスワードがサーバーの要求する鍵形式になっているかを確認します。GUIにノード名しか表示されない場合は、設定をエクスポートするか、元のProfileを確認してください。

VMessの状態依存性と時刻条件

VMessはユーザー識別子で認証し、セッションに関する処理も行います。Clash設定では uuid、alterId、cipher、トランスポート、TLS設定などがよく使われます。新しいサーバーでは簡略化された認証構成が一般的ですが、古いサブスクリプションには過去のフィールドが残っていることがあります。設定の出所が多岐にわたるため、VMessノードで確認すべきなのは名称ではなく、フィールドの組み合わせがサーバーと一致しているかどうかです。

VMessはシステム時刻の影響を受けやすい方式です。Androidやデスクトップの時刻が大きくずれていると、ノードが存在し、ネットワーク権限も正常なのに、ハンドシェイクだけが失敗し続けることがあります。この場合、クライアントの再インストールでは解決しません。まず自動時刻と自動タイムゾーンを有効にしてから、再接続してください。企業ネットワーク、仮想マシンのスナップショット、長期間オフラインの端末では時刻ずれが起きやすくなります。

VMessはTCP、WebSocket、HTTP、gRPCなどの上に実装できます。トランスポート層は導入の柔軟性を高めますが、設定項目も増えます。WebSocketノードではパスとHostの対応が必要です。TLSノードではサーバー名と証明書名を一致させます。gRPCノードではサービス名を正しく指定します。サブスクリプション変換でどれか1つのフィールドが失われても接続に失敗する可能性があります。そのためVMessの互換性は「カーネルがVMessに対応しているか」だけでなく、サブスクリプションが使う具体的なトランスポート構成まで確認する必要があります。

適用範囲と注意点

設定をシンプルにし、クライアント間で移行しやすくしたい場合、SSは堅実な選択です。既存のVMessサブスクリプションが安定しているなら、プロトコル名だけを理由に設定を変更する必要はありません。複数のクライアントを頻繁に切り替える場合は、VMessノードの元のサブスクリプションを優先して保持し、何段階もの変換を避けてください。変換を重ねるほど、フィールド名の変更、デフォルト値の変化、トランスポート設定の欠落が起きる可能性が高まります。

Androidで長時間動かす場合、両者の基本的な電池消費はプロトコル名ではなく、実際の通信量、TLS接続数、UDPの稼働状況、DNSモード、遅延テストの頻度によって決まります。バックグラウンド消費が急に増えた場合は、Androidのバックグラウンド消費と常駐設定を参照し、高頻度の自動速度テストを停止して、端末メーカーのバッテリー設定がVPNサービスを繰り返し終了させていないか確認してください。

proxies:
  - name: ss-primary
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

この例では、mihomoで使える基本的なフィールド構造を示します。ドメイン、ポート、パスワードはサブスクリプションが提供する実際の値に置き換えてください。手入力する場合はYAMLのインデントを統一し、タブは使わないでください。クライアントがサブスクリプションを管理している場合は、更新のたびにローカルコピーを修正するのではなく、元の設定ソースを直すことを優先します。

03 · TROJAN / VLESS

TrojanとVLESS：TLSセッションと簡潔な認証

Trojanの接続構造

Trojanは通常、TLSを接続の基盤とし、クライアントがパスワードで認証します。主な設定項目はサーバーアドレス、ポート、パスワード、SNIに対応する servername、証明書検証、UDPの有効化です。フィールド数は多くありませんが、TLSの名前は正確でなければなりません。サーバーアドレスにはIPアドレスを指定できますが、SNIには証明書に対応するドメインを入力します。IPアドレスをサーバー名としても使うと、通常は証明書検証に失敗します。

Trojanの一般的な強みは、成熟したTLSスタックを基盤とし、デスクトップ・モバイル双方で実装が安定していることです。性能はTLSハンドシェイク、接続の再利用、サーバー設定、回線品質に大きく左右されます。確立済みの長時間接続では、転送のたびに完全なハンドシェイクを繰り返さないため、継続的なスループットは比較的安定します。短時間接続が大量に発生する場面では、暗号化負荷だけでなく接続再利用とDNSの結果を確認することが重要です。

クライアントには「証明書検証をスキップ」といった項目がありますが、長期的な解決策として使うべきではありません。証明書エラーは、システム時刻、SNI、ドメイン、サーバー側の証明書設定が一致していないことを示す場合が多いです。一時的に検証を無効にすると原因を隠し、もとの安全境界も変えてしまいます。自動時刻を確認し、servernameを照合し、サブスクリプションでこのフィールドが保持されているかを確認した後、サーバー管理者に証明書チェーンを確認してもらうのが正しい順序です。

VLESSの役割と範囲

VLESSは認証とトランスポートの安全性を分けて扱い、従来型の内蔵暗号化層自体は備えません。通常はTLSなど、対応する安全なトランスポートに依存します。UUID系の識別子で認証し、プロトコルヘッダーは比較的軽量です。TCP、WebSocket、gRPCなどのトランスポートと組み合わせられ、一部の設定にはフロー制御やReality関連のフィールドも含まれます。これらの機能が使えるかは、サーバー実装とクライアントカーネルに依存します。

「VLESS対応」とは、カーネルが基本プロトコルを認識するという意味にすぎず、すべての拡張機能に対応するとは限りません。旧版のオリジナルClashはVLESSと後続拡張の対応範囲が限られますが、Meta系の後継であるmihomoはより多くのフィールドを扱えます。Clash Plus、Clash Verge Rev、FlClashなどを使う場合も、実際に組み込まれているカーネルと設定画面を確認してください。GUIで表示できるのは一般的なフィールドだけでも、サブスクリプションのインポートで追加パラメーターが保持される場合があります。一方で、画面が認識しない値を内部変換で破棄することもあります。

VLESS設定のトラブル対応は、基礎層から順に進めます。まずアドレス、ポート、UUIDを確認し、次にTLS、サーバー名、トランスポート種別、最後にパス、サービス名、フロー制御、Realityのパラメーターを確認します。一度に複数の項目を変更しないでください。接続が戻っても、原因を特定できなくなります。サブスクリプション更新でローカル変更が上書きされることもよくあります。検証後は、修正をサブスクリプションの元データまたはクライアントの永続的な上書き設定へ反映してください。

両者の選び方

Trojanは、設定項目が比較的まとまり、TLS設定が明確で、複数クライアントへ移行しやすい用途に向いています。VLESSは、サーバー側が対応するエコシステムを採用し、クライアントがmihomoなどの互換カーネルを明確に使っている場合に適しています。どちらもサーバー回線の品質を補うものではありません。TrojanとVLESSが異なるサーバーにある場合、速度テストで一方のプロトコルが効率的だとは証明できません。同じサーバー、同じ回線、同じ時間帯で比較して初めて参考になります。

モバイルで使う場合、TLSセッションを維持するだけで異常に電池を消費するとは限りません。電池に大きく影響するのは、接続が頻繁に切れるか、システムがVPNサービスを何度も起動するか、アプリがURLテストを継続するか、QUIC・音声・ゲームなどのUDP通信が長時間活発かどうかです。正しく設定され安定して接続できるTrojanノードのほうが、頻繁に再接続する軽量プロトコルより省電力になる場合もあります。安定性そのものが消費電力に影響します。

proxies:
  - name: vless-tls
    type: vless
    server: proxy.example.com
    port: 443
    uuid: 00000000-0000-4000-8000-000000000000
    network: ws
    tls: true
    servername: edge.example.com
    ws-opts:
      path: /proxy
      headers:
        Host: edge.example.com

この断片はフィールドの階層を示すもので、接続可能なノードを表すものではありません。WebSocketのパスは大文字・小文字を区別します。HostとSNIは同じ場合もあれば、サーバー側で別々に指定される場合もあります。インポートに失敗したときは、他のノードからフィールドをコピーするのではなく、サブスクリプションの原文と照合してください。異なるサーバーのパスや認証情報を混在させることはできません。

04 · QUIC TRANSPORT

Hysteria2とTUIC：変動のある回線向けのQUICプロトコル

QUICで変わる接続動作

Hysteria2とTUICはいずれもUDPベースのQUICトランスポートを使用します。QUICは暗号化ハンドシェイク、信頼性のある転送、多重化をユーザー空間で組み合わせ、従来のTCPにおける複数接続間のヘッドオブラインブロッキングを避けます。RTTが大きく、パケットロスが変動する回線では、適切に設定したQUICセッションのほうがスループットを早く回復できる可能性があります。Wi-Fiからモバイルデータへ切り替える際、一部の実装では接続移行によりセッション再確立の負荷を下げることもできます。

ただし、これらの特徴があらゆるUDP環境での高速化を意味するわけではありません。アクセス回線がUDPセッションの継続時間を制限している、ルーターが大容量UDPの処理を苦手としている、NATマッピングが頻繁に変わるといった場合、QUICノードは接続できてもスループットが不安定、待機後の復旧が遅い、音声は正常なのにWebページがときどきタイムアウトするといった症状を示します。まずUDPの基本的な到達性を確認してから、プロトコル設定を調整してください。帯域幅の申告値を増やすだけでは、ネットワーク経路の問題は直りません。

Hysteria2の帯域幅と輻輳制御の設定

Hysteria2は初期の設定構造を簡略化しており、一般的なフィールドにはサーバー、ポート、パスワード、SNI、証明書検証、上下り帯域幅のヒントなどがあります。帯域幅の値は、クライアントが自由に得る加速枠ではなく、輻輳制御が送信ペースを推定するための入力値です。実際の回線能力を大幅に上回る値を入れると、バースト的なパケットロスや再送を招く可能性があります。低すぎる値はスループットを制限します。明確な指定がなければ、サブスクリプションの値またはカーネルのデフォルトを優先してください。

Hysteria2はUDP経路の品質に敏感です。テストでは遅延だけでなく、継続ダウンロードが周期的に減速しないか、ネットワーク切り替え後に復旧するか、スリープ解除後の最初のリクエストがタイムアウトしないかも確認します。Androidメーカーのバッテリー制御でクライアントが停止されると、QUICのキープアライブが途切れることがあります。前面復帰後の再接続は、必ずしもプロトコル障害ではなく、OSのバックグラウンド制限によるものです。比較の前に、クライアントを適切なバックグラウンド動作の対象に設定してください。

証明書に関する処理は、他のTLSプロトコルと同じです。SNIはサーバー証明書と一致させ、システム時刻も正確に保ちます。検証のスキップを常用設定にしてはいけません。サブスクリプションに難読化パスワードやポートホッピングなどの拡張フィールドが含まれる場合は、mihomoカーネルと現在のクライアントが同じフィールド名を使っているか確認してください。変換サービスが基本的なHysteria2だけを認識し、拡張項目を無視することがあります。

TUICのセッションと並行処理の特徴

TUICもQUICを基盤とし、一般的な認証にはUUIDとパスワードを使います。輻輳制御、UDPリレーモード、SNI、ALPNなどのパラメーターも指定できます。並行ストリームと低遅延のデータ転送を重視した設計で、Webページの多数のリクエスト、リアルタイム通信、TCP・UDP通信が同時に存在する環境では、安定した回線で良好な応答性を保てます。ただし、サーバーとクライアントがプロトコルのバージョンとフィールド定義で一致している必要があります。古い形式の設定は type だけ変更して使い続けないでください。

TUICの輻輳制御オプションは、サーバーの推奨値と回線特性に応じて選びます。他人の設定をそのままコピーすると、帯域幅やキュー管理が異なる環境で逆効果になる可能性があります。UDPリレーモードも互換性に影響します。ネイティブUDPの動作を重視するモードもあれば、QUICストリーム経由の転送に適したモードもあります。ゲーム、音声、DNSだけに障害が出る場合は、ノード全体が「接続成功」かどうかだけでなく、リレーモードを確認してください。

Hysteria2とTUICは、すべてのTCPノードを置き換えるのではなく、特定の回線向けの候補としてプロキシグループに加えるのが適しています。手動選択グループを作り、成熟したTCPノードとQUICノードを1つずつ残して、固定サイト、固定ファイル、固定時間帯で比較できます。変動のある回線での復旧性能を活かしつつ、UDP条件が変わったときもすぐ切り替えられます。

05 · PERFORMANCE / POWER

接続速度、リソース消費、モバイルの電池消費

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

体感速度には、少なくとも接続確立時間、TTFB、継続スループット、障害からの復旧時間が含まれます。Webページの表示が遅い場合はDNS、TLS、初回接続の遅延が原因かもしれません。大容量ファイルの転送が遅い場合は継続スループットの問題に近く、地下鉄やモバイルホットスポットの切り替え後に長時間応答しない場合は接続復旧の問題です。プロトコルごとに改善する箇所が異なるため、1回の遅延テストだけでは全指標を評価できません。

SSは基本的なカプセル化が軽く、パケットロスの少ない環境では接続確立も転送もシンプルです。Trojan、TLSを有効にしたVMessやVLESSではハンドシェイクが増えますが、長時間接続が確立した後は継続転送の差が小さくなることが多いです。Hysteria2とTUICは、高遅延、変動、ランダムなパケットロスのある回線で復旧が速い場合がありますが、UDP経路が安定していることが前提です。プロトコルの速度は固定値ではなく、仕組みと現在の回線が相互に作用した結果です。

クライアントの遅延テストにも測定上の限界があります。URL-Testは通常、指定したアドレスへHTTPリクエストを送り、DNS、接続、サーバー応答を含む結果を返します。複数ノードを同時にテストすると、短時間に大量の接続が作られ、モバイル端末の無線やCPUが頻繁に起動します。テスト間隔が短すぎると、表示される数字は頻繁に変化しますが、バックグラウンド消費と通信量が増えます。日常利用で秒単位の遅延を常時更新する必要はありません。

CPU、メモリ、接続数

CPU消費は、暗号化、TLS、データコピー、ルール照合、DNS処理、TUNプロトコルスタックなどから発生します。一般的な接続1本でデスクトップCPUに大きな負荷がかかることは通常ありませんが、高速ダウンロード、数百の同時接続、低性能ルーターでは差が拡大します。SSの暗号化方式はハードウェア性能と合わせて選びます。TLS系プロトコルはシステムまたはカーネルの暗号化ライブラリを使い、QUICはユーザー空間でパケットロス回復と輻輳制御を管理するため、単純なTCPプロキシより計算資源を多く使う場合があります。

メモリ使用量はプロトコルだけでは決まりません。ルールセットの規模、Geoデータ、Fake-IPマッピング、接続追跡、ログレベルも常駐メモリを増加させます。同じノードでも、ルールモードとグローバルモードの差がプロトコルではなくルール処理に由来する場合があります。調査では設定を固定し、ノードだけを1つ置き換えて、しばらく安定稼働した後のCPUとメモリを観察してください。起動時のルール読み込みピークを長期状態と混同しないことが重要です。

接続の再利用はハンドシェイクを減らせますが、長時間接続が多すぎると状態管理の負荷が増えます。ブラウザー、メッセージアプリ、システム同期サービスが同時に接続を維持することもあります。TUNモードでは対象アプリの範囲が広いため、接続数はシステムプロキシだけの場合より多くなりがちです。TUNへ切り替えて電池消費が増えたら、プロキシ対象アプリ、DNSループの有無、バックグラウンド同期アプリの再試行を確認してください。

Androidの電池消費はウェイクアップの仕方で決まる

AndroidのClashクライアントは VpnService を使ってローカルVPNインターフェースを作成します。VPNアイコンが表示されている間、対象の通信はクライアントへ渡されますが、常駐サービスが常に高負荷という意味ではありません。電池消費を左右するのは、毎秒処理するデータ量、無線をアクティブに保つ時間、定期的な速度テスト、ログ書き込み、接続の再確立、端末メーカーのバックグラウンド制御です。

頻繁に終了と再起動を繰り返す状態は、安定して常駐する状態より電池を消費しやすくなります。バッテリー最適化でクライアントが停止されても、システムアプリがリクエストを発生させることがあります。復帰時には再接続が集中し、短時間のCPUピークと通信の急増が起こります。長時間使う場合は必要なバックグラウンド動作を許可し、自動速度テストの頻度を下げ、トラブル対応後は詳細ログを無効にしてください。複数のVPNやネットワークフィルターアプリを同時に使うことも避けます。

QUICプロトコルはUDPマッピングとキープアライブを維持することがあり、モバイル回線での電池消費は実装とネットワークのタイムアウトポリシーに左右されます。待機中の消費が異常な場合は、TCPノードとQUICノードを1つずつ、同じルール、DNS、アプリ利用方法でテストしてください。変更するのはプロトコルグループだけにします。画面オフ後の電池残量、クライアントの再接続回数、システムのネットワーク状態を記録して初めて、差の原因を判断できます。

クライアントが接続済みと表示されているのに、アプリの通信が完全に止まっている場合は、まずDNS、ルール、システムプロキシの問題を除外します。ブラウザーとターミナルではプロキシを参照する経路が異なります。確認方法はシステムプロキシが効かない場合の2つのトラブル対応経路を参照してください。通信が実際にカーネルへ到達していると確認できて初めて、プロトコル性能の比較に意味が生まれます。

06 · KERNEL FAMILY

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

オリジナルClashの設定基盤

オリジナルClashは、proxies、proxy-groups、rules、DNS、待受ポート、動作モードなどを含む、広く使われるYAML設定構造を確立しました。現在も多くのサブスクリプションやクライアントGUIがこの構造を基盤としています。ノード、プロキシグループ、ルールによる振り分けを統一的に表現し、異なるプロトコルを同じ選択・自動テストの仕組みに組み込めることが、基本的な価値です。

オリジナルプロジェクトがメンテナンスを終了した後も、既存クライアントは過去のカーネルを使い続ける場合があります。しかし、新しいプロトコル、DNSの挙動、各プラットフォームへの対応が自動的に改善されるわけではありません。したがって「Clash設定」と「オリジナルClashカーネル」は分けて考える必要があります。前者はエコシステムで広く使われる設定形式の呼び名で、後者は特定の実装を指します。Clash YAML形式のファイルだからといって、オリジナルカーネルでしか読み込めないわけではありません。

Clash.Metaからmihomoへ

Clash.Metaは従来の設定モデルを基盤に、プロトコル、TUN、DNS、ルールプロバイダー、プラットフォーム機能を拡張し、その後はカーネル名mihomoとして発展を続けています。実際の利用では、Meta設定、Metaノード、Clash Meta for Androidなどの名称が引き続き使われています。これらはプロジェクトの発展やクライアントブランドを示すもので、完全に独立した3種類の設定構文が存在するという意味ではありません。

mihomoはオリジナルClashの設定と高い互換性を保ちながら、VLESS、Hysteria2、TUIC、Reality関連のパラメーター、さらに多くのDNS・TUNオプションを追加しています。互換性の基本方向は「新しいカーネルで古い設定を読む」ことです。逆方向は成り立ちません。新しいプロトコルや拡張フィールドを含むmihomo設定を、オリジナルカーネルへ渡して完全に動作させることはできません。古いカーネルは未知のプロキシ種別を報告したり、認識できないグローバルフィールドを無視したりするため、一部だけ動作し、他の挙動が想定と異なる状態になることがあります。

設定の互換性は、フィールドのデフォルト値にも左右されます。新しいカーネルでは過去の挙動が修正されたり、厳密な検証が追加されたり、境界条件が変わったりすることがあります。移行後はファイルの構文チェックに通っても、DNS、ルールの適用、UDP、LAN待受、TUNによる通信の取り込みを確認してください。構文チェックに通ることは、構造を解析できるという意味であって、実行結果が完全に同じという意味ではありません。

クライアント名だけではカーネルの機能を特定できない

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for AndroidなどはGUIクライアントやアプリの名称であり、mihomoはその中でよく使われるプロキシカーネルです。クライアントはインストール、権限、設定管理、トレイ、モバイル画面を担当し、カーネルはプロトコル接続、DNS、ルール、通信処理を担当します。両者の更新ペースは異なる可能性があるため、クライアント名だけで対応プロトコル全体を判断しないでください。

当サイトのダウンロードページでは、プラットフォームごとに利用できるクライアントを掲載し、Clash Plusを全プラットフォーム向けの第一候補としています。VLESS、Hysteria2、TUICなどの最新プロトコルが必要な場合は、mihomoまたは互換実装を明確に採用したクライアントを選んでください。Clash for WindowsとClashX Metaはメンテナンス終了として扱っており、既存環境やアーカイブ用途には使えますが、新しいプロトコルフィールドを検証する第一候補には適しません。

Androidでは、アプリのバージョン、カーネルのアーキテクチャ、インストールパッケージのアーキテクチャも区別する必要があります。ARM64端末では通常、対応するアーキテクチャのパッケージを使い、汎用パッケージはより多くの端末との互換性を確保します。インストールできても、サブスクリプション内のすべてのプロトコルが使えるとは限りません。カーネルがProfileを読み込む際、プロキシ種別とフィールドを検証するためです。「一部のノードが消えた」場合は設定読み込みログを確認し、サブスクリプション側の未配布、クライアントのフィルタリング、カーネルによる未知フィールドの拒否のどれかを切り分けます。

移行時はまず静的チェックを実行する

mihomoには設定チェックの入口があります。コマンドライン環境があれば、起動前にYAMLを解析できるか検証できます。このチェックでインデント、未知の種別、一部のフィールドエラーは検出できますが、ノードのパスワード、サーバー証明書、実際のネットワーク経路まではテストできません。

mihomo -t -f ./config.yaml

チェックに通ったら、「DNS解決—単一ノード接続—ルール適用—UDP—TUN」の順で確認します。最初からすべての上書き設定、スクリプト、複雑なルールを有効にすると、問題の層を特定しにくくなります。Profile各領域の役割を理解したい場合は、設定ファイルの構造と複数設定の管理を参照してください。

07 · PROFILE COMPATIBILITY

サブスクリプション形式、フィールド変換、設定互換性の境界

リンク型サブスクリプションとYAML Profile

Clashクライアントでよく使われるインポート元は2種類あります。1つ目は、ノード、プロキシグループ、ルール、DNS設定を直接含む完全なYAML Profileです。2つ目はURIまたは統合サブスクリプションで、サーバーがノードリンクを返し、クライアントまたは変換サービスがClash設定を生成します。前者は構造が完全で、ルールや高度なフィールドを保持するのに適しています。後者はアプリ間で配布しやすい一方、特定プロトコルの拡張が変換中に失われることがあります。

単一ノードURIで表現できる内容は、各プロトコルのリンク形式に制限されます。SS、Trojan、VMess、VLESS、Hysteria2、TUICにはそれぞれ固有のリンクフィールドがあり、クライアントのパーサーによって許容される形式も異なります。リンク内のドメイン、パス、SNI、ノード名にはURLエンコードが必要です。サーバーの出力が標準的でない場合、あるクライアントは受け入れても、別のクライアントは拒否することがあります。これはノード自体の停止ではなく、解析処理の違いです。

完全なYAMLのほうが問題を確認しやすい構造です。ノードのフィールドを1つずつ読み取れ、プロキシグループの参照関係も明確です。サブスクリプション更新時、クライアントは通常、リモートの内容でキャッシュ済みProfileを置き換えます。生成されたファイルを直接編集しても、次回更新で消える可能性があります。長期的に変更する場合は、クライアントが提供する上書き、マージ、スクリプトの入口を使い、上書きの適用順も確認してください。

変換サービスで失われやすいフィールド

サーバー、ポート、認証情報などの基本フィールドは通常保持されますが、失われやすいのはトランスポート拡張です。VMess・VLESSのWebSocket Host、パス、gRPCサービス名、フロー制御、TrojanのSNI、Hysteria2の難読化と帯域幅のヒント、TUICの輻輳制御とUDPリレーモードは、変換サービスが明示的に理解する必要があります。変換サービスが基本構造しか認識しない場合、ノードは一覧に残っていても接続確立時に失敗します。

別の問題として、フィールド名の違いがあります。サブスクリプションによっては上流プロジェクトの元の名称を使い、Clash設定では別のキー名が必要です。クライアントが自動で対応付ける場合もあれば、未知のフィールドをそのまま残す場合もあります。トラブル対応では、変換前の元ノード情報を取得し、インポート後のYAMLと照合してください。GUIでノード名を見るだけでは、フィールドが完全かどうか確認できません。

プロキシグループも変換後の使用感を変えます。ノードがすべてインポートされていても、現在選択中のグループに入っていないことがあります。ルールが最終的に別のグループを参照している場合もあります。自動テストグループがテストURLへ到達できず、使えるノードを失敗扱いにすることもあります。プロトコルを評価する前に、手動選択グループで単一ノードを直接指定し、自動切り替えの影響を除外してください。

最小構成で検証する

完全なサブスクリプションを読み込めない場合は、待受設定、ノード1つ、手動プロキシグループ1つ、最終ルールだけを残した最小構成を作成できます。これにより、ノードフィールドのエラーと、大規模なルール、DNS、Providerの問題を切り分けられます。最小構成で確認できたら、DNS、ルールプロバイダー、TUNを段階的に追加してください。毎回追加する機能は1種類だけにし、直前の動作するファイルを保存します。

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

proxies:
  - name: test-node
    type: trojan
    server: proxy.example.com
    port: 443
    password: "your-password"
    sni: edge.example.com
    udp: true

proxy-groups:
  - name: MANUAL
    type: select
    proxies:
      - test-node
      - DIRECT

rules:
  - MATCH,MANUAL

この設定構造はmihomoの基本検証に使えます。サンプルのアドレスと認証値は置き換えてください。テスト中は log-level: info で十分です。ハンドシェイクのフィールドを調べる必要がある場合だけ、一時的にログの詳細度を上げ、完了後に戻してください。大量のログを長期間書き込むのを避けられます。クライアントがポートを自動管理する場合は、クライアントが生成した基本テンプレートに従い、GUIの設定と重複して宣言しないでください。

互換性チェックリスト

複数の設定を共存させる場合は、Profileに目的が分かる名前を付け、必要なカーネルも記録します。たとえば「基本互換」「mihomo拡張」「モバイル省電力」などです。名前は設定の目的を示すために使い、日付だけで区別しないでください。Profileを切り替えた後は、現在のプロキシグループの選択も確認します。アプリによってはProfileごとに状態を保存し、別のアプリでは同名グループの前回選択を引き継ぐためです。

08 · DECISION GUIDE

利用シーンでプロトコルを選び、フォールバックを残す

日常のWeb閲覧と複数端末での移行

主な用途がWeb閲覧、ソフトウェア更新、一般的なアプリで、Windows、macOS、Android、Linux間で設定を移行する必要があるなら、フィールドが少なく対応クライアントの多いプロトコルを優先します。SSとTrojanは基本ノードに適しています。SSでは暗号化方式がすべての端末で対応しているか確認し、TrojanではSNIと証明書を確認してください。どちらも、DNS、音声、特定アプリで個別の障害が起きないよう、サーバーが実際に対応するUDP転送を有効にすることを推奨します。

クライアントは、統一された画面と設定入口を求める場合、当サイトの全プラットフォーム向け第一候補であるClash Plusが適しています。Clash Verge RevやFlClashはデスクトップの代替として利用でき、Clash Meta for AndroidやSurfboardはAndroidで異なる使い方をカバーします。クライアント選びでは、まずプラットフォームとカーネル、次にGUI機能を確認してください。Clashという名前が付いているだけで、2つのアプリの設定機能が完全に同じだと考えないようにしましょう。

高遅延・変動回線とリアルタイム通信

RTTが大きく、移動中のパケットロスが激しく変動する場合は、Hysteria2やTUICを試せます。テスト前にUDPの到達性を確認し、TCPノードも残してください。同じアプリと同じテスト内容に固定し、接続復旧、初回表示、継続転送を観察します。遅延の数字だけを比較しないでください。QUICノードがWi-Fiでは安定するのにモバイルデータで頻繁に切断される場合は、2種類のプロトコルを含むグループを残し、ネットワーク環境に応じて手動で切り替えるのが適切です。

ゲーム、音声、ビデオ会議では、ジッター、パケットロスからの復旧、UDPリレーが重要です。Webページを開けても、リアルタイム通信が正常とは限りません。TUICではUDPリレーモード、Hysteria2ではUDPと輻輳パラメーター、SS・Trojan・VLESSではクライアントとサーバーの双方でUDPが有効かを確認します。テストでは実際のアプリを観察し、Webの速度テストだけで代用しないでください。

低消費電力端末とルーター

低性能ルーターでは、プロトコルを比較する前にルールセット、ログ、同時接続数を抑えます。ハードウェアに合った暗号化方式を使う軽量なSSは、リソース消費を予測しやすい傾向があります。TrojanとVLESSのTLSではハンドシェイクと暗号化ライブラリを考慮し、Hysteria2とTUICのユーザー空間QUICではCPU・メモリ負荷の増加を見込みます。高スループットを目指すと、ルーターのCPUが先に上限へ達し、速度が伸びなくなることがあります。

Androidを長時間バックグラウンドで動かす場合は、理論上カプセル化が最も軽いノードではなく、接続が安定したノードを優先します。頻繁に切断とハンドシェイクを繰り返すノードは、より多くのウェイクアップを発生させます。速度テストは分単位または必要時のみ実行し、ログは通常レベルに保ち、システムがVPNサービスを繰り返し終了していないか確認してください。特定アプリだけでプロキシを使うなら、アプリ単位の振り分けで不要なバックグラウンド接続を減らせます。

古いサブスクリプションから新しいカーネルへの移行

既存のVMess、SS、Trojanサブスクリプションが正常に動作しているなら、mihomoへ移行するために先にプロトコルを変更する必要はありません。第1段階ではカーネルまたはクライアントだけを置き換え、Profileの内容を維持します。第2段階でDNS、ルール、UDP、TUNを確認します。第3段階でVLESS、Hysteria2、TUICなどの新しいノードを追加します。段階的に進めることで、カーネルの違いとプロトコルの違いを切り分けられます。

mihomoから古いカーネルへ戻す場合は、古いカーネルが認識できないノードとフィールドを削除または置き換える必要があります。ファイル名を元に戻すだけでは解決しません。プロキシグループが削除したノードを参照している場合、読み込みにも失敗します。フォールバック設定は独立したProfileとして保存し、基本プロトコルと汎用フィールドだけを使ってください。新しい設定に問題が起きても、複雑なメイン設定をその場で修正せず、すぐに復旧できます。

実行しやすい判断手順

1. クライアントを確認。OS、CPUアーキテクチャ、実際のカーネルを確認します。最新プロトコルが必要なら、mihomoを採用したクライアントを優先してください。
2. サブスクリプションを確認。ノード種別と拡張フィールドが完全か確認し、目的のプロトコルに対応しない変換サービスを避けます。
3. 基本ノードを構築。まずSS、Trojan、または既存の安定ノードでDNS、ルール、システムプロキシ、TUNを検証します。
4. 候補プロトコルを追加。同じ手動プロキシグループにVLESS、Hysteria2、TUICを加え、毎回1つの変数だけをテストします。
5. 用途別にテスト。Webページの初回表示、継続ダウンロード、リアルタイムUDP、ネットワーク切り替え、待機後の復旧をそれぞれ観察します。
6. フォールバック設定を保存。動作している前回のProfileを残し、サブスクリプション更新で唯一の利用可能な設定が上書きされないようにします。

プロトコル選定の最終目標は、固定のランキングを得ることではなく、理由を説明でき、切り戻し可能な接続構成を作ることです。安定ノードを日常利用の基準とし、最新プロトコルを特定のネットワーク条件向けに使い、手動プロキシグループで素早く切り替え、独立したProfileで変更を隔離します。障害が起きたら、サブスクリプション、解析、プロキシグループ、接続、DNS、システムによる通信取り込みを順番に確認し、すべてをプロトコルのせいにしないでください。

選択後はインストールパッケージページで対応プラットフォームのクライアントを確認するか、入門ガイドに沿ってインポートと初回接続を進めてください。Profileの更新後に構造が変わった場合は、Profile構造の解説を参照してください。接続は成功しているのにネットワークへアクセスできない場合は、接続済みなのにインターネットへ接続できない場合のチェックリストに戻り、項目ごとに確認します。