本稿のゴールと前提
ここでは proxies: に購読由来のノードが並んでいる前提で、その上に載るポリシーグループだけをいじります。ドメインごとの命中順や国情報の切り方は GEOIP／GEOSITE 分流ガイド に譲り、「どのプロキシ名を選ぶか」を自動化する層に絞ります。GUI クライアントによっては項目名が日本語化されていても、保存されるのは同じ YAML なので、名前の整合とコアの読み込みログを軸に進めると安全です。
url-test と fallback の気持ちの違い
url-test は、リストに載せた候補それぞれに対して定期的に url へ到達性とレイテンシを測り、一定ルールのもとで「いまいちばん良さそうな」ノードを選び直すタイプです。体感としては「自動選択」「最速」に近い運用になりがちです。一方 fallback は、先頭から順に「生きているか」を見て、最初に通ったものを使い続けるイメージが近く、主用・予備用を並べたフェイルオーバー向きです。どちらも url で軽い HTTP リクエストを飛ばすヘルスチェックを伴いますが、切り替えの哲学が違うので、用途に合わせて型を選ぶのがポイントです。
整理：select は手動（または外部コントローラ）で選び、url-test／fallback はコアが測定結果に応じて選択状態を更新します。ルールの PROXY 行が最終的に指しているグループ名が、これらの自動グループになっている必要があります。
ヘルスチェックまわりの主なキー
代表的なのは次のとおりです（利用中の Mihomo バージョンで廃止・追加がないか、リリースノートも併せて確認してください）。url はチェック用の小さな応答が返る URI を置くのが一般的で、環境によっては自前の 204 エンドポイントに差し替えます。interval は測定の周期（秒）で、短すぎると購読側やノード側に負荷が寄り、長すぎると切替が鈍く感じられます。tolerance は url-test で「現状維持してよい揺らぎ」を表すことが多く、新しい候補が現行よりどれだけ良くないと乗り換えないか、といった遅延閾値のニュアンスで理解すると運用しやすいです。
追加で lazy: true を付ける例も見かけます。これは実際にそのグループが選ばれたあとで測定を始める方向の挙動を期待する設定で、起動直後のプローブ嵐を抑えたいときに検討します。ただし初回接続までの挙動が変わるので、ログで意図どおりかを一度確認してください。
パターンA：測って最速を選ぶ（url-test）
たとえば「海外出口は常に速い方へ」という方針なら、候補ノード名を並べた url-test グループを一つ用意し、ルール側の PROXY 相当がそのグループ名を指すようにします。YAML の骨子は次のようなイメージです（名前は環境に合わせて差し替え）。
# Sketch — replace proxy names; align keys with your Mihomo version
proxy-groups:
- name: AUTO-BEST
type: url-test
proxies:
- NODE-A
- NODE-B
- NODE-C
url: http://www.gstatic.com/generate_204
interval: 300
tolerance: 50
運用上は、同じ地域・同じ用途の候補だけを並べると挙動が読みやすいです。国やプロトコルがバラバラだと、「速いが意図しない地域に飛ぶ」ことがあります。tolerance を狭めると乗り換えが敏感になり、広げると現状維持バイアスが強くなります。夜間だけ混むノードがある場合は、interval とセットで様子を見るのがよいでしょう。
パターンB：主備で落ちたら次へ（fallback）
「普段はこの1本、ダメなら予備」という主備構成なら fallback が素直です。proxies: の先頭が主用で、その次に予備を並べます。ヘルスチェックで主用が不通と判断されると、リストを下方向にスライドするイメージで別ノードへ移ります。
# Sketch — primary first, backups follow
proxy-groups:
- name: AUTO-FAILOVER
type: fallback
proxies:
- PRIMARY-LINE
- BACKUP-LINE-1
- BACKUP-LINE-2
url: http://www.gstatic.com/generate_204
interval: 300
購読更新でノード名が変わると、ここで参照している文字列が静かにズレるのが典型トラブルです。GUI 上の表示と YAML の実名が一致しているか、更新直後に必ず確認してください。購読まわりの切り分けは 購読更新の 403／タイムアウト稿 も参考になります。
ルールとつなぐときの注意
自動グループを書いても、MATCH より上の行で別ポリシーに落ちていると、想定どおりに使われません。例えば GEOIP,CN,DIRECT のような行が先に当たると、国内向けトラフィックはそちらへ流れ、自動グループは関係しません。国情報ルールの評価順や no-resolve の扱いは GEOIP 稿 を参照してください。また HTTPS が IP 表示のままだとドメインルールに乗らず、意図しないポリシーへ寄ることがあります。必要に応じて Sniffer や DNS の整合を Sniffer 稿、DNS リーク防止稿 で揃えます。
効いているかの確認手順
- コアの読み込み：YAML 文法エラーや、存在しないプロキシ名を参照していないか。
- GUI の現在選択：手動
selectが別のノードを指して上書きしていないか。 - 接続ログ：対象アプリのフローが、想定のグループ名を経由しているか。
- 遅延表示の更新：ヘルスチェック周期後に数値が動くか（クライアントの表示更新タイミングも含む）。
- 意図的な劣化テスト：主用を一時的に落として
fallbackが予備へ移るか、あるいはurl-testが別候補へ寄るか。
外部ダッシュボード（例：yacd 系）を使う場合は、External Controller の権限とバインド先に注意してください。社内ネットワークでは露出範囲を絞るのが無難です。ダッシュボード全般は External Controller と yacd の稿 も参照できます。
relay チェーンとの関係
二段の出口を relay で固定したい場合は、自動選択グループとは別の話です。relay チェーンの稿 のとおり、type: relay は順路の積み上げであり、url-test で「速い方へ」という最適化とは目的が異なります。運用では、入口の自動選択と出口のチェーンをどちらのレイヤーで表現するかを分けて設計すると混乱が減ります。
よくある詰まり
- チェック URL 自体が不安定：特定ドメインだけ遅いと、全ノードが不利に見える。
- interval が短すぎて BAN やレート制限：プロバイダ規約と合わせて調整する。
toleranceが広すぎて乗り換わらない：体感では「壊れているのに変わらない」に見える。- ルールが別の
selectを指している：自動グループに到達する前に決着している。
注意：ヘルスチェックは小さなトラフィックを継続的に発生させます。利用規約・職場方針・ノード提供者のポリシーに反しない範囲で間隔と URL を選んでください。
ドキュメントと入手先
細かな追加キーや既定値は、利用中の Mihomo 版の公式ドキュメントを最終判断にしてください。日々のクライアント入手は 公式ダウンロードページ を第一にし、用語の整理は ドキュメント・チュートリアル も活用できます。ソースや Issue は GitHub で追えますが、インストーラの主たる入手経路はサイト側と混同しないようにすると安全です。
まとめ
Clash Meta／Mihomo でノードの自動切替を実現するには、proxy-groups に url-test か fallback を置き、ヘルスチェック用の url と interval、必要に応じて tolerance による遅延閾値を調整します。速さ最優先なら前者、主備の切替なら後者、という対比で最初の一歩を踏み出せます。そのうえで、ルール命中とDNSを同じ作業セッションで揃えないと、設定は正しくても見かけだけ不調に見える、という落とし穴があります。ログと YAML を突き合わせながら一段ずつ確認するのが、2026年現在もっとも確実な検証です。
同じエコシステムのクライアントでも、編集画面の見え方は様々ですが、名前と順序が意図どおりかという一点は共通のチェックポイントです。他ツールに比べ、ルールとポリシーの見通しが立てやすいのが Clash の強みなので、その強みを活かして運用に落とし込んでください。
→ Clash を無料ダウンロードし、url-test／fallback を含む Mihomo プロファイルを快適に試す