Clashのプロトコルとコア技術ガイド

1. プロトコル・通信方式・クライアントの選び方

まず4つの層を区別する

クライアントの画面、プロキシコア、プロキシプロトコル、下位の通信方式は、それぞれ異なる層です。クライアントは設定管理、サブスクリプションの更新、システムプロキシや権限との連携を担当します。コアは設定を読み込み、DNS、ルール判定、出向きの接続を処理します。プロトコルはクライアントとサーバー間の認証やデータ転送の方法を定め、通信方式はTCP、UDPやその上のカプセル化を通じてデータを相手に届けます。画面に同じノード名が表示されても、実際のコア設定まで同じとは限りません。互換性を確認するには、まずプロトコルの種類、次に通信方式を確認し、最後にクライアントが必要な項目をすべてコアに渡しているかをチェックしてください。

選ぶ際にまず確認すべきなのは、どのプロトコルが新しいかではなく、サーバーが何に対応しているかです。サーバーがTrojanのみを提供している場合、ローカル側の種類をVLESSに変更しても別の接続方式にはならず、認証やハンドシェイクに失敗します。サブスクリプションに含まれるアドレス、ポート、認証情報、TLSの名前、通信パスは、一組の設定として扱ってください。項目を編集できるからといって、自由に置き換えられるわけではありません。別のプロトコルを試す場合は、サーバーが明示的に提供している別の設定を使い、現在接続できている設定も比較用に残しておきましょう。

接続速度はひとつの指標ではない

体感速度には、最初のページが開くまでの時間、継続転送時のスループット、長時間利用した際の安定性などが含まれます。最初のリクエストでは、DNS名前解決、サーバーとのハンドシェイク、認証、サーバーから接続先への接続が順番に発生することがあります。継続ダウンロードの速度は、帯域幅、輻輳制御、パケットロス、サーバー負荷にも左右されます。小さなリクエストへの応答が速いノードが大容量ファイルにも向いているとは限りません。一度のダウンロードで帯域を使い切れても、ビデオ会議中の揺らぎが小さいとは限りません。そのため、本ページでは環境を考慮しないプロトコルの速度ランキングを掲載せず、クライアントのテスト欄に表示される単発の結果だけで性能を判断しません。

安全性の境界と比較の順序

プロキシ接続の暗号化で保護されるのは、主にクライアントからプロキシサーバーまでの区間です。接続先サイト自体の安全性が自動的に変わるわけではありません。HTTPSサイトにアクセスする際は、ブラウザーが引き続きサイトの証明書を検証します。プロキシプロトコルでTLSを使う場合、コアはプロキシサーバーの証明書も検証する必要があり、両者は代用できません。サーバーの運営者、サブスクリプションの入手元、接続先アプリの権限も、信頼性を判断する範囲に含まれます。プロトコル名だけでは接続先の信頼性を証明できません。証明書検証を無効にしたり、サブスクリプションURLを公開したり、LANからの接続範囲を広げたりする根拠にもなりません。

「接続できるか」「必要な機能があるか」「リソース負荷を許容できるか」「継続して管理できるか」の順に絞り込むのがおすすめです。まずOSとアーキテクチャへの対応を確認し、次にコアがサブスクリプション内のプロトコルと通信方式をサポートしているかを調べます。その後、実際の用途で安定性とバッテリー消費を比べてください。ルール振り分け、TUN、ドメインのスニッフィングは、通信を取り込んで識別する機能であり、特定ノードのプロトコルだけに備わる高速化機能ではありません。ブラウザーだけを使うなら、システムプロキシで十分な場合があります。システムプロキシに従わないアプリも扱う場合に、TUNやルーティング設定を検討してください。

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

Shadowsocks：軽量な転送と暗号化方式

ShadowsocksはSSとも呼ばれ、暗号化プロキシとしての転送を中心に設計されています。一般的な設定項目は、サーバーアドレス、ポート、暗号化方式、パスワードです。証明書管理や複雑な通信方式の交渉、制御パネルまでをプロトコルに含めず、転送経路を比較的シンプルに保つことを重視しています。クライアント画面にSSと表示されていても、それが示すのはプロトコルの系統までです。実際の互換性は暗号化方式や拡張機能にも左右されます。同じ種類名が表示されていても設定項目を個別に確認し、以前のクライアントがSSに対応していたからといって、後から追加されたすべての暗号化方式にも対応していると考えないでください。

