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

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

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

Clashの設定にある1つのプロキシノードには、通常3層の情報が含まれます。第1層はShadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICなどのプロトコル本体で、認証方法、データのカプセル化、セッション管理を定めます。第2層は通常のTCP、WebSocket、gRPC、HTTP/2、QUIC、UDPベースの独自トランスポートなど、プロトコルを運ぶ方式です。第3層が設定を実行するクライアントとカーネルです。GUIクライアントはサブスクリプション管理、プロキシグループ、システムプロキシ、画面操作を担い、mihomoなどのカーネルがノードを解析して接続を中継します。

この3層を1つの結論にまとめてはいけません。TCP上のVMessとWebSocket上のVMessでは、ハンドシェイク回数、ヘッダーのオーバーヘッド、接続再利用が異なります。VLESS自体は軽量でも、TLS、REALITY、gRPCを組み合わせれば、そのトランスポート層に応じた計算処理と往復が発生します。クライアント名だけで、あるプロトコルの拡張機能をすべてサポートしているとは判断できません。互換性を確認するときは、画面に似た名前があるかではなく、カーネルの種類、ノードのフィールド、トランスポートの組み合わせを確認してください。

制約を先に決めてからプロトコルを比較する

実用的な選定手順は、まずサーバー側で提供されているプロトコルを確認し、次に現在のクライアントのカーネルが完全に解析できるかを確かめ、その後でネットワーク特性とデバイスの制約を考慮し、最後に速度を比較することです。ユーザーが既存ノードをローカルだけで別のプロトコルに変えることは通常できません。プロトコル、ポート、認証情報、サーバー設定が対応している必要があるためです。サブスクリプションがSSノードしか提供していない場合、typeフィールドを書き換えてHysteria2に変換することはできません。この変更ではハンドシェイクに失敗するだけです。

ネットワークの制約には少なくとも、UDPが安定しているか、RTTが高いか、パケットロスが目立つか、Wi-Fiとモバイル回線を頻繁に切り替えるかの4項目があります。デバイス側では、CPU性能、バックグラウンド実行の制限、バッテリー容量、大量の同時接続を長時間維持するかどうかを確認します。常時給電されるデスクトップではスループットと接続復旧を優先しやすい一方、モバイルではウェイクアップ回数、継続的な送信、無線モジュールの稼働時間、バックグラウンド維持のコストを同時に見ます。

6つの判断軸

本稿では、プロトコルを6つの軸で比較します。ハンドシェイクコストは接続確立に必要な往復回数、転送効率は有効ペイロードの割合と多重化方式、低品質ネットワークでの復旧性はパケットロスやジッター時の劣化度合いを示します。リソース使用量には暗号化、輻輳制御、セッション維持によるCPU・メモリコストを含め、モバイルでの挙動では無線モジュールが頻繁に起こされるかを重視します。エコシステム互換性では、サブスクリプション形式、カーネル、サーバー側の対応範囲を確認します。どのプロトコルにも、ある軸での優位性と別の軸でのコストがあります。

したがって、プロトコル選びの目的は万能な最強候補を探すことではなく、明らかなミスマッチを避けることです。UDP品質が長期間不安定なら、QUICのパラメーターを調整し続けるより、実績のあるTCP構成を選ぶ方が効果的です。遅延が大きくランダムロスがある場合は、Hysteria2やTUICの方がスループットが滑らかになる可能性があります。古いデバイスでWeb閲覧とメッセージ通信だけを行うなら、構造がシンプルで実装が成熟したSSの方が省リソースになりやすいでしょう。要件を制約として整理すれば、プロトコルランキングより信頼できる結論に至ります。

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

Shadowsocks：シンプルな構造と幅広い実装

Shadowsocksは通常SSと略されます。共有鍵でプロキシデータを保護し、比較的シンプルな構造でTCPとUDPのトラフィックを中継するのが基本です。初期の実装では従来型の暗号方式も複数使われましたが、現在の設定ではaes-128-gcm、aes-256-gcm、chacha20-ietf-poly1305などのAEAD暗号が一般的です。AEADは暗号化と完全性保護を同時に提供するため、クライアントとサーバーで方式とパスワードを完全に一致させる必要があります。

SSの強みは、実装が成熟し、ノードのフィールドが少なく、対応クライアントが多いことです。一般的なWeb閲覧、ソフトウェア更新、メッセージ通信、多くのデスクトップ用途では、少ない設定で安定した性能を得やすいでしょう。AESはハードウェアアクセラレーションに対応したデスクトップCPUで効率がよく、ChaCha20は一部のモバイル端末や省電力CPUに適する場合があります。ただし、アルゴリズム名だけで結果を決めつけることはできず、実装とデバイスの命令セットも重要です。

SSの制約も、そのシンプルな構造に関係します。複雑なトランスポート制御を含む汎用プロトコルフレームワークではなく、拡張性は実装、プラグイン、サーバー側の機能に依存します。サブスクリプションにプラグインパラメーターが含まれる場合、mihomoが該当するプラグイン種別とフィールドを認識しなければなりません。サーバー、ポート、パスワードだけをコピーすると、重要なトランスポート情報が抜けることがあります。読み込みはできるのに接続できないSSノードでは、システムプロキシを何度も切り替える前に、暗号方式、プラグイン設定、UDPの有効化を確認してください。

