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

プロトコル、通信方式、カーネル、ルールを分けて考える

クライアント内の1つのノードには複数の設定層がある

Clashクライアントでノード名を見ると、末尾のSS、Trojan、VLESSを技術情報のすべてだと考えがちです。実際には、利用可能な接続には少なくともプロトコル識別、暗号化または認証方式、基盤となる通信方式、任意のTLS、ドメイン名とポート、そしてクライアントカーネルによる各項目の解析実装が含まれます。どちらもVLESSと表示されるノードでも、一方はTCP、もう一方はWebSocketを使い、TLS関連機能も異なる場合があります。そのため、ハンドシェイク回数、データのカプセル化、リソース使用状況も変わります。逆に、プロトコル名が異なる2つのノードでも、安定したTCPと近いサーバー経路を使っていれば、日常のWeb閲覧では名前から想像するほど差が出ないことがあります。

したがって、選定時に「どのプロトコルが最速か」だけを問うべきではありません。より正確な問いは、現在のクライアントカーネルが設定を完全に認識できるか、現在のネットワークが信頼性重視の通信に向くかUDPベースの高速復旧に向くか、端末が長時間バックグラウンドで動作するか、サーバーが該当プロトコルを正しく実装しているかです。これらの変数を分けて考えることで、サブスクリプション解析の失敗、DNS異常、ルール選択ミスをプロトコルそのものの問題と誤認せずに済みます。

4つの層に沿って判断する

第1層はカーネルの機能確認です。原版Clashと現行のmihomoでは対応プロトコルが完全には一致せず、Hysteria2、TUIC、一部のVLESS拡張には通常、新しいMeta系カーネルが必要です。クライアント画面に項目が表示されていても、実際に動作しているカーネルが処理できるとは限りません。第2層は設定形式の確認です。サブスクリプション変換ツールによってUDP、TLS、SNI、ALPN、通信経路の項目が失われることがあり、プロトコル名は正しく見えても重要なパラメータが変わっている場合があります。第3層はネットワーク条件です。パケットロスの少ない固定回線では接続確立とサーバー応答を重視し、変動の大きいモバイル回線では復旧能力とセッション移行を重視します。第4層が端末コストで、常駐メモリ、CPUウェイクアップ、バックグラウンド維持、バッテリー消費を確認します。

この順序で考えると、よくある現象の多くを説明できます。たとえば、対応クライアントでは正常に接続できるHysteria2ノードが、旧版Clashに読み込むと未知の種類としてエラーになる場合、これはカーネルの機能不足です。Trojanノードを手動追加すれば使えるのに、特定の汎用サブスクリプションから読み込むと使えない場合は、まず項目が完全に保持されているかを比較します。同じノードがWi-Fiでは安定し、モバイル回線への切り替えで切断される場合に、通信方式とセッション復旧を詳しく調べます。

速度テストで分かるのは一部だけ

1回の速度テストには、回線容量、サーバー負荷、テスト先、ローカルネットワークが同時に影響するため、特定プロトコルの設計が優れていることだけを示すものではありません。比較する際は、少なくとも同じ端末、同じネットワーク、近い時間帯、同じサーバー地域、同じテスト先をそろえ、初回接続、連続リクエスト、大容量転送、ネットワーク切り替え後の復旧を個別に観察します。初回接続が速ければハンドシェイク経路が短い可能性があり、継続的なスループットが安定していれば輻輳制御と回線の相性が良いと考えられます。ネットワーク切り替え後の復旧が速ければ、セッションと通信方式がモバイル環境に適していることを示します。これらを無理に1つの総合点へまとめる必要はありません。

多くのユーザーにとって、保守が活発でmihomoまたはMeta互換機能を内蔵したグラフィカルクライアントが妥当な出発点です。本サイトのダウンロードページでは各プラットフォーム向けにClash Plusを第一候補として紹介し、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Androidなども掲載しています。クライアントを決めたら、サブスクリプションが提供するプロトコルと実際のネットワーク条件に基づいて判断し、特定のプロトコル名を追いかけて頻繁に設定を移行しないようにしましょう。

6種類のプロトコルの背景と設計上のトレードオフ

Shadowsocks：シンプルな構造と成熟した実装

Shadowsocksは通常SSと略され、比較的シンプルな暗号化プロキシ構造でTCPとUDPの通信を運ぶことを重視して設計されています。基本設定は、サーバーアドレス、ポート、暗号化方式、パスワードと分かりやすい構成です。構造が明確で実装の歴史も長いため、多くのクライアントやサブスクリプション形式がSSを認識でき、プラットフォームをまたぐ移行でも項目の違いは比較的少なく済みます。現在の設定では、利用中のカーネルが対応するAEAD暗号化方式を使用してください。サブスクリプションにカーネルが受け付けない古い方式が含まれていると、クライアントは自動置換せず、読み込み段階で拒否することがあります。

SSの利点は、カプセル化のオーバーヘッドを把握しやすく、クライアント実装が広く成熟しており、低複雑度の環境ではリソースコストを抑えやすいことです。一方、拡張性は具体的な実装やプラグインの組み合わせに左右されます。追加の通信プラグインを使うと、実際の接続構造は基礎的なSSだけではなくなります。トラブルシューティングでは、プラグイン名、プラグインパラメータ、通信経路を必ず記録してください。アドレス、ポート、パスワードだけをコピーしても、元の接続は再現できません。

VMess：認証と通信方式を組み合わせる設計

