Clashのプロトコル解説とmihomoコアの選び方 | Clash ダウンロード公式サイト

接続の階層：プロトコル、トランスポート、出力経路

まず設定の4つの階層を区別する

クライアントの画面では、プロトコル、ノード、プロキシグループが並んで表示されることがありますが、それぞれ別のものです。プロトコルはクライアントとサーバーが認証し、データをやり取りする方法を定めます。ノードはアドレス、ポート、認証情報、トランスポート設定などを含む接続設定です。プロキシグループは複数の出力先から接続先を選びます。ルールは接続をどのプロキシグループに振り分けるかを決めます。同じプロトコルでもノードは複数あり、ひとつのプロキシグループに異なるプロトコルのノードをまとめることもできます。そのため、ノードを切り替えた後に速度が変わっても、プロトコルの違いだけが原因とは限りません。経路、サーバーの負荷、接続先のサイトも影響します。

トランスポート層も分けて確認する必要があります。TCP接続上で直接動作するプロトコルもあれば、WebSocketやgRPCと組み合わせるもの、QUICを基盤とするものもあります。TLSは認証と暗号化された通信路を提供し、さまざまなアプリケーション層プロトコルと組み合わせられます。画面にVLESSと表示されていても、TLS接続が確立しているとは限りません。WebSocketも、独立した暗号化プロトコルというわけではありません。設定を読む際は、プロトコル、下位トランスポート、セキュリティ層、サーバーの識別情報を個別に確認し、名称だけで機能を判断しないようにしましょう。

アプリの通信がコアに届くまで

システムプロキシは、HTTPまたはSOCKSの入口を使うようOSの設定でアプリに通知します。実際に従うかどうかはアプリによって異なります。TUNモードは仮想ネットワークインターフェースとルーティングを使い、条件に合う通信を取り込みます。通常はより広い範囲をカバーできますが、権限、ルーティング、DNSの調整が必要です。入口の方式と接続先のプロトコルは別々です。TUNを有効にしてもSSノードがQUICに変わるわけではなく、システムプロキシを無効にしても、TUNですでに取り込まれた通信が必ず止まるとは限りません。問題を調べる際は、まず通信がコアに届いているかを確認し、その後に接続先とのハンドシェイクを確認しましょう。

アクセスは通常、ドメイン名の解決、ルール照合、ポリシー選択、サーバーへの接続、接続先へのアクセスという段階を経ます。DNSモード、ドメインルール、既存の名前解決キャッシュによって、実際の順序は変わることがあります。たとえばIPアドレス用のルールでは名前解決が行われる場合がありますが、no-resolveを指定したルールは、そのルールによる名前解決を制限します。ログにDIRECTと表示される場合、原因はノードのプロトコルではなくルールやモードかもしれません。ハンドシェイク失敗と表示されている場合は、認証、時刻、証明書、トランスポートの設定を確認しましょう。

遅延、スループット、接続安定性を分けて記録する

ノードの遅延は、多くの場合、プロキシ経由でテスト用アドレスにアクセスするまでの時間です。接続の確立、TLSネゴシエーション、サーバーでの転送、サイトからの応答時間が含まれることがあります。単純なネットワーク往復時間ではなく、大容量ファイルのダウンロード速度を示すものでもありません。スループットは経路の帯域幅、輻輳制御、ウィンドウサイズ、接続先の速度制限、端末の処理能力などに左右されます。接続安定性は、接続が安定して成功するかどうかを示します。小さなリクエストへの応答が速いノードでも、連続ダウンロードでは制限されることがあります。初回接続に時間がかかるノードでも、接続を再利用すると安定する場合があります。

プロトコルを比較する際は、サーバーの地域、テスト先、クライアントのバージョン、入口方式をそろえ、初回接続、連続したブラウジング、継続的なデータ転送を個別にテストするのがおすすめです。条件をそろえられない場合は、結果をプロトコル単体の評価ではなく、その時点でのノード構成の性能として扱いましょう。ログに表示されるタイムアウトも、名前解決、接続、読み込みのどの段階で起きたかを区別する必要があります。名前解決のタイムアウトではまずDNSを、接続タイムアウトでは経路とポートを、読み込みタイムアウトではサーバーと接続先のサイトを確認します。このように階層を分けて考えることで、設定の調整方針が明確になります。

SSとVMess：軽量な転送とセッション認証

Shadowsocksの設計上の特徴

