Clashのプロトコルとコア
互換性と用途別の選び方

1. プロトコル・トランスポート・プロキシの入口

ノード名だけでは接続構成はわからない

クライアントに表示されるノードは、実際には複数の接続パラメーターで構成されています。サーバーアドレスとポートが接続先を決め、プロトコルが認証とデータのカプセル化方法を定め、トランスポートがデータを運ぶ経路を決めます。TLSは通信の暗号化や相手の認証を担う場合があります。ノード名は識別用のラベルにすぎず、名前に書かれたプロトコルが設定上の種類と一致するとは限りません。互換性を確認するときは、名前や地域、アイコンから推測せず、ノード詳細に表示される実際の種類を確認してください。

こうしたレイヤーは混同されがちです。たとえばVLESSはプロキシプロトコル、WebSocketはトランスポート方式、TLSはセキュアな通信路を確立する仕組みで、1つの接続に組み合わせて使えます。QUICはUDP上に構築され、安全なハンドシェイクと多重化されたストリームを統合しています。「VLESSとQUICの比較」だけでは、異なるレイヤーを比べてしまいます。VLESSと特定のトランスポートの組み合わせをHysteria2のノードと比較するなど、クライアントとコアも明記して、接続全体で比べるのが適切です。

アプリから接続先までの4段階

プロキシ接続は、アプリからローカルの入口、ローカルのコアからプロキシサーバー、サーバーから接続先、接続先からの応答という4つの段階に分けられます。システムプロキシの影響を受けるのは、その設定に従うアプリだけです。TUNは仮想ネットワークインターフェースとルーティングを使って、対象の通信を取り込みます。どちらも通信をコアに渡す方法を決めるもので、SSのノードをTrojanに変換したり、サーバーにないUDP転送機能を補ったりするものではありません。通信を取り込む範囲とノードのプロトコルは、分けて確認しましょう。

ルールモードでは、入口の後で接続先に応じた経路を選びます。DIRECTに一致した接続は直接送信され、プロキシのポリシーグループに一致した接続だけが対応するノードを使います。そのため「ノードを切り替えてもWebページの表示が変わらない」場合、プロトコルの差が小さいのではなく、そのページが直結されている、あるいは接続が以前のセッションを再利用している可能性があります。接続パネルで適用ルール、ポリシーの経路、接続先アドレスを確認してから比較すると、ルール設定の誤りをプロトコルの性能問題と取り違えずに済みます。

比較前にそろえる条件

プロトコルを公平に比較するには、少なくともプロキシサーバーのネットワーク、接続先、テスト端末、おおよその時間帯をそろえる必要があります。同じ地域の2つのノードでも、経路や共有帯域が異なり、負荷状況も大きく違うことがあります。その場合、片方が速くても、現在の条件ではそのノードが適しているとわかるだけで、そのプロトコル全般が速いとは言えません。同一サーバーで比較できない場合は、実際の使い勝手でノードを選びつつ、結論はプロトコルの順位ではなく、試した組み合わせに限って述べましょう。

設定を読み込める、接続を確立できる、目的の通信を通せる、という3つの状態も区別してください。設定の読み込みに成功しただけでは、構文や一部の項目が受け入れられたことしかわかりません。ハンドシェイクに成功しただけでは、クライアントとサーバー間で認証や通信路の確立ができたことしか確認できません。音声通話、ゲーム、動画が正常に使えるかは、UDP、DNS、ルーティング、接続先サービスにも左右されます。問題はレイヤーごとに順に調べましょう。接続状態が緑色だからといって、データ経路全体の確認が済んだとは限りません。

このページでは、実際の選び方と同じ順序で解説します。まずサーバーが提供する方式を確認し、次にコアの対応状況、ネットワーク条件やリソース負荷を確認して、最後に実際の用途で検証します。プロトコルだけで回線品質が向上するわけではなく、クライアント側からサーバーに未導入の機能を有効にすることもできません。この前提を押さえておけば、帯域幅の設定、輻輳制御、キープアライブの項目を見たときに、設定変更ですべての接続問題が解決すると誤解せずに済みます。

2. ShadowsocksとVMessの設計上の違い

Shadowsocks：シンプルなプロキシ方式

Shadowsocksは一般にSSと略され、比較的早い時期から軽量な暗号化プロキシとして使われてきました。プロキシへのリクエストやデータを暗号化して包み、サーバー側で復号して接続先へ転送するのが基本です。クライアントの設定項目は、サーバー、ポート、パスワード、暗号化方式が中心で、構成は比較的シンプルです。ただし「SS」が常に同じ形式を指すわけではありません。世代や拡張によって鍵の要件、実装の対応状況、設定方法が異なるため、種類が同じというだけで項目を使い回さないでください。

