Clashプロトコル・コアガイド

1. プロトコル選び：接続を構成する要素を整理する

プロトコル・通信方式・クライアントの役割

クライアントでノードを選ぶと、サーバーの場所、認証方式、プロキシプロトコル、下位の通信方式を同時に選ぶことになります。Shadowsocks、VMess、Trojan、VLESSは主にプロキシ接続の仕組みを表し、TCP、UDP、TLS、WebSocketなどは各層の通信方式を表します。Hysteria2とTUICはQUICをベースに設計されています。これらを同じ基準で単純に比較すると、プロトコルの違いを回線品質の差と取り違えやすくなります。

クライアントは設定や操作の窓口で、コアは設定の読み込み、接続の確立、ルールの適用を担います。画面にノードが表示されても、現在のコアがそのノードの全オプションに対応しているとは限りません。コアがプロトコルに対応していても、サブスクリプション変換ツールが関連項目を保持するとは限りません。「サーバーの要件—サブスクリプションの内容—コアの対応機能—クライアントの設定」の順に確認し、ノード名の略称だけで判断しないことが大切です。

アプリの通信と、プロキシトンネルの通信も区別する必要があります。ゲームがUDPを使うからといって、UDP対応と表示されたノードなら必ず正常に通信できるわけではありません。ブラウザーがHTTPSに接続していても、プロキシの外側で必ずTLSが使われるとは限りません。1つの接続が複数の層でカプセル化される場合があり、暗号化、輻輳制御、タイムアウトは層ごとに動作します。問題を調べる際は、アプリのリクエストと、クライアントからプロキシサーバーへの接続のどちらに問題があるか、まず切り分けてください。

まず互換性を確認し、その後に性能を比較

選定は、サーバーが対応するプロトコルの確認、利用中のOS・クライアント・コアの対応状況の確認、同じ事業者の近い地域・時間帯での比較、の順に進めます。サーバーがTrojanしか提供していない場合、ノードの種類をVLESSに書き換えても接続できません。プロトコルはクライアント側だけで変更できる表示上の選択肢ではなく、認証情報と通信パラメーターをサーバーに合わせる必要があります。

「UDP対応」「多重化対応」「TUN対応」も同じ機能ではありません。UDP転送はプロトコルとサーバーの機能、多重化は接続の構成方法、TUNは端末内の通信を取り込む方式です。TUNを有効にすると、システムプロキシを参照しない一部のアプリも取り込めますが、サーバーにUDP転送機能を追加したり、誤ったパスワードや証明書のホスト名を修正したりするものではありません。

セキュリティとメンテナンスも選定基準

メンテナンスが継続しているクライアントとコアを選び、証明書の検証を有効にしたまま、信頼できる配布元から設定を取得してください。プロキシ経路が暗号化されていても、アプリから機密情報を平文で送信してよいわけではありません。プロキシサーバーを出た後の保護は、アプリの通信方式によって異なります。アカウントや決済、管理画面にアクセスする際は、有効なHTTPS接続を引き続き使用してください。プロキシの外側の暗号化で、Webサイト自体の安全な接続を代用することはできません。

サブスクリプションURLにはアクセス情報が含まれることが多く、設定ファイルにもパスワード、UUID、管理APIキーなどが含まれる場合があります。スクリーンショットを共有するときはURLと認証情報を隠し、トラブル相談ではプロトコルの種類、エラーの分類、必要最小限の機密でないパラメーターだけを提示してください。協力を依頼する場合も、サブスクリプションファイル全体を公開の掲示板にアップロードしないでください。ノード名から事業者や個人の命名情報が分かることもあります。

2. ShadowsocksとVMess：暗号化プロキシの2つの方式

Shadowsocks：シンプルな構成、暗号化方式の照合が重要

ShadowsocksはSSとも呼ばれ、比較的軽量な暗号化プロキシとして設計されました。サーバーのアドレス、ポート、暗号化方式、パスワードを使って接続します。設定が短いことが多く、少数のノードを自分で管理する用途に向いています。ここでいう軽量さはプロトコルの構成を指し、すべての端末や暗号化方式でCPU負荷が同じという意味でも、サーバーがすべての拡張機能に対応するという意味でもありません。

SSを選ぶ際に最も重要なのは、暗号化方式とパスワードの照合です。現在の環境では、サーバーとクライアントの両方が対応する認証付き暗号方式を使い、古いソフトとの互換性のために旧式の方式へ安易にダウングレードしないでください。新しいSS方式の中には、鍵の形式や長さ、複数ユーザーの構成に固有の要件があるものもあり、任意のテキストをそのまま入力できるとは限りません。インポート後に鍵の長さに関するエラーが出た場合は、ポートを何度も変更するのではなく、まず元データの形式を確認してください。