現在の設定では、認証機能付きの暗号化方式がよく使われます。AEADは暗号化に加えて、データの完全性も検証できます。SSの方式によって鍵の導出、パスワードの形式、実装要件が異なるため、方式名だけを変えて他の設定をそのまま流用することはできません。新しい方式を使う場合は、クライアントに含まれるコアとサーバー実装の両方が対応しているか確認してください。プロセッサーのハードウェアアクセラレーションに大きく依存するアルゴリズムは、デスクトップと低消費電力端末で負荷が異なる場合もあります。方式名だけで消費電力の優劣を判断する必要はありません。実際の負荷や実装品質のほうが重要なことも多くあります。

SSのTCP転送とUDP転送は、分けて考える必要があります。サーバーでTCP接続が許可されていても、UDP経路、ポート、ファイアウォール設定が整っているとは限りません。Webページは表示できるのに通話やゲームに問題がある場合は、UDPを個別に確認してください。一部のSS設定はプラグインにも依存します。プラグインはパスワードに付随する文字列ではなく、別の通信条件です。クライアントがSSの基本項目を認識しても、特定のプラグインやそのオプションを実装していなければ、読み込みに成功しただけで接続できるとは限りません。設定を移行する前に、プラグイン名、モード、サーバー側の設定が一致しているか確認しましょう。

VMess：認証、時刻、通信方式の組み合わせ

VMessはV2Rayのエコシステムに由来し、ユーザー認証とプロキシデータの転送を中心に設計されています。一般的な設定では、ユーザーを識別するUUIDを使います。VMessは複数の通信方式と組み合わせられるため、「VMessノード」という情報だけでは接続設定を十分に説明できません。TCP直結やWebSocketなどでは、ハンドシェイクの流れや設定項目が異なります。一方の通信方式のパスやリクエストヘッダーを、別の方式にそのままコピーすることはできません。クライアントはVMessの実装と指定された通信層の両方に対応している必要があり、サーバー側も同じ組み合わせを受け付けなければ、認証前に接続が終了することがあります。

VMessでは、システム時刻が正確であることが重要です。端末の時計が大きくずれていると、アドレスとUUIDが正しくても認証に失敗する場合があります。この問題ではポートを何度も変えるのではなく、自動時刻設定とタイムゾーン表示を確認してください。古い資料にあるalterIdは以前の認証方式に関係する項目です。過去の設定例を、すべてのサーバーで使える汎用的な書き方と考えないでください。現在の設定はサーバーの案内と最新のコアのドキュメントに従い、古い手順との互換性だけを理由に旧オプションを有効にしないようにしましょう。更新後に問題が起きた場合は、認証方式の変更なのか、通信方式の変更なのかを切り分けてください。

既存サービスを継続利用するには

すでに使っているSSやVMessのサービスが安定しているなら、新しいプロトコルがあるという理由だけで移行する必要はありません。まず、現在の問題が何かを整理してください。サーバーの帯域不足なのか、UDPが通らないのか、古いクライアントが設定を読み込めないのかを確認します。帯域不足は、ローカル側のプロトコル名を変えても解決しないことがほとんどです。通信方式への対応が不足している場合は、コアの変更が必要になることがあります。比較時は元のノードを残し、新しい設定を別の名前で追加して、Webページ、継続転送、必要なUDPアプリをそれぞれ確認してください。そうすることで、移行による改善がプロトコル、サーバーリソース、クライアント設定の修正のどれによるものか判断できます。

3. TrojanとVLESSのTLS設定と制約

Trojan：TLSに依存する認証と転送

TrojanはTLS接続内でプロキシの認証と転送を行います。一般的な構成ではパスワードでユーザーを認証し、TLSで通信を暗号化します。設定項目は少なく見えますが、サーバーアドレス、ポート、パスワード、証明書の名前、TLSの動作が正しく対応していなければなりません。IPアドレスで接続する場合も、証明書はドメイン名に対して発行されていることがあります。そのため、接続先のIPアドレスと証明書の検証名が異なる場合があります。エラーを解消するために検証を無効にするのではなく、サーバーから指定された名前の設定を使ってください。証明書の有効期限、端末の時刻、信頼チェーンの不足が原因で、正しいパスワードを使っていても認証に進めないことがあります。