VMessは、ユーザー認証、時刻検証、複数の通信方式を1つのプロトコル体系で組み合わせる必要から生まれました。一般的な設定には、UUID、alterIdまたは互換項目、ネットワーク方式、TLS、サーバー名、パスなどが含まれます。Clash設定や汎用サブスクリプションで広く使われてきたため、多くのClash系カーネルは比較的成熟した解析機能を備えています。VMessは柔軟な反面、設定変数も多くなります。TCP、WebSocket、HTTP系の通信方式ではハンドシェイクとカプセル化が異なるため、性能を比較する際は通信方式の組み合わせを明記してください。

VMessで端末時刻が重要だとされてきたのは、認証と時刻に関係する仕組みに由来します。現代のシステムは通常、自動的に時刻を同期しますが、端末時刻が大きくずれている場合は、システム時刻とタイムゾーンを確認してください。接続失敗の主因とは限りませんが、「パラメータは完全に一致し、ネットワークにも到達できるのに認証だけ失敗する」場合に確認する価値があります。設定を移行するときは、旧項目が新しいカーネルで無視または変換されていないかにも注意し、互換性警告をネットワークエラーと取り違えないようにします。

Trojan：TLS接続を中心に構成する設定

Trojanの一般的な構成はTLS接続とパスワード認証を中心とし、設定には通常、サーバー名、証明書検証の状態、必要に応じてALPNなどが含まれます。ユーザーにとっては、複雑な通信方式の組み合わせより項目を確認しやすい構成です。アドレスとポートが接続先を決め、パスワードが認証を担い、SNIまたはservernameがTLSハンドシェイクに使われます。アドレスをIPに変更しただけで正しいサーバー名を保持しないと、TLS検証に失敗することがあります。証明書検証を無効にすればテストが続けられる場合もありますが、本人確認の範囲が変わるため、長期的な解決策にはすべきではありません。

TrojanはTCPが安定したネットワークではバランスの取れた挙動になりやすく、ログから接続段階を切り分けやすいプロトコルです。よくある失敗原因は、ドメイン名の解決エラー、システム時刻の異常、サーバー名の不一致、証明書チェーンの問題、パスワードの誤りです。これらは実際のプロトコルデータが転送される前に発生するため、まずTLSと認証のエラーを確認し、すぐにプロキシモードやルーティング規則を変更しないでください。

VLESS：軽量なコアと組み合わせ層に委ねる機能

VLESSはプロトコルの中核を軽量に保ち、通常はUUIDで識別し、異なる通信方式やセキュリティ層を組み合わせて機能を拡張します。名前だけではTLSを使っているか、TCP、WebSocket、gRPC系の通信方式か、その他の拡張を採用しているかは分かりません。そのためVLESSは、「ラベルではなく完全な設定を見る」必要が特に高いタイプです。現代のMetaおよびmihomoカーネルは、通常、原版Clashより完全なVLESS機能に対応していますが、項目は実装の進化に伴って変わるため、旧クライアントでは基本構造しか認識できない場合があります。

VLESSは、現代的なカーネル拡張を必要とし、サーバーとクライアントの機能が明確に一致している設定に適しています。主なリスクは基礎プロトコルが難しいことではなく、サブスクリプション変換で拡張項目が削られやすいことです。ノードはVLESSのまま表示されても、flow、servername、client-fingerprint、通信方式のパラメータが欠落している可能性があります。この場合、ノード名やアドレスを比べても意味がありません。元の共有情報とクライアントが最終的に生成した設定を直接照合してください。

Hysteria2とTUIC：QUICベースの現代的な通信方式

Hysteria2とTUICはいずれもQUICとUDPの通信能力を大きく活用しますが、同じプロトコルではなく、設定を相互に流用することもできません。共通する目的は、ジッター、パケットロス、帯域変動があるネットワークで、従来の単一経路TCPでは再送やヘッドオブラインブロッキングによって待ち時間が増幅される問題に対応することです。QUICはユーザー空間で、より柔軟な輻輳制御、ストリーム管理、接続復旧を実装できます。Hysteria2の設定は通常、認証、TLS、帯域幅、輻輳関連の項目を中心に構成され、TUICではUUID、パスワード、輻輳制御、UDPリレー関連の項目がよく使われます。

これら2種類のプロトコルの利点は、UDP経路の品質に依存します。ローカルネットワーク、ルーター、サーバー入口のUDP対応が不安定だと、「復旧が速い」どころか「接続に失敗する、または周期的に揺れる」状態になることがあります。また、比較的新しいカーネル実装が必要であり、Clashという名前のクライアントなら何でも対応しているとは限りません。選ぶ前に、クライアントが実際にmihomoまたは該当するMeta機能を使っていることを確認し、小容量アクセス、継続転送、ネットワーク切り替えの3種類のテストで判断してください。1回のピーク速度だけを見るべきではありません。

接続速度、スループット、リソース使用量

初回接続速度はハンドシェイクの連鎖で決まる

ユーザーが感じる「Webページが速く開くか」は、DNS、TCPまたはQUICの接続確立、TLSハンドシェイク、プロトコル認証、最初のリクエストへの応答によって、まず決まることが多いです。SSの基礎接続はプロトコル層が比較的シンプルですが、ノードの前段にプラグインや追加の通信方式があると、ハンドシェイクの連鎖が増えます。Trojanでは通常、TCPとTLSを完了してからプロトコル認証を行います。VMessとVLESSの実際のハンドシェイクは、選択した通信方式とセキュリティ層によって変わります。Hysteria2やTUICをQUICで使う場合、暗号化と通信のハンドシェイクを統合できますが、初回アクセスはDNSとUDP経路の確立にも左右されます。

