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

1. プロトコル選びの基本

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

Clashクライアントは設定とトラフィック制御の入口であり、プロトコルはクライアントがリモートサーバーと通信する方法を定義します。両者は異なる層に属します。設定ファイルのtypeはプロキシノードの種類を指定します。たとえばss、vmess、trojan、vless、hysteria2、tuicなどです。カーネルはこのフィールドを読み取り、対応する実装で接続を確立します。GUIクライアントはサブスクリプションのインポート、プロキシグループの選択、ルール管理、システムプロキシ、TUNの切り替えを担いますが、実際にプロトコルのハンドシェイク、暗号化、多重化、データ転送を実行するのはカーネルです。

同じプロトコルでも、異なるトランスポート方式を組み合わせることがあります。VMessとVLESSではTCP、WebSocket、gRPCなどがよく使われ、TLSは独立した層です。Trojanは通常TLS上で動作します。Hysteria2とTUICはQUICとUDPを基盤とします。「VLESS + WebSocket + TLS」と表示された場合は、VLESSが認証とプロトコルの意味を担い、WebSocketがデータをカプセル化し、TLSが暗号化とサーバー認証を担う、と3つに分けて理解します。どの層でもパラメータが一致しなければ、接続失敗として現れることがあります。

クライアント名だけでカーネルの種類を判断することもできません。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどはユーザーが操作するGUIクライアントで、mihomoを組み込む場合もあれば、プラットフォームや配布形態によって異なるビルドを使う場合もあります。クライアントを選ぶ際は、カーネルの種類、更新方式、対象プラットフォームを確認してください。プロトコルを選ぶ際は、現在のカーネルがそのプロトコルと拡張フィールドを実装しているかを確認します。画面の見た目が似ているだけでは、基盤の互換範囲は判断できません。

優先して確認する4項目

1つ目は設定の入手元です。サービス提供者が利用可能なサブスクリプションを用意している場合は、記載されたプロトコルとパラメータを優先し、クライアント上でSSノードをTrojanに手動変更したり、typeだけを書き換えたりしないでください。プロトコルごとに認証情報、トランスポートパラメータ、ハンドシェイクは異なり、名前を変えてもプロトコルは変換されません。2つ目はカーネルの対応状況です。新しいHysteria2、TUIC、一部のVLESS拡張には通常mihomoまたは互換実装が必要で、旧オリジナルClashではこれらのフィールドを完全に読み取れません。

3つ目はネットワーク条件です。安定してパケットロスの少ない固定回線では、TCP系プロトコルが安定しやすい傾向があります。変動が大きく一定のパケットロスがあるモバイル回線では、最新の輻輳制御と高速な復旧機能を備えたQUIC系が適する場合があります。ただし、UDPの到達性、通信事業者の制御、ルーターの実装によってQUICの挙動は変わるため、プロトコル名だけで結果を決めつけることはできません。4つ目は端末の制約です。モバイル端末では継続的なスリープ解除、バックグラウンド維持、ハンドシェイク頻度、無線モジュールの稼働時間を重視します。サーバーやルーターでは同時接続数、メモリ上限、転送効率が重要です。

速度テストだけで結論を出せない理由

1回のダウンロードテストでは、通常1つの時間帯、1本の経路、限られた接続数しか確認できません。TCPのスロースタート、QUICの輻輳ウィンドウ、DNS解決、接続先の再利用、サーバーの現在の負荷によって結果は変わります。短時間のテストはハンドシェイクと最初の応答に左右されやすく、長時間のテストは継続スループットと輻輳からの回復を反映しやすくなります。Web閲覧ではDNS、ハンドシェイク、TTFB、小さなオブジェクトの並列性を重視し、大容量ファイル転送では安定したスループット、リアルタイム音声・動画ではジッター、パケットロスからの回復、UDP転送を重視します。異なる用途を1つのピーク値だけで評価することはできません。

より信頼できる方法は、同じ端末、同じルール、同じ接続先、近い時間帯で複数回比較し、接続成功率、初回表示時間、長時間接続の安定性、端末温度の上昇を同時に観察することです。特定の時間帯だけ明らかに異常がある場合は、すぐにプロトコルの欠陥と判断せず、経路とサーバーの状態を確認してください。最終的には、継続利用でき、設定を保守しやすく、端末への負担が許容範囲に収まるものを選びます。

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

Shadowsocks：シンプルな暗号化プロキシプロトコル

Shadowsocksは通常SSと略され、比較的シンプルな構成で暗号化転送を行うことを目的とします。クライアントはパスワードと暗号化方式からセッションに必要な情報を導出し、TCPまたはUDPでサーバーと通信します。プロトコル構造が軽いため、成熟した実装では処理負荷が低く、設定項目も理解しやすい傾向があります。一般的なノードには、サーバーアドレス、ポート、パスワード、暗号化方式が含まれます。最新の設定では、サーバーが明示し、現在のカーネルが対応するAEADまたは2022系の方式を選び、クライアントとサーバーの暗号化方式を完全に一致させる必要があります。

SSの利点は、広く実装されていること、必要なリソースが比較的少ないこと、マルチプラットフォームでの互換性が高いことです。設定項目を減らし、安定した転送と端末リソースを重視する用途に向いています。一方、SSそのものがTLSを意味するわけではなく、VLESSやVMessのようなトランスポート拡張の意味も含みません。サブスクリプションによっては追加のプラグインパラメータが指定されますが、プラグインはクライアントとサーバーの双方が対応している必要があります。サブスクリプションにプラグインが含まれていてもカーネルが認識できなければ、一覧に表示されても接続できない場合があります。

SSを調べるときは、まず暗号化方式の表記、パスワード、サーバーポート、UDP設定を確認します。TCPではアクセスできるのにUDPを使うアプリだけ異常がある場合は、ノード、プロキシグループ、クライアントカーネルのすべてでUDPが許可されているかを確認してください。サブスクリプションから生成された設定では、暗号化方式を手動で置き換えないことをおすすめします。クライアント側で変更してもサーバー側は自動的に変わらないためです。SSのシンプルさはプロトコル層が少ないことに由来し、パラメータ一致の確認を省略できるという意味ではありません。

VMess：時刻検証とユーザー識別子を備えたプロトコル