SNIはTLSハンドシェイクで接続先サーバー名を伝える情報です。証明書の検証では、接続先の身元が想定した名前と一致するかを確認します。関連する仕組みですが、同じものではありません。クライアントによっては一つの入力項目から関連情報を設定し、別々に表示する場合もあります。設定をコピーする際は、画面上の項目名だけで判断せず、コアへのフィールドの割り当てを確認してください。ALPNはアプリケーション層のプロトコルをネゴシエートするためのものなので、サーバーの指定に従う必要があります。よく見かける値を適当に入力すると、接続先の選択を誤ったり、ハンドシェイク直後に切断されたりすることがあります。

VLESS：プロトコル本体とセキュリティ層を分離

VLESSもV2Ray関連のエコシステムに由来します。プロトコル自体の負担を抑え、暗号化は外部のセキュリティ層に委ねる設計です。UUIDは認証情報であり、通信内容を暗号化するパスワードの代わりではありません。実際に使う際は、VLESSとTLS、REALITY、または明確に保護された運用環境をセットで考える必要があります。名前から「軽量」という印象を受けても、セキュリティ層を省略してはいけません。クライアントがVLESSに対応していても、すべての通信方式、セキュリティ層、フロー制御の組み合わせに対応しているとは限りません。

REALITYは特定のハンドシェイク方式や公開鍵などのパラメーターを使います。通常のTLSで証明書名の項目を別の値に変えるだけではありません。設定には公開鍵、short ID、サーバー名、クライアントフィンガープリントなどが必要になる場合があり、各項目は対応するサーバー設定から取得する必要があります。flowは別のプロトコル動作を指定する項目です。REALITYを有効にしたからといって、任意に入力してよいわけではありません。組み合わせが利用できるかどうかは、現在のmihomoとサーバー実装の両方が対応しているか確認してください。他のコア向けの設定例を、そのまま移植できる設定と考えないようにしましょう。

WebSocketやgRPCなどの通信方式も、汎用的な高速化スイッチではありません。既存の接続先や中継層と組み合わせるために使われることがありますが、パス、サービス名、リクエストヘッダー、ネゴシエーションなどの条件が追加されます。サーバーがWebSocketを使っている場合、パスを間違えると通常のHTTPエラーが返ることがあります。gRPCではサービス名が一致しないと接続に失敗します。問題が起きたら、まず通信方式を確認し、対応する項目を調べてください。プロトコル、セキュリティ層、パスを同時に切り替えないでください。一度に一つの条件だけを変更すれば、どの層の修正で解決したか特定できます。

TrojanとVLESSの選び方

サーバーがTrojanとVLESSの両方を提供している場合は、認証項目の数だけで比較せず、設定が完全か、実装に互換性があるかを優先してください。シンプルなTLS構成で現在のサービスが安定しているなら、Trojanをそのまま使えます。サーバーが明示的に対応するVLESSの特定の組み合わせが必要な場合は、その組み合わせに対応したクライアントを選びましょう。どちらも安定して使える可能性がありますが、DNS、証明書、サーバー負荷によって遅くなることもあります。初回接続に失敗したら、名前解決、TCP接続、TLSハンドシェイク、ユーザー認証の4段階に分けて原因を確認し、該当する設定を見直してください。

移行時は、サブスクリプション変換ツールによってセキュリティ層の項目が失われないよう特に注意してください。変換後のノードに名前、アドレス、UUIDが残っていても、公開鍵やフロー制御の設定が欠落していると、画面上は揃って見えて実際には接続できないことがあります。変換前後のファイルを保存し、項目ごとに照合してください。公開の場に実際の認証情報を貼り付けてはいけません。不足している項目の説明が見つからない場合は、サーバーのドキュメントを確認し、使える組み合わせを探すためにパラメーターを手当たり次第に試すのは避けてください。

4. Hysteria2とTUICのQUIC接続の仕組み

共通の基盤：UDP上の信頼性の高い転送

Hysteria2とTUICはいずれもQUIC関連の機能を使いますが、別々のプロトコルであり、互換性はありません。QUICは通常UDP上で動作し、暗号化ハンドシェイク、ストリーム管理、パケットロスからの回復などを通信実装に統合します。だからといって、アプリケーションのデータを自由に失ってよいわけではありません。信頼性の高いストリームでは、パケットロスへの対処や再送が行われます。単一のTCPバイトストリームと比べると、複数のQUICストリームでは、あるストリームのパケットロスが他のストリームの順序待ちを引き起こしにくくなります。ただし、帯域幅、輻輳状態、端末リソースは共有するため、ネットワーク自体の容量を超えられるわけではありません。