比較的新しいAEAD方式では、暗号化とデータの完全性保護を組み合わせています。以前のストリーム暗号の知識を、新しい設定にそのまま当てはめないようにしましょう。SS 2022では鍵やプロトコルの要件も異なり、実装によっては複数ユーザー向けの構成に対応しています。指定された方式を使うときは、方式名と鍵の形式をそのまま確認してください。通常のパスワード、エンコードされた鍵、複数の鍵はそれぞれ異なる入力です。クライアントに文字列を保存できても、サーバーが想定どおりに解釈するとは限りません。

SSのリソース負荷は、暗号アルゴリズム、ハードウェアアクセラレーション、実装の品質によって変わります。対応命令を備えたプロセッサでは、特定のAES方式が適していることがあります。一方、別の端末ではChaCha20系の方式のほうが良好な場合もあります。これは端末と実装の組み合わせによるため、スマートフォンのメーカーやCPUアーキテクチャだけで判断できません。普段のWeb閲覧、小さなファイルのやり取り、メッセージアプリでは、こうした暗号方式の違いより回線の待ち時間のほうが目立つことも多く、方式を何度も変えるより安定性を確認するほうが有益です。

VMess：認証とトランスポートの選択肢が豊富

VMessはV2Rayのエコシステムから生まれ、ユーザーの識別、認証、データ転送を組み合わせたプロキシプロトコルです。さまざまなトランスポート方式と組み合わせられます。一般的な設定にはUUID、暗号化関連の項目、トランスポートの種類、TLS設定が含まれます。VMessという名前だけでは用途を判断できません。TCPで直接接続する場合と、TLS付きWebSocketを使う場合では、接続手順、追加ヘッダー、リバースプロキシへの導入方法、中間機器の要件が異なります。

過去のVMess設定にあるalterIdは、旧式の認証方式に関連する項目です。現在よく使われる設定ではAEADベースの認証方式が採用され、値をゼロにする形式がよく見られます。古い解説記事の項目を「そろえる」ためにゼロ以外の数値を設定したり、古いクライアントから出力した設定を現行サーバーのテンプレートとしてそのまま使ったりしないでください。認証エラーが起きたら、まずサーバーから提供されたUUID、認証方式、システム時刻を確認し、その後にトランスポート層を調べましょう。関係のない項目を一度に変更するのは避けてください。

時刻の同期は、VMessのトラブル対処で見落とされがちです。IDとポートが正しくても、端末の時刻が大きくずれていると認証に失敗することがあります。スリープからの復帰後、タイムゾーンを手動で設定した端末、長期間オフラインの端末では特に確認してください。確認すべきなのは、画面に表示されるタイムゾーン名だけでなく、実際のシステム時刻です。一方、TLS証明書のエラーも時計が原因の場合がありますが、別のレイヤーの検証です。ログに記録された認証失敗と証明書の有効期間エラーを、同じ原因としてまとめないようにしましょう。

選び方とUDPの考え方

設定の提供元が、構成の明確なSSまたはVMessのノードを安定して提供しており、用途がWeb閲覧や一般的なアプリ中心なら、プロトコルが古いという理由だけで乗り換える必要はありません。クライアントが指定された暗号化方式やトランスポートに対応しているか、実際の接続が安定して続くかを優先して確認しましょう。リバースプロキシ経由で導入する場合は、VMessの具体的なトランスポート設定がより重要です。設定項目を少なくしたい場合、サーバー側に適切な実装があれば、SSのシンプルな構成が管理しやすいこともあります。

クライアントのUDP設定をオンにするだけで、すべてのUDP通信が使えるようになるわけではありません。コア、サーバー、ノード設定、現在のトランスポートがそろって対応し、リモート側のファイアウォールも必要な通信を許可している必要があります。ゲームに接続できずWebは見られる場合は、UDPが必要なアプリで個別に確認し、接続履歴とサーバー側の対応状況を調べてください。UDPをオフにしてもWebが使えるからといって、以前のUDP経路が機能していたことにはなりません。また、そのプロトコルがゲームに向かないという証明にもなりません。

これらの設定を移行するときは、元のサブスクリプションを保存し、新しいクライアントに読み込んだあと、種類、方式、認証情報、トランスポート、TLSを1項目ずつ確認するのが確実です。その後、簡単なWebページと、接続を維持するアプリでテストしてください。プロトコル名は同じでも接続の挙動が異なる場合、トランスポートの設定やプラグインの項目が抜けていることがあります。SSのプラグインはすべてのコアが対応しているわけではありません。プラグインの項目がある場合は、対象コアのドキュメントを先に確認してください。項目を削除しても、サーバー側が自動で互換対応するわけではありません。

3. Trojan、VLESS、TLSの役割

Trojan：TLSの通信路を使ったプロキシ接続

一般的なTrojanの構成では、TLSで安全な通信路を確立し、その中でプロキシ認証とデータ転送を行います。クライアント側では、サーバーアドレス、ポート、パスワードに加えて、サーバー名と証明書の検証も重要です。「アドレス」は接続先を指定し、「サーバー名」はTLSハンドシェイクと接続相手の確認に使われます。両者は関連することがありますが、同じ文字列とは限りません。IPアドレスで接続しながら、検証にはドメイン名を指定するノードは、この違いを保つ必要がある典型例です。