VMessはV2Rayエコシステムに由来し、ユーザー識別子とプロトコルハンドシェイクで接続を構成します。通常はTCP、WebSocket、HTTP/2、gRPCなどのトランスポート方式と組み合わせます。設定はSSより階層的で、サーバー、ポート、ユーザー識別子に加えて、セキュリティ設定、ネットワーク種別、パス、ホスト名、TLSの有無、サーバー名などを含む場合があります。VMessは複数のトランスポートを組み合わせる構成で広く使われてきたため、汎用サブスクリプションや古い設定には現在も多くのVMessノードが含まれています。

VMessはシステム時刻のずれに比較的敏感です。端末の時刻が大きくずれていると認証段階で失敗し、画面にはタイムアウトやハンドシェイクエラーだけが表示されることがあります。OSの自動時刻同期が有効で、タイムゾーンと時刻が正しいことを確認してください。もう1つの頻出問題は、WebSocketのパス、Hostヘッダー、TLSサーバー名を同じものとして扱うことです。パスはWebSocketのリクエスト先、HostはHTTP層のフィールド、サーバー名はTLS証明書の検証に使われます。3つは同じ場合もありますが、サーバーから別々に指定される場合もあります。

VMessは機能が豊富ですが、純粋なSSよりプロトコル処理と設定が複雑になる傾向があります。既存のVMessサブスクリプションが安定して動作しているなら、プロトコルが古いという理由だけで移行する必要はありません。新規設定では、サーバーの対応状況、カーネル互換性、保守方法を基準に判断します。実際の性能はトランスポート方式とネットワーク経路に大きく左右されます。たとえばVMess over WebSocketはカプセル化とハンドシェイクの層が増えますが、直接TCPを使う経路は短くなります。ただし適したサーバー構成が異なるため、プロトコル名だけで比較することはできません。

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

Trojanは認証とデータ転送をTLS接続内で行います。クライアントにはサーバーアドレス、ポート、パスワードが必要で、通常は正しいサーバー名も必要です。TLSハンドシェイクでは証明書と対象名が一致するかを検証するため、システム時刻、証明書チェーン、SNI、サーバー設定が接続結果に影響します。Trojanの設定概念は比較的わかりやすいものの、「TLSを使う」からといって証明書検証を省略してよいわけではありません。証明書検証を無効にするとサーバーの身元確認が弱くなります。管理下でのテストを除き、タイムアウトや名前不一致の恒久的な解決策として使うべきではありません。

Trojanでよくある問題は、サーバー名とアドレスの関係です。ノードアドレスにはドメイン名またはIPを指定できますが、sniには通常、証明書が対象とするドメイン名を指定します。サブスクリプションにsniが記載されている場合は、その値を保持してください。ALPNなどの高度なパラメータも、サーバーが対応する範囲と一致させる必要があります。一般ユーザーには、GUIで各項目を推測して入力するより、サブスクリプションが提供する完全なパラメータを使う方法が信頼できます。

性能面では、TrojanはTLSハンドシェイクを必要としますが、最新の実装では接続の再利用、セッション再開、長時間接続によって繰り返しコストを抑えられます。安定したネットワークでは、ハンドシェイクの負荷は通常接続確立時に集中します。短い接続を頻繁に作成したり、モバイルネットワークを何度も切り替えたり、バックグラウンド接続がOSに回収されたりすると、再接続のコストが目立ちます。そのため、Trojanは長時間接続後のスループットだけでなく、初回接続も合わせて評価してください。

VLESS：軽量な認証層と組み合わせ可能なトランスポート

VLESSもV2Rayエコシステムに由来し、プロトコル自身が担う暗号化機能を減らし、通常はTLSなどの対応するセキュリティ層に機密性とサーバー認証を委ねます。設定にはユーザー識別子、トランスポート方式、TLS設定、サーバー名、使用するカーネルが対応する拡張フィールドなどが含まれます。VLESS自体は固定されたトランスポートではなく、TCP、WebSocket、gRPCなどと組み合わせられます。そのため「VLESSは速いか」を論じるには、トランスポート方式とセキュリティ層を明示する必要があります。

VLESS設定の互換性で難しいのは拡張機能です。Reality、フロー制御の指定、クライアントフィンガープリント、トランスポートの詳細などは、カーネルによって対応範囲が異なります。オリジナルClashでは多くの最新VLESS設定を扱えませんが、mihomoは関連プロトコルと拡張により幅広く対応しています。サブスクリプションを正常にインポートできても、すべてのフィールドが実行されるとは限りません。変換サービスによっては基本フィールドを残したまま拡張パラメータを失うため、ノードは存在するのに接続できないことがあります。

SS、VMess、Trojan、VLESSはいずれも基盤のトランスポートにTCPを使えますが、認証、暗号化の責任、拡張方式は異なります。SSは軽量な暗号化転送、VMessは完全なプロトコルハンドシェイクと複数のトランスポート、TrojanはTLSを基盤とした認証、VLESSはより多くのセキュリティ責任を外層に委ねつつ組み合わせ能力を提供します。選択時はサーバー設定とカーネル対応を優先し、あるプロトコルを別のプロトコルの単純な代替とみなさないでください。

3. Hysteria2とTUIC：QUICベースの接続モデル

QUICによって変わる通信の仕組み

Hysteria2とTUICはいずれもUDPとQUICの機能を基盤とします。QUICはユーザー空間で信頼性のある転送、暗号化ハンドシェイク、多重ストリームを構成し、従来のTCP接続で異なる論理ストリームが同じ先頭ブロックに完全に依存する状態を避けられます。あるストリームでパケットロスが発生しても、他のストリームが同じ順序の欠落データを必ず待つ必要はありません。これは並列リクエストやジッターのあるネットワークで実用的な利点になります。QUICはTLSの意味論も接続確立に組み込み、プロトコル層間で重複したネゴシエーションを減らします。

この仕組みは、UDPが本質的にTCPより速いという意味ではありません。UDPが提供するのはデータグラム転送だけで、信頼性、輻輳制御、再送、ストリーム管理はQUICが担います。性能は実装、輻輳制御パラメータ、パスMTU、サーバー帯域、ネットワークのUDP対応に左右されます。ローカルネットワークがUDPを遮断または厳しく制限している場合、Hysteria2とTUICは接続できないことがあります。一方、UDP経路の品質が良く、ある程度のパケットロスがある場合は、TCPの輻輳回復を繰り返す方式より安定する可能性があります。