VMess：セッション情報を持つ包括的なプロトコル

VMessはV2Rayエコシステムに由来し、UUIDなどの識別情報で認証しながら、TCP、WebSocket、HTTP/2などのトランスポートと組み合わせられます。SSより多くの処理をプロトコル層が担うため、設定フィールドも豊富です。古い設定ではalterIdなどのフィールドも見られますが、現在のサーバーでは別の推奨値が使われることがあります。古いサブスクリプションを読み込む際、カーネルがフィールドを受け付けても、サーバー側の設定と一致するとは限りません。

VMessの価値は、成熟したエコシステム、多彩なトランスポート、古いサブスクリプションへの幅広い対応にあります。その一方で、設定の連鎖は長くなります。プロトコル認証、トランスポート種別、TLS、サーバー名、パス、リクエストヘッダーが接続結果を左右します。どれか1つでもサーバーと異なると、タイムアウトやハンドシェイク切断として現れることがあります。トラブル時は元のサブスクリプションのフィールドを起点に確認し、余分に見えるパラメーターを経験だけで削除しないでください。

性能面でVMessが本質的に遅いわけではありませんが、追加のカプセル化、トランスポート層、暗号化には一定のコストがあります。同じ回線上のノードを比較するなら、通常のTCP構成はWebSocketとTLSを重ねた構成より、ハンドシェイクやフレームのオーバーヘッドが少ない傾向があります。ただし実際の利用では、回線の混雑がこの差より大きく影響することが多いでしょう。条件を揃えて初めて、プロトコル層の比較に意味が生まれます。

Trojan：TLS接続を基盤とするプロトコル

Trojanは通常TLS上に接続を構築し、パスワードで認証したうえで、TLSに保護された接続にデータを載せます。主な設定項目はサーバーアドレス、ポート、パスワード、サーバー名、証明書の検証動作です。クライアントのsniまたはservernameは、サーバー証明書と構成に対応していなければなりません。証明書検証を無効にすれば一時的にエラーを回避できる場合がありますが、安全性の境界が変わるため、通常のトラブル対処として使うべきではありません。

Trojanの強みは、標準TLSコンポーネントが成熟しており、デプロイと証明書の仕組みが明確で、多くのカーネルで安定して処理できることです。新しい接続ではTCPとTLSのハンドシェイクが必要なため、高遅延環境では最初のデータ到着まで時間がかかることがあります。接続の再利用やセッション再開で一部のコストを減らせますが、効果はクライアントとサーバーの実装に依存します。短い接続が多いWeb閲覧では最初のデータ到着時間も確認し、継続的な通信では回線品質をより重視してください。

Trojanのサブスクリプションでは、SNI、証明書のドメイン、トランスポート層、ポートの不一致がよく問題になります。あるクライアントでは使えるのに別のクライアントで失敗する場合は、両方から出力したノードの全フィールドを比較します。特にネットワーク種別、ALPN、SNI、証明書検証の設定を確認してください。パスワードだけを照合しても、設定が同等だとは判断できません。

VLESS：軽量認証と組み合わせ可能な拡張

VLESSは軽量なプロトコル層を採用し、VMessのような内蔵暗号化は行わず、通常はTLS、REALITYなどの安全なトランスポートで保護します。UUIDなどの情報で認証し、TCP、WebSocket、gRPCなどの方式と組み合わせられます。VLESSは設定を読みやすい一方、ノードのフィールドが少ないとは限りません。フロー制御、トランスポート、安全層、サーバー名、公開鍵、短い識別子、パスなどのパラメーターは、サーバー側と一致させる必要があります。

VLESSは新しいサーバー構成でよく使われ、異なるトランスポートを組み合わせてさまざまな環境に対応できます。プロトコル層のオーバーヘッドは小さいものの、最終的な性能は組み合わせ全体で決まります。通常のTCP上のVLESS、gRPC上のVLESS、WebSocket上のVLESSは異なるデータ経路であり、同じ性能として扱えません。REALITY関連のフィールドはカーネルの対応にも依存し、古いオリジナル版Clashでは完全に解析できないことがあります。mihomoの方が対応範囲は広いでしょう。

VLESSを選ぶときに重要なのは、単に「新しい」ことではありません。サブスクリプションとカーネルが必要なフィールドをすべて提供しているか、サーバー構成が安定しているか、現在のネットワークがそのトランスポートに適しているかを確認します。既存のVMessやTrojanノードが長期間安定しているなら、プロトコル名が変わったという理由だけで移行する必要はありません。移行は、設定を簡素化したい、カーネル対応の新しいトランスポートを使いたい、特定ネットワークでの接続復旧を改善したいなど、明確な目的がある場合に行うべきです。

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

QUICや独自の輻輳制御を使う理由