実際の運用では、外側の通信にUDPを使えることが条件になります。現在の接続ネットワーク、ルーター、サーバーのファイアウォールが、該当する通信経路を許可している必要があります。UDPが破棄されるネットワークでは、ブラウザーでHTTPSサイトを閲覧できてもQUICプロキシが接続できるとは限りません。UDPマッピングのアイドル保持時間が短いネットワークでは、しばらく使わないうちに接続が切れる場合もあります。トラブルの切り分けでは、アプリがUDPを利用しているかだけではなく、クライアントからプロキシサーバーまでのUDP通信を確認してください。外側の通信プロトコルと内側のアプリケーション通信は別のものです。TCPを使うアプリもQUICプロキシ経由で転送できます。

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

Hysteria2は、Hysteriaをベースにプロトコルを再設計したものです。一般的な設定ではパスワード認証を使い、TLSでサーバーを検証します。初代Hysteriaとは種類も設定項目も異なり、互いに流用できません。輻輳制御の動作は帯域幅の設定に関係し、具体的なモードはクライアントとサーバー間のネゴシエーションにも左右されます。上り・下りの値は、サーバーの公称帯域や目標速度を表すものではありません。現在の接続ネットワークと実際の経路を踏まえて設定してください。他人の高い帯域値をそのまま使うと、キューイングやパケットロスが増え、他のアプリとの帯域競合が悪化することがあります。

サーバーで難読化が有効な場合は、種類とパスワードが正しいか確認してください。難読化設定はTLSの代わりではなく、証明書名の誤りも解決しません。まずQUICの基本接続が確立することを確認し、その後に認証と難読化の条件を検証します。設定を移行するときは、サブスクリプションの帯域幅の単位と、クライアントが該当項目を認識するかを確認してください。文字列と数値を混在させないようにしましょう。ダウンロード速度が落ちても、設定値が小さすぎるとは限りません。接続ネットワークの変化、サーバーの出口、継続的な輻輳が原因の場合もあります。帯域幅を変更する前に元の値を記録し、変更後のWeb応答や他のアプリの動作も確認してください。

TUIC：接続の多重化とUDP転送方式

TUICはQUIC上でプロキシセッションを運び、接続の多重化とTCP・UDP通信の扱いを重視しています。一般的な設定にはUUIDとパスワードの両方が含まれますが、具体的な形式はプロトコルの世代と現在のコア実装に従う必要があります。旧版TUICと新版は、項目を一つ追加するだけで互換性が得られるわけではありません。クライアントの対応一覧にTUICと書かれていても、それだけで判断せず、対応する設定の世代、輻輳制御オプション、サーバー側のUDP転送方式を確認してください。

UDP転送には複数のカプセル化方式があり、信頼性と通信負荷のバランスも異なります。データグラム方式は一般にリアルタイム通信の即時性を保ちやすく、信頼性の高いストリーム方式では古いデータの再送が後続データの遅延につながる場合があります。実際の動作は実装ドキュメントで確認してください。画面に「信頼性」と表示されていても、ゲームにより適しているとは限りません。ゲーム、通話、ファイル転送では再送や待ち時間への許容度が異なります。Webページが開くかだけで判断せず、対象アプリで動作を確認しましょう。

どちらも適切なネットワーク経路で評価する価値はありますが、あらゆるネットワークで常に最適とは限りません。診断用に、動作確認済みのTCP系ノードも一つ残しておくことをおすすめします。QUICノードだけが失敗しTCPノードが正常な場合は、クライアントの再インストールより先にUDP経路とサーバー側の設定を確認してください。

5. 通信負荷、リソース使用量、モバイル端末のバッテリー消費

ハンドシェイク、スループット、多重化を分けて測定