そのため、「UDPプロトコルなら必ず接続が速い」「カプセル化が少なければ必ず速い」と単純には言えません。サーバーとの距離が近く、パケットロスが少ないネットワークでは、ハンドシェイクの差が全体の読み込み時間に占める割合は小さいでしょう。RTTが大きい場合は、直列化されたハンドシェイクが1回増える影響が目立ちます。既存セッションを再利用できる場合は、初回ハンドシェイクの差も小さくなります。テストでは、クライアント起動直後の最初のリクエストと、クライアントを起動したまま連続して行うリクエストを分けて記録し、セッション再利用の効果をプロトコル固有の優位性と誤認しないようにしてください。

スループットは輻輳制御と回線容量に左右される

継続的なダウンロードや動画転送では、輻輳制御、サーバーの出口帯域、ローカルアクセス回線、中継経路の品質がより重要です。TCP系の接続はOSまたはランタイムの輻輳制御に依存し、安定した経路では予測しやすいスループットが得られます。しかしパケットロスが発生すると、再送や輻輳ウィンドウの縮小によって、1本のTCP接続が大きく変動することがあります。QUIC系プロトコルはユーザー空間で輻輳制御と多重ストリームを管理し、揺らぎのあるネットワークに異なる戦略を適用できますが、設定が不適切だと送信過多、キューの増加、リソース消費の増大を招くこともあります。

Hysteria2設定の帯域関連情報は、大きく入力すればよいわけではありません。通信事業者が示す理論上の最大値や、1回の速度テストの最高値ではなく、継続的に利用できる回線能力を反映させるべきです。過大に見積もるとキューの滞留やパケットロスが発生し、過小に見積もると利用可能なスループットを制限します。TUICの輻輳制御も、クライアントとサーバーの対応を前提に選ぶ必要があります。サーバー側から明確な説明がない一般ユーザーは、いわゆる汎用の最適値を自己流で設定するより、サブスクリプション提供者のパラメータをそのまま使う方が安全です。

CPUとメモリをプロトコル名だけで順位付けしない

プロトコル自体は暗号化、カプセル化、再送、状態管理に影響しますが、クライアント全体のリソースにはルールデータベース、DNSキャッシュ、接続追跡、TUN仮想NIC、トラフィック統計、UIプロセスも含まれます。グラフィカルクライアントのメモリ使用量がカーネルプロセスを大きく上回ることもありますが、それはプロトコル処理が同じ量のリソースを使っているという意味ではありません。プロトコルのコストを比べるときは、同じクライアント、同じルール設定、近い通信量でカーネルプロセスを観察し、軽量なコマンドラインカーネルと完全なデスクトップクライアントを直接比較しないでください。

ハードウェアとランタイムで最適化されたAEAD方式をSSで使うと、通常はCPUコストが安定します。TrojanのTLS実装も成熟した暗号ライブラリを利用できます。VMessとVLESSのコストは通信方式によって変わり、WebSocket、TLS、追加のカプセル化が処理量を増やす可能性があります。Hysteria2とTUICは、高スループット、パケットロスからの復旧、大量の同時ストリームで、ユーザー空間の通信状態をより多く管理する必要があります。その結果、不安定なネットワークでのスループットが向上する一方、CPUウェイクアップが増えることもあります。低消費電力の端末やルーターでは、「接続できる」だけでなく、継続負荷テストを行ってください。

同時接続とヘルスチェックがリソース差を拡大する

Clash設定には、自動選択、フォールバック、ロードバランシングのプロキシグループが含まれることがあります。プロキシグループが多数のノードに対して高頻度でヘルスチェックを行うと、チェックのたびにDNS、ハンドシェイク、小容量の通信が発生します。ノード数が多く、間隔が短いほど、バックグラウンドのウェイクアップも増えます。このとき電池消費、通信量、接続数が増えていても、主因はプロキシグループの設定であり、特定プロトコルが本質的に異常な量を消費しているとは限りません。ノードを選ぶ際は、ヘルスチェックの対象を実際の候補に絞り、安定した小容量レスポンスのテストURLと適切な間隔を使ってください。

同様に、TUNモードではより広いシステム通信を引き受けるため、ブラウザー、システムサービス、バックグラウンドアプリもカーネル経由で接続する可能性があります。システムプロキシモードの対象範囲は通常より狭いです。2つのプロトコルを比較するときにTUNの状態も同時に切り替えると、結果の原因を特定できません。プロキシモード、DNS設定、ルールセット、プロキシグループを固定し、同じサーバー条件でプロトコルノードだけを交換して、完全な利用サイクルを観察してください。

モバイル端末の電池、バックグラウンド、ネットワーク切り替え

バッテリー消費はウェイクアップ回数と通信時間で決まる

モバイル端末のプロキシによる電池消費は、特定のプロトコル名だけで決まるものではありません。無線チップを低消費電力状態から復帰させる処理、CPUによる暗号化とカプセル化、VPNサービスの維持、アプリのバックグラウンド同期、DNS問い合わせ、ヘルスチェックはいずれも電力を消費します。短時間で転送が終われば、無線モジュールが早く低消費電力状態に戻れる場合があります。一方、高頻度の小容量リクエスト、継続的なハートビート、繰り返される再接続は、端末を長時間アクティブな状態にします。電池消費を判断するときは、数時間または通常の1日分の利用サイクルを観察し、数分間の温度変化だけで結論を出さないでください。