TLS証明書の検証は、単に「証明書があるか」を確認するだけではありません。証明書の信頼チェーン、有効期間、名前の一致も確認します。接続先に到達できるのに検証に失敗する場合は、システム時刻、SNI、証明書のドメイン名、サーバーの証明書チェーンを確認しましょう。検証をスキップすると接続できる場合はありますが、重要な接続相手の確認が省かれます。証明書そのものの問題が解決するわけではありません。長期的に使う設定では、検証スキップを汎用的な互換オプションとして使うのではなく、正しい名前と証明書を設定してください。

Trojanの通信性能は、TLSセッションの再利用、下位のTCP接続、サーバーの構成にも左右されます。初回接続に必要な往復回数は、確立済みセッションや接続維持後のリクエストとは異なります。クライアントを再起動した直後のWebページ表示を、接続を維持している別のノードと直接比べることはできません。サーバーがリバースプロキシや別のトランスポート拡張を使っている場合、さらにレイヤーが加わることがあります。拡張機能にはコア側の対応が必要です。「Trojan対応」と書かれているだけで、すべての組み合わせが使えるとは限りません。

VLESS：認証とセキュリティを分けて考える

VLESSはV2RayやXray関連のエコシステムに由来し、プロキシプロトコル自体をシンプルにし、ユーザー認証と下位のトランスポートやセキュリティ機構を分ける設計が特徴の1つです。特に、VLESS自体はデータを暗号化して保護しません。実際の構成では通常、TLSなど、対応するセキュリティ機構で通信路を保護します。したがって「VLESSは暗号化の負荷が軽い」という説明は、セキュリティ設定を省略できるという意味ではありません。サーバーとクライアントで合意したセキュリティ方式を含めて、接続全体を評価してください。

同じVLESSノードでも、TCP、WebSocket、gRPCなど、トランスポートの組み合わせによって設定項目が異なります。WebSocketではパスやリクエストヘッダー、gRPCではサービス名が関係し、TLSではサーバー名と証明書の検証を設定します。共有リンク、サブスクリプション、YAMLでは、これらの項目の表記が異なる場合があります。手動で移行するときは、それぞれの意味に対応する項目を選び、あるトランスポートのパスを別の方式に流用しないでください。設定項目が非対応と表示されたら、まずコアのドキュメントと設定構造を確認しましょう。

REALITYやVisionもVLESSと一緒に見かける名称ですが、VLESSそのものと同じものではありません。REALITYは特定のセキュアなハンドシェイク設定に関わり、Visionは特定のフロー制御の組み合わせを指します。クライアントがVLESSに対応していても、これらの機能に自動で対応するわけではありません。公開鍵、短いID、サーバー名、flowなどの情報は、サーバー設定に基づいて指定してください。別のノードから項目をいくつかコピーして補ったり、読み込み時に項目が無視されたのに接続の挙動が保たれていると考えたりしないでください。

性能差は実際の組み合わせから考える

TrojanとVLESSのクライアントでのCPU使用率は、プロトコルヘッダーの大きさだけでは推定できません。TLSの実装、再利用の方法、トランスポートのラッパー、データ量、CPUの命令セットなどで結果は変わります。短い接続ではハンドシェイクや処理待ちが目立ちやすく、長時間の転送では回線容量、輻輳制御、サーバーの転送能力がより大きく影響します。選ぶ際は、まず接続全体の構成が保守されていることを確認し、同じネットワークで再現可能な性能を比べましょう。認証方式を速度のランクのように扱うのは適切ではありません。

Webページは表示できるのに一部のアプリが使えない場合は、通信の入口と種類に戻って確認してください。アプリがシステムプロキシを使っていない、UDPを使用している、独自のDNS処理を行っている、といった可能性があります。別のTLS系プロトコルに替えると設定の違いをたまたま回避できることがありますが、問題の原因がプロトコル設計にあるとは限りません。まずよくある質問を参考にシステムプロキシ、TUN、DNSの違いを確認し、接続パネルでどの段階に問題があるかを調べると、より適切に対処できます。

4. Hysteria2、TUIC、QUICトランスポート

UDPを使うからといって、アプリもUDPを使うとは限らない

Hysteria2とTUICはどちらもQUICベースの設計で、下位の通信にUDPを使います。ここでいうUDPはクライアントとプロキシサーバー間の通信路を指し、UDPを使うアプリしかプロキシできないという意味ではありません。TCP通信も転送できます。この違いを理解することが大切です。ブラウザーのTCPリクエストをQUICにカプセル化して転送することはできます。一方、UDPを使うゲームが快適に動くかは、プロトコルの実装、データ転送方法、経路の品質、サーバーの対応状況に左右され、下位層の名称だけでは判断できません。