SSではTCPとUDPの転送をそれぞれ確認する必要があります。Webページを閲覧できても、関連するTCPリクエストが通ったことしか分かりません。音声通話、ゲーム、一部のDNSリクエストは失敗する可能性があります。サーバーでUDPが無効、経路上でUDPが制限、本体のプロキシ入口がアプリの通信を取り込んでいないといった場合、クライアントのUDPオプションを有効にするだけでは解決しません。まずログでリクエストがコアに届いているかを確認し、その後サーバーと通信方式を調べてください。

SSの構成によってはプラグインが必要です。プラグインを使うと外側の接続方式が変わり、種類、パス、TLSなどの追加パラメーターも加わるため、「SS対応」だけではそのプラグインとの組み合わせにも対応しているとは限りません。サブスクリプション変換後にアドレスとパスワードしか残っていないと、ノードをインポートできたように見えても利用できない場合があります。特にスマートフォンでは、コアに該当プラグインの機能が組み込まれているかを確認してください。デスクトップで外部プラグインを使う方法をそのまま適用できるとは限りません。

VMess：認証と外側の通信方式を分けて確認

VMessはV2Rayエコシステムで生まれ、ID認証とプロキシデータの転送を組み合わせて接続します。一般的なノードではUUIDなどの認証情報を使い、TCP、WebSocketなど対応する通信方式を組み合わせることがあります。VMessはプロトコル名だけでは実際の動作を把握できず、設定一式に大きく左右されます。同じUUIDでも、パス、Hostヘッダー、TLS設定が異なれば接続結果は変わります。

古い資料には過去の認証方式や廃止された項目が混在していることがあり、そのまま現在の推奨設定として扱うことはできません。サブスクリプションに古いパラメーターが含まれている場合は、検索で見つけた断片を試すのではなく、提供元の要件とコアの説明を確認してください。端末の時刻も確認が必要です。認証の仕組みによっては適切な時刻が必要なため、システム時刻が大きくずれている場合は自動時刻合わせを有効にしてから、ノードの停止を判断してください。

WebSocketを使う場合は、接続ポート、リクエストパス、Hostヘッダー、TLSのサーバー名をそれぞれ確認してください。HostはHTTP層の情報で、サーバー名はTLS接続や証明書検証に使われます。両者が関連することはありますが、常に同じとは限りません。リバースプロキシを使う構成では、パスをサーバー側の転送ルールに合わせる必要があります。パスが違うと、認証エラーではなくHTTPレスポンスの異常としてログに現れることがあります。

2つのプロトコルを適切に比較する

SSは設定項目が比較的まとまっており、外側の構成をシンプルにしたい環境に向いています。VMessは組み合わせの選択肢が多く、既存の通信基盤に接続しやすい一方、確認すべき項目も増えます。ただし、これを理由にSSは常に省電力、VMessは常に低速とは言えません。暗号化の実装、CPU命令への対応、ネットワークの往復時間、接続の再利用によって結果は変わり、低性能なルーターと最新のスマートフォンで異なることもあります。

比較する際は、出口の地域、サーバーのリソース、対象ファイルをできるだけそろえてください。異なるサーバーのノードを比べた場合、結果が示すのは主にノード全体の品質です。日常利用では、ページを最初に開くときの滑らかさ、転送の安定性、アイドル後の再接続、ネットワーク切り替え後の復旧のほうが、接続時間1回分の測定より参考になります。

3. TrojanとVLESS：TLS・認証・通信方式の組み合わせ

Trojan：TLSの条件をすべて確認

TrojanはTLS接続内でプロキシ認証とデータ転送を行い、一般的な構成ではパスワード認証を使います。成熟したTLS通信で保護し、その中でプロキシリクエストを転送する設計です。クライアントで確認する主な項目は、ノードのアドレス、ポート、パスワード、サーバー名です。証明書チェーンが信頼できるか、システム時刻が正しいかも接続に影響するため、パスワード欄だけに注目しないでください。

証明書検証は、暗号化の有無だけでなくサーバーの身元を確認するものです。接続先にはIPアドレスもドメイン名も使えますが、証明書は検証に使う名前と正しく一致する必要があります。構成によってはサーバー名を別途指定するため、その場合は提供元の値を入力し、ノードの表示名で代用しないでください。証明書の期限切れ、ドメイン名の不一致、証明書チェーンの不足は、設定の提供元またはサーバーの管理者に修正を依頼してください。