QUICはユーザー空間で動作するため、迅速な更新と柔軟な制御が可能になる一方、暗号化、パケットスケジューリング、再送処理がCPUを消費します。デスクトップ端末では処理しやすいことが多いですが、モバイル端末や省電力ルーターでは、継続的な高スループット時の発熱と電池消費に注意が必要です。ネットワーク効率と端末の電力効率は同じ指標ではありません。転送を早く終えて無線モジュールを早くスリープさせられる場合がある一方、CPU負荷が高ければその効果が相殺されることもあります。

Hysteria2の帯域幅と輻輳制御の考え方

Hysteria2は、高遅延、パケットロス、帯域変動のある経路を想定しています。設定には通常、サーバーアドレス、認証情報、TLSサーバー名、任意のアップロード・ダウンロード帯域ヒントが含まれます。帯域値はクライアントによる速度測定結果でも強制保証値でもなく、輻輳制御が適切な送信動作を組み立てるための情報です。実際の回線能力を大幅に上回る値を入力すると、キューの蓄積やパケットロスを招く可能性があります。低すぎる値は利用可能なスループットを自ら制限します。根拠がない場合は、サーバーまたはサブスクリプションが提供する設定を優先してください。

Hysteria2の認証フィールドは文字列として指定される場合があります。TLS関連フィールドでは、サーバー名と証明書設定の一致も必要です。設定によっては難読化やポートホッピングなどの拡張が含まれますが、サーバー、クライアントカーネル、設定形式の3者が対応していなければ利用できません。汎用サブスクリプション変換ツールが拡張フィールドを認識しない場合、基本ノードだけが出力され、インポート後に接続できなくなることがあります。その場合はGUIでプロキシモードを繰り返し切り替えるのではなく、元のYAMLを確認してください。

パスMTUはQUIC系接続で見落とされやすい要素です。経路の一部が大きなUDPデータグラムを処理できず、フラグメンテーションやパス検出も正常に動作しない場合、ハンドシェイクは成功するのに大容量通信が停止したり、一部のサイトは開くのにダウンロードだけ中断したりします。調査ではまず追加のトランスポート層を無効にし、サブスクリプションの元のパラメータに戻してから、別のネットワークで比較してください。特定のLANやルーターだけで異常が起きる場合は、ルーターのUDPセッション、MTU、ファイアウォールポリシーを確認します。

TUICの多重化とモバイルネットワーク切り替え

TUICもQUICを基盤とし、低遅延接続、多重ストリーム、高効率な転送を重視します。一般的な設定には、サーバーアドレス、ポート、ユーザー識別子、パスワード、TLSサーバー名、輻輳制御アルゴリズム、UDPリレー方式が含まれます。TUICの世代によってフィールドが異なる場合があるため、クライアントとサーバーには互換性のある実装が必要です。サブスクリプションに「TUIC」としか書かれておらず、必要な認証フィールドが残っていない場合、カーネルが推測で補完することはできません。

QUICには接続移行に関する機能がありますが、クライアント、OS、具体的なプロトコル実装がその機能を利用するかどうかは、バージョンとプラットフォームを含めて判断する必要があります。スマートフォンが無線LANからモバイル回線に切り替わると、ローカルアドレスが変わります。理想的には接続を素早く復旧できますが、OSのバックグラウンド制限、VPNインターフェースの再構築、DNS更新、クライアントのライフサイクルによって完全な再接続が発生することもあります。QUICの接続移行を、すべてのモバイルアプリがセッションを維持できることと同一視しないでください。

TUICの輻輳制御オプションを他人の設定からそのまま写すべきではありません。アルゴリズムはネットワーク経路とサーバーの能力に合わせる必要があり、実装によってはデフォルト値が用意され、サブスクリプションが明示的に指定する場合もあります。一般ユーザーはまずサブスクリプションの値を保持し、長期的な安定性を観察してから調整する方が、速度テストのピークだけを追うより信頼できます。高負荷時に遅延が急増する場合は、上り回線の飽和、ルーターのUDPキューの蓄積、帯域管理とQUICトラフィックの競合を確認してください。

QUIC系プロトコルを優先しなくてよいケース

固定回線が安定し、TCPノードが継続的に信頼でき、端末の処理能力が限られている場合、または環境によってUDPの挙動が予測できない場合は、新しいプロトコルだからという理由だけで切り替える必要はありません。ルーターの省電力CPUはNAT、DNS、ルール照合、暗号化転送を同時に処理するため、QUICのユーザー空間処理が先にCPU上限へ達することがあります。モバイル端末で主に軽いWeb閲覧を行う場合も、QUICのスループット上の利点がバックグラウンド接続と暗号化処理のコストを上回るとは限りません。

反対に、ネットワークのジッターが大きく、長距離経路で時折パケットロスが発生し、アプリが多くの並列ストリームを使い、UDP経路が安定している場合は、Hysteria2またはTUICを候補に加えられます。安定して動くTCP系ノードを比較対象として残し、同じルールと近い時間帯で数日観察するのが正しい方法です。短時間の速度テスト1回で長期的なデフォルトノードを決めないでください。

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

速度を4つの段階に分けて考える

ユーザーが感じる「速度」には、少なくとも名前解決、接続確立、最初の1バイトの到着、継続転送という4つの段階があります。DNSは接続先アドレスの取得方法を決め、クライアントとプロキシサーバーがプロトコルとセキュリティのハンドシェイクを行い、サーバーが接続先と通信し、最後に安定したデータ転送へ移ります。Webページの表示は遅いのにダウンロードは正常なら、DNS、ハンドシェイク、小さなオブジェクトの並列性に問題がある可能性があります。ダウンロード開始直後は速いのに後から変動する場合は、輻輳制御、パケットロス、サーバーの速度制限、無線品質が関係している可能性があります。

SSのプロトコル処理は比較的直接的で、CPUの弱い端末でも負荷を予測しやすい傾向があります。TrojanはTLS処理を必要としますが、成熟したTLSライブラリは通常よく最適化されています。VMessや組み合わせ型VLESSの負荷はトランスポート層に大きく左右され、WebSocket、gRPC、追加のTLSによってカプセル化とメモリバッファが増えます。Hysteria2とTUICはユーザー空間でQUICの状態、ストリーム、再送を管理するためCPU使用率が高くなることがありますが、特定のパケットロス経路ではタスクをより早く完了できる可能性もあります。

接続の再利用は短時間接続のコストを変えます。複数のリクエストが確立済みの接続を共有すれば、ハンドシェイクとシステムコールを減らせます。一方、再利用しすぎると多数の論理ストリームが1本の接続に集中し、その接続に異常が起きた際の影響範囲が広がります。カーネルによって再利用の実装とデフォルト値は異なるため、別のツールのパラメータをそのままmihomoに適用しないでください。サーバー対応を確認し、問題を再現でき、明確な測定方法がある場合に限って再利用オプションを調整します。