Shadowsocksは一般にSSと略され、比較的シンプルなプロトコルでプロキシ通信を行うことを重視して設計されています。一般的な設定項目はサーバー、ポート、パスワード、暗号化方式で、HTTPSのようにドメイン証明書が必須というわけではありません。歴史の中で複数の世代の実装があるため、すべてのSSノードを同一の通信仕様と考えることはできません。従来のストリーム暗号、AEAD、Shadowsocks 2022では、鍵の扱い、メッセージ形式、実装要件が異なります。選ぶ際は、クライアントにSSの項目があるかだけでなく、対応する暗号化方式を確認しましょう。

AEADは暗号化と完全性保護を組み合わせた方式です。鍵の長さ、パスワードの導出方法、エンコード方式は、暗号化方式によって異なります。Shadowsocks 2022の鍵には明確な形式要件があり、通常のテキストパスワードをそのまま代用することはできません。サーバーで指定された方式とクライアント側の方式を一致させ、認証情報も変更せずに使用してください。暗号化処理の負荷は、プロセッサの命令セットにも左右されます。デスクトップで軽快に動く方式が、古いスマートフォンやルーターでも同じように有利とは限りません。アルゴリズム名だけで端末をまたいだ性能を比較しないようにしましょう。

TCP、UDP、プラグインは別々の設定項目

SSはTCP通信に対応し、UDP転送の仕組みもありますが、実際に使えるかどうかはクライアント、サーバー、ネットワーク経路がすべて対応している必要があります。クライアントでUDPを有効にしても、関連する通信の転送を許可するだけで、サーバー側の未対応機能を補えるわけではありません。追加のトランスポートカプセル化にプラグインが必要なノードもあります。プラグイン名、モード、パラメーターも設定の一部です。アドレスとパスワードだけをコピーすると、インポートはできても接続できない場合があります。提供元が明確なサブスクでは、元の設定を維持し、見慣れないプラグイン項目を推測で削除しないでください。

TCPでのブラウジングは正常なのに、ゲームや音声通話に問題がある場合は、まずアプリの通信がプロキシに入り、ルールで該当ノードが選ばれているか確認します。そのうえでUDP対応と戻り方向の通信を調べましょう。DNSの問い合わせが成功しても、すべてのUDPアプリが使えるとは限りません。DNSだけがコア経由で別の経路を通っている可能性があるためです。大きなパケットで問題が起きる場合は、経路MTUやフラグメンテーションも確認してください。この状況で暗号化方式だけを変更しても効果は期待しにくく、かえって変数が増え、正常だったTCP接続まで使えなくなるおそれがあります。

VMessの背景と認証上の注意点

VMessはV2Rayエコシステムで生まれたプロトコルで、認証とデータ保護を担い、複数のトランスポート方式と組み合わせられます。一般的なノードではUUIDをユーザー識別子として使い、古い設定には旧式の認証関連フィールドが残っていることもあります。現在の実装は主にAEADを前提としていますが、古いサブスクや異なるコアでは、過去のフィールドの扱いが完全には統一されていません。以前のクライアントで設定を読み込めたからといって、新しいコアでも同じ意味に解釈されるとは限りません。移行する際は、まず移行先のコアに合った設定を入手してから、旧設定との互換性を確認しましょう。

VMessの認証では時刻の有効性が関係するため、システム時刻が大きくずれていると認証失敗に見えることがあります。まずシステム時刻の自動同期を有効にし、UUIDとサーバー設定を確認してください。ノードがWebSocketを使う場合はパスとHostを、TLSを使う場合はSNIと証明書も確認します。UUIDが正しいことは必要条件のひとつにすぎません。すべての接続失敗を認証情報の誤りと決めつけると、下位のトランスポートが確立していないことを見落とし、サブスクを何度も再登録しても改善しないことがあります。

SSとVMessで優先して確認する項目
種類	優先して確認する項目	よくある制約
SS	暗号化方式、鍵の形式、プラグイン設定	方式の対応状況とUDP機能は実装によって異なる
VMess	UUID、時刻、トランスポート、セキュリティ層	旧式の認証フィールドが移行に影響する場合がある

接続経路が分かっている環境では、設定のシンプルさや実装の成熟度を重視する場合にSSが候補になります。VMessは、対応するサーバーとトランスポートがすでに整っている環境に向いています。これは運用の手間をどう選ぶかという話であり、品質の優劣を示すものではありません。現在のノードが安定しているなら、登場時期が古いという理由だけで置き換える必要はありません。新しいトランスポート機能が必要な場合も、クライアントの選択欄でプロトコルを変えるだけでなく、サーバー側が対応しているかを先に確認しましょう。

TrojanとVLESS：認証とセキュリティ層の組み合わせ

TrojanはTLSにセキュリティを委ねる