証明書検証を無効にすると身元確認が弱まるため、日常的な修正方法として使うべきではありません。特定の端末だけで証明書エラーが出る場合は、その端末の時刻、システムの信頼ストア、ネットワーク上の中継機器、クライアントログを確認してください。すべての端末で同時に失敗するなら、サーバー証明書や構成変更を優先して調べます。検証設定を変更すればエラーが消えることはありますが、接続先が想定したサーバーだと確認できたことにはなりません。

TrojanのUDP機能も、ネイティブなUDP通信と同じとは限りません。一般的な実装ではUDPデータを信頼性のある接続にカプセル化しますが、具体的な経路はコアと設定によって異なります。アプリに必要な転送機能を提供できても、パケットロス時に外側の信頼性のある通信による待ち時間が発生することがあります。音声通話やゲームの使い心地は、ノードのUDP対応表示だけで判断せず、実際のアプリで確認してください。

VLESS：認証が軽量でも暗号化が完結するわけではない

VLESSは認証と外側の通信保護を分離して設計されており、プロトコル自体はデータを暗号化しません。実際の構成では通常、TLSやREALITYなど、対応する安全な通信方式と組み合わせます。そのため、VLESSノードはUUIDだけ入力すればよいものではありません。サーバーが使うセキュリティ層や通信方式、特定のフロー制御の要件にクライアントが対応している必要があり、どれか1つ欠けても接続に失敗する場合があります。

REALITY、Vision、VLESSは、互いに置き換えられる3つのプロトコル名ではありません。VLESSはプロキシプロトコル、REALITYは安全な通信方式、Visionは特定のフロー制御方式です。サブスクリプションに含まれる公開鍵、短いID、サーバー名、フロー制御などの項目には、それぞれ役割があります。画面に表示されないからといって削除しないでください。VLESSの基本接続に対応していても、これらすべての拡張機能に対応するとは限りません。

VLESSをWebSocketなどと組み合わせる場合も、パス、Hostヘッダー、TLSの条件を確認する必要があります。特定のフロー制御と組み合わせる場合は、サーバーとクライアントの通信方式が要件を満たしているか確認してください。ある構成のフロー制御項目を別の構成に流用することはできません。設定を移行するときは、まず元の組み合わせを維持して接続を確認し、その後に調整してください。プロトコル、通信方式、DNSを同時に変更すると、原因を特定できなくなります。

同じセキュリティ層を使っていても、違いは実測が必要

TrojanとVLESSはいずれもTLSを使う場合があり、ハンドシェイクや証明書処理に共通のコストが発生します。ただし、認証やカプセル化、拡張機能は異なるため、性能差のすべてをTLSのせいにはできません。最初の応答時間には、DNS解決、TCP接続、安全なハンドシェイク、接続先の応答が含まれます。軽量な確認用アドレスを1つ測定しただけでは、多数のリソースを読み込むWebページの実際の表示性能は分かりません。

提供元が両方のノードを用意している場合は、設定項目がそろっていて、現在のコアが明確に対応するものを選び、普段使うアプリで確認してください。既存のサービス基盤に複数の通信方式を接続する必要がある場合は、プロトコル名の比較よりも組み合わせの確認が重要です。既存のサブスクリプションを安定して使いたいだけなら、表示上の種類を変えるためにノードを手作業で作り直す必要はありません。サーバーのメンテナンス状況、証明書の更新、設定変更の反映頻度も長期的な利用可否に直結します。

4. Hysteria2とTUIC：QUIC接続の利点と注意点

QUICはどの層を変えるのか

QUICはUDPをベースに、安全なハンドシェイク、信頼性のあるストリーム、接続管理の機能を統合しています。Hysteria2とTUICはこれらの機能を利用してプロキシ通信を構成し、一部の接続負荷の軽減、並行処理の改善、複雑なネットワーク経路への対応などを目指しています。ただしUDPはあくまで土台であり、経路が良くなる保証はありません。現在のネットワークでUDPが制限、破棄されたり、タイムアウトが厳しかったりする場合、QUIC系ノードはTCP系ノードより安定しにくいことがあります。

QUICの複数の信頼性のあるストリームは、トランスポート層での順序付き配信によるストリーム間の待ちを減らせます。ただし、同じストリーム内でデータが失われれば再処理が必要で、すべてのストリームが輻輳ウィンドウや下位の回線を共有する場合もあります。無線の電波状況を改善したり、サーバーの帯域を超えたりするものではありません。多数のリソースを並行して読み込むWebページでは効果が出る可能性がありますが、単一ファイルのダウンロードは引き続き利用可能な回線容量、パケットロス、輻輳制御に左右されます。