CPU、メモリ、同時接続

プロトコルのリソース使用量は、アイドル時のタスクマネージャーの数値だけで判断できません。実際の負荷はスループット、接続数、ルール数、DNSモード、ログレベル、TUN転送の組み合わせで決まります。高スループットでは暗号化とデータコピーが増え、大量の短時間接続ではハンドシェイクと接続テーブルの維持が増えます。複雑なルールセットは照合処理を増やし、詳細ログの継続出力はI/O負荷をもたらします。プロトコルを比較する場合は他の設定を同じにしなければ、クライアント設定全体の違いを測ることになります。

デスクトップOSは通常、メモリとスケジューリングに余裕がありますが、Clash Plus、Clash Verge Rev、FlClash、Clash NyanpasuのGUIプロセスには、それぞれグラフィックランタイムの負荷もあります。カーネルを評価するときは、GUIプロセスとカーネルプロセスを分けて考えてください。Linuxサーバーでmihomoカーネルを直接実行する場合は構成が単純です。ルーターでは、システムサービス、コネクショントラッキングテーブル、DNSキャッシュに必要なメモリを確保する必要があります。メモリが上限に近づくと、どのプロトコルでもOSによる回収やプロセス終了で不安定になる可能性があります。

同時接続数と1接続あたりのスループットは別の指標です。Webブラウジング、ソフトウェア更新、同期ツールは多くの接続を作ることがあり、総通信量が少なくてもファイルディスクリプター、接続状態、DNSクエリが増えます。QUICの多重ストリームは複数の論理ストリームを少数の基盤接続にまとめられますが、カーネルは各ストリームの状態を維持する必要があります。SSやTrojanなどもカーネルレベルの再利用で接続数を減らせますが、サーバーとクライアントの設定を一致させる必要があります。

モバイルの電池消費を左右する要素

モバイル端末の電池消費は、無線モジュールの稼働時間、CPUのスリープ解除、バックグラウンド維持、データ転送量、VPNインターフェース処理、ネットワーク切り替えに大きく左右されます。プロトコルの暗号化アルゴリズムはその一部にすぎません。低速な転送が続くと無線モジュールが長時間高消費電力状態になる場合がありますが、高スループットでタスクを早く終えれば、かえって早くスリープできることもあります。同時に、複雑なハンドシェイク、頻繁な再接続、高負荷のユーザー空間暗号化はCPUの稼働を増やします。そのため、「速い」ことを単純に「省電力」と読み替えることはできません。

AndroidでClash Plus、Clash Meta for Android、FlClash、Surfboardを使う場合、OSは通常VPNサービスを通じてトラフィックを処理します。省電力設定はバックグラウンドプロセスを制限し、画面ロック後に接続が回収されることがあります。画面を点灯するとクライアントがプロキシ接続を再確立する場合があります。iOSクライアントはNetwork Extensionのライフサイクルに管理され、バックグラウンド動作はデスクトップOSと異なります。モバイルでプロトコルを比較する際は、同じシステム設定、同じ電波条件、近い利用強度で観察し、クライアントとプロトコルを同時に変更しないでください。

TCP系の長時間接続は、安定したネットワークで成熟したOSレベルの最適化を利用できます。QUIC系接続はネットワークの揺らぎや切り替え時に復旧待ちを短縮できる場合がありますが、ユーザー空間でのデータ処理がCPU活動を増やすこともあります。軽いブラウジング、メッセージ同期、長時間の待機では、バックグラウンドの安定性とスリープ解除回数を重視してください。動画、大容量ファイル、クラウド同期では、タスク完了時間と発熱を重視します。端末が継続的に熱くなる場合は、異常な再試行、DNSループ、高頻度ログ、TUNルートの競合を先に確認し、すぐにプロトコルだけを変更しないでください。

再現可能な比較方法

まず、サーバー所在地と回線条件が近く、プロトコルまたはトランスポート方式だけが異なる2つのノードを選びます。クライアント、カーネル、ルールモード、DNS設定、ネットワーク環境を固定し、結果に影響するバックグラウンドダウンロードを停止します。1回目は新規接続で、初回表示と接続失敗を記録します。2回目は継続転送で、スループットの安定性を観察します。3回目は複数アプリを同時に動かします。モバイル端末では、画面ロックからの復旧と無線ネットワークの切り替えも追加します。各回を異なる時間帯に繰り返し、単発のサーバー負荷による誤判定を避けてください。

結果はピーク値の順位ではなく、「タスクを満たせたか」で記録します。たとえば、Webページを安定して最初に開けること、動画が途切れないこと、画面ロック後に正常復旧すること、端末の発熱が許容範囲であることは、ある1回のスループットが少し高いことより重要です。2つのプロトコルがどちらも要件を満たすなら、設定が簡単で、クライアントの対応が完全で、サーバーの保守方針が明確な方を選びます。安定性と説明可能性も重要な性能指標です。

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

オリジナルClashの位置づけと限界

オリジナルClashは、設定ファイル、プロキシグループ、ルール照合、DNS、制御インターフェースなどの基本的な利用方法を確立しました。多くのYAMLフィールドとクライアントの操作モデルは、このエコシステムによって広まりました。SS、VMess、Trojanなどの主要タイプを扱い、ルールによってリクエストをプロキシ、直接接続、拒否へ振り分けられます。多くのチュートリアルにあるproxies、proxy-groups、rulesの構造は、現在も利用できます。

オリジナルプロジェクトが継続的な進化を停止した後、プロトコル対応とプラットフォーム対応は従来の範囲にとどまっています。新しいVLESS拡張、Hysteria2、TUIC、ルールプロバイダーの拡張、TUN、DNSの新機能が、オリジナルカーネルで利用できるとは考えないでください。古いクライアントは最新のサブスクリプションをインポートできても、未知のフィールドを無視したり、ノードをスキップしたり、起動時に設定エラーを報告したりすることがあります。旧版クライアントは既存環境の維持には使えますが、現代的なプロトコル選びの基準には適しません。

Clash for Windowsは保守が終了したGUIクライアントで、歴史的にはオリジナルClashのエコシステムと密接な関係がありました。古い設定解説には今も登場しますが、新しいサブスクリプションやプロトコルへの対応範囲は限られています。現在も保守されているクライアントを入手する場合は、まずクライアント一覧からClash Plusを選ぶか、プラットフォームに応じてClash Verge Rev、FlClash、Clash Nyanpasuなどを検討してください。