QUICは、安全なハンドシェイク、ストリーム管理、輻輳制御をユーザー空間のトランスポートに統合しています。独立した複数のストリームは、1つのストリームでデータが失われても、すべてが同じ順序付きデータの到着を待つ必要はありません。これは複数の通信を1つのTCP接続にまとめる方式との大きな違いです。ただし、各ストリーム内の信頼性が必要なデータは再送などの回復処理が必要で、すべてのストリームが接続単位のリソースと輻輳の制限を共有します。「ストリーム間のヘッドオブラインブロッキングを軽減する」ことは、パケットロスの影響がなくなることでも、輻輳時にすべてのリクエストが通常速度を維持できることでもありません。

Hysteria2：帯域幅の設定は経路に合わせる

Hysteria2は複雑なネットワーク経路を想定し、帯域幅に関する設定と輻輳制御機能を備えています。一般的な設定にある上り・下りの数値は、クライアントとサーバー間の調整や送信制御に使う重要な入力値であり、設定しただけでその帯域幅が得られるわけではありません。値を実際の回線能力より大幅に大きくすると、キューがたまり、パケットロスが増えて、同じネットワーク上の他のアプリにも影響することがあります。どの制御方式を使うか、設定値が適用されるかは、サーバー側の方針とコアの実装も踏まえて判断してください。

帯域幅の値は、契約プランに記載された数値ではなく、使用中の端末からサーバーまでの経路で継続的に出せる速度を参考に設定します。スマートフォンが携帯回線に切り替わると、自宅のネットワークに合っていた値が適さなくなることがあります。提供元がデフォルトのネゴシエーションや特定の値を指定している場合は、まずその説明に従いましょう。設定を変更するのは、繰り返し確認して改善があり、遅延や他の通信との競合が目立たない場合に限るのが無難です。上りの輻輳が下りの確認応答や操作性に影響していないか判断しやすいよう、テストでは一度に片方の方向だけを変更してください。

TUIC：認証、バージョン、セッションの挙動

TUICもQUICのストリームとデータグラムを活用し、信頼性のあるストリーム、UDP転送、接続管理を組み合わせたプロキシ通信を行います。設定にはUUID、パスワード、輻輳制御、UDPの転送方式などが含まれることがあります。プロトコルの世代によって互換性の境界があるため、クライアントとサーバーは相互に接続できる実装でなければなりません。「TUIC」とだけ書かれた説明では、すべての設定項目まではわかりません。読み込みに失敗したりハンドシェイクに異常があったりする場合は、サーバーが要求するプロトコルの世代と、コアの対応範囲を確認してください。

QUIC系の設定には、接続のキープアライブ、高速な復旧、ハンドシェイクの動作を調整できるものがあります。こうした設定は既存のセッション状態、サーバーの受け入れ方針、ネットワークの切り替えに関係するもので、初回接続の待ち時間を毎回なくせるという意味ではありません。早期データにはリプレイなどのセキュリティ上の制約もあり、プロトコルの実装とアプリの両方で対応する必要があります。一般の利用者は、接続を最速にするための設定をコピーするより、まずクライアントと提供元の双方が対応する標準の構成を使い、必要に応じて細部を調整するほうが安全です。

高パケットロス環境とモバイルネットワークの注意点

QUIC系プロトコルは、高い往復遅延やパケットロスがある一部の経路で有利になることがあります。ただし、UDP経路の品質がTCPより大幅に悪くないことが前提です。アクセス回線によっては、UDPに別のキューや速度制限、アイドル時のタイムアウトが設定され、逆の結果になることもあります。接続の移行が可能かどうかも、プロトコルの実装、クライアントのネットワークスタック、通信の取り込み方法に左右されます。Wi-Fiから携帯回線に切り替えても切断されないとQUICの接続IDだけから判断することはできません。実際のアプリで既存の接続を個別に確認してください。

小さなWebページは表示できるのに大きなファイルの転送が止まる場合は、MTUや経路上の断片化処理も確認しましょう。カプセル化によって実際のペイロードに使える領域が減り、大きなUDPデータグラムを適切に処理できない経路もあります。MTUを極端に小さくしてそのまま使い続けるのではなく、まずノードを固定してほかの条件を変えず、特定のネットワークだけで起こるか確認してください。同じ端末で別のネットワークなら正常な場合は、問題を経路に絞れます。どのネットワークでも失敗する場合は、認証、TLSの名前、サーバーポートの設定を再確認しましょう。

5. 通信速度・リソース使用量・スマホの電池消費

まず4種類の「速さ」を分けて考える