接続IDはネットワーク経路の変化に対応する仕組みの土台になりますが、モバイル通信への切り替えが途切れず復旧するかどうかは、プロトコルの実装、サーバーの状態、NAT、クライアントの動作にも依存します。QUICなら常に切断されないというわけではありません。スマートフォンがWi-Fiからモバイル通信に切り替わった後は、利用中のアプリが復旧するか、コアが再度ハンドシェイクするか、OSがバックグラウンド動作を許可しているかを確認し、問題の箇所を切り分けてください。

Hysteria2：帯域パラメーターは速度倍率ではない

Hysteria2は、条件のよくない経路で調整可能な通信方式を提供することに重点を置いています。一般的な設定には認証、TLS、任意の帯域申告などが含まれ、輻輳制御の動作は双方の設定によって異なります。上り・下りの申告は回線状況を伝えるためのもので、数値を大きくすればよいわけではありません。上り容量に限りがあるのに大きな値を設定すると、キューの滞留や再送が起き、ほかのアプリの応答も遅くなるなど、かえって全体の使い心地が悪化することがあります。

帯域パラメーターを確認する際は、まず上り・下りの向きと単位を確認し、その後に実際に使える回線容量を考慮してください。家庭用回線の公称速度が、プロキシ経路で常に使える速度とは限りません。モバイル回線では電波状況や混雑によってさらに変動します。適切な値を見積もれない場合は、信頼できる設定元の値やコアの既定動作を優先し、ネット上の極端な数値をそのまま使わないでください。調整後はスループットだけでなく、応答性やパケットロスも確認します。

Hysteria2と旧Hysteriaの設定は、名前を変えるだけで互換になるわけではありません。サブスクリプション変換ツールが種類、認証項目、難読化設定を取り違えると、読み込みには成功しても接続できないノードが生成されることがあります。難読化やポートホッピングなどの任意機能を使う場合は、コアとサーバーの両方が対応している必要があります。まず提供元の完全な設定で基本接続を確認し、その後で拡張機能の条件を1つずつ調べてください。

TUIC：並行処理とUDP転送は双方の対応が必要

TUICもQUICを利用して接続し、認証、ストリーム転送、UDP転送に関する仕組みを備えています。実装や設定の世代によって、必要な認証項目やパラメーターが異なる場合があるため、TUICという表示だけで互換性を判断しないでください。インポートする際は、利用中のコアが提供元の設定形式に明確に対応しているかを確認します。未知の項目があれば、すぐ削除するのではなく、コアのログとサブスクリプションの出力形式を確認してください。

TUICでは、輻輳制御、UDP転送方式、接続維持などのオプションが動作に影響します。信頼性のある転送と信頼性を保証しないデータグラムには、それぞれ適した用途があります。前者はデータの到達を重視し、後者は損失を許容しても即時性を重視するアプリに適しています。最終的な動作は双方の実装に左右されるため、オプション名だけを見てすべてのゲームに効果があると判断することはできません。リアルタイムアプリでは、実際の通話やゲームで遅延の揺れ、途切れ、復旧時間を確認してください。

どちらのQUIC系ノードでも、MTU、経路上のUDPの状態、ルーターの動作を確認する必要があります。小さなリクエストは通るのに大きな転送が止まる場合、経路上のフラグメントやパケットサイズが関係している可能性がありますが、すべてのタイムアウトをMTUの問題と決めつけないでください。まず別のネットワークを試し、QUIC系ノードだけで発生するかを確認してから、クライアントのドキュメントに沿って調整します。比較の基準を失わないよう、利用できるTCP系ノードも残してください。

5. 接続速度・リソース使用量・スマートフォンの電池消費

初回接続と継続的な通信を分けて測定

接続の「速さ」は、少なくとも初回応答、継続的なスループット、操作時の遅延変動、切断後の復旧という複数の側面があります。初回応答はDNS、接続確立、安全なハンドシェイク、接続先の処理時間に左右されます。継続的なスループットは回線容量、パケットロス、輻輳制御、サーバー負荷に左右されます。最初の表示が速いノードが長時間のダウンロードに適するとは限らず、ダウンロード速度が高くてもビデオ会議で遅延が大きくなる場合があります。