Clash.Metaで拡張された機能

Clash.Metaは、Clashの設定構造との互換性を保ちながら、プロトコル、ルール、DNS、TUN、プラットフォームのネットワーク機能を拡張しました。ユーザーは従来のプロキシグループとルール構文を使い続けながら、より多くのノード種別と最新のトランスポートを利用できます。「Metaカーネル」と表示されるクライアントの多くは、これによってVLESS、Hysteria、TUICなどの拡張に対応しています。設定は引き続き主にYAMLで記述しますが、追加フィールドを認識できるのはMeta系の実装です。

「Clash設定に対応する」ことは、すべての方向で完全に相互変換できるという意味ではありません。オリジナルClashの設定はMeta系で読み取れることが多い一方、Meta拡張を含む設定がオリジナルカーネルで動く保証はありません。未知のノード種別、追加DNSフィールド、TUNパラメータ、ルールプロバイダーの挙動、プロキシグループの拡張などが問題になります。移行時の互換性は「基本構造が引き継がれる」ものと理解し、「すべてのフィールドをカーネル間で交換できる」と考えないでください。

サブスクリプション変換ツールには、ClashとClash.Metaの2種類の出力先を用意しているものがあります。サブスクリプションにVLESS、Hysteria2、TUICが含まれる場合は、Metaまたはmihomo向けの形式を選んでください。古いClashテンプレートを選ぶと、これらのノードが削除または簡略化される可能性があります。SS、VMess、Trojanだけを含む場合、基本ノードはどちらの出力先でも読めることがありますが、DNSとルール部分は別途確認が必要です。

mihomoは現在引き継がれているカーネル名

mihomoはClash.Metaの後継として使われているカーネル名で、設定体系と拡張機能を引き継いでいます。実際のクライアント画面には「Meta」と表示されることがあり、設定ドキュメントでも両者が並べて説明されることがあります。判断するときは、画面のブランド名だけでなく、クライアントのカーネル情報やプロジェクト説明を確認してください。新規インストールや最新プロトコルには、通常mihomoがより適した互換性の基準となります。

mihomoはプロトコル接続、DNS、ルール照合、プロキシグループ、TUN、制御インターフェースを担当します。GUIクライアントはその外側で、設定管理、システムトレイ、サブスクリプション更新、プラットフォーム権限の処理を提供します。クライアント更新とカーネル更新は異なるペースで行われることがあります。画面のバージョンが変わってもカーネル機能が変わるとは限らず、カーネル更新がクライアントに静かに組み込まれる場合もあります。新しいプロトコルを認識できない場合は、クライアントの配布状況と実際のカーネル情報を両方確認してください。

サーバーやルーターのユーザーは、デスクトップGUIを使わずにmihomoカーネルを直接導入することもできます。この方法は設定ファイルとシステムサービスで管理しやすい一方、権限、ログ、起動順序、DNSポート、ファイアウォールを自分で処理する必要があります。一般的なデスクトップやモバイルのユーザーには、システムプロキシ、TUN権限、サブスクリプション管理が画面にまとめられたフルクライアントが適しています。

設定移行を安全に進める順序

旧クライアントからmihomoクライアントへ移行するときは、まず元の設定のコピーを残してから、サブスクリプションまたはYAMLをインポートしてください。すぐに旧ファイルを上書きしないでください。起動後は設定解析ログを確認し、プロキシノード数、プロキシグループ名、ルールプロバイダーが読み込まれていることを確認します。次に基本的なTCPノードをテストし、その後Hysteria2やTUICなどの拡張ノードをテストします。最後にシステムプロキシまたはTUNを有効にし、設定が通る前にシステムルートの変数まで同時に持ち込まないようにします。

設定の解析に失敗した場合は、ログに示されたフィールドまたは行番号から確認します。YAMLはインデントに敏感で、Tab、重複キー、引用符、コロンの位置がエラーの原因になります。設定を読み込めても一部のノードが消える場合は、ノード種別とフィールドが現在のカーネルの対応範囲に含まれるかを確認します。すべてのノードが正常でもルールの挙動が変わった場合は、ルール順序、ルールセット形式、DNSモードを確認します。移行を解析、ノード、プロキシグループ、ルール、システム接続の5段階に分けると、問題範囲を大きく絞れます。

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

proxies:
  - name: "Example-SS"
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "ノード選択"
    type: select
    proxies:
      - "Example-SS"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - MATCH,ノード選択

上の断片は基本構造を示すためのもので、例のアドレスはドキュメント用です。実際のノードパラメータはサーバーまたはサブスクリプションから提供されます。設定をmihomoが読み取れることは、例のノードが接続できることを意味しません。実際に導入する際は、プラットフォームに応じてDNS、TUN、制御インターフェースなどを追加設定する必要があります。

6. サブスクリプション形式、YAMLフィールド、変換互換性

サブスクリプションURLが返す内容は1種類ではない

クライアントに貼り付ける「サブスクリプションURL」は設定を取得する入口にすぎません。返される内容は、完全なClash YAML、Base64でエンコードされた汎用ノード一覧、単一の共有リンク集合、またはクライアント識別子に応じてサーバーが動的生成した形式などさまざまです。インポートできるかどうかは、クライアントのサブスクリプション解析器が返却内容を認識できるかで決まります。ブラウザーでURLを開けても、それがClash設定とは限りません。読みにくい文字列が表示されても、データが壊れているとは限りません。

完全なClash YAMLには通常、proxies、proxy-groups、rulesが含まれ、DNS、ルールプロバイダー、ポート設定が含まれる場合もあります。汎用サブスクリプションはノードだけを含み、プロキシグループとルールは含まないことがあります。その場合、インポート後にクライアント側で既定のグループを作成します。共有リンクはss://、vmess://、trojan://、vless://などのスキームで始まります。Hysteria2とTUICにもそれぞれの表現方法がありますが、単一リンクと一括サブスクリプションの対応範囲はクライアントによって異なります。

詳しい説明はサブスクリプションURLの形式とインポート方法を参照してください。このページでは互換性の判断に重点を置きます。サブスクリプションサービスがmihomoまたはClash.MetaのYAMLを直接出力できる場合は、その形式を優先してください。プロキシグループ、ルール、最新プロトコルのフィールドを保持できるためです。汎用ノード一覧しか取得できない場合は、クライアントまたは変換ツールでグループとルールを補う必要があります。