TrojanはTLS通信路を基盤とし、その中でプロキシ認証とデータ交換を行います。プロトコル内部で暗号化の役割をすべて担う方式とは異なり、成熟したTLS実装と証明書の仕組みを利用します。クライアントでよく使う設定項目は、アドレス、ポート、パスワード、サーバー名です。設定項目は少なく見えますが、ドメイン名の解決、証明書の有効性、サーバーの構成が一致している必要があります。ポートに接続できてもTLSの本人確認が成功したとは限らず、TLSが成功してもパスワード認証が通るとは限りません。

接続先アドレスとSNIは異なる場合があります。接続先アドレスはサーバーの特定に使い、SNIはTLSハンドシェイク時に接続を希望するサービス名を伝えます。証明書の検証でも、想定したサーバー名との一致が必要です。複数のサイトを運用するサーバーでは、SNIが誤っていると別の証明書やサービスに接続することがあります。ドメインをIPアドレスに置き換えて証明書エラーが出ても、すぐに検証を無効にしないでください。元の設定で専用のサーバー名が指定されていたか、その名前がサーバーの証明書と一致するかを確認しましょう。

VLESSの軽量さを支える役割分担

VLESSもV2Ray関連のエコシステムを起源とし、VMessのプロトコル層に組み込まれていた暗号化の役割を取り除き、ユーザー識別と外部のセキュアなトランスポートを分離しています。UUIDは主に認証に使うもので、暗号鍵ではありません。適切なセキュリティ層を設定していないVLESS接続は、プロトコル名だけで通信内容が保護されているとは判断できません。実際に使う際はTLS、REALITYなどの要件を確認し、クライアントのコアとサーバーの両方が対応している必要があります。

REALITYは専用の対応が必要なセキュアなハンドシェイク方式で、通常のTLSの別名ではありません。公開鍵、Short ID、サーバー名などのパラメーターにはそれぞれ意味があり、一般的な証明書設定から自由に組み立てることはできません。VLESSのflowも汎用的な高速化スイッチではなく、指定されたトランスポートとサーバー設定が一致する場合にのみ機能します。クライアントが関連フィールドを認識しない場合、削除してインポートできても、設定の意味が保たれるとは限りません。移行先のコアが対応していることを確認し、条件に合った設定を改めて入手するのが安全です。

WebSocket、gRPC、接続再利用のコスト

WebSocketはHTTPのUpgrade後の接続に双方向のデータを流す方式です。パス、リクエストヘッダー、サーバー側の入口を一致させる必要があります。gRPCは通常HTTP/2に依存し、サービス名、接続ネゴシエーション、リバースプロキシの設定も通信結果に影響します。これらのカプセル化方式は既存の構成に適合させるのに役立つ一方、プロトコルの階層や障害の切り分け箇所を増やします。ネイティブTCP、WebSocket、gRPCに、環境を問わず通用する速度の順位はありません。カプセル化方式そのものより、中継プロキシ、接続再利用、サーバーのリソース設定が使い勝手を左右することもよくあります。

接続を再利用すると、新しい接続を確立する回数を減らせます。一方、複数のリクエストが同じ接続を共有するため、輻輳や下位接続の異常の影響も同時に受けることがあります。すべてのサーバーが同じ接続再利用方式に対応するわけではなく、短時間の接続を多用する処理で必ず効果があるとも限りません。調査する際は、サーバーが許可する範囲で再利用の有無を比較し、新規接続にかかる時間、継続的なデータ転送、エラーからの復旧を確認しましょう。1回のノード遅延だけで判断しないでください。再利用、トランスポート、DNSを同時に変更すると、どの設定が改善につながったのか分からなくなります。

Trojanは、TLSが適切に構成され、認証の流れを明確に保ちたい環境に向いています。VLESSは認証とセキュアなトランスポートを柔軟に組み合わせられる一方、利用者が確認すべき組み合わせ条件も増えます。クライアント上の入力方法が似ていても、パスワードとUUIDは互換性がなく、種類の項目だけを書き換えて変換することもできません。選ぶ前に元のサブスクを保存し、接続の詳細で実際に使用される出力タイプを確認してください。必要に応じて、コアの機能と設定の互換性に関するメモで対応範囲を確認しましょう。

Hysteria2とTUIC：QUICとUDP経路

QUICはトランスポートを変えるが、物理的な経路は変えない

QUICはUDPを基盤とし、ユーザー空間で信頼性のある転送、輻輳制御、セキュアなハンドシェイクを実現します。ひとつのデータストリームでのパケットロスが別のストリームの待ち時間につながる現象を抑えられる場合がありますが、パケットロスが無視できるわけでも、経路の帯域幅を超えられるわけでもありません。すべてのストリームで、接続の輻輳状態と実際のネットワークリソースを共有します。QUICを「速いUDP」とだけ捉えると誤解につながります。UDPは下位の通信手段にすぎず、信頼性、確認応答、フロー制御はプロトコルの実装が担います。