接続速度には少なくとも、プロキシ通信路の確立にかかる時間、接続先から最初のデータを受信するまでの時間、継続的な転送速度、長時間運用したときの安定性があります。Webページの表示が遅い場合、DNS、ハンドシェイク、接続先サービスの応答のどこで時間がかかっているかはさまざまです。ファイルのダウンロードが遅い場合は、経路の容量、輻輳、出口の負荷が影響している可能性が高くなります。これらを1つの遅延値にまとめると、実際の違いがわからなくなります。ノードテストに表示されるミリ秒数は、通常、特定のリクエストを測った結果にすぎず、帯域幅やゲームの遅延、すべてのサイトでの使い勝手を総合評価したものではありません。

自動速度テストは、テスト先、接続の再利用、タイムアウトのしきい値にも左右されます。同じノードでも、先に測るか後で測るかによって接続状態が異なり、テスト先の経路もリクエストごとに変わる場合があります。数値の意味を知りたい場合は、Clashのノード遅延テストの仕組みを確認してください。手動で選ぶときは、同じテスト先で基本的な接続性を確かめ、その後よく使うアプリでも検証しましょう。数値が小さいだけで、実際の使い勝手が悪いノードを選ぶのを防げます。

再現可能な比較手順を作る

2つのプロトコルの組み合わせを比べるときは、サブスクリプションの更新と自動ポリシー切り替えを一時停止し、ポリシーグループの出口を固定します。大容量ファイルの同期やシステム更新など、回線を使う処理を止め、ネットワーク環境と端末の給電状態を記録しましょう。初回表示と再訪問は分けて測定します。ノードを切り替えた後は、以前の接続が前の出口を使い続けないよう、既存の接続を終了するかアプリを開き直してください。各条件を複数回テストし、順番を交互にすると、時間帯による偏りを抑えられます。

帯域幅のテストで、長時間にわたって最大速度を出し続ける必要はありません。同じ接続先、近い時間、同じ並列数で測定し、速度が安定しているか、操作への影響が目立つかを確認すれば十分です。測定中にルーターとスマートフォンの両方で遅延が大きくなるなら、プロトコルの帯域幅不足ではなく、アクセス回線側のキューの輻輳が原因かもしれません。特定のリモート接続先だけ遅く、ほかのサービスが正常なら、まず接続先や出口経路を確認してください。結論には端末、ネットワーク、ノードの構成全体を記載し、1回の測定結果を長期的な順位として扱わないようにしましょう。

CPU・メモリ・電池消費は別々に考える

CPU負荷は、暗号化と復号、プロトコルのカプセル化、ユーザー空間でのネットワーク処理、ルール判定、ログ記録など複数の処理から発生します。ユーザー空間で動くQUICの処理経路は、OSのTCPスタックとは異なります。だからといって、常に電池を多く消費するわけではありませんが、スループットが高い場合、小さなパケットが大量に発生する場合、実装の最適化が不十分な場合は差が大きくなることがあります。メモリ使用量は、接続数、キャッシュ、ルールセット、クライアントの画面などにも左右されます。特定のクライアントの使用量が多いからといって、すぐに現在のノードのプロトコルが原因だと判断しないでください。

モバイル端末では、無線機能を動作状態に保つコストも考慮する必要があります。頻繁なキープアライブ、自動テスト、サブスクリプションの定期確認があると、1回あたりの通信量が少なくても低消費電力状態に入りにくくなり、累積した影響が出ることがあります。携帯回線の電波が弱いと、同じデータを送る場合でも再送が増え、通信中の時間が長くなりやすくなります。待機中の電池消費を比べるときは、電波の強さ、バックグラウンドアプリ、使用時間をそろえてください。電波の強いWi-Fiと弱い携帯回線を直接比べることはできません。

電池の消費を抑えるには、まずクライアントの動作を見直しましょう。不要な高頻度テストを減らし、接続の再確立につながる切り替えを繰り返さないようにし、デバッグログを長時間有効にしないでください。ネットワークを制御するツールを複数同時に動かしていないかも確認しましょう。TUNによる負荷は、取り込む通信量やプラットフォームの実装によって異なります。TUNの主な役割は通信を取り込む範囲を決めることで、省電力モードではありません。クライアントのバックグラウンド権限やシステムプロキシを設定するときは、TUNとプロキシの入口に関するガイドで操作の範囲を確認してください。

最終的に選ぶべきなのは、最大速度が最も速い組み合わせとは限りません。モバイルでの作業ではスリープからの復帰、弱い回線での再接続、電池消費を重視することがあり、デスクトップでのダウンロードでは持続的なスループット、小型ルーターではCPUの単コア性能やメモリが重要になる場合があります。「画面ロック後もメッセージを受信できる」「ダウンロード中も音声が大きく途切れない」など、検証できる条件を決めて比較しましょう。プロトコルを「軽量」「超高速」「省電力」と固定的に分類するより、確実な判断につながります。

6. オリジナル版Clash、Meta、mihomoの違い

クライアントは管理、コアは接続を担当