従来のTCPは、接続ごとに信頼性のある順序付きデータストリームを維持します。パケットロスが発生すると、再送や輻輳ウィンドウの調整によって後続データが待たされることがあり、複数の論理リクエストが同じTCP経路を共有すると互いに影響します。QUICはUDP上で信頼性のある転送、暗号化、多重ストリームを実装し、より多くの転送制御をユーザー空間で行います。Hysteria2とTUICはいずれもこの方向性を利用し、高遅延、ランダムなパケットロス、帯域幅の変動が大きい環境で接続性能を改善しますが、単純な「UDP高速化スイッチ」ではありません。

UDP方式が効果を発揮できるかは、まずエンドツーエンドのUDP品質で決まります。ローカルネットワーク、ルーター、サーバーの入口でUDPが厳しく制限されていたり、NATマッピングの保持時間が短かったり、継続的なロスが発生していたりすれば、高度なプロトコルでも基礎経路の問題は補えません。接続直後は正常なのに数十秒後にスループットが急落する、速度測定は通るのに長時間接続が頻繁に再構築される、といった症状が典型です。まず同じ回線上のTCPノードと比較し、原因がプロトコル、回線、ローカルネットワークのどこにあるかを確認してください。

Hysteria2の帯域利用の考え方

Hysteria2はQUICベースのトランスポートを使い、高遅延・パケットロス環境で帯域を有効活用することを重視します。設定には通常、サーバー、ポート、認証情報、TLSのサーバー名、証明書検証の設定が含まれます。サーバーによっては、オブファスケーション関連のパラメーターも提供されます。クライアントにサブスクリプションを読み込んだ後は、これらのフィールドを保持してください。認証文字列をSSのパスワードと取り違えたり、通常のHTTPSアドレスをHysteria2ノードに入力したりしないでください。

Hysteria2は、長距離、高帯域幅遅延積、ランダムなパケットロスがある環境で、保守的なTCP輻輳制御より積極的に帯域を利用できる場合があります。積極的な送信はスループットの維持に役立ちますが、ネットワーク状態が悪いと再送、CPU処理、無線モジュールの稼働時間が増えることもあります。継続的なダウンロード、動画転送、リモートでの大容量ファイル操作には向きますが、すべての短いWeb接続が速くなるわけではありません。短いリクエストの体感は、DNS、QUIC接続確立、証明書検証、アプリ側の接続再利用にも左右されます。

設定にある帯域幅関連のパラメーターは、実際に利用できる能力を反映させるべきで、大きく設定するほどよいわけではありません。過大に見積もると、バースト送信、キューイング、余分なパケットロスを招くことがあります。過小に見積もればスループットが制限されます。サービス提供元がサブスクリプションで値を指定している場合は、まずその値を維持してください。手動で調整するなら、安定したネットワークで複数回測定し、継続的に利用できるスループットを少し下回る値に設定して、キューイングによって遅延が大きく上昇しないか確認します。

TUICの接続移行と多重ストリーム

TUICもQUICを基盤とし、UUID、パスワード、サーバー名、輻輳制御アルゴリズム、UDPリレー方式を含む設定が一般的です。低遅延、多重化、接続状態の管理を重視した設計です。QUICは従来の4タプルだけに依存せず接続IDを使うため、実装とネットワーク条件が整えば、Wi-Fiからモバイル回線へ切り替えた後もセッションを復旧しやすい場合があります。ただし「移行に対応」していても、切り替え中に中断が発生しないとは限りません。モバイルOSのバックグラウンド制御、アドレス変更、中間機器のマッピングが結果に影響します。

TUICの輻輳制御オプションは、スループットと遅延のバランスを変えます。積極的なアルゴリズムは帯域に余裕があると送信速度を素早く高めますが、共有ネットワークではキューイングを増やすことがあります。保守的な方式は安定しやすい反面、高遅延回線では速度の立ち上がりが遅くなります。クライアントはサブスクリプションやサーバーの推奨に従い、アルゴリズム名だけを根拠に変更しないでください。クライアントとサーバーでTUICの世代やフィールド解釈が一致しない場合、認証直後の切断やUDP中継不能として現れることが多いです。

Hysteria2とTUICの選択は、通常サーバー側の対応状況で決まります。同じ回線上に両方があるなら、3つの作業で比較できます。短いWebページを連続して開いて最初のデータ到着時間と再試行を確認し、10分以上継続的に通信してスループットの変動を観察し、モバイル端末で1度回線を切り替えて復旧時間と電池消費の変化を確認します。結論は単一の速度測定値ではなく、実際の作業に基づけてください。

4. 速度、リソース使用量、モバイルの電池消費

速度を最初のデータ到着時間、スループット、安定性に分ける

「速い」には少なくとも3つの異なる指標があります。最初のデータ到着時間は、アプリが接続を開始してから最初の有効データを受け取るまでの時間で、DNS、プロトコルのハンドシェイク、TLSまたはQUICの接続確立、サーバー処理に左右されます。継続的なスループットは、大容量ファイルや動画を安定した状態で転送する能力です。安定性は、1分から数時間の間に通信断、再接続、目立つ揺らぎが起きるかを見ます。継続転送では優れていても、接続確立が複雑なため短いWebページの体感を改善しないプロトコルもあります。