YAMLでノードの利用可否を決めるフィールド

すべてのノードには名前、タイプ、サーバー、ポートが必要ですが、プロトコルごとに固有の認証フィールドも必要です。SSはパスワードと暗号化方式、VMessは通常ユーザー識別子に加えてalterId、セキュリティ設定、トランスポートネットワークを指定する場合があります。TrojanはパスワードとTLSサーバー名、VLESSはユーザー識別子、セキュリティ層、トランスポート拡張、Hysteria2は認証、SNI、任意の帯域パラメータ、TUICはユーザー識別子、パスワード、SNI、輻輳制御、UDPリレー設定を含むことが一般的です。

フィールド名は対象カーネルの構文に従う必要があります。あるアプリが出力したJSON設定を、そのままClash YAMLへコピーすることはできません。階層と命名規則が異なるためです。同じVLESSに対応していても、トランスポート、セキュリティ層、フィンガープリントを異なるフィールドで表すことがあります。信頼できる方法は、対象カーネルが認識するサブスクリプションテンプレートを使うか、mihomoのドキュメントに従って項目ごとに変換し、起動ログで設定解析の結果を確認することです。

YAML文字列にコロン、シャープ記号、波括弧、特殊な接頭辞が含まれる場合は、引用符を使うと解析の曖昧さを減らせます。インデントにはスペースを使い、階層を統一してください。プロキシグループがノード名を参照する場合、空白や大文字・小文字を含めて完全に一致させる必要があります。サブスクリプション更新後にノード名が変わると、手書きのプロキシグループが古い名前を参照し、グループが空になったり別の項目へフォールバックしたりします。ルールの転送先も既存のプロキシグループ名と一致させてください。

サブスクリプション変換で失われるもの

変換では通常、入力元のフィールドを出力先のフィールドへ対応付けます。基本的なSS、VMess、Trojanノードは比較的変換しやすいものの、最新VLESSの拡張、Hysteria2の帯域オプション、TUICのリレー方式、クライアントフィンガープリント、特定のトランスポートパラメータは、テンプレートの機能不足で失われることがあります。変換後のYAMLが構文チェックを通っても、プロトコルの意味が完全に保たれているとは限りません。

変換が完全かどうかは、元のノードと出力YAMLを比較して確認します。ノード種別が保持されているか、サーバーとポートが一致しているか、認証フィールドが存在するか、TLSが有効か、SNI、パス、Host、ALPN、フィンガープリント、プロトコル拡張が残っているかを確認してください。Hysteria2とTUICでは、UDP、輻輳制御、認証フィールドも確認します。変換後に特定のノード種別が一括して消えた場合は、出力先に古いClash形式を選んだか、変換ツールがそのプロトコルに対応していない可能性があります。

変換を何度も連結しないでください。変換を1回追加するごとに、ノード名の変更、プロキシグループの再構築、未知のフィールドの削除が起こる可能性があります。最も望ましいのは、サブスクリプション元がmihomo設定を直接出力することです。次善策は元の汎用サブスクリプションを1回だけ変換する方法で、旧Clashへ変換してからMetaへ再変換する方法はおすすめしません。カスタムルールを維持する必要がある場合は、クライアントが対応するオーバーライド、マージ設定、ルールプロバイダー機能でノードサブスクリプションとローカルルールを組み合わせ、更新のたびにファイル全体を手動編集する作業を減らします。

サブスクリプション更新とローカル変更の関係

多くのクライアントはサブスクリプション更新時にリモートの内容を再ダウンロードします。サブスクリプションから生成された設定を直接編集すると、次回更新で上書きされる可能性があります。長期的に保持したいルール、DNS、プロキシグループの変更には、クライアントが提供するオーバーライド、マージ設定、スクリプト機能を使ってください。そうした機能がない場合はローカル設定としてコピーし、自分で更新を管理しますが、ノードの変更も手動で同期する必要があります。

サブスクリプションの更新に失敗した場合は、まずダウンロード失敗と解析失敗を分けて考えます。ダウンロード失敗は、URLの有効性、システム時刻、DNS、現在のネットワークが原因であることが多く、解析失敗ではYAMLの行番号、未知のタイプ、フィールドエラーがログに表示されます。古い設定が接続できるのに更新だけ失敗する場合は、すぐに古いファイルを削除しないでください。利用可能な設定を1つ残しておけば、調査中にノードフィールドとプロキシグループ構造を比較できます。

クライアント間でサブスクリプションを移行するときは、キャッシュファイルのパスだけをコピーしないでください。クライアントごとに設定ディレクトリ、オーバーライドルール、カーネルパラメータの構成が異なります。元のサブスクリプションURLを再インポートし、必要なローカルルールだけを移行する方が安定します。ローカルYAMLを使う場合は、パスの権限、ファイルエンコーディング、改行コードが正常であることを確認してください。WindowsのパスにあるバックスラッシュがYAML文字列に含まれる場合は、引用符と正しいエスケープで誤解釈を防ぎます。

7. クライアント、OS、プロトコル対応の選び方

GUIクライアントはまずカーネルとプラットフォーム連携を見る

プロトコル対応はカーネルが決めますが、日常的な使いやすさはクライアントがカーネルをどう管理するかにも左右されます。WindowsとmacOSのクライアントでは、システムプロキシ、サービスモード、TUN権限、自動起動、トレイ状態を処理する必要があります。AndroidとiOSはシステムVPNインターフェースに依存し、Linuxデスクトップではデスクトップ環境、システムプロキシ変数、権限も関係します。コマンドラインのカーネルでプロトコルが使えても、GUIクライアントが完全なインポート、編集、エラー表示を提供しているとは限りません。

Clash Plusは全プラットフォームでの第一候補で、Windows、macOS、Android、iOSの間で似た操作感を保ちたいユーザーに適しています。WindowsとmacOSではClash Verge Rev、FlClashも検討できます。WindowsではClash Nyanpasu、AndroidではClash Meta for Android、FlClash、Surfboard、LinuxデスクトップではClash Verge Rev、FlClashがよく使われ、mihomoを直接導入することもできます。Clash for WindowsとClashX Metaは保守が終了しているため、過去の設定を扱う場合を除き、最新プロトコルの第一選択にはしないでください。