クライアントの接続テストは通常、指定された接続先への測定にすぎず、その経路の結果しか分かりません。測定先や接続の再利用条件が異なれば、数値をそのまま比較できません。自動選択では測定の揺れによってノードが頻繁に切り替わり、長時間接続するアプリに影響することもあります。テスト方法を確認してから自動選択を使うか判断してください。安定したセッションでは、適切なノードを固定するほうが問題を特定しやすい場合があります。

比較時は端末、ネットワーク、対象リソース、ルールを固定し、帯域を使うバックグラウンド処理を停止して、一度に変更する条件を1つに絞ります。ページの初回表示、継続的な転送、アイドル後の復旧の順に測定してください。時間帯による変化をプロトコルの差と取り違えないよう、条件を入れ替えながら複数回テストします。ノードの出口やサーバーが異なる場合は、結果をノードの使い心地として記録し、プロトコル全体が速いと断定しないでください。

CPUとメモリは何に使われるのか

CPU負荷は、暗号化と復号、カプセル化、データのコピー、ルール照合、プロトコルスタックの処理から発生します。最近の端末ではハードウェアアクセラレーションにより暗号化方式の負荷が低い場合がありますが、古いルーターでは単一コアの処理能力が先に限界に達することがあります。QUICのユーザー空間処理、頻繁な小さなパケット、多数の並行接続も負荷を増やす可能性があります。スループットが不足する場合は、ノードを変え続けるのではなく、CPU使用率と回線状況の両方を確認してください。

メモリ使用量は、接続数、バッファー、ルールセット、DNSキャッシュ、クライアント画面などに左右されます。画面のプロセスとコアのプロセスを分けて確認し、負荷を増やさないようログレベルも通常の設定に戻してください。接続の再利用はハンドシェイクを減らせる一方、追加の状態を保持します。並行接続やバッファーを増やしても、必ず効果があるわけではありません。特にメモリの少ないルーターやバックグラウンド動作が制限されるスマートフォンでは注意が必要です。

TUNを使うと端末内の通信を取り込む処理が加わり、DNSの横取り、プロセス識別、ルール照合によって負荷も変わる可能性があります。そのため、システムプロキシとTUNのテスト結果をそのままプロトコルの比較に使うことはできません。2つの接続方式で異なるルールが適用されれば、実際の出口も変わる場合があります。比較前に接続履歴を確認し、同じアプリが同じノードとポリシーを使って同じ接続先へ通信していることを確かめてください。

電池消費は端末の起動状態、電波状況、実際の通信量に左右される

スマートフォンの電池は、暗号化処理だけで消費されるわけではありません。モバイル無線の通信状態の維持、電波の弱さによる再送、バックグラウンド接続の維持、アプリの頻繁な通信も大きく影響します。接続を長く維持するとハンドシェイクを減らせる一方、無線通信がアクティブな時間も延びる可能性があります。タイムアウトを短くするとアイドル時の消費を減らせても、次のリクエストで接続を何度も作り直すことがあります。すべてのスマートフォンに当てはまる省電力の順位はありません。

電池消費を比較する際は、画面の明るさ、電波状況、使用するアプリ、テスト時間をそろえ、アイドル時と連続使用時をそれぞれ確認してください。OSの電池使用量は、通信の計上方法に影響されます。VPNインターフェースを通った通信がクライアントにまとめて計上される場合もありますが、消費のすべてがプロキシ処理によるとは限りません。クライアントの電池使用順位だけで判断せず、全体の消費量、通信量、バックグラウンド動作もあわせて見てください。

日常的な最適化では、不要な高頻度チェックや詳細ログを減らし、サブスクリプションの更新間隔を適切に設定し、アプリがリクエストに失敗して再試行を繰り返していないか確認します。OSの電池制限が厳しすぎるとバックグラウンド接続が終了することがあるため、電池持ちと接続維持のバランスを取ってください。Androidではバックグラウンド動作の権限を、iOSではVPNの状態とオンデマンド接続の設定を確認します。こうしたOSの動作は、プロトコルを変えるだけでは解決できません。

6. 旧版Clash・Clash Meta・mihomo：コアとクライアントの関係

名称が似ていても、機能を混同しない

Clashはもともとプロキシコアのプロジェクト名で、後に関連する設定やクライアントのエコシステム全体を指す言葉としても使われるようになりました。オリジナルのオープンソースコア、過去のPremium版、その後のMeta系統は、同じ機能セットではありません。古いガイドに「Clash対応」とだけ書かれている場合、どの系統を前提にしているか省略されている可能性があります。ルールの種類、TUN、プロトコル拡張を使う場合は、画面のタイトルではなく具体的なコアの名称を確認してください。