Hysteria2とTUICはいずれもQUICを利用しますが、別々のプロトコルです。認証フィールド、転送方式、パラメーターの意味も異なります。サーバーがどちらか一方しか提供していない場合、クライアントで種類を書き換えても、もう一方のプロトコルに変換することはできません。サーバーまでのUDP通信がネットワークで許可されている必要があります。通信事業者のネットワーク、企業のゲートウェイ、ルーター、サーバーのファイアウォールのどこかでUDPが制限されていると、接続できない場合があります。ブラウザーで通常のHTTPSサイトを開けても、確認できるのは主にTCP経路が使えることだけであり、QUICノードのUDP経路が使える証明にはなりません。

Hysteria2の帯域幅パラメーターは実環境に合わせる

Hysteria2は複雑なネットワーク経路を想定したQUICベースのプロキシトランスポートで、想定帯域に関係する輻輳制御の設定も利用できます。帯域幅フィールドの役割はモードによって異なり、サーバー側のポリシーにも制限されることがあります。上り・下りに大きな数値を設定しても、帯域幅が増えるわけではありません。過度に強気な値を設定すると、キューの滞留やパケットロスが起き、ほかのアプリの遅延が増すこともあります。現在の接続回線とサーバーの制限に合わせて控えめに設定し、継続的なデータ転送中にインタラクティブなリクエストまで悪化しないか確認しましょう。

見落としやすいのが上り回線の性能です。家庭用回線やモバイル回線では、上りが下りより大幅に遅い場合があります。確認応答、アプリのアップロード、ほかの端末の通信も同じ帯域を共有します。ダウンロード中だけ通話が途切れる場合は、ダウンロード帯域の設定を増やす前に、キューが詰まっていないかを確認しましょう。HysteriaとHysteria2は、同じ名称の表記違いではありません。インポート時は、サーバーがどちらの世代を提供しているか確認してください。認証情報、難読化設定、TLSパラメーターはまとめて維持し、パスワードだけを移行しないようにしましょう。

TUICのセッション、証明書、実装の対応

TUICもQUICを使ってプロキシ接続を行い、実装によっては信頼性のあるデータストリームとデータグラムを用途に応じて扱えます。設定では、実装が対応するプロトコル世代、UUIDやパスワードなどの認証情報、証明書、サーバー名を確認しましょう。実装によっては0-RTT、輻輳制御、UDP転送モードの設定がありますが、それぞれ単独で有効にすれば使えるというものではなく、サーバー側の機能と一致している必要があります。サブスク変換ツールが関連パラメーターを取り込めないと、ノードが一覧に表示されても、正常に転送できないことがあります。

0-RTTは条件を満たす再接続の負荷を軽減できますが、以前のセッション状態が必要であり、リプレイ攻撃に関する制約もあります。初回接続ですべての待ち時間がなくなるわけではありません。モバイル端末でネットワークを切り替えた後にスムーズに復旧できるかは、接続移行の実装、アドレスの変化、NATの状態、クライアントのライフサイクル管理にも左右されます。QUICのプロトコル自体に対応する仕組みがあっても、Wi-Fiとモバイル回線の切り替え時にすべてのクライアントが切断されないとは限りません。プロトコルの説明から使い勝手を推測せず、実際のアプリで復旧を確認しましょう。

QUIC系ノードの確認手順
確認する層	確認する内容	失敗した場合の対応
ネットワーク経路	サーバーポートへのUDP到達性	別のネットワークと比較し、ファイアウォールを確認
サーバーの識別情報と認証	証明書、SNI、プロトコルに対応する認証情報	サーバーから提供された設定一式を復元
継続的なデータ転送	帯域幅の設定、パケットロス、MTU、リソース使用量	一度にひとつだけ変更し、記録を残す

これら2種類のプロトコルは、UDP経路が安定し、サーバーの構成が一致する場合に候補になります。接続する機会の多いゲスト用ネットワークの条件が分からない場合は、同じQUIC設定を何度も変更するのではなく、TCP系ノードを別の予備として残しておきましょう。予備を用意するのは異なる経路条件に備えるためで、どれかひとつのプロトコルが常に優れているという意味ではありません。

性能と電池消費：測定方法とリソースの考え方

接続速度は複数の指標に分ける