初回リクエストの所要時間は複数の処理に分かれ、プロトコルが影響するのはその一部です。DNSキャッシュが使われたか、プロキシサーバーとのセッションが確立済みか、接続先サイトが接続の再利用を許可しているかによっても結果は変わります。TLSを使うプロトコルでは初回のハンドシェイクに追加の処理が必要なことがありますが、接続を再利用すれば同じコストを繰り返す必要はありません。QUICのセッション再開にも条件があり、理想的な再開経路が毎回使えるわけではありません。普段のWeb閲覧を評価する際は、コールドスタートと連続アクセスの両方を確認し、キャッシュ済みページを何度も再読み込みするだけで判断しないでください。

継続転送時のスループットは、輻輳制御、利用可能な帯域幅、受信側の処理能力に大きく左右されます。外側のTCPでパケットロスが起きると、再送や速度調整が発生します。カプセル化が重なると、ヘッダーやバッファーの負荷も増えます。一方、QUICはユーザー空間で多くの通信処理を行うため、CPU負荷は実装、システムインターフェース、ハードウェアの影響を受けます。どちらの経路も、端末によってはボトルネックになりえます。ダウンロード中にCPUが高負荷なのに回線を使い切れていない場合は、端末の処理能力を確認してください。CPU負荷が低くても速度の変動が大きい場合は、ネットワークとサーバーの出口を調べましょう。

モバイル端末の電力消費は継続的な動作から生じる

プロトコル名だけでスマートフォンのバッテリー消費に固定の順位は付けられません。暗号化処理、ユーザー空間でのデータ処理、無線通信の起動、バックグラウンドの接続維持、ログの書き込み、DNS問い合わせなど、複数の要因が関係します。モバイル回線では小さなパケットでも無線モジュールが稼働状態を保つことがあり、継続ダウンロードでは無線とプロセッサーの両方に負荷がかかります。接続の多重化でハンドシェイクの繰り返しを減らせる場合がありますが、頻繁なキープアライブはアイドル時の消費電力を増やすこともあります。実際に使う時間帯や状況に合わせて確認し、数分間画面を操作した後の変化から、1日分のバックグラウンド動作を推測しないでください。

比較時は画面の明るさ、ネットワークの種類、バックグラウンドアプリ、作業内容をそろえ、アイドル時と負荷時を分けて確認してください。アイドル時のテストでは、異常な再接続、頻繁な探査、バックグラウンドログを確認できます。負荷時のテストでは、同じダウンロード、通話、ブラウジングを行い、リソース使用量を比べます。OSのバッテリー統計は通常アプリ単位で集計されますが、ネットワーク拡張やシステムサービスの一部は別々に表示される場合があります。総消費電力や端末温度も考慮してください。端末が発熱して速度制限されている場合、その後の結果は冷えた状態と単純には比較できません。状態が戻ってからテストするのがおすすめです。

TUN、MTU、キープアライブを調整する際の注意

TUNを有効にすると、通信を取り込む範囲が広がり、ルーティング、DNS、ネットワークスタックの処理も増えます。有効化後に消費電力が増えても、すぐにノードのプロトコルが非効率だと判断しないでください。これまでプロキシを経由していなかったバックグラウンドアプリも、通信を始めた可能性があります。まず接続一覧で通信元を確認し、ルール振り分けを調整する必要があるか判断してください。MTUが合わないと、特に経路上でパケットサイズを正しく通知できない場合に、一部のリクエストが停滞することがあります。ただし、MTUを過度に小さくすると、分割と処理の回数が増えます。症状を確認してから、クライアントとコアのドキュメントに従い、条件を管理して調整してください。

キープアライブはセッションやネットワーク上のマッピングを維持するためのもので、頻度を上げれば安定するわけではありません。間隔が短すぎるとパケット数が増え、長すぎるとネットワークによってはアイドル状態の接続が切れることがあります。適切な間隔は、プロトコルの実装、接続ネットワーク、使い方によって異なります。初回はクライアントの既定値を使い、再現性のあるアイドル切断が起きた場合に限って、一項目ずつ調整してください。「最適な設定値」だけでなく、ネットワーク条件、作業内容、変更した値、結果を記録しましょう。他の端末の設定をそのまま流用するより、記録のほうが役立ちます。

6. Clashオリジナル版、Meta、mihomoの系統と関係

名称の変遷だけで機能が同じとは限らない