クライアントを選ぶときは、次の3点を確認します。内蔵カーネルがサブスクリプションのノード種別に対応しているか、システム接続方式が要件を満たすか、サブスクリプションと設定を明確に管理できるかです。テーマ、ウィンドウ配置、トレイの見た目は好みの問題であり、プロトコル互換性の判断材料にはなりません。対応クライアントの一覧とシステム要件はクライアント比較とクライアントを入手で確認できます。

WindowsとmacOS

Windowsのシステムプロキシは、設定に従うアプリに主に影響します。一部のUWPアプリ、ゲーム、独自のネットワークスタックを持つソフトウェアでは、TUNや追加のシステム設定が必要な場合があります。プロトコル接続は成功しているのに特定のアプリだけプロキシを通らない場合は、ノードのプロトコルを変更する前に、トラフィックがカーネルへ入っているかを確認してください。TUNモードは仮想ネットワークインターフェースを通じてより広い範囲のトラフィックを処理するため、適切な権限とルーティングが必要です。Windowsのインストール、システムプロキシ、よくあるエラーについてはWindowsインストール・設定完全ガイドを参照してください。

macOSでも、システムプロキシと仮想ネットワークによる接続は区別されます。Apple Silicon版とIntel版ではインストーラーのアーキテクチャが異なりますが、設定ファイルのプロトコルの意味は同じです。クライアントが起動してもカーネルプロセスがすぐ終了する場合は、アーキテクチャ、実行権限、設定解析ログを確認してください。Trojan、VLESS、Hysteria2などTLSを使うプロトコルはシステム時刻とサーバー名にも依存するため、時刻異常が複数のノードに同時に影響することがあります。

デスクトップ版は、より詳しいログ調査に向いています。まずログレベルをinfoに設定し、接続問題を1回再現して、DNS、プロトコルハンドシェイク、TLS、タイムアウト、ルール選択のどこで失敗したかを記録します。ログレベルを長期間高く保つと、ディスク書き込みが増え、重要な情報を見つけにくくなります。原因を特定したら通常のレベルに戻してください。

AndroidとiOS

Androidクライアントは通常、ローカルVPNサービスを作成し、アプリのトラフィックをカーネルへ送ります。省電力設定、バックグラウンド実行権限、常駐通知が継続接続に影響します。画面ロック後しばらくして接続が切れ、クライアントを開くと復旧する場合は、OSがバックグラウンド動作を制限していないか確認してください。特定のアプリだけプロキシを通らない場合は、アプリ別プロキシ、バイパス設定、ルールのマッチ状況を確認します。プロトコル自体は通常、最初に調べる項目ではありません。

iOSのクライアントはシステムのネットワーク拡張を使い、利用できるメモリとバックグラウンドのライフサイクルはOSが管理します。Clash PlusはApp StoreでiOS版を提供し、clashplus.ioで製品情報を案内しています。モバイル端末では、サイズの大きいルールセットをインポートし、詳細ログを長時間有効にする運用は避けてください。メモリと処理負荷が増えるためです。複雑なルールが必要な場合は、整理済みのルールセットを優先し、重複項目を減らしてください。

モバイルネットワークの切り替えによって、ローカルアドレス、DNS、利用可能なトランスポートが変わります。TCPノードは接続の再構築が必要になることがあり、QUIC系プロトコルはより早く復旧できる可能性がありますが、システムVPNインターフェースとクライアントのライフサイクルにも左右されます。モバイルでプロトコルを比較する際は、少なくとも無線LAN、モバイル回線、画面ロックからの復旧、ネットワーク切り替えの4状態をテストしてください。デスクトップで速度が出ても、モバイル設定が同じように安定するとは限りません。

Linux、サーバー、ルーター

LinuxデスクトップではGUIクライアントもmihomoの直接実行も利用できます。GUIクライアントはサブスクリプションとデスクトッププロキシの管理に適し、カーネルの直接実行はサーバー、コンテナ、ルーターに向いています。コマンドラインで導入する場合は、設定ディレクトリ、作業ディレクトリ、ログ出力、サービスユーザーを明確にしてください。設定ファイルはまずフォアグラウンドで起動して確認し、その後systemdなどのサービス管理に移します。そうしないと、起動失敗時に再起動を繰り返す状態だけが見えることがあります。

ルーターへの導入では、転送チェーン、DNSの引き受け、LANアクセス、コネクショントラッキングも関係します。Hysteria2とTUICにはUDP経路の要件があり、省電力端末ではCPUにも注意が必要です。ルーターのカーネルは正常に動作しているのにLAN端末からアクセスできない場合は、認証情報を変更する前に、リッスンアドレス、LAN接続の許可、システムファイアウォール、クライアントのゲートウェイを確認してください。導入方法はルーター・バイパスルーター導入概要を参考にできます。

サーバー環境では、まず復旧しやすさを確保してください。検証済み設定を1つ残し、カーネル更新前に現在の起動パラメータを記録し、プロトコルノードを変更したら設定チェックまたはフォアグラウンド起動を先に行います。新しい設定に失敗してもすぐ戻せるようにします。複数端末で共有するルーター環境では、安定したSS、Trojan、既存のTCPノードの方が、プロトコルを頻繁に調整するより保守しやすいことが多いです。パケットロスのある経路やUDPアプリを改善する明確な理由がある場合にのみ、QUIC系を検討してください。

8. 利用シーン別のプロトコル選択とトラブルシューティング

日常のWeb閲覧とオフィスアプリ

日常のWeb閲覧、ドキュメント共同編集、メッセージアプリでは、単一接続のピーク速度より接続成功率、最初の1バイトまでの時間、長期安定性が重視されます。既存のSS、Trojan、VMessノードが安定しているなら、より新しいプロトコルが登場したという理由だけで移行する必要はありません。新しい設定を作る場合は、サブスクリプションが標準で提供し、クライアントが完全に対応し、パラメータ階層が少ないノードを優先してください。ルールモードでは、対象リクエストが想定したプロキシグループにマッチしていることも確認します。

ブラウザーは正常なのに他のアプリが異常な場合は、まずシステムプロキシの適用範囲を確認します。システムプロキシはその設定に従うプログラムだけに影響し、より広いトラフィックを処理するのはTUNです。ブラウザーの初回表示だけ遅く、その後は正常なら、DNSとハンドシェイクを分けて確認してください。すべてのプロトコルで名前解決に失敗するなら、DNS設定またはシステムネットワークの問題である可能性が高いです。特定のプロトコルだけ失敗する場合は、そのプロトコルの認証、TLS、UDP条件を確認します。