安定したネットワークでは、SSと基礎的なTrojanは低複雑度の接続を維持しやすい傾向があります。VMessとVLESSの電池消費は通信方式の組み合わせに左右され、特定の接続を維持し続けたり、TLSを頻繁に再確立したりするとウェイクアップが増えます。Hysteria2とTUICは揺らぎのある経路でも通信を速く復旧できますが、ユーザー空間QUIC、UDPキープアライブ、輻輳処理にも計算資源が必要です。モバイル回線が安定しているなら、QUIC方式が明確に省電力とは限りません。ネットワーク切り替えが多く、従来の接続がタイムアウトを繰り返す場合は、復旧が速いことで無駄な待機と再接続時間を短縮できる可能性があります。

AndroidのVPNサービスと省電力設定

Androidクライアントは通常、システムVPNインターフェースを通じて通信を引き受けます。バッテリー最適化、バックグラウンド制限、メーカー独自のプロセス管理、待機設定によって、システムがアプリを停止することがあります。その結果、画面ロック後しばらくすると接続が切れる、通知が消える、復帰後に再接続するなどの現象が起きます。まずクライアントの継続実行が許可されているか、VPNが有効なままか、必要なバックグラウンド動作が許可されているかを確認してください。これはプロトコル認証の失敗とは異なります。ロック解除後にクライアントが再起動し、すぐ復旧するなら、まずシステムのバックグラウンド設定に対処します。

Clash Plus、Clash Meta for Android、FlClash、Surfboardでは、UIとカーネル機能が異なります。同じサブスクリプションを読み込んでも、DNS、アプリ別プロキシ、バックグラウンドの初期設定が変わる場合があります。クライアント間で電池消費を比較するときは、プロキシモード、ルール、ヘルスチェック、対象アプリを統一してください。本当に必要なアプリだけをVPN経由にすれば不要な通信を減らせますが、アプリ別設定を誤ると一部アプリが迂回したり接続できなくなったりするため、変更後は項目ごとに確認が必要です。

iOSのシステムネットワーク拡張の制約

iOSクライアントはシステムが提供するネットワーク拡張機能を通じて動作し、バックグラウンドのライフサイクルはシステムが一元管理します。Clash PlusはApp Storeから入手でき、関連する入口と公式サイトclashplus.ioはダウンロードページのiOS欄に掲載しています。Wi-Fiとモバイル回線を切り替えると、基盤アドレス、デフォルトルート、NAT状態が変化し、既存のTCPセッションは通常再確立が必要です。接続移行や復旧に対応するQUIC実装なら中断時間を短縮できる可能性がありますが、最終的な効果はクライアント、サーバー、ネットワークのUDP対応に左右されます。

ネットワーク切り替え後にすべてのプロトコルが使えなくなった場合は、すぐノードの無効化を疑わず、まずシステムVPNの状態とDNSを確認してください。Hysteria2またはTUICだけが失敗し、TCP系プロトコルは接続できるなら、新しいネットワークのUDP到達性を重点的に調べます。逆に、QUIC系プロトコルは正常に復旧し、特定のTCP接続だけが長時間待機するなら、ノード切り替えや接続再起動で古いセッションを消去できます。クライアントを再インストールする必要はありません。

モバイルネットワークのNATとUDPキープアライブ

モバイルネットワークではアドレス変換が使われることが多く、UDPマッピングのアイドル保持時間はTCPより短い場合があります。利用可能なセッションを維持するため、クライアントやプロトコル実装がキープアライブ通信を送ることがあります。少なすぎるとアイドル後の最初のリクエストで経路の再確立が必要になり、多すぎると無線のウェイクアップと電池消費が増えます。間隔を自己判断で極端に短くするべきではありません。サブスクリプションやサーバーから明確な指定がない場合は、まずクライアントの初期値を使い、「画面ロック後にアイドル状態にして、最初のアクセスが成功するか」で調整の必要性を判断します。

ネットワーク切り替えテストは3段階で行います。まずWi-Fiで接続し、複数の宛先へアクセスします。次にWi-Fiを切り、モバイル回線への切り替えが完了するまで待ち、現在のノードが自動復旧するか観察します。最後に端末をしばらくロックしてから、再度アクセスします。切り替え中、ロック解除後、最初のDNS問い合わせのどの段階で失敗したかを記録してください。このように段階を分けて記録すると、「モバイルでは不安定」という説明より診断に役立ち、プロトコル復旧、システムのバックグラウンド制御、名前解決の問題を区別できます。

原版Clash、Meta、mihomoの関係

カーネルは設定を解析し、通信を転送する実体コンポーネント

Clashクライアントは通常、グラフィカルUI、設定管理、プロキシカーネルで構成されます。UIはサブスクリプションの追加、ノード選択、ログ表示、システムプロキシの制御を担当し、カーネルはYAMLの解析、接続確立、ルール実行、DNS処理、通信転送を担います。クライアント名とカーネル名は必ずしも一致しないため、プロトコル対応を判断するときにアプリアイコンだけを見てはいけません。クライアントの情報、設定、ログで実際のカーネルを確認し、カーネルを切り替えられるかも確認してください。

原版Clashは、ルールマッチング、プロキシグループ、設定構造、制御インターフェースなどの基礎モデルを確立し、多くの設定項目がエコシステムの標準的な記法になりました。SS、VMess、Trojanなどの代表的な種類には対応しますが、後から登場したプロトコルや拡張機能の対応範囲は限られます。古い設定が使い続けられるからといって、現代的なノードをすべて扱えるとは限りません。サブスクリプションにHysteria2、TUIC、新しいVLESS拡張が含まれると、原版カーネルが未知の種類を報告したり、項目を無視したり、対象プロキシを起動できなかったりする場合があります。