オリジナル版Clashは、YAMLでプロキシ、グループ、ルールを記述する一般的な使い方を広めました。Clash Metaはその関連プロジェクトをベースに機能を拡張したフォークで、mihomoはこの系統の開発を引き継いでいます。Metaという呼び方は現在も多くの資料に残っており、クライアント名に過去の名称が含まれていることもあります。関係を確認する際は、ソフトのアイコンやタイトルだけでなく、実際に動作しているコアを確認してください。名前にClashが含まれていてもオリジナル版のコアを使っているとは限りません。画面にMetaと書かれていても、実装や機能範囲を実行情報で確認する必要がある場合があります。

オリジナル版、過去のPremium系統、mihomoの間に、すべての項目を完全に包含する単純な関係はありません。過去の系統ではルールセット、TUNなどの機能や実装に違いがあります。移行時は新しいコアがファイルを読み込めるかだけではなく、各項目の意味も照合してください。mihomoではプロトコル、DNS、スニッフィング、ルールの機能が拡張されていますが、新しい項目は実装の進化に伴って変更されることもあります。本記事では特定バージョンの対応表を固定していません。新しい項目や特殊なオプションは、現在のコアのドキュメント、起動時の出力、設定チェックの結果を合わせて確認してください。

設定の互換性は3段階で確認

第1段階は構文の互換性です。ファイルを解析できるかを確認します。インデント、コロン、リストの構造が誤っていると、YAMLとして不正になります。第2段階は項目の互換性です。コアがキーと値を認識できるか確認します。第3段階は動作の互換性です。既定値、マッチ順、ネットワークスタックの実装が変わっても、同じ設定で期待どおりに動くかを確認します。起動できたからといって、一部のチェックを通過しただけで、すべての動作が検証済みとは限りません。未知の項目は実装によって拒否されたり無視されたりするため、「エラーが出なかった」だけで移行が完全に成功したと判断しないでください。

グループやルールから参照している名前は、特に見落としやすい項目です。変換ツールでノード名が変更されてもグループが古い名前を参照している場合や、存在しないグループをルールが指定している場合、読み込みに失敗したり誤った選択になったりします。rule-providersとproxy-providersは、それぞれルールの取得元とプロキシの取得元を管理するもので、互いに置き換えられません。サーバーが新しいプロトコルを提供しても、対応するコア実装が必要です。GUIだけを更新し、古いカスタムコアを使い続けても、新しいプロトコルが自動で使えるようにはなりません。クライアントが実際に起動している実行ファイルと実行情報を確認してください。

# core-check.yaml として保存。基本項目とルール構造の確認用
mixed-port: 7897
allow-lan: false
mode: rule
log-level: info
rules:
  - MATCH,DIRECT

この最小構成では、リスニングポートとDIRECTルールだけを確認します。プロキシノードは含まれておらず、プロキシプロトコルの検証には使えません。mihomoの独立したコマンドラインプログラムをインストールした環境では、mihomo -t -f core-check.yamlを実行して設定を確認できます。コマンド名とパスはローカルのインストール方法に応じてください。完全な設定を確認する前に、コピーを作成して作業し、元のファイルを残してください。ルールやプロキシプロバイダー、データファイルを外部から読み込む設定では、ネットワーク接続、ファイルパス、必要なリソースの利用可否も確認してください。静的チェックだけでは実行時のテストを代替できません。

クライアント側の設定も引き継ぐ

Clash Verge Rev、FlClash、Clash Nyanpasuなどのクライアントでは、オーバーライド、マージ、画面上の設定によって最終的な設定が生成される場合があります。そのため、サブスクリプションの元ファイルとコアが実行するファイルは異なることがあります。一時ファイルを直接編集すると、更新や再起動で変更が失われます。クライアントが提供する永続化オーバーライドの設定を使い、最終設定の該当箇所を確認してください。サービスモード、システムプロキシ、自動起動もクライアントとシステムの連携に関する設定です。YAMLをコピーしただけでは、こうした状態は引き継がれません。移行後は権限、リスニングポート、通信の取り込み方法を再確認してください。

設定項目の違いを詳しく知りたい場合は、Clashオリジナル版・Meta・mihomoのバージョン比較をご覧ください。ルールセットとスニッフィングについては、mihomoコア機能ガイドで解説しています。これらは設定項目の背景を補足する資料です。実際に移行する際は、現在の設定を項目ごとに検証してください。

7. サブスクリプション形式、項目の割り当て、更新時の互換性

サブスクリプションURLは取得先であり、形式を示すものではない