初回接続にかかる時間には、DNS、サーバーとのハンドシェイク、プロトコル認証、接続先との接続確立が含まれます。再利用した接続では、その一部を省ける場合があります。ページの読み込みは複数のドメインや並列リクエストにも左右されるため、ひとつのテスト先での結果だけではページ全体の性能を評価できません。比較時は、最初の応答、ページの読み込み完了時間、継続的なダウンロード、エラー回数を記録しましょう。どの段階が遅いかを特定して初めて、ノードの変更、DNSの調整、ハンドシェイクや接続再利用の確認のどれが必要か分かります。遅延の数値だけを一律に小さくしようとしないでください。

スループットをテストする際は、テスト元の速度制限をノードの性能と取り違えないようにしましょう。固定された信頼できるテスト先を使い、近い時間帯に複数回比較します。テスト中は、ほかの大容量通信を止めてください。サーバーの場所や外向き経路が異なる設定同士は、実際の利用環境を選ぶためには比較できますが、プロトコルの優劣を示すものではありません。連続ダウンロードはデータ通信量を消費し、端末の温度も変化させます。モバイル回線では特に、テスト時間を抑えましょう。測定結果には速度だけでなく、ネットワークの種類、入口モード、端末の状態も記録すると役立ちます。

CPU、メモリー、TUNの負荷

暗号化と復号、カプセル化、パケット処理、ルール照合はいずれもプロセッサを使用します。高帯域でのユーザー空間QUICは、演算やパケット処理の負荷が大きくなることがあります。一方、ハードウェアアクセラレーションに対応した暗号化方式が、特定の端末でより効率よく動く場合もあります。いずれも条件次第です。TCPは一律に省電力、QUICは必ずメモリーを多く使う、と決めつけることはできません。接続数、バッファー、コアの実装、アプリのリクエストパターンも結果に影響するため、実際に使う端末で確認しましょう。

TUNでは仮想ネットワークインターフェースとプロトコルスタックを処理するほか、DNSの制御、通信のスニッフィング、多数の接続記録も負荷につながることがあります。システムプロキシで普段使うアプリをカバーできている場合は、まずシステムプロキシで基準を測り、その後TUNを有効にしてカバー範囲とリソースの変化を比較しましょう。TUNが必要なら、少し負荷を減らすために必要な機能を犠牲にする必要はありません。ただし、不要なデバッグログ、頻繁すぎる自動テスト、重複するDNS問い合わせがないか確認できます。メモリー使用量が多くても、キャッシュが蓄積しただけの可能性があります。安定した使用量と継続的な増加を区別しましょう。

モバイル端末の電池消費は通信の起床頻度に左右される

スマートフォンの電池は暗号化処理だけでなく、無線モジュールの稼働、バックグラウンドでの起床、電波の強さ、再接続にも使われます。Keepaliveの間隔が短すぎると起床回数が増え、長すぎるとNATのマッピングが失効し、次のリクエストで接続を再確立することがあります。すべてのモバイルネットワークに共通する最適値はありません。画面ロック後によく切断される場合は、まずクライアントのバックグラウンド実行権限とOSの省電力制限を確認し、その後Keepaliveを確認しましょう。間隔を極端に短くすると見かけ上は接続が安定しても、待機中の電池消費が大幅に増えることがあります。

消費電力を比較する際は、画面の明るさ、ネットワークの種類、バックグラウンドアプリ、作業内容をそろえ、操作中と画面ロック中を分けて観察しましょう。短時間での電池残量の変化は推定誤差の影響を受けやすく、わずかな差の順位付けには向いていません。OSの電池使用状況、バックグラウンドの稼働時間、端末の温度、接続ログをあわせて判断できます。クライアントが到達できないノードへの再接続を繰り返すと、実際の通信量が少なくても電池を消費することがあります。その場合は、暗号化方式を変えるより接続性や再試行設定を修正する方が効果的です。

繰り返し使える検証手順は、まず固定したネットワークでノードが使えることを確認し、ブラウジング、ダウンロード、音声通話、ゲームなど実際の作業を続けて試します。その後、画面ロックからの復帰とネットワーク切り替えを確認し、最後に電池とエラーの状況を記録します。プロトコルまたは関連パラメーターを一度にひとつだけ変更し、複数回比較しましょう。遅延が短くても端末の温度が上がり、再接続も増えるなら、実際の用途に合わせて選ぶ必要があります。テストの数値が小さい方を最終的な選択と決めつけないでください。モードの違いについては、ルール、グローバル、DIRECTモードの解説も参考になります。

コアの系統：オリジナルClash、Meta、mihomo

クライアントの画面とプロキシコアを分けて考える