Clash.Metaはプロトコルとネットワーク機能を拡張

Clash.Metaは既存の設定とルール体系を基盤に、プロトコル、DNS、TUN、ルールプロバイダー、通信機能を拡張しました。目的の一つは、Clashの設定習慣をできるだけ維持しながら、新しいプロトコルを同じプロキシグループとルールエンジンで扱えるようにすることです。そのため、1つの設定にSS、Trojan、VLESS、Hysteria2、TUICを混在させ、自動選択または手動プロキシグループで利用できます。ただし完全互換ではありません。Meta専用項目を原版Clashに渡すと失敗することがありますが、原版の設定をMeta系カーネルで読み込む方が一般に容易です。

「Metaがあるプロトコルに対応している」からといって、どの時代のMetaビルドでもすべての項目に対応しているわけではありません。プロトコル実装、項目名、初期動作は進化し、クライアントに同梱されるカーネルの更新ペースも異なります。本サイトでは固定のバージョン番号だけで対応状況を判断しません。実際にはクライアントのカーネル情報と設定読み込みログを確認してください。サービス提供者が特定機能を明示的に要求している場合は、保守が続き、カーネルを更新できるクライアントを選びます。

mihomoは現在のMeta系カーネル名

mihomoはMeta系の機能を引き継ぎ、発展させたものです。多くの現代的なグラフィカルクライアントはmihomoを中核コンポーネントとして採用しているため、Hysteria2、TUIC、現代的なVLESS拡張、より完全なDNSとTUN設定を認識できます。資料でClash.Metaとmihomoを見かけても、完全に別々の設定エコシステムだと考える必要はありません。同じ拡張路線が異なる段階で使っている名称と実装と捉える方が適切です。具体的な互換性は、現在のカーネルによる実際の解析結果を基準にしてください。

Clash Plusは本サイトが各プラットフォームで第一候補として推奨するクライアントです。Clash Verge Rev、FlClash、Clash Nyanpasuなども、OSとUIの好みに応じて選べます。Linuxサーバー、ルーター、自分で設定を管理したいユーザーはmihomoカーネルを直接使えます。一般的なデスクトップ・モバイルユーザーには、システムプロキシ、TUN権限、サブスクリプション更新、ログ確認を画面上で行えるグラフィカルクライアントが適しています。対応プラットフォームの入口はダウンロードページのmihomoカーネル欄にまとめています。

設定の互換性は構文互換と動作互換に分けて考える

構文互換とは、カーネルが項目を読み込み、起動できることです。動作互換とは、ルール、DNS、プロキシグループ、プロトコル接続が期待どおりに動くことを意味します。古い設定がmihomoで正常に読み込めても、それだけでDNS結果、ルールプロバイダーの更新、TUNルーティングが元のクライアントと完全に一致するとは限りません。移行後は、設定の読み込み、ノード接続、ルール適用、DNS問い合わせ、システムアプリの通信を確認し、画面に「接続済み」と表示されるかだけで判断しないでください。

逆方向の移行はよりリスクが高くなります。mihomo設定に新しいプロキシ種別、ルール構文、DNS項目が含まれていると、原版Clashが認識できない可能性があります。エラー項目を単純に削除する方法も信頼できません。削除した項目がTLSの本人確認、UDPリレー、ルーティング動作を担っている場合があるためです。元の設定を保管し、対象カーネル向けに互換性を明示したコピーを作り、未対応のノードと機能を項目ごとに置き換える方が適切です。

サブスクリプション形式と設定の互換性

ネイティブYAMLと共有サブスクリプションは異なる問題を解決する

ClashネイティブYAMLは、プロキシノード、プロキシグループ、ルール、DNS、TUN、ルールプロバイダーを同時に記述でき、情報の完全性が高いため、互換カーネルに直接読み込ませるのに適しています。汎用共有サブスクリプションは通常、リンク一覧またはエンコードされたテキストで単一ノードを表し、プロトコル接続パラメータを運ぶことに重点があります。Clashのプロキシグループやルールまでは含まれない場合があります。サブスクリプション変換ツールはノードをClash設定へ変換しますが、各プロトコルと拡張項目を理解していなければなりません。変換ツールの機能が古いと、最終YAMLは解析できても正しい接続を確立できないことがあります。

サブスクリプションのインポートに成功したことは、クライアントが入力を受け付けたことを示すだけで、すべてのノードが完全だという意味ではありません。少なくとも従来型プロトコルを1つ、現代的なプロトコルを1つ抽出し、最終的なノード種別、ポート、TLS、servername、ネットワーク方式、パス、UDP、プロトコル固有項目を確認してください。特にVLESS、Hysteria2、TUICでは、項目が欠落してもUIに明確な警告が出ない場合があります。現在の設定を確認できるクライアントなら元の設定と段落ごとに比較し、ノード詳細しか見られない場合は重要項目を記録してログと照合します。

URI形式は単一ノード向けで、表現力には限界がある

SS、VMess、Trojan、VLESSなどの代表的なプロトコルには、対応する共有URIやエンコード形式があります。ただし、ソフトウェアによってクエリパラメータ、名前のエンコード、拡張項目の扱いが異なる場合があります。リンク末尾のノード名は表示用で、認証には関与しません。接続を変えるのはクエリパラメータ内のtype、security、sni、pathなどです。リンクをコピーするときにチャットツールが特殊文字を切り捨てたり、中間システムが二重エンコードしたりすると、クライアントが誤ったパスやサーバー名を受け取る可能性があります。