サブスクリプションは通常、URLから設定を取得しますが、URLだけでは返される内容は分かりません。サーバーからは、完全なClash YAML、ノードのみのYAML、エンコードされた共有リンクの一覧、または別のクライアント向け設定が返されることがあります。リクエストパラメーターやクライアント識別情報に応じて、内容を切り替える接続先もあります。そのため、ブラウザーでサブスクリプションURLを開けても、現在のクライアントに適した形式とは限りません。取り込む前にサービス提供元が案内する形式を確認し、クライアントが対応を明示している方法を使ってください。ファイルの拡張子から形式を推測しないようにしましょう。

完全なClash設定には、proxies、proxy-groups、rules、DNS設定などが含まれることがあります。一方、プロキシプロバイダー用ファイルの役割は通常、ノード一覧などに限られ、完全な設定の代わりにはなりません。逆に、完全な設定をプロキシプロバイダーとして読み込もうとすると、構造が合わず失敗する場合があります。インポート画面に「設定サブスクリプション」と「プロキシプロバイダー」が別々に表示される場合は、内容に合った方を選んでください。更新後はファイルサイズが変わったかだけでなく、グループに利用可能なノードがあるか、ルールの参照先が存在するかも確認しましょう。

共有リンクの変換で設定情報が失われることがある

SS、VMess、Trojan、VLESSなどの共有リンクには、それぞれ異なるエンコード方式とパラメーター規則があります。拡張パラメーターへの対応も、ツールによって異なります。変換ツールでアドレスや認証情報を正しく抽出できても、通信パス、SNI、ALPN、フロー制御、プラグイン設定、QUIC関連の項目が欠落することがあります。項目名が似ていても、値の形式が異なる場合もあります。変換後はサーバー提供元の説明と項目ごとに照らし合わせ、ノード一覧に表示されたことだけで変換の正しさを判断しないでください。複雑なプロトコル構成では、サービス提供元が用意した対象クライアント向けの形式を使うのがおすすめです。

プロトコルの種類名は、大文字・小文字、ハイフン、別名も含めて、使用するコアの仕様に従ってください。他のエコシステムの種類名をそのままYAMLに置き換えてはいけません。また、読み込みを通すためだけに認識されない項目を削除するのも避けてください。削除した項目が接続に必須の場合があります。現在のクライアントに該当項目の設定画面がない場合は、まずコアの対応状況を調べ、自分で設定を追加するか、対応するサービス設定を選ぶか判断してください。Web上の変換結果には機密性の高い認証情報が含まれることがあります。保存や共有の際は、サブスクリプションと同等の権限情報として扱ってください。

更新後の最終設定を検証する

サブスクリプションを更新すると、ノード名、グループ、ルールが変わったり、手動で追加した設定が上書きされたりする場合があります。個人用ルールやローカルポートなどは、クライアントが対応する永続化オーバーライド層に配置し、マージ順も確認してください。更新後にグループの選択先が突然変わった場合は、ノード名の変更で以前の選択が無効になっていないかを調べます。特定のサイトだけ動作が変わった場合は、ルールやDNS設定が置き換わっていないか確認してください。差分を確認せずに何度も更新すると、再現できていた状態を保ちにくくなり、配信元の変更とローカル設定の問題を区別しにくくなります。

サブスクリプションURLにはアクセス用の認証情報が含まれることが多いため、スクリーンショットや公開ログに載せたり、オンライン変換フォームに入力したりしないでください。他の人に相談する場合は、URL全体、UUID、パスワード、その他の認証情報を削除し、種類、項目名、エラーが起きた段階だけを共有します。クライアントで更新に失敗した場合は、ネットワークに到達できるか、HTTP応答、内容の形式、設定の解析の順に確認してください。接続タイムアウトとYAMLの解析エラーは別の問題です。新しい設定が使えることを確認してから古いコピーを削除し、次回の更新で問題が起きたときにすぐ戻せるよう、動作確認済みの設定を一つ残しておきましょう。

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

デスクトップ、スマートフォン、ルーターで異なる選び方