GUIクライアントは、サブスク管理、システムプロキシ、サービスのインストール、操作画面、プラットフォームとの連携を担います。コアは設定の読み込み、ルール照合、出力先への接続を担います。画面が似ていても対応機能が同じとは限らず、同じクライアントでもコアを変更すると挙動が変わることがあります。VLESSやHysteria2に対応しているかを確認する際は、クライアント名とコアの情報をあわせて確認してください。アプリ名にClashと含まれているだけでは、プロトコル、TUN、ルールのフィールドに対応しているか判断できず、設定をそのまま移行できる保証にもなりません。

オリジナルのClashは、ルールに基づくプロキシ、プロキシグループ、YAML設定の基本的な使い方を確立しました。Clash Premiumには一般的なオープンソース版とは異なる拡張機能があり、すべてのオリジナル版に共通する機能一覧と考えることはできません。Clash.Metaは関連エコシステムをもとにプロトコルや設定機能を拡張し、その後mihomoという名称で開発が続いています。Metaとmihomoは、別々にインストールする2つのサービスというより、プロジェクトの継続として捉えるのが適切です。古いガイドにはMetaの名称が残っている場合があるため、実際の対応機能を確認しましょう。

共通の構文があっても完全な後方互換性はない

プロキシ、プロキシグループ、ルールなどの基本構造には継続性がありますが、新しいプロトコル、DNSオプション、ルールの種類、TUNのフィールドは古いコアで使えないことがあります。古い設定を新しいコアに読み込む場合も、フィールドの既定値、古いオプションの処理、プラットフォームごとの実装が異なる可能性があります。設定の解析に成功しただけでは、接続経路が以前と同じとは限りません。移行後は少なくとも、サブスクのノード、プロキシグループの選択、ドメインの振り分け、LANへのアクセス、DNSの挙動を確認しましょう。起動できたことだけを完了条件にしないでください。

OSも機能の範囲に影響します。TUNの権限、システムサービス、仮想ネットワークインターフェース、ルーティングの実装はプラットフォームによって異なります。デスクトップで動く設定をスマートフォンでそのまま使えるとは限りません。GUIクライアントによってはコア設定を生成または上書きするため、実行中のファイルを直接編集しても、サブスクの更新や再起動で既定の内容に戻ることがあります。変更前に、クライアントが設定の上書き、マージ用スクリプト、元ファイルの編集のどれを提供しているか確認してください。長期的なカスタマイズは適切な階層で管理し、画面上の挙動をコアの非対応と取り違えないようにしましょう。

コアとGUIの役割分担
対象	主な役割	確認方法
GUIクライアント	サブスク、システム連携、操作、設定の上書き	アプリの設定と実行ログを確認
プロキシコア	プロトコル、ルール、DNS、接続処理	コアの識別情報と設定の検証結果を確認
OS	権限、ルーティング、バックグラウンド動作、ネットワークインターフェース	システムサービス、ネットワーク、電池の設定を確認

移行時は確認してから置き換える

単体で動作するmihomoでは、次のコマンドを使って指定したディレクトリ内の設定を検証できます。ディレクトリには使用するconfig.yamlと関連するローカルファイルを用意し、コマンドのパスは実際のインストール先に合わせて変更してください。検証だけで実際の接続テストを代替することはできませんが、書式、参照先、フィールドに関する問題の多くを事前に見つけられます。GUIクライアントに設定検証機能がある場合は、そちらを優先してください。実行ディレクトリ、設定のマージ、権限をクライアント側で管理していることがあり、別のディレクトリでコマンドを実行しても実際の環境を再現できるとは限りません。

mihomo -t -d ./profile

クライアントを比較する際は、まずClash Plusから確認できます。各プラットフォームのダウンロード先はダウンロードセンターをご覧ください。WindowsではClash Verge Rev、FlClash、Clash Nyanpasuも候補です。macOSではClash Verge RevとFlClash、LinuxではClash Verge RevとFlClashを比較できます。Clash for WindowsとClashX Metaは開発・保守が終了しているため、過去の環境を確認する場合には参考になりますが、使い慣れた画面だけを理由に保守状況を見過ごさないようにしましょう。最終的には、選んだクライアントが実際に使うコア、プラットフォーム対応、既存の設定に基づいて判断してください。おすすめの順番はプロトコルの性能を証明するものではありません。

サブスクの互換性：形式、フィールド、設定の上書き

サブスクのURLが同じファイル形式を意味するわけではない