GUIクライアントはサブスクリプションの管理、ポリシーの選択、ログ、OSとの連携を提供します。コアは設定の解析、ルール判定、DNS、実際のプロキシ接続を担当します。両者は別のレイヤーです。画面が異なる2つのクライアントが同じコアを使うこともあれば、1つのクライアントでコアを切り替えたり個別に更新したりできる場合もあります。プロトコルを利用できるか確認するときは、まず実際に動作しているコアとその機能を確認し、次にクライアントが必要な項目をすべて保存できるかを見てください。画面にボタンがないからといって、コアに機能がないとは限りません。

オリジナル版Clashでは、広く使われているYAML設定とルールの仕組みが確立されました。エコシステムの歴史上、オープンソースのコアやPremium版などの違いもあり、過去にClashの機能として紹介されたものがすべて同じ基準で利用できるとは限りません。従来の設定にあるリスニングポート、ポリシーグループ、ルールの順序は現在の利用にも影響しますが、新しいプロトコル、セキュリティ構成、ネットワークスタックの機能まで、オリジナルのコアが対応すると推測することはできません。古いクライアントで新しい設定ファイルを開けても、新しい意味どおりに実行できるとは限りません。

Metaとmihomoは後継関係にあるが、自由に置き換えられるわけではない

Clash.MetaはClashのエコシステムを基盤にプロトコルやネットワーク機能を拡張し、その後mihomoの名称で開発が続いています。サブスクリプションや解説でMeta、Clash Meta、mihomoを見かける場合、同じ発展の流れを指していることが多いものの、名称だけでは正確な機能の範囲はわかりません。インストールしたパッケージにどのビルドが含まれているか、特定の実装が有効かどうかは、クライアントの実際の情報で確認してください。設定ファイルのタイトルにあるMetaをmihomoに書き換えるだけで、移行が完了したと思わないようにしましょう。

mihomoで拡張されたプロトコル、DNS設定、ルールプロバイダー、TUNの挙動は、オリジナル版Clashの解析範囲を超えることがあります。一方、基本的なClash設定の多くは引き続き出発点として使えますが、古い項目、プラットフォーム固有の設定、動作の変更を確認する必要があります。設定の互換性は、「対応」か「非対応」かの二択ではありません。項目が拒否または無視されたり、デフォルト値の変更によって動作が変わったりすることがあります。移行後はログを確認し、プロセスが起動するかだけで判断しないでください。

特に見落としやすいのは、クライアントが設定を生成する段階です。サブスクリプション、全体設定、オーバーライドを結合するクライアントでは、コアに渡される最終設定が、利用者が見ているサブスクリプションの原文と異なる場合があります。ノードに項目が含まれているのに期待した動作にならない場合は、エディターが項目を保持していない、あるいはオーバーライドで上書きされた可能性があります。トラブル対処では、実行中の設定と起動ログを優先して確認してください。そこにはサブスクリプションURLや認証情報が含まれることがあるため、他の人に共有する前に機密情報を削除しましょう。

プラットフォームに合ったクライアントを選び、機能を確認

一般の利用者は、ダウンロードセンターで最初に紹介されているClash Plusから確認し、プラットフォームに応じてClash Verge RevやFlClashなどを選べます。WindowsにはClash Nyanpasu、AndroidにはClash Meta for AndroidやSurfboardもあります。クライアントごとに使うコアが異なる場合があり、同じサブスクリプションを読み込めるとも限りません。特にSurfboardの設定形式はmihomo YAMLとしてそのまま使えないため、クライアントを選ぶ際は提供元が対応する形式も確認してください。

Clash for WindowsとClashX Metaは、ダウンロードページで開発終了済みのアーカイブとして掲載しています。旧環境での利用が必要な方が配布元を確認するためのものであり、新しいプロトコルとの互換性を求める場合の標準的な選択肢ではありません。移行前にクライアントの比較レビューでプラットフォーム、サブスクリプション管理、通信の取り込み方法を確認し、さらに詳しい選び方はGUIクライアントの機能比較をご覧ください。名前が似ているだけで、内部の実装も同じだと判断しないようにしましょう。

コアのアップグレード後に問題が起きたら、まず最小限の設定で新しいコアが起動するか確認し、その後ルールプロバイダー、DNS、TUNを順に戻してください。以前のディレクトリ全体を一度に読み込むと、キャッシュ、古いスクリプト、ローカル設定もテストに混ざることがあります。デスクトップとスマートフォンはそれぞれ個別に確認しましょう。同じYAMLでも設定の意味は近い一方、権限、仮想ネットワークインターフェース、システムDNS、バックグラウンド処理は異なります。コアがプロトコルに対応していることは互換性の一部にすぎず、プラットフォームとの連携は別途確認が必要です。

7. サブスクリプション形式・YAML・設定項目の互換性

サブスクリプションURLだけでは、取得できる内容はわからない