Clash Metaは既存のエコシステムをベースにプロトコルや機能を拡張したコアの系統で、mihomoはその流れを引き継いでいます。クライアントやサブスクリプションにはMetaという名称が残っているものも多く、名前が違っても設定体系がまったく異なるとは限りません。ただし、名称が引き継がれていても、どの時期のビルドでも新しい項目に対応するわけではありません。実際の対応機能は、稼働中のコアとそのドキュメントで確認してください。最新の情報から古いインストーラーの機能を推測しないでください。

Premiumにはオープンソース版とは異なる機能が含まれていた時期があり、独自の設定項目やスクリプト機能をmihomoへそのまま移行できるとは限りません。用途が似た項目でも実装や構文が違う場合があり、そのまま残すと設定の読み込みに失敗したり、動作が変わったりする可能性があります。古い設定を移行する際は、まず最小限の構成で動作を確認し、ルールセット、DNS、TUN、自動化設定を1つずつ戻してください。過去の機能一式をそのままコピーするのは避けましょう。

クライアントは画面、コアは処理を担当

クライアントには、サブスクリプション管理、ノード選択、システムプロキシ、ログ表示などの機能があり、設定の上書きやコアの更新機能を備える場合もあります。画面上の設定によって実行時の設定が生成・変更されることがあるため、ディスク上のサブスクリプション原本がそのままコアに読み込まれるとは限りません。トラブル時は、クライアントが表示する実行時設定や統合後の内容を確認してください。特にDNS、ポート、ポリシーグループ、TUNが画面の設定で上書きされていないか注意が必要です。

初めて使う場合はプラットフォームに合ったClash Plusをまず確認し、必要に応じてClash Verge RevやFlClashなどと比較してください。WindowsではClash Nyanpasuも候補になり、LinuxではClash Verge RevとFlClashから選べます。おすすめのクライアントでも、各プラットフォームの内部実装がすべて同じとは限りません。特定のプロトコル拡張が必要な場合は、該当プラットフォーム向けビルドの機能と各パラメーターへの対応を確認してください。

AndroidではClash Meta for AndroidとSurfboardも、それぞれの対応機能に基づいて選んでください。Surfboardは独自の設定体系を使うため、同じプロキシクライアントだからといってClash YAMLをそのまま適用できるわけではありません。iOSではダウンロードページからClash Plusのストアへのリンクと公式サイト clashplus.ioを確認できます。OS間で移行する際は、アプリ名だけでなく、具体的な設定と対応機能を比較してください。

アーカイブ版ソフトウェア、コアの更新、移行時の注意点

Clash for WindowsとClashX Metaは、当サイトのダウンロード一覧でメンテナンス終了と表示しています。明確な互換性要件がある場合に限り、情報を確認するためのアーカイブ版としてご利用ください。アーカイブ版クライアントには、新しいプロトコル項目、OSへの対応、セキュリティ修正が含まれない場合があります。古いガイドの画面に見慣れているという理由だけで、新規インストールの第一候補にしないでください。違いはアーカイブ版クライアントの説明で確認し、旧環境を維持するか移行するか判断できます。

クライアントの更新とコアの更新は別々に行う場合もあれば、クライアント側でまとめて管理する場合もあります。更新前にローカルルール、上書き設定、ポリシーグループ名、システム接続の設定を保存してください。更新後はサブスクリプションの解析、ルールの適用、DNS、よく使うアプリを確認します。クライアント、サブスクリプション形式、すべてのノードを一度に変えると、問題が起きたときに変更箇所を特定しにくくなります。

mihomoを直接起動する方法は、サーバー、ルーター、サービスを自分で管理するユーザーに適しています。プロセス権限、起動方法、ログ、設定ファイルのパスも管理する必要があります。デスクトップでは通常GUIを使うほうが便利です。コアを直接実行しても透過接続が自動で構成されるわけではなく、ルーティング、DNS、ファイアウォールの設計に代わるものでもありません。導入前に、どの端末のどの通信をコアに通すのか明確にしてください。

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

共有リンク、ノード一覧、完全な設定ファイルは別物

サブスクリプションは設定を取得する方法であり、統一されたファイル形式ではありません。リンクから返されるのは、エンコードされた共有リンクの一覧、完全なClash YAML、または別のクライアント向け設定の場合があります。共有リンクには通常、単一ノードの情報が記載されます。完全な設定にはポリシーグループ、ルール、DNS、待ち受けポートなども含まれます。インポート後にノード一覧が表示されても、元の振り分け設定まで保持されたとは限りません。ポリシーグループとルールも確認してください。