サブスクとは、URLを使ってデータを取得する仕組みです。取得する内容は、完全なYAML、プロキシプロバイダーの設定、共有リンクの一覧やエンコードされたテキストなどさまざまです。URLがすべてHTTPSで始まっていても、取得方法が同じというだけで、クライアントが同じ形式として読み込めるとは限りません。サービスによってはリクエストのパラメーターやクライアント識別情報に応じて返す内容が変わるため、同じURLを複数のアプリにコピーしても結果が異なることがあります。インポートに失敗した場合は、ノードのプロトコルが非対応と決めつける前に、取得した内容の形式を確認しましょう。認証情報を何度も変更するのも避けてください。

完全な設定には通常、プロキシ、プロキシグループ、ルールが含まれ、DNS、待ち受けポート、APIなどの設定が含まれることもあります。プロキシプロバイダーは通常、ノードの一覧を提供し、メイン設定から参照して使います。共有リンクは主に個々の接続情報を記述し、ルールや完全なDNSポリシーを含まないことがよくあります。ノード一覧を完全設定としてインポートすると、トラフィックの振り分けに必要な構造が足りない場合があります。逆に、ノード一覧のみ対応する画面に完全設定を読み込むと、解析に失敗することがあります。クライアントのサブスク追加、設定ファイルの読み込み、プロバイダー管理の各画面を区別して、適切な形式を選びましょう。

変換でフィールドは並べ替えられても、機能は追加できない

サブスク変換ツールでは、共有リンクの解析、YAMLの生成、ルールテンプレートの適用などができます。しかし、古いコアに存在しないプロトコルを理解させたり、不足している情報から証明書、flow、QUICの設定を正確に復元したりすることはできません。変換ツールが拡張フィールドを認識しない場合、エラーになることもあれば、フィールドを黙って削除することもあります。後者はノードがインポート済みに見えるため、気付きにくい点に注意が必要です。新しいプロトコルを使う場合は、まず提供元が対象のコア向けに公開している形式を利用し、ノード数が表示されたことだけを変換成功の証拠とせず、変換前後の設定項目を比較しましょう。

サブスクURLには通常、アクセス用の認証情報が含まれています。完全設定にもノードのパスワードやUUIDが含まれる場合があります。問題を調べる際は必要なフィールドだけをローカルで確認し、ログやスクリーンショットを共有する前に機密情報を隠してください。サブスク全体を、信頼できないサードパーティーサービスに送らないようにしましょう。変換が必要な場合は、元のURLや内容が外部に送信されるかどうかを先に確認してください。クライアントが設定を読み込める範囲は、そのまま機能の境界にもなります。ルールプロバイダー、外部リソース、APIは通信動作を変えることがあるため、提供元が明確で用途を理解できる設定だけをインポートしてください。

ローカルの上書き設定とリモート更新を分けて管理する

サブスクの更新後にローカルの変更が消えるのは、通常、保存に失敗したのではなく、同じ階層のファイルがリモート側の内容で上書きされたためです。長期的に残すルール、DNS設定、ポートのカスタマイズは、クライアントが対応するマージや上書きの仕組みを使って管理しましょう。マージ順序も重要です。同名のプロキシグループが既存のメンバーを置き換えたり、MATCHの後ろに追加したルールが一度も照合されなかったりすることがあります。フィールド全体の置き換え、リストへの追加、名前によるマージのどれが行われるか確認してから、変更する場所を決めてください。名前の空白や大文字・小文字も統一し、存在しない項目を参照しないようにしましょう。

次の例はルール構造を説明するものです。Proxyプロキシグループを定義済みの設定で使ってください。LAN内の接続先はDIRECT、指定したドメインはプロキシグループへ振り分け、その他の接続は最後の行で処理します。ノードを含む完全なサブスクではないため、単独で接続用の設定としてインポートしないでください。no-resolveが制限するのはこのIPルールでの名前解決だけで、DNSを全体的に無効にするものではありません。実際の振り分けでは既存ルールの順序も考慮し、サービス提供元のルール一覧全体を機械的に置き換えないようにしましょう。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - DOMAIN-SUFFIX,github.com,Proxy
  - MATCH,Proxy

メンテナンス用に、正常に動作する設定のバックアップを残しておきましょう。更新後は設定の解析結果を確認し、代表的なノードと普段使うルールをテストします。新しいプロトコルのノードだけ失敗する場合は、フィールドとコアを優先して確認してください。すべてのノードが失敗する場合は、まずサブスクの取得結果、システム時刻、ローカルの入口を確認します。接続はできても振り分けが変わった場合は、ルールと上書き順序を調べましょう。詳しくはGEOIPとDOMAIN-SUFFIXを使った振り分けの実践ガイドをご覧ください。問題が起きている階層を特定することで、ルールの問題を解決するためにプロトコルを変更するといった誤った対応を避けられます。

用途別の選び方：プロトコル候補と検証の進め方