サブスクリプションからは、完全な設定、ノードだけを含むYAML、共有リンクの一覧、エンコードされたテキストなどが返されます。URLの末尾にファイル拡張子があるかどうかで、形式を確実に判断することはできません。サービスによっては、リクエストのパラメーターやクライアントの識別情報に応じて異なる内容を返す場合もあります。ブラウザーでテキストが表示されても、すべてのクライアントに読み込めるとは限りません。提供元の画面で、使用するクライアントやコア向けの形式を選びましょう。別のエコシステム向けのサブスクリプションを、そのままClashの設定パーサーに渡すのは避けてください。

完全な設定には、ノードのほかにポリシーグループ、ルール、DNS、リスニング設定が含まれます。ノードだけのサブスクリプションは、ローカルのテンプレートやproxy-providersの仕組みを使って取り込む必要があります。両者では更新時の動作も大きく異なります。完全な設定を読み込んだあと別の設定に切り替えると、ルールもまとめて変わる場合があります。ノードプロバイダーだけを更新する場合、通常はメイン設定のポリシーやルールが維持されます。サブスクリプションの種類を理解しておけば、更新後にノードだけでなくモードや振り分け方も変わった理由を説明できます。

共有リンクからの変換では設定の意味が失われることがある

共有リンクは個々のノードを渡すのに便利ですが、ポリシー、ルール、DNSを含む完全な設定を表現できるとは限りません。変換ツールが新しい項目を認識できずに削除したり、プロトコルの設定を完全には同等でない項目に置き換えたりすることもあります。特にトランスポートのパス、サーバー名、flow、セキュアなハンドシェイク、UDPの方式は、アドレスとパスワードだけ確認しても移行完了とは言えません。変換後は元の設定と照らし合わせ、ログと接続の挙動を確認してください。「変換成功」は互換性の保証ではありません。

サブスクリプションURLやノードの認証情報には、実際の利用権限が含まれる場合があります。完全なサブスクリプションを公開変換サイトや質問のスクリーンショットに貼り付けたり、実行中の設定をそのまま掲示板に公開したりしないでください。変換が必要な場合は、クライアントが対応するインポート機能を優先するか、信頼できる環境で処理しましょう。説明やトラブル対処では必要な項目だけを示し、サーバー名は構造を保ったまま例示用ドメインに置き換えられます。認証情報、サブスクリプションのパラメーター、ローカルの制御インターフェース情報は共有内容から削除してください。

まず構造を理解し、次にオーバーライドの適用順を確認

以下は、通信の振り分けを理解するための最小限のYAML例です。リモートノードは含まず、ローカルのリスニングと直結ルールだけを設定しています。プロキシのサブスクリプションではないため、実行してもリモートの出口は得られません。この例では、ポート、モード、ポリシーグループ、ルールの関係を示します。ルールに記載するポリシー名は、既存のアウトバウンドまたはポリシーグループを参照する必要があります。インデントにはスペースを使い、リストの階層をそろえてください。実際のサブスクリプションの読み込みと接続手順は、サブスクリプションのインポートガイドを参照してください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 出口を選択
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,出口を選択

ユーザーオーバーライドは、サブスクリプションの更新とは別にローカル設定を追加する仕組みですが、クライアント間で共通のマージ方式はありません。項目全体を置き換えるもの、リストに追加するもの、スクリプトから最終設定を生成するものがあります。rules全体が置き換えられると、元のサブスクリプションにあったルールがすべて消える可能性があります。ルールリストのMATCHより後に追加されたルールは、一度も適用されない場合があります。編集前にマージ方法と挿入位置を確認し、更新後に実行中の設定も見てください。エディターに保存された内容だけを確認してはいけません。

ポリシーグループ名も参照関係の一部です。ノード更新で名前が削除されると、固定参照が無効になることがあります。フィルター条件が厳しすぎると、プロバイダー内のノードがすべて除外されることもあります。YAMLの構文に問題がなくても、グループ内に使えるメンバーがない状態になり得ます。ノードプロバイダーからの取得、形式、フィルター条件の一致、ポリシーグループの現在の選択を順に確認してください。実際の問題が空リストや参照切れなのに、インデントを何度も直して解決しようとしないようにしましょう。

更新後に突然使えなくなった場合は、エラーログを保存し、直前に使えていた設定に戻してから、ノードの種類、トランスポート設定、オーバーライドの結果を比較しましょう。ローカルのリスニングだけに問題があるなら、サブスクリプションを再変換するのではなく、ポートの競合を確認してください。具体的なコマンドはClashのリスニングポートが使用中の場合の対処法を参照してください。ダウンロード失敗、解析失敗、参照エラー、実行時エラーを分けて考えると、エラー情報から修正箇所を特定しやすくなります。

8. 用途に合わせたプロトコル選びとトラブル対処

デスクトップでの普段使い：安定した基準を残す