比較時は、サーバーの場所、回線、デバイス、時間帯、クライアントのカーネルを揃えてください。名前が異なり回線も異なる2つのノードでは、測定結果の大部分が回線差を示します。Webページの読み込み、継続的なファイル転送、リアルタイム音声の3種類を使い、それぞれ複数回実行して、最高値ではなく中央値に近い体感を記録するのがおすすめです。Clashのプロキシグループによる遅延テストは、明らかに使えないノードを除外するには向きますが、総合的なスループットの基準にはなりません。自動プロキシグループの違いは、url-test・fallback・load-balanceの選び方で詳しく確認できます。

CPU、メモリ、同時接続

プロトコルのリソース使用量は、暗号処理、データコピー、輻輳制御、接続再利用、ログ、ルール照合から生じます。SSは構造が比較的シンプルで、常駐時のオーバーヘッドが小さい傾向があります。AESとChaCha20の実際のコストはハードウェアアクセラレーションに左右されます。VMessや多層トランスポートでは、より多くのカプセル化を処理します。Trojanは成熟したTLSライブラリを利用しますが、短い接続が大量にあるとハンドシェイクを繰り返します。VLESS自体は軽量でも、gRPC、TLS、複雑なフロー制御を重ねれば、最終的な負荷は構成全体で決まります。

Hysteria2とTUICのQUIC処理はユーザー空間で行われ、パケットロス検出、輻輳ウィンドウ、複数の論理ストリームを維持します。高速転送や低品質ネットワークで再送が多い場合、単純なTCPプロトコルよりCPU使用率が高くなることがあります。現代的なデスクトップでは通常問題ありませんが、省電力ルーター、古いスマートフォン、小型サーバーでは継続負荷に注意が必要です。メモリについては、単一プロトコルのオブジェクトより、ノード数、ルールセット、GeoIPデータ、接続パネルの履歴、DNSキャッシュの方が大きく影響することがあります。クライアントの使用量が増えたからといって、すぐプロトコルのせいにしないでください。

リソース問題を診断するときは、まず同じルールとDNS設定に固定し、1つのノードプロトコルだけを変更します。接続詳細画面の継続更新を止め、ログレベルを通常に保ちます。アイドル、通常のブラウジング、継続転送の3状態を個別に観察してください。アイドル時からリソース使用量が高いなら、GUI、ルール更新、DNSループ、システムプロキシの競合が原因である可能性が高くなります。高速転送時だけ上昇するなら、暗号処理やトランスポート処理のコストに近いと考えられます。

モバイルの電池消費はプロトコル名だけでは決まらない

モバイル端末の主な消費電力は、画面、無線ベースバンド、CPUのウェイクアップ、バックグラウンド維持から生じます。プロキシプロトコルは、パケット送信頻度、再送回数、接続維持、暗号処理を通じて間接的に電池へ影響します。小さなパケットを継続的に送ると無線モジュールが長くアクティブになり、低品質ネットワークでの大量再送はネットワークとCPUの両方のコストを増やします。短すぎるキープアライブはシステムを頻繁に起こし、長すぎるキープアライブは不要なセッションを維持することがあります。

日常的な軽いブラウジングでは、成熟したSS、Trojan、VLESSのTCP構成は消費電力を予測しやすい傾向があります。モバイル回線の品質がよく、継続転送が多い場合、Hysteria2やTUICは短時間で処理を終えて、瞬間的な負荷を一部相殺できることがあります。しかしUDPのロスが深刻なネットワークでは、再送と接続維持によって消費電力が増える可能性があります。省電力かどうかは、同じ作業を完了するまでの総時間と総消費電力で判断し、ある瞬間のCPU使用率だけを比べないでください。

AndroidとiOSでは、バックグラウンドのネットワーク活動も制限されます。クライアントがシステムによって停止されたり、VPNサービスが省電力機能で終了されたり、回線切り替え後に接続が再構築されなかったりすると、プロトコルの切断に見えることがあります。AndroidではクライアントのVPN権限とバックグラウンド実行設定を確認し、iOSではシステムが許可するクライアントとネットワーク拡張方式を使ってください。対応ソフトを選ぶ場合は、AndroidダウンロードまたはiOSダウンロードでClash Plusなどのクライアントを確認できます。

5. オリジナル版Clash、Clash Meta、mihomoのカーネルの関係

オリジナル版Clashの位置づけ

オリジナル版Clashは、設定ファイル、ルールによる振り分け、プロキシグループ、DNS、複数プラットフォーム向けのプロキシ入口といった基本モデルを築きました。現在も多くの設定が、proxies、proxy-groups、rules、mixed-port、modeなど、その時代に形成されたフィールドと構造を採用しています。Meta系とmihomoは幅広い互換性を維持しているため、これらの基本構造を理解することには今も価値があります。

ただし、オリジナル版プロジェクトが拡張を停止した後に登場した新しいプロトコルやトランスポートは、完全には対応していません。VLESSの新しい拡張、Hysteria2、TUIC、REALITY、新しいDNS機能を含む設定を、オリジナル版カーネルが解析できると決めつけないでください。古いクライアントの画面にClashという名前が残っていても、内部のカーネルは異なる場合があります。製品名ではなく、クライアントのバージョン情報、カーネル設定、実行ログを確認してください。