Hysteria2とTUICの共有形式でも、異なるエコシステムのツール間で項目名が異なる場合があります。「一方のクライアントではインポートできるが、別のクライアントでは認識されない」場合は、まず対象クライアントがそのURI方式に対応しているか確認し、必要に応じてネイティブYAMLを使います。リンクのプレフィックスだけを別のプロトコル名に置き換えないでください。認証構造、通信方式、必須項目が異なるためです。

設定変換で失われやすい項目

TLS関連項目が最初の重点確認箇所です。servername、SNI、証明書検証、ALPN、クライアントフィンガープリントなどが含まれます。次が通信方式関連で、WebSocketのパスとリクエストヘッダー、gRPCのサービス名、UDPリレー、QUICの輻輳オプションなどです。3つ目はプロトコル固有項目で、SSの暗号化方式、VLESSのflow、TUICのUUIDとパスワードの組み合わせ、Hysteria2の認証と帯域パラメータなどです。4つ目はClashの動作項目で、プロキシグループ名、ルールの対象、DNSモードなどが含まれます。

プロキシグループの参照も変換時に壊れることがあります。ルール末尾で指定するプロキシグループ名は、proxy-groups内の名称と完全に一致していなければなりません。プロキシグループが参照するノード名も、proxies内の名称と一致する必要があります。変換ツールが名前を重複排除したり、接尾辞を追加したり、文字を変更したりすると、ルールが存在しないプロキシグループへ向かう可能性があります。カーネルが読み込み段階でエラーを出すこともありますが、ツールによっては自動置換され、元の設定と異なる動作になる場合があります。

mixed-port: 7890
mode: rule

proxies:
  - name: "例のTrojan"
    type: trojan
    server: example.com
    port: 443
    password: "your-password"
    sni: example.com
    udp: true

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "例のTrojan"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,手動選択
  - MATCH,DIRECT

上の短い設定は、項目間の参照関係を示しています。ノード名をプロキシグループが参照し、ルールがさらにそのプロキシグループを参照します。例示用のアドレスと認証値は構造の説明だけを目的としています。実際の設定にはDNS、ルールプロバイダー、さらに多くのプロキシ種別が含まれることがあります。手動で編集するときはスペースでインデントし、タブを混在させないでください。文字列にコロン、シャープ記号、特殊文字が含まれる場合は引用符を使い、YAMLが別の型として解釈しないようにします。

サブスクリプション更新ではロールバック手段を残す

クライアントがサブスクリプションを更新すると、リモート側の内容によってノード名、プロキシグループ、プロトコル項目が変わる可能性があります。古い名前に依存するローカル上書きは、更新後に機能しなくなることがあります。変更前に現在利用できる設定を保存し、サブスクリプション由来の内容とローカル上書きで生成した内容を明確に分けてください。サブスクリプションが完全なClash YAMLを提供するなら、プロキシグループとノードを同じソースで管理するのが安全です。ノード一覧だけが提供される場合は、クライアントのテンプレートで安定したローカルプロキシグループを作成します。

更新後にすべてのノードが使えなくなった場合は、まずサブスクリプションを正常に取得できたか、ファイルが空でないか、YAMLを解析できるかを確認し、その後でノードパラメータの変化を調べます。現代的なプロトコルだけが失敗するなら、クライアントのアップグレードや切り替えでカーネルが変わっていないかを優先的に確認します。ノードには接続できるのにルールの動作が変わった場合は、プロキシグループ名とルール名を確認し、認証パラメータの調査を続けないでください。初回インポートの問題については、Clash初心者によくある10の質問とよくある質問も参照してください。

端末とネットワーク環境に応じたプロトコル選定

固定回線と日常的なデスクトップ利用

パケットロスが少なく遅延が安定した固定回線では、SS、Trojan、VMess、VLESSのいずれでも安定した利用感が得られる可能性があります。この場合、プロトコルの差よりも、サーバー負荷、経路距離、DNS品質の影響が大きいことが一般的です。設定項目が完全で、カーネルの対応が成熟し、サーバーの保守状態が良いノードを優先してください。SSはシンプルな構成に、TrojanはTLSパラメータが明確な接続に、VMessは成熟したサブスクリプションがある環境に、VLESSはクライアントとサーバーが現代的な実装を採用し、関連拡張が必要な構成に適しています。

デスクトップでTUN、ルールデータベース、多数のプロキシグループを長時間動かす場合、プロトコル選択よりリソース管理の方が重要になることがあります。不要なノードのヘルスチェックを減らし、ルールセットの規模を適正に保ち、DNSの重複問い合わせを避ける方が、プロトコル変更より安定性を改善しやすいでしょう。WindowsとmacOSではClash Plusから始め、UIの好みに応じてClash Verge Rev、FlClash、Clash Nyanpasuを検討できます。保守が終了したClash for WindowsやClashX Metaから移行する場合は、クライアント移行と設定互換性ガイドを参照してください。

モバイルネットワーク、通勤、頻繁なアクセスポイント切り替え

モバイルネットワークで重要な変数は、ジッター、短時間のパケットロス、アドレス変更、バックグラウンド制限です。UDP経路が安定しているなら、Hysteria2またはTUICを比較候補にする価値があります。QUIC方式は通信復旧をより柔軟に処理できるためです。接続先ネットワークによってUDP対応が不安定なら、Trojan、SS、TCPベースのVMessやVLESSの方が予測しやすい可能性があります。最も安全な構成は1種類だけを残すことではなく、同じプロキシグループに信頼できるTCP系ノードと、検証済みのQUIC系ノードを用意し、ネットワーク切り替え後の結果に応じて使い分けることです。