日常のブラウジングとデスクワーク

日常のブラウジングでは、新しいプロトコル名を追うより、接続の安定性、サブスクの管理のしやすさ、ルールの調整しやすさを重視しましょう。信頼できるSS、VMess、Trojanのノードがあれば、まず普段使いの基準として設定できます。VLESS、Hysteria2、TUICが必要な場合は、コアとサーバーの組み合わせを確認してください。職場のネットワークに明確なプロキシ利用ルールがある場合は、それに従い、システムプロキシ、ルーティング、DNSを奪い合う複数のクライアントを同時に動かさないようにしましょう。クライアントを選ぶ際は、まずClash Plusを確認し、その後プラットフォームに合わせてほかの選択肢と比較できます。

ブラウザーでは問題ないのにデスクトップアプリが接続できない場合は、すぐにプロトコルを変えないでください。アプリがシステムプロキシに従うか、独自のプロキシ設定があるか、クライアントのログに通信が表示されるかを確認しましょう。通信を広く取り込む必要がある場合に、TUNを検討します。LANプリンター、ファイル共有、開発用サービスでは適切なDIRECT経路を残さないと、プロキシが使えていても仕事に支障が出ることがあります。仕組みについてはTUN仮想ネットワークインターフェースによる通信の取り込みガイドを、実際の設定手順については使い方ガイドをご覧ください。

モバイル回線、リアルタイム通信、継続的なダウンロード

モバイル端末では、ネットワークの切り替え、画面ロック後の復帰、待機中の動作を最初にテストしましょう。AndroidではClash Plusから確認し、Clash Meta for Android、FlClash、Surfboardの実際の設定形式と機能対応を比較できます。iOSではClash PlusのApp Storeへのリンクと公式サイトclashplus.ioをご確認ください。これらのクライアントが同じコアやサブスク形式に対応しているとは限りません。同じリンクを読み込めるというだけで、すべてのプロトコル拡張やルールの動作まで同じだと考えないでください。

音声通話やゲームでは、ジッター、パケットロス、UDPの利用可否が重要です。HTTPの遅延を一度測るだけでは判断できません。まずアプリの通信が正しい出力先を通っているか確認し、実際のセッションで切断、復旧、遅延の変動を観察しましょう。Hysteria2やTUICも候補になりますが、ネットワークでUDPが制限されている場合は、条件に合った別の方法を使ってください。大容量ファイルのダウンロードでは、継続的なスループット、端末の温度、ほかの通信がキュー待ちになるかを確認します。回線の上限に達した後で帯域幅の想定値を上げても、通常は効果がなく、並行する通信の使い勝手が下がることもあります。

ルーター、サーバー、リソースに制約のある端末

ルーターやサーバーでは、常時稼働の安定性、設定を再現できること、障害から復旧できることが重要です。プロセスと設定を自分で管理したい場合は、mihomoコアを単体で運用できます。一般的なデスクトップユーザーには、まずGUIクライアントを使う方が管理しやすいでしょう。CPUアーキテクチャ、使用可能なメモリー、OSの権限、TUN対応を個別に確認してください。デスクトップでのスループット測定結果を低消費電力の端末にそのまま当てはめることはできません。ルールセットの規模、接続数、ログの書き込みもリソースに影響するため、シンプルな設定から基準を測り、機能を少しずつ追加しましょう。

端末全体に適用するプロキシ設定は複数の機器に影響するため、変更前に元へ戻す手順を用意してください。元の設定と検証済みのノードを残し、まず少量の通信でテストしてから適用範囲を広げます。ルーター、クライアント、ほかのサービスが同時にDNSを処理する場合は、それぞれの役割を明確にし、問い合わせのループを防ぎましょう。サーバーの外向き通信がファイアウォールで制限されている場合は、証明書の検証を緩めて解決しようとせず、TCPとUDPを別々に確認します。プロトコル接続の失敗とルーティングや権限の問題は別の原因であり、対処方法も異なります。

最終的な判断は、決まった順序で進めましょう。まずコアまたはサーバーが対応しない組み合わせを除外し、次に現在のネットワークで使えないトランスポートを除外します。その後、実際の作業を使って遅延、スループット、端末の温度、復旧動作を比較し、異なるトランスポート経路の予備ノードをひとつ残します。プロトコル、DNS、TUN、振り分けルールを同時に変更しないでください。変更のたびに、普段使うサイト、LAN、リアルタイムアプリを確認します。問題が再発した場合は、検証済みの設定に戻しましょう。プロトコル選びは一度きりのランキングではなく、条件を明確にし、理由を説明できる、保守しやすい接続方法を整える作業です。