Clash Metaとmihomoの継承関係

Clash Metaは、オリジナル版の設定モデルを基盤に、プロトコル、DNS、ルールプロバイダー、TUN、ネットワークスタックの機能を拡張しました。mihomoは、このカーネル系統で現在使われている名称です。実際の議論では「Metaカーネル」と「mihomo」が、同じ技術ファミリーの異なる時期やパッケージ形態を指すことがあります。新しい設定ではmihomoのドキュメントと、現在のクライアントが実際に使うカーネルを優先してください。古いチュートリアルのMetaフィールドは多くの場合参考になりますが、すべての初期値をそのまま適用することは避けます。

mihomoの価値は、単に対応プロトコルを増やすことではありません。プロトコル、プロキシグループ、ルール、DNS、TUNを同じカーネルで連携させられる点にあります。SS、VMess、Trojan、VLESS、Hysteria2、TUICなど多様なノードを処理し、より高度なルールセットとDNS動作にも対応します。ただし、プロトコルを解析できることとノードに接続できることは別です。サーバーのパラメーター、証明書、トランスポートフィールド、ローカルネットワークがすべて正しくなければなりません。

GUIクライアントとカーネルは分けて考える必要があります。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuは、それぞれ異なる画面、更新方式、システム統合機能を提供します。設定構文とプロトコル能力を実際に決めるのは、内蔵または呼び出されるカーネルです。クライアントによっては一部フィールドをGUIのスイッチで設定できますが、YAMLの編集が必要な場合もあります。Clash Plusを第一候補とするのは、複数プラットフォームでのGUI操作と一般的な設定を幅広くカバーするためであり、基礎となるプロトコルをサーバーに合わせる必要がある点は変わりません。

設定互換性は「基本互換性＋拡張フィールドの認識」

基本ポート、一般的なプロキシグループ、DOMAIN-SUFFIXルール、SSノードだけを使う設定は、複数のClash系カーネル間で移行しやすい傾向があります。mihomo専用プロトコル、ルールセット形式、DNSオプション、TUN拡張を加えると、古いカーネルへの移行に失敗することがあります。失敗の形は3つあります。設定チェックで未知のフィールドが直接報告される、未知のフィールドが無視されて期待と異なる動作になる、ノードは表示されるがプロトコル実装がないため接続に失敗する、のいずれかです。2つ目が最も見つけにくいため、移行後は実際の通信経路を必ず確認してください。

設定チェックは、最も低コストで行える最初の手順です。mihomoでは、コマンドを使って構文とフィールドを現在のカーネルが受け付けるか確認できます。コマンド内のパスは、実際の設定ファイルの場所に置き換えてください。

mihomo -t -f config.yaml

チェックに通るのは、YAML構造と既知のフィールドが基本的に有効だという意味にすぎません。サブスクリプションURLにアクセスできること、ノード認証が正しいこと、DNS経路が期待どおりであることまでは保証しません。続いてクライアントを起動し、プロバイダー更新、証明書、DNS、待ち受けポートのエラーがログに出ていないか確認します。その後、直接接続ルール、プロキシルール、最終的なMATCHルールを個別に検証してください。

6. サブスクリプション形式、ノードフィールド、互換性の判断

共有リンク、YAML、サブスクリプション変換

一般的なサブスクリプションは、完全なClash YAML、ノード共有リンクの一覧、またはクライアント種別に応じてサーバーが動的生成したデータを返します。完全なYAMLにはノード、プロキシグループ、ルール、DNSをまとめて含められます。共有リンクは通常1つのノードだけを記述し、サブスクリプション変換サービスは上流データを特定クライアント向けの形式に組み直します。3つは情報量が異なり、読み込みに成功しても内容が完全とは限りません。

SSの共有リンクには通常、暗号方式、パスワード、サーバー、ポートが含まれます。古い形式のVMessリンクはJSON情報をエンコードして渡すことが多く、Trojan、VLESS、Hysteria2、TUICはURIのクエリパラメーターでSNI、トランスポート、安全層などの拡張を表します。中間ツールが新しいフィールドを認識できないと、ノード名だけ残して重要なパラメーターを失い、「一覧にはあるのにすべてタイムアウトする」設定になることがあります。

サービス提供元がClash Metaまたはmihomo向けと明記したサブスクリプション形式を優先してください。元の共有リンクしかない場合は、該当するプロトコルと拡張フィールドを認識できるインポートツールを使います。複数の変換サービスを連続して通すのは避けてください。各段階でフィールド名の変更、未知のパラメーターの削除、エスケープの変更が起きる可能性があるためです。サブスクリプションの解析に失敗した場合は、サブスクリプションURLの無効化・解析失敗を確認する手順を参照してください。

最小構成のノードでフィールドを確認する

互換性の問題を切り分けるときは、サブスクリプションから1つのノードをコピーして単独のテスト設定に入れ、サーバーが提供した全フィールドを残し、selectプロキシグループを1つ作る方法があります。以下の例はフィールドの階層を示すもので、実在するサーバー情報は含みません。インデントにはスペースを使い、プロトコルパラメーターはサーバーの実際の値に置き換えてください。

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