モバイル端末では自動テストの頻度も抑えるべきです。短い間隔で全ノードを探査すると、電池と通信量を消費し、ネットワーク切り替え直後に大量の失敗接続を発生させることもあります。普段使う候補を少数に絞り、テスト間隔を長めに設定し、手動選択のプロキシグループも残しておくとよいでしょう。アプリが継続的なバックグラウンド通信を必要とする場合は、まずシステムがVPNサービスの動作を許可していることを確認し、その後でプロトコルの復旧能力を判断します。

パケットロスが多い、または帯域変動が大きいネットワーク

Webページが時々停止し、継続ダウンロードの速度が周期的に低下し、ローカルの直接接続テストでもジッターが確認できる場合、問題はアクセス回線にある可能性があります。Hysteria2とTUICは、ユーザー空間の輻輳制御とQUICの多重ストリームによって、このような環境で有利になることがあります。ただしUDPに到達でき、サーバーパラメータが適切であることが前提です。少なくとも10分間の継続転送テストを行い、短いリクエストへの応答も同時に観察してください。速度テスト開始直後の数秒間のピークだけを見るべきではありません。

QUIC系ノードが繰り返しタイムアウトする場合は、まずUDP対応が確認できている別のネットワークで比較します。別のネットワークでは正常なら、元のネットワーク経路を引き続き調べます。すべてのネットワークで失敗するなら、サーバー、認証、TLS、クライアントカーネルの問題である可能性が高まります。帯域パラメータをむやみに増やしたり、キープアライブ間隔を短くしたりしないでください。キューの滞留や電池消費を悪化させる可能性があります。高パケットロス環境でTCP系ノードが遅くても安定するなら、フォールバック経路として利用できます。

低消費電力端末、ルーター、Linuxサーバー

リソースに制約のある端末では、継続的なCPU使用率、メモリ、同時接続状態を最優先します。基礎的なSSやシンプルな設定のTrojanはコストを見積もりやすい傾向がありますが、実際の結果は暗号ライブラリとハードウェアにも左右されます。Hysteria2とTUICは高スループットと復旧に価値がある一方、ユーザー空間でより多くの処理を必要とする可能性があります。導入前に対象端末で継続負荷、空きメモリ、温度をテストし、UDPバッファを安定して処理できることを確認してください。

mihomoを直接実行するLinuxユーザーは、設定ファイル、サービス起動、権限、ログを自分で管理する必要があります。設定はまずフォアグラウンドで検証し、成功してからシステムサービスに渡してください。ルーターでは透過プロキシ、DNSのハイジャック、LANアドレス、ファイアウォール規則も考慮する必要があります。そのため「ノードは接続済みなのに端末からアクセスできない」ことがよくあります。この場合はカーネルの外向き接続とLAN転送を分けて検証し、すべての失敗をプロトコルのせいにしないでください。

最大限の設定互換性が必要な移行シナリオ

旧クライアントから移行する際、元の設定が主にSS、VMess、Trojanで構成されているなら、Clash設定のインポートに対応した現代的なmihomoクライアントを選ぶとスムーズです。移行は、設定をコピーし、旧クライアントのシステムプロキシまたはTUNを停止し、新クライアントへインポートし、解析ログを確認し、ノードを選び、ルールを検証し、最後に自動起動を設定する順で行います。2つのクライアントに同時にシステムプロキシや仮想NICを引き受けさせないでください。ポート競合、ルートの上書き、転送ループが発生する可能性があります。

元の設定にVLESS、Hysteria2、TUIC、Meta専用DNS項目が含まれるなら、mihomoを明確に使用するクライアントを選んでください。原版Clash向けに設定をダウングレードすると、機能の削除や置換が必要になることが多く、ファイル拡張子を変更するだけでは済みません。移行の目的は、画面上のノード数を一致させることではなく、主要プロトコル、プロキシグループ、ルール、DNSの動作を一致させることです。

検証、移行、トラブルシューティングの手順

ステップ1：設定をカーネルが完全に読み込めることを確認

インポート後、すぐにTUNを有効にしたり、すべてのシステム通信をクライアント経由にしたりしないでください。設定の読み込み結果とログを確認し、未知のプロキシ種別、項目の型エラー、存在しないプロキシグループ参照、YAML解析失敗がないことを確認します。現代的なプロトコルでunsupported、unknown proxy typeなどが表示されたら、まず実際のクライアントカーネルを確認します。YAMLエラーでは、インデント、コロン、リスト記号、引用符を確認してください。プロキシグループのエラーでは、ノード名とグループ名が完全に一致しているか確認します。

クライアントが「インポートに失敗しました」とだけ表示し、詳細を示さない場合は、同系統のクライアントまたはmihomoをフォアグラウンドで使って設定を読み込み、より明確なエラー位置を取得できます。複数の項目を一度に削除しないでください。明確なエラーを1つだけ修正して再読み込みすれば、どの変更が有効だったか確認できます。設定を読み込めるようになってから、ノード接続の段階へ進みます。

ステップ2：DNS、ネットワーク到達性、プロトコルハンドシェイクを分離

接続に失敗したときは、まずサーバードメインを解決できるか、対象ポートに到達できるか、TLS、認証、データ転送のどの段階で失敗したかを確認します。ログのtimeoutは通常、どこかの待機がタイムアウトしたことを示すだけで、サーバー停止、UDP到達不能、DNSエラーのどれかまでは判断できません。certificate、servername、handshakeなどの情報はTLS段階に近く、authentication、invalid user、パスワード関連の情報は認証を示します。unknown fieldとunsupportedは、依然として設定またはカーネル段階の問題です。