サブスクリプションの出力形式は、実際に使うクライアントに合わせて選んでください。従来のClash形式、mihomo拡張向けの形式、ほかのアプリ向け形式は、ひとまとめに互換とは言えません。形式変換で一般的な項目を処理できることはありますが、新しいプロトコル拡張、特殊な通信方式、プラグインのパラメーターが省略される場合があります。変換後はノードの種類と重要なパラメーターを確認し、「変換成功」を一連の接続が確認できた結果とみなさないでください。

サブスクリプションの応答内容は、リクエスト方法、アカウント状態、提供元の設定によって変わることがあります。更新後にノードが表示されなくなった場合は、YAMLの構文を疑う前に、Webページ、ログイン案内、エラー説明が返されていないか確認してください。元の設定をすぐ削除せず、利用可能なコピーを残しておくと変更内容を比較できます。トラブル相談の資料を共有する際は、認証情報を削除した構造とエラーだけを提示し、元のサブスクリプションURLは公開しないでください。

設定の階層で上書きと更新の動作が決まる

Clash形式の設定では、ノード、プロキシの一覧、ポリシーグループ、ルールがそれぞれ異なる役割を持ちます。プロキシの一覧から別のソースのノードを読み込み、ポリシーグループで出口を選び、ルールの順序に従ってリクエストを振り分けます。ルールが参照するグループ名は存在している必要があり、名称を変更すると起動失敗や振り分けの変更につながることがあります。サブスクリプションの更新で新しいノードが追加されても、手動で固定したポリシーグループに自動で追加されるとは限りません。

クライアントの上書き設定は、サブスクリプションを更新するたびにローカルの設定を作り直さずに済むように使います。ただし、統合時の動作は置換、追加、名称による統合などがあり、すべてのクライアントで同じとは限りません。特にルールを追加する位置を確認してください。最終的なフォールバックルールより後ろに置かれた項目は、通常適用されません。上書きの説明を読んだうえで、実際の実行時設定が想定どおりか確認してください。

以下は該当する設定箇所に追加できるルール例です。PROXYは、すでに存在するポリシーグループ名に合わせてください。ドメインルールの後にLAN・地域ルールを置き、最後にどのルールにも一致しない接続をフォールバックルールで処理します。ここではルールの順序だけを示しており、ノードや完全なDNS設定は含みません。地域ルールには対応するデータが必要です。実際の適用結果は、名前解決と接続履歴を確認してください。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - DOMAIN-KEYWORD,google,PROXY
  - GEOIP,LAN,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

移行時は構文を確認してから動作を検証

YAMLではインデントとデータ型に決まりがあり、インデントにはスペースを使います。パスワードや特殊文字、誤った型として解釈されやすい値は、元データの要件に従って正しく引用してください。コピー時に半角の記号を全角に置き換えないよう注意します。構文エラーが出た場合は、該当行付近のインデント、リスト記号、キーと値の関係を確認してください。未知の項目や未対応の種類が原因なら、すべてを形式エラーと決めつけず、コアの対応状況を確認します。

移行時は3段階で確認できます。まず設定を読み込めるか、次に特定のノードでアクセスできるか、最後に自動ポリシーと複雑なルールを戻します。基本ノードは使えるのにドメインへのアクセスに失敗する場合はDNSを確認してください。単独のノードは使えるのに自動グループが機能しない場合は、メンバーとヘルスチェック条件を確認します。システムプロキシは正常でTUNだけ失敗する場合は、端末側の接続方式と権限を確認してください。この順序なら、複数の要因が干渉しにくくなります。

サブスクリプションの更新間隔は、提供元の更新頻度に合わせてください。更新頻度が高すぎると提供元の制限に触れる可能性があり、スマートフォンのバックグラウンド動作も増えます。更新しない期間が長すぎると、使えなくなったノードや古い証明書パラメーターが残ることがあります。更新に失敗したら、まずURLとアカウントの状態を確認し、その後ネットワークと返却内容を調べてください。ルールデータとノードのサブスクリプションが異なる提供元から取得される場合は、それぞれの更新時刻と読み込みログを確認します。

8. 用途に合わせた選び方とトラブル対処の手順

デスクトップとモバイルでの選び方の基本