proxies:
  - name: SS-Test
    type: ss
    server: server.example
    port: 443
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - SS-Test

rules:
  - MATCH,PROXY

この最小設定は、カーネルがポートを待ち受け、ノードを解析し、基本接続を確立できるか確認するのに適しています。DNS、ルールセット、ローカルネットワーク設定がないため、本番設定を直接置き換えるものではありません。最小設定は使えるのに完全なサブスクリプションが使えない場合、原因は通常、プロキシグループの参照、ルールプロバイダー、DNS、重複したノード名にあります。最小設定も失敗するなら、プロトコルフィールド、認証情報、サーバーの状態、ローカルネットワークに戻って確認してください。

ファイル拡張子よりフィールドの対応関係が重要

ファイル名がYAMLだからといって、内容がmihomoの構造に合うとは限りません。有効なドキュメントには正しいインデントが必要で、リスト項目とマッピングの階層も明確でなければなりません。サブスクリプションがテキスト形式のエラーページ、ログイン案内、タイムアウト情報を返すこともあり、その場合クライアントは解析失敗を報告します。確認時はまず、返された内容の先頭がYAMLまたはノードリンクの形式かを確かめ、続いてHTTPステータス、文字コード、更新ログを確認します。

同じ概念でも、カーネルによっては別名を受け付けることがありますが、記録されていない暗黙の変換に頼るべきではありません。サーバー名がsniまたはservernameとして表現されたり、証明書検証のスキップに異なるフィールドを使ったり、WebSocketのパスとリクエストヘッダーに特定の入れ子構造を要求したりします。最も確実なのは、サブスクリプション生成ツールの出力を保持し、現在のカーネルが対応する形式と照合することです。手動移行では一度に1つのフィールドだけ変更し、変更後すぐに設定チェックを実行してください。

プロキシグループは、ノード名やプロバイダー名も参照します。ノード名を変更した後にグループ内の参照を更新しないと、カーネルがプロキシを見つけられないことがあります。プロバイダーの更新に失敗しても、キャッシュが残っていると古いノードが表示され、サブスクリプションが正常だと誤認しやすくなります。更新日時、ログ、実際の選択肢を確認し、クライアントが新しい内容を使っていることを確かめてください。ノード一覧が空になる、特定のプロトコルだけ除外される、更新後にフィールドが消えるといった現象は、通常サブスクリプション形式とカーネルの能力に関係します。

サブスクリプションの安全範囲とローカル上書き

サブスクリプションにはサーバー、認証情報、プロキシグループなどが含まれるため、信頼できる提供元だけを読み込んでください。設定を共有する前に、実際の認証情報を削除します。クライアントに上書きやマージ機能がある場合は、どのフィールドがリモートサブスクリプション由来で、どれがローカルで補われるかを明確にしてください。よくある構成は、リモート側にノードを提供させ、ローカル設定でプロキシグループ、ルール、DNSを管理する方法です。これなら更新で個人のルールが何度も上書きされませんが、マージ順を誤ると同名グループが置き換わることがあります。

大きな変更を行う前には、使える設定のバックアップを保存し、現在のカーネル種別を記録してください。サブスクリプション更新後に接続異常が起きたら、クライアント、プロトコル、DNSを同時に変えるのではなく、まず設定を戻します。複数の変数を一度に変えると原因を特定できなくなります。よくある質問やエラーの現象は、よくある質問で引き続き確認できます。

7. ネットワーク、デバイス、用途からプロトコルを選ぶ

デスクトップでの仕事と通常のブラウジング

Windows、macOS、Linuxのデスクトップ環境は通常安定して給電でき、クライアントを長時間動かせます。仕事用Webサイト、ドキュメント同期、コードホスティング、メッセージ通信では、接続の安定性、最初のデータ到着時間の一貫性、互換性が重視されます。成熟したSS、Trojan、VLESSのTCPノードがあるなら、プロトコル名が新しいという理由だけで頻繁に移行せず、安定したものを優先してください。SSは設定が簡単で、TrojanはTLSの構成が明確、VLESSは新しいサーバー構成をすでに採用している環境に向いています。

クライアントでは、GUI、システムプロキシ、TUN、サブスクリプション管理が必要なユーザーにClash Plusが適しています。Clash Verge Rev、FlClash、Clash Nyanpasuも、OSや操作の好みに応じて選べます。サーバーやスクリプト環境ではmihomoカーネルを直接使うこともできます。クライアントの違いは主に画面とシステム統合にあり、プロトコルが接続できるかはカーネルとノードフィールドで決まります。インストール先はダウンロードセンターにまとめています。

オフィスネットワークでUDPの状態が不明な場合は、まずTCPプロトコルで安定した基準を作り、その後Hysteria2やTUICを試します。モードはruleを基本とし、ドメインをルールに従って適切なプロキシグループへ送るのがおすすめです。globalモードは短時間の診断には使えますが、ルールの誤りを隠すために常用しないでください。ノード選択でurl-testを使う場合、テスト先への遅延で候補を選ぶだけで、すべての業務通信の実スループットを継続評価するわけではない点に注意します。

高遅延、ランダムロス、継続的な通信