ノードパラメータを変えずにネットワークを切り替えて比較できます。Wi-Fiとモバイル回線の両方で失敗するなら、設定とサーバーを優先的に確認します。片方のネットワークだけで失敗するなら、そのネットワークのDNS、UDP、ルーティングを調べます。Hysteria2やTUICが失敗し、TrojanやSSが使える場合は、UDP経路を確認してください。すべてのノードが利用可能と表示されるのにブラウザーからアクセスできない場合は、システムプロキシ、TUN、ルール、DNSを調べ、プロトコルの交換を続けないでください。

ステップ3：プロキシグループとルールが実際に対象ノードを選んでいるか確認

Clashのルールは上から順に照合され、マッチするとルールが指定したプロキシグループを使います。プロキシグループは、手動選択、自動テスト、フォールバック、ロードバランシングの状態になっている可能性があります。画面で特定ノードをクリックしても、現在のリクエストが必ずそのノードを通るとは限りません。別のプロキシグループにマッチしている場合や、DIRECTルールで直接接続している場合があります。接続詳細またはルールログで、対象ドメインがどのルールにマッチし、どのプロキシグループへ入り、最終的にどのノードを使ったか確認してください。

トラブルシューティングでは、対象ノードとDIRECTだけを含む小さな手動プロキシグループを一時的に作り、少数のテストルールから参照するとよいでしょう。自動選択と複雑なルールを切り離せます。検証後は元の設定に戻してください。ルールの誤りを隠すために、すべての通信を長期間グローバルモードへ変更しないでください。元の振り分け範囲が失われ、特定のルールがなぜマッチしないのかも分からなくなります。

ステップ4：最小限の変数でプロトコルを比較

SSとTrojan、VLESSとHysteria2などを比較する場合は、サーバー地域、テスト先、クライアント、プロキシモード、DNS、テスト時刻をできるだけそろえます。設定読み込み、初回接続、連続リクエスト、継続スループット、アイドル復旧、ネットワーク切り替えを順番に観察します。各ラウンドではノードだけを交換し、クライアントとルールを同時に変更しないでください。「どの段階で失敗したか」を記録する方が、総遅延を1つ記録するより価値があります。

2つのノードが異なるサーバーに属する場合、テスト結果はノード選定には使えますが、プロトコル設計の優劣を証明するものではありません。サーバーCPU、出口帯域、ルート、負荷が結果を左右する可能性があります。プロトコル解説は差異を理解するための枠組みであり、最終的な選定は自分の端末とネットワークで検証して決めてください。

ステップ5：移行時はフォールバックを残し、段階的に引き継ぐ

旧クライアントからClash Plus、Clash Verge Rev、FlClash、その他のmihomoクライアントへ切り替えるときは、まず元の設定をエクスポートまたはコピーし、現在のシステムプロキシポート、TUN状態、DNSモード、よく使うプロキシグループを記録します。旧クライアントを終了し、システムプロキシと仮想NICが解放されたことを確認してから新クライアントを起動します。インポート後はまず単一ノードをテストし、次にプロキシグループとルールを検証し、最後にTUN、LAN共有、自動起動などのシステム機能を有効にします。

移行後にポート競合が起きる場合、通常は旧プロセスがまだ動いているか、新旧設定が同じ待ち受けポートを使っています。アプリはアクセスできるのにシステムサービスがアクセスできない場合は、システムプロキシとTUNの対象範囲を比較します。ドメイン名だけが失敗し、直接アドレスには到達できる場合は、DNSを重点的に調べます。現代的なプロトコルだけが使えない場合は、新クライアントが想定したカーネルを実際に有効化しているかを確認し、ルールの変更を続けないでください。

再利用できるトラブルシューティング記録の形式

有効な障害記録には、少なくともOS、クライアント名、実際のカーネル、プロキシモード、ノードのプロトコル、通信方式、問題発生時刻、ネットワーク種別、ログの段階、実施済みの比較テストを含めます。認証情報をそのまま公開して貼り付けてはいけません。「使えない」を「設定は読み込み可能。TrojanノードはTLSハンドシェイク段階でservername不一致を表示。同じネットワークでSSノードは接続可能」と書き換えるだけで、解決への道筋がはるかに明確になります。

設定を長期的に保守する場合は、毎回1種類の設定だけを変更し、変更後に基本的な回帰確認を行います。サブスクリプションが更新できるか、よく使うノードに接続できるか、ルールが正しくマッチするか、DNSを解決できるか、システムのスリープ復帰が正常かを確認してください。GeoIPとGeoSiteのルールデータベースの更新や異常確認は、Clash GeoIP・GeoSiteデータ更新ガイドを参照してください。LAN共有の問題については、混合ポートとLAN共有プロキシの解説も確認できます。

ここまでの手順を完了すると、プロトコル選択は通常、説明可能な結論に収束します。安定した固定回線では、設定が成熟しカーネルが完全対応するノードを使います。モバイルまたはジッターの大きいネットワークでは、UDPに到達できる場合にHysteria2やTUICを試します。リソースに制約のある端末では、同時接続、ヘルスチェック、通信コストを抑えます。現代的なVLESS拡張とQUIC系プロトコルにはmihomoカーネルを選びます。まだ判断できない場合は、クイックスタートガイドで基本確認を済ませ、よくある質問から症状に合う項目を調べてください。