デスクトップでWeb閲覧や仕事をする場合は、クライアントの管理機能、ルールの分かりやすさ、既存サービスの安定性を優先してください。まずClash Plusを候補にし、OSとの連携や設定要件に応じて、Clash Verge Rev、FlClash、Windows版Clash Nyanpasuと比較できます。既存のSS、VMess、Trojanサービスで問題がなければ、プロトコル名を新しくするためだけに移行コストを増やす必要はありません。特定のVLESS構成が必要な場合は、画面の使いやすさを比べる前に、クライアントの実際のコアが対応しているか確認してください。設定できても目的の構成を実行できない事態を避けられます。

Androidでは、Clash Plus、Clash Meta for Android、FlClash、Surfboardから、実際の設定要件に合うものを選べます。ただし、各クライアントのコアや設定項目の対応範囲が同じとは限りません。iOSではClash Plusのストア説明と設定機能を確認してください。公式サイトはclashplus.ioです。スマートフォンはWi-Fiとモバイル回線を頻繁に切り替えるため、切り替え後の復旧、バックグラウンドでの安定性、バッテリー消費を含めて検証してください。QUICには接続移行に関係する仕組みがありますが、どのクライアント、サーバー、OSのバックグラウンド条件でも通信が途切れないという意味ではありません。

LinuxデスクトップではClash Verge RevとFlClashを比較できます。サーバーやルーターでは、mihomoコア、サービス管理、ネットワークルーティングを個別に評価する必要があります。低消費電力端末では、プロトコルの対応一覧だけでなく、プロセッサーのアーキテクチャ、暗号化の負荷、メモリ、継続スループットも確認してください。Clash for WindowsとClashX Metaはメンテナンスが終了したアーカイブ版です。既存環境の移行先を検討する際の参考にはなりますが、新規導入では継続的なメンテナンスと互換性を重視してください。インストーラーと対応プラットフォームについてはClash ダウンロードページを、クライアントごとの特徴についてはクライアント比較をご覧ください。

リアルタイム通信と大容量ファイルでは基準が異なる

通話、ゲーム、インタラクティブなアプリでは、揺らぎ、パケットロス、一時的な途切れを重視します。まずノードとサーバーが必要なUDP通信に対応しているかを確認し、実際の使い勝手を比較してください。速度テストが成功しても、アプリのポートや転送経路が正常とは限りません。大容量ファイルのダウンロードでは、安定したスループット、端末温度、他のアプリへの影響を確認します。Hysteria2やTUICはUDP経路が適している場合の候補になりますが、動作確認済みのTCP系設定と比較してください。仕事でのWeb閲覧では、ピーク速度よりも失敗率と初回応答が重要です。日常の安定性を犠牲にして、一度だけ最高速度を狙う必要はありません。

プロトコル名から推測せず、エラーが起きた段階を特定する

手順1：問題の範囲を確認します。すべてのノードが失敗する場合は、サブスクリプション、システムネットワーク、ポートの競合、通信の取り込み状態を確認してください。特定のプロトコルだけ失敗する場合は、対応する通信方式と認証を調べます。特定のドメインだけ失敗する場合は、ルール、DNS、接続先サービスを確認してください。手順2：どの段階で失敗したかを切り分けます。名前解決の失敗ならDNS、接続タイムアウトならアドレスと経路、TLSエラーなら時刻、名前、証明書、認証エラーなら認証情報を確認してください。ログの読み方はClashのよくあるログエラーと対処法をご覧ください。段階の異なるエラーをすべて「ノードが使えない」と一括りにしないようにしましょう。

手順3：変更を最小限にして再テストします。出向きのルールを一時的に明示し、接続先へのリクエストが想定したノードを通っていることを確認してから、Webページと必要なリアルタイムアプリをそれぞれテストします。DNSに関する変更はFake-IPマッピングと互換性の解説を、ルール振り分けの順序はドメイン・GeoIPルールの実践ガイドを参照してください。DNS、TUN、MTU、プロトコルを同時に変更しないでください。接続が戻っても原因を説明できず、長期的に管理しやすい設定を作ることが難しくなります。

最終的な選択では、次の3点を説明できることが大切です。サーバーが対応しているか、現在のクライアントが機能を一通り実装しているか、実際の用途で安定した結果が得られるか。どの環境でも一律に優れたプロトコルはなく、すべてのネットワークで使える固定の設定値もありません。この3点を確認できたら、目的のない設定変更はやめましょう。初めて使う際に操作で迷った場合は、かんたんスタートガイドに戻り、インポート、モード、接続、確認の順にチェックしてください。