デスクトップでのWeb閲覧、文書の同期、日常的な開発には、提供元が継続して保守し、現在のクライアントが完全に対応しているノードの構成から試しましょう。SS、VMess、Trojan、VLESSのいずれでも要件を満たす可能性があります。重要なのは、ハンドシェイクが安定し、証明書や認証情報が正しく、よく使うサービスで一貫して応答することです。検証済みのノードを基準として残したうえで、別のプロトコルを試してください。切り替え後に特定のサイトだけ改善した場合は、その経路での結果に限って判断しましょう。ほかの種類をすべて削除すると、今後のトラブル対処に使える比較対象がなくなります。

継続的なダウンロードや並列処理の多い開発では、接続管理も確認が必要です。依存パッケージの取得、コンテナイメージのダウンロード、バックグラウンド同期が同時に回線を使う場合、1つのファイルで出た最大速度だけでは全体の性能を判断できません。同じ作業内容でスループット、再試行の失敗、端末の温度を確認しましょう。帯域幅を使い切ったときに操作への影響が大きい場合は、プロトコルを比較する前にアクセス回線のキューと並列数を確認してください。LAN内での共有には、ローカルのリスニングやファイアウォールも関係します。設定の詳細はLAN接続とプロキシ共有の設定を参照してください。

モバイル端末：ネットワーク切り替えと電池消費を重視

通勤中のスマートフォンは、Wi-Fi、携帯回線、電波強度の異なる環境を頻繁に切り替えます。固定ネットワークでの最高速度より、切り替え後に復旧するか、画面ロック中も動作を続けるか、メッセージの接続が何度も作り直されないかを確認しましょう。Hysteria2やTUICは条件をそろえて比較できますが、UDP経路とサーバー設定の確認が必要です。特定のアクセス回線で不安定なら、安定して使えるTCP系の構成に戻せるようにしてください。どのネットワークでも同じパラメーターを使うために、1つのプロトコルにこだわる必要はありません。

音声通話やゲームでは、ジッター、連続したパケットロス、セッション復旧が重要です。まずアプリの通信が実際にクライアントに取り込まれていることを確認し、次に選択したノードが必要なUDP転送に対応しているかを確かめましょう。Webページの遅延を1回測定しても、リアルタイム通信の経路全体を評価したことにはなりません。同じアプリとサーバーを使い、近い時間帯に比較して、バックグラウンドのダウンロードが影響していないかも確認してください。直結でも同じ問題が起きるなら、プロキシプロトコルは主な原因ではない可能性があるため、ローカルの無線ネットワークと接続先サービスを調べましょう。

小型端末：リソースの上限から使える範囲を決める

サーバーやルーターでコアを使う場合は、利用可能なメモリ、単コア性能、ストレージ、CPUアーキテクチャへの対応を選定に含めてください。大量のルール、頻繁なログ記録、多数の接続は、リソース負荷を積み重ねます。アイドル時の使用量だけで判断してはいけません。まずルールを絞って出口を1つにし、接続を確認してからプロバイダー、DNS、通信の取り込み機能を順に追加しましょう。GUIで管理したい一般の利用者は、ダウンロードページからクライアントを選べます。mihomoを直接実行する方法は、サービス、権限、ネットワークルーティングを管理できる方向けで、誰もが行う必要はありません。

失敗が起きた場所から原因を絞り込む

1つ目は設定を起動できない場合です。ログで最初に現れる解析、設定項目、ポートに関するエラーを確認し、まずそこを直してください。後続のエラーは連鎖している可能性があります。2つ目はプロキシサーバーに到達できない場合です。アドレスの名前解決、ポート、アクセス回線を確認し、既知の使用可能なノードと比較しましょう。3つ目は認証やセキュアなハンドシェイクの失敗です。プロトコルに応じてパスワード、UUID、システム時刻、TLSの名前、サーバー側の要件を確認し、すべての問題をネットワークのタイムアウトとして扱わないでください。

4つ目は通信路を確立したあと、一部のアプリだけが使えない場合です。適用ルール、接続先の名前解決、UDP、データサイズを確認し、次にサーバーから接続先までの通信を調べます。5つ目はスリープ後やネットワーク切り替え後に失敗する場合です。以前のセッションを終了して接続し直し、特定の種類のプロトコルだけで再現するかを確認してください。クライアントを開き直すと復旧しても、古いルート、DNSキャッシュ、セッション状態のどれが原因かをさらに切り分ける必要があります。再起動で一度直っただけでは、原因を調べる手がかりにはなりますが、恒久的な解決策にはなりません。

問題を報告するときは、OS、クライアント名、実際に使っているコア、プロトコルとトランスポートの組み合わせ、アクセス回線、再現手順を記録してください。ログは該当する時間帯だけを抜き出し、サブスクリプションや認証情報を削除しましょう。「読み込み後に使えない」ではなく、「設定の起動は成功、TLSハンドシェイクは失敗、別のノードなら接続可能」のように記載すれば、確認を始める箇所が明確になります。用語がまだわからない場合は用語集を、基本接続を手順に沿って復旧したい場合はクイック設定ガイドを参照し、検証できる最小の接続から確認してください。