ルール設定では、具体的な条件からフォールバックへ進む順序を守ります。ドメインサフィックス、ルールセット、地域ルールにマッチすると、その後の照合は停止し、最終的にMATCHが未マッチのトラフィックを処理します。ノードの接続テストは正常なのにアプリが誤った経路を通る場合は、サブスクリプションを何度も更新するのではなく、接続一覧のルールとプロキシグループを確認してください。ルール分岐の詳しい設定方法はClashルール分岐設定の実践を参照してください。

動画、大容量ファイル、高スループットのタスク

継続転送では、まずサーバーが利用できる帯域、回線の安定性、輻輳からの回復を比較します。安定してパケットロスの少ないネットワークでは、SS、Trojan、VLESS、VMessのいずれでも良好なスループットを得られる可能性があり、プロトコル差より回線差の方が大きいことがよくあります。明らかなパケットロスがあり、UDP経路が良好な場合はHysteria2またはTUICを試せますが、開始直後の速度ではなく、長時間のスループット、バッファリング、端末の発熱を観察してください。

高スループット時に異常がある場合は、まずローカルの無線信号と上り回線が他のタスクで埋まっていないかを確認し、直接接続とプロキシ経路を比較します。すべてのノードが同じ速度付近で頭打ちになるなら、ローカルネットワーク、サーバー帯域、端末CPUの制限が考えられます。QUIC系接続だけが不安定ならUDP、MTU、帯域パラメータを確認し、WebSocketまたはgRPCノードだけが異常なら、パス、Host、TLS名、サーバー側のトランスポート設定を確認します。

ルーターを全体の入口として使う場合、端末のCPUがボトルネックになりやすいです。デスクトップクライアント1台で達成できるスループットが、省電力ルーターでも達成できるとは限りません。テストではカーネルプロセスのCPU使用率が1コアの上限に近づいていないかを確認し、高頻度のデバッグログを停止します。CPUが飽和している場合、輻輳制御を調整しても問題は解決しにくいため、リソース負荷の低いプロトコルへ変更するか、より高性能な端末へカーネルを移してください。

モバイル端末と頻繁なネットワーク切り替え

モバイルでは、ピークスループットよりバックグラウンドからの復旧を優先します。無線LANとモバイル回線を頻繁に切り替える場合は、Trojan、VLESS、QUIC系ノードの復旧時間を比較できますが、クライアント、ルール、DNSは同じにしてください。切り替え後にすべてのノードが一時的に失敗するなら、VPNインターフェースの再構築またはDNS更新前の状態が考えられます。Hysteria2とTUICだけが失敗する場合は、新しいネットワークでUDPが到達可能かを確認します。

待機中の電池消費が異常な場合は、継続的な再接続が起きていないかを確認します。誤ったサーバーアドレス、期限切れのサブスクリプション、TLS名の不一致、到達不能なUDPノードによって、クライアントが接続を繰り返すことがあります。デフォルトのプロキシグループを一時的に確認済みの安定ノードへ切り替え、バックグラウンドの電池消費が戻るか観察してください。不要なヘルスチェックの頻度を下げ、ルール規模を小さくし、デバッグログを停止することでも継続的なスリープ解除を減らせます。

モバイル端末では、機能が重複するノードを大量に残す必要はありません。プロキシグループ内のノードが多すぎると、ヘルスチェックとサブスクリプション処理の負荷が増えます。実用的な構成は、安定したTCPノードを少数、検証済みのQUIC系ノードを1つ、明確なフォールバック先を残すことです。自動選択グループでは適切なチェック間隔を使い、複数のプロキシグループが同じノード群を高頻度で重複テストしないようにします。

エラーの現象から問題の層を推測する

設定を読み込めない場合は、まずYAML構文、未知のフィールド、対応していないノード種別を確認します。設定の読み込みは成功したのにノードが表示されない場合は、サブスクリプション変換とカーネル互換性を確認します。ノードは表示されるのに認証にすぐ失敗する場合は、パスワード、ユーザー識別子、暗号化方式、プロトコル世代を確認します。TLSハンドシェイクに失敗する場合は、システム時刻、SNI、証明書名、ALPNを確認します。QUICノードがタイムアウトする場合は、UDP経路、ポート、MTU、サーバーのリッスンを確認します。ノードテストは正常なのにアプリが使えない場合は、ルール、システムプロキシ、TUN、DNSを確認します。

接続問題では、一度に1種類の変数だけを変更してください。まず元のサブスクリプションを保持し、1つのノードを選び、ルールを最小限にしたテスト設定でプロトコル接続を確認します。次にプロキシグループを戻し、その後ルールとDNSを戻し、最後にTUNを有効にします。プロトコル、DNS、ルール、システム接続を同時に変更すると、結果を説明できなくなります。よくあるエラーの詳しい対処法はよくある質問で確認できます。

最終的な選択の目安

既存のSSノードが安定し、端末リソースに余裕がなく、設定要件もシンプルなら、SSを使い続けるのが合理的です。VMess設定が長期的に安定しているなら、歴史が長いという理由だけですぐに変更する必要はありません。新しく組み合わせ型の設定を作る場合は、トランスポートとTLSのパラメータを確認してください。標準TLS接続と明確な認証構造を重視するなら、サーバーが提供するTrojanを選べます。最新の拡張が必要で、クライアントがmihomoを使っている場合は、完全なパラメータを備えたVLESSを利用できます。

ネットワークにパケットロスやジッターがあり、UDP経路が正常で、端末のリソースにも余裕がある場合は、Hysteria2またはTUICを試せます。どちらもサーバー設定から切り離して単独で選ぶべきではなく、認証フィールドを手動で相互流用してもいけません。モバイルではバックグラウンドからの復旧と電池消費を主要指標とし、ルーターではCPU、メモリ、保守の複雑さを主要指標とします。デスクトップでは互換性を確認した上で、トランスポートの使用感をより詳しく比較できます。

最終的にどのプロトコルを選ぶ場合でも、検証済みの予備ノードと、元に戻せる設定を1つ残してください。サブスクリプション更新後はまずノード種別とプロキシグループを確認し、次にルールを確認します。クライアント更新後は実際のカーネルを確認し、障害が起きたら設定解析、プロトコルハンドシェイク、ルール選択、システム接続の順に切り分けます。プロトコル選びの目的は名称を追いかけることではなく、検証可能で保守しやすく、現在の端末とネットワークに適した接続環境を構築することです。