デスクトップで使う場合は、ブラウザー、開発ツール、会議アプリの通信経路を明確にすることを優先してください。Clash Plusなど適切なクライアントに完全なサブスクリプションを追加し、ルールモードでよく使う接続先にどのルールが適用されるか確認します。アプリが明示的なプロキシ設定に対応している場合は、まずシステムプロキシまたはアプリ内プロキシで検証してください。より多くのアプリを接続する必要がある場合にTUNを検討すると、権限、ルーティング、プロトコルの問題が一度に加わるのを防げます。

スマートフォンではダウンロードのピーク速度だけでなく、接続の復旧しやすさとバックグラウンドでの安定性を重視してください。信頼できる設定の既定通信方式を維持し、Wi-Fiとモバイル通信をそれぞれ試します。QUIC系ノードが特定のネットワークでだけ失敗する場合は、TCP系ノードを予備として残してください。電波が弱い環境では、帯域申告の値を大きくし続けるのではなく、先に電波状況を改善するか別のネットワークを試してください。再送や無線通信による電池消費は、それだけでは解決できません。

音声通話やゲームでは、アプリのUDP通信が実際にコアに取り込まれていることを確認し、ノードとサーバーの転送対応も調べてください。大きなファイルの速度ではなく、遅延の揺れ、パケットロス、セッションの継続性を重視します。一部のゲームでは、LAN内の機器検出、専用ポート、地域ごとのサービス設定も必要です。プロキシが扱える範囲を超える接続もあるため、Webページを1つ開けたことだけでゲームのネットワーク設定が完了したとは判断できません。

ルーター、サブゲートウェイ、多数の同時接続

ルーターでmihomoを使う場合は、まずハードウェアのアーキテクチャ、利用可能なメモリ、CPU性能を確認してから、プロトコルとルールの規模を選んでください。複雑な通信方式の組み合わせ、多数の同時接続、大きなルールデータはリソース負荷を高める可能性があります。家庭内のすべての端末が同時に遅くなった場合は、すべてのノードの品質低下と決めつけず、ルーターの負荷と接続状態を確認してください。

サブゲートウェイでは、ゲートウェイ、DNS、戻りの通信経路も明確にする必要があります。ある端末ではアクセスできるのに別の端末ではできない場合、プロキシプロトコルの互換性ではなく、接続方式の違いが原因かもしれません。すべての端末のプロトコルを変更するのではなく、まずデフォルトゲートウェイ、DNSの転送先、ルーティングルールを確認し、同じ接続先でテストしてください。配置の範囲はルーター・サブゲートウェイでmihomoを動かす概要を参照し、本ページのプロトコル選びとあわせてご覧ください。

エラーが起きた段階から順に原因を絞る

最初に読み込みを確認します。コアが起動しない、ノードが表示されない場合は、YAML、サブスクリプション形式、未知のプロトコル、項目への対応状況を確認してください。次にサーバーへの接続を確認します。アドレス解決に失敗する場合はDNS、接続拒否の場合はアドレスとポート、タイムアウトの場合は別のネットワークや通信方式と比較します。その次に安全なハンドシェイクと認証を確認し、証明書の名前、システム時刻、パスワード、UUID、拡張パラメーターを提供元の情報に沿って1つずつ照合してください。

4段階目に接続先へのアクセスを確認します。サーバーへの接続が確立した後も失敗する場合は、どのポリシーがルールに適用されたか、接続先のドメインがどう名前解決されたか、特定の種類のリクエストだけ失敗しているかを調べてください。Webページは正常でアプリだけ失敗する場合は接続方式を、ドメインでは失敗するのにIPアドレスならつながる場合はDNSを優先して確認します。証明書検証を常時無効にする、理由なくDIRECTルールを追加する、エラーが出た項目を削除するといった方法で根本原因を隠さないでください。

5段階目で性能を調整します。まず同じ条件のノードを変更し、次に通信方式を変え、最後に帯域申告、多重化、TUNの設定を1つずつ変更してください。何を変え、何が起きたかを記録し、元に戻す方法も残しておきます。問題を報告する場合は、OS、クライアント、コア名、エラーが起きた段階、機密情報を除いたログを提示してください。元のサブスクリプション、パスワード、設定ファイル全体を公開の添付ファイルに含めないでください。

最終的には、設定内容を把握でき、元に戻せて、安定して使える組み合わせを選びましょう。パラメーターの多さだけで選ぶ必要はありません。速度の問題を引き続き調べる場合は、ノード・回線・ローカル設定の3段階で原因を特定する方法に沿って確認してください。インストールや権限の問題はクイックスタートガイドに戻り、個別のエラーはよくある質問をご覧ください。原因の層をまたいでやみくもに変更するのは避けましょう。