RTTが高く、断続的なパケットロスが目立ち、動画、リモートファイル、継続的なダウンロードが中心なら、Hysteria2とTUICを優先して試す価値があります。QUICのトランスポートと輻輳制御により、保守的なTCPより送信を早く復旧できる可能性があります。ただし、テスト前にUDPを継続利用できることと、サーバーが比較可能な回線上にあることを確認してください。UDPが制限されているなら、Trojan、VLESS、SSのTCP構成の方が予測しやすいでしょう。

継続的な通信では、開始直後の数秒のピークではなく、10分以上観察します。平均スループット、最低スループット、通信断の回数、同時にWeb閲覧した際の遅延を記録してください。高スループットによって他のアプリの待ち行列が明らかに増えるなら、送信上限を上げ続けるのではなく、同時実行数を減らすか帯域幅パラメーターを調整します。家庭内で回線を共有する場合は、1台あたりの速度と全体の遅延のバランスが特に重要です。

リアルタイム音声、オンライン会議、インタラクティブなリモートデスクトップでは、最高帯域よりジッターとパケットロスからの復旧が重視されます。適切なネットワークならHysteria2やTUICで変動が改善する可能性がありますが、再送が続くと逆効果になることもあります。実際の通話や操作でテストし、fallback用に安定したTCPノードを1つ残してください。fallbackプロキシグループは利用可能性を順番に確認するため、明確な主系・待機系に向いています。遅延で候補を選ぶurl-testとは異なる仕組みです。

モバイル端末と頻繁な回線切り替え

AndroidとiOSでは、電池、バックグラウンド制限、ネットワーク移行を同じ基準で考えます。軽いブラウジング、メッセージ、メールなら、まず成熟したSS、Trojan、VLESSノードを選びます。長時間の動画や大容量ファイルでは、Hysteria2とTUICを比較してください。Wi-Fiとモバイル回線を頻繁に切り替える端末では、QUIC接続の復旧が滑らかか確認できますが、OSが回線を切り替える際に短時間の再接続が起こる可能性は残ります。

モバイルでのテストは、少なくとも通常の利用サイクルを1回分続けてください。画面の明るさ、使用アプリ、ネットワーク条件をできるだけ揃え、同じ作業を終えた後の電池残量を比べます。瞬間的なCPU使用率が高くても、転送を早く終えれば無線モジュールの稼働時間が短くなり、総消費電力が少ない場合があります。逆に、バックグラウンドで小さなパケットを送り続けたり頻繁に再試行したりすると、負荷が低く見えてもウェイクアップ時間が延びます。クライアントがOSに終了させられる場合は、すぐプロトコルを変えず、まずバックグラウンド権限を調整してください。

ルーター、省電力ホスト、家庭用ゲートウェイ

ルーターや省電力ホストは、CPU、メモリ、冷却の余裕が限られているため、プロトコル選びでは継続的なCPU使用率を確認します。SSは無難な出発点になりやすく、暗号アルゴリズムはハードウェア性能と合わせてテストします。TrojanのTLS、VMessのカプセル化、QUICプロトコルは、高スループット時に計算負荷を増やす可能性があります。回線速度を出し切れない場合は、まず単一コアの使用率、ソフト割り込み、温度を見て、プロトコルのボトルネックかシステム転送のボトルネックかを判断します。

家庭用ゲートウェイとして使う場合、接続数とDNSリクエスト数は通常、単一デバイスより多くなります。ルールセットの規模、TUNネットワークスタック、コネクショントラッキング、ログレベルもリソースに影響します。全体の負荷をプロトコル変更だけで解決しようとせず、重複ルールを減らし、デバッグログを常時有効にせず、DNSキャッシュを適切に設定してください。完全なルールと多プロトコル対応が必要なゲートウェイにはmihomoカーネルが適していますが、個人のPCではGUIクライアントの方が扱いやすいでしょう。

8. 検証、移行、トラブル切り分けの方法

再現可能な検証手順を作る

プロトコル移行は、古いノードを削除することから始めないでください。現在使えている設定を残し、新しいノードを独立したプロキシグループに追加して、同じルールでテストします。第1段階では設定チェックを実行し、YAMLとフィールドを現在のカーネルが解析できることを確認します。第2段階ではクライアントで新しいノードを選び、基本的なTCP接続をテストします。第3段階ではDNSクエリとルールの適用先を確認します。第4段階でUDP、継続通信、回線切り替えをテストします。各段階で1つの層だけを検証すれば、失敗時にすぐ戻せます。

基本接続が成功したら、短い接続、長い接続、複数同時接続を個別に検証します。短い接続では、キャッシュされていないページを複数連続して開き、最初のデータ到着時間と失敗率を確認します。長い接続ではファイル転送や動画再生を10分以上続け、変動を観察します。複数同時接続では、日常的な負荷でプロキシグループとカーネルが安定するかを確認します。モバイルでは、しばらく画面をロックしてから解除し、接続が復旧するかも確認してください。1回のテストですべての状態を網羅することはできません。

プロキシが実際に有効か確認するときは、画面上のスイッチだけを見ないでください。システムプロキシまたはVPNの状態、接続パネルの宛先ドメイン、ルールの適用先、出口の結果を確認します。初回接続の一連の操作はノード選択、遅延測定、プロキシ有効化の確認を参照してください。すべてのノードが同時にタイムアウトする場合は、ノードのタイムアウトを切り分ける手順に従い、クライアント、ノード、ローカルネットワークを区別します。

再インストールを繰り返さず、障害の層から切り分ける

設定解析エラーは通常、接続前に発生し、ログにYAMLの行番号、未知のフィールド、プロキシグループの参照が示されます。この場合はインデント、コロン後のスペース、リストの階層、カーネルの対応を確認し、ファイアウォールを変更する必要はありません。ノードは表示されるのに接続がタイムアウトするなら、サーバー、ポート、プロトコル種別、認証情報、ローカルネットワークを確認します。TLSハンドシェイクのエラーでは、システム時刻、SNI、証明書検証、ALPNを重点的に見ます。QUICノードが認証後に切断される場合は、UDP経路、輻輳制御、サーバー側の世代も確認してください。

一部のWebサイトだけに異常がある場合、最初からプロトコルを疑う必要はありません。ドメインが期待するプロキシグループへ送られているか、DNSが現在のモードに適した結果を返しているか、アプリがシステムプロキシを迂回していないかを確認します。TUNモードはより多くのアプリの通信を取り込めますが、ルーティング、権限、DNSの引き継ぎという変数も増えます。最小限のルールで一時的に接続を確認し、その後ルールとDNS設定を1つずつ戻して、globalモードでルールの誤りを隠さないようにします。

すべてのプロトコルが突然使えなくなった場合は、まずサブスクリプション更新、システム時刻、ローカル待ち受けポート、システムプロキシ、VPN権限、ファイアウォール、現在のネットワークを確認します。同じプロトコルの他ノードは使えるのに1つだけ失敗するなら、サーバー側またはノードフィールドの問題である可能性が高いでしょう。特定のプロトコルだけすべて失敗する場合は、カーネル対応、サブスクリプション変換、そのプロトコルが依存するトランスポート層を比較します。このようにグループ単位で判断する方が、ノードを無作為にクリックし続けるより早く解決できます。

古いカーネルからmihomoへ移行する

移行前に、古い設定のポート、プロキシノード、プロキシグループ、ルール、DNS、TUN、プロバイダーを一覧化します。第1段階では基本ポート、使えるノード1つ、selectグループ1つ、MATCHルールだけを移行し、カーネルが動くことを確認します。第2段階でDNSとよく使うルールを加え、第3段階でリモートプロバイダー、TUN、新しいプロトコルを追加します。段階的に移行すれば、どの機能群が差異の原因かを特定できます。

オリジナル版Clash設定の基本フィールドは通常そのまま使えますが、古いチュートリアルの初期値をmihomoの最適設定とみなしてはいけません。特にDNSの拡張モード、Fake-IPの範囲、スニッフィング、TUNネットワークスタック、ルールセット形式は、現在のクライアントとOSに合わせて調整します。非推奨の警告が出たら、ログを無効にして隠すのではなく、現在のカーネルのドキュメントに従ってフィールドを置き換えてください。

新しいプロトコルへ移行するときは、サーバーが生成したノードオブジェクト全体を保持してください。VLESSのフロー制御と安全層、Hysteria2の認証と帯域幅フィールド、TUICのUUID、パスワード、輻輳制御を、古いノードのテンプレートから推測して書き足してはいけません。設定が通った後で、url-testまたはfallbackグループにノードを加えます。自動グループのテスト先と間隔は追加のリクエストを発生させるため、モバイルでは間隔を短くしすぎないでください。

長期的に保守できる設定を作る

安定した設定では、変更頻度の異なる内容を分離します。サブスクリプションはノード更新、ローカルのプロキシグループは選択ロジック、ルールはトラフィック分類、DNSとTUNはシステムへの接続を担当させます。同じノードを複数の場所で重複管理せず、リモート更新で重要なローカル設定が上書きされないようにしてください。ノード名は分かりやすく安定したものにし、ルールやアプリからの参照が切れないよう、プロキシグループ名も頻繁に変更しないでください。

変更のたびに、どの層を変更したか、何を解決したいのか、どう検証するか、どう戻すかの4項目を記録します。明確な目的がないプロトコル移行では、現在の安定した構成を維持してください。SS、VMess、Trojan、VLESS、Hysteria2、TUICにはそれぞれ適した範囲があり、最終的な選択は、利用できるサーバー、ネットワーク特性、デバイスのリソース、用途によって決まります。プロトコルの新旧順で決めるものではありません。

判断手順を簡略化すると、通常のブラウジングでは安定したTCPプロトコルを選び、高遅延で継続的な通信ではHysteria2またはTUICを試し、新しいプロトコルと拡張機能にはmihomoを優先します。モバイルではバックグラウンド復旧と総消費電力も比較し、サブスクリプションに問題があれば形式とフィールドを先に確認します。プロトコルを変更した後は、設定、接続、DNS、ルール、アプリの5層を順番に検証してください。この手順を踏めば、プロトコル選びは一度きりの速度測定ではなく、再現可能なエンジニアリング上の判断になります。