購読だけでは「自動で最速」にならない理由

多くのテンプレートでは、プロキシ一覧は proxies: に展開されますが、実際にブラウザやアプリのトラフィックが「どのノード集合から一つを選ぶか」は、proxy-groups: のエントリ名で決まります。rules: の右側に書くのが Proxy や ♻️ 自動選択 のようなグループ名であり、そのグループの type: が selector のままだと、遅延測定による自動切替は基本的に起きません（手動または UI の選択が効きます）。

また、url-test や fallback は「HTTP(S) の小さなリクエストで応答時間を見る」ヘルスチェックに依存します。測定先 URL がブロックされる・タイムアウトしやすい・サブスク側の名前と proxies リストの参照がズレている、といった条件だと、画面上はノードが並んでいても選別結果が常に同じに見えたり、すぐ別ノードへフラップしたりします。

ルールの書き方自体は ルール分流のベストプラクティス とセットで効いてきます。分流の順序と DNS の話を押さえたうえで、本稿のポリシーグループを足すと「ルールで送り先を決め、グループ型でその中から最適なノードを選ぶ」という二段構えが完成します。

ポリシーグループの型：selector／url-test／fallback／load-balance

Mihomo／Clash Meta 系でよく使う型は次のとおりです（実装差はありますが、概念は共通です）。迷ったら「手動で選びたいか」「遅延で勝ちを取りたいか」「主備で耐障害したいか」で型を決めると早いです。

type ふるまいの要約 向いている用途
selector 子要素のうち一つを（多くは UI か設定で）明示選択 国別・用途別に手で切り替えたいとき
url-test 定期的に url へ HEAD/GET し、最も遅延の小さい alive な候補を選ぶ 「とにかく今速いノードへ」自動寄せ
fallback リストの上から順に死活を見て、最初に生きているものを採用 メイン／サブ／最後の直結など主備
load-balance アルゴリズムに従い複数ノードへ分散（同一ホスト sticky などオプション） 帯域を複数出口でならしたいとき
ℹ 用語の整理：rules: の右辺に書けるのは「ビルトインの DIRECT／REJECT」か「proxy-groups の name」か「proxies にある単一プロキシ名」です。テンプレによっては最終行が MATCH,Proxy のように別名のグループを指しているので、自分の YAML 上の名前と一致しているか必ず確認してください。

url-test の実装手順（url・interval・tolerance・lazy）

手順 1：候補ノードを proxies: 列挙にそろえる

url-test の proxies: 配列に書く文字列は、proxies: セクションで定義した各プロキシの nameと一致させます。購読プロバイダが生成する名前が長い場合でも、そのままコピーするのが安全です。ここが一文字でも違うと、その候補は無視されたりエラーになったりします。

手順 2：type: url-test と測定・周期を書く

最低限そろえるキーは url（測定先）、interval（秒）、しばしば tolerance（ミリ秒）です。tolerance は「現行ノードからこれ以上速くなければ乗り換えない」ためのヒステリシスで、ちらつき抑制に効きます。lazy: を true にすると「そのグループを実際に使うまで積極的に測らない」挙動になり、バックグラウンドのテスト回数を減らせることがあります。

proxy-groups: url-test (example — adjust names and URLs) 
proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - "Node-A"
      - "Node-B"
      - "Node-C"
    url: "https://cp.cloudflare.com/generate_204"
    interval: 300
    tolerance: 50
    lazy: false

手順 3：rules: 側で AUTO-BEST を指す

例として海外向けドメインをまとめて送りたいなら、- DOMAIN-SUFFIX,example.com,AUTO-BEST のようにグループ名を右辺に置きます。最終行はしばしば - MATCH,AUTO-BEST または用途別の別グループになります。国内ドメインを直結させたい場合は - GEOIP,JP,DIRECT のように DIRECT を明示し、それより上に広い MATCH を置かないようにします（順序の詳細は前述の分流ガイド参照）。

⚠ 注意：url-test は「HTTP で測定できること」と「実トラフィックの遅延・損失が一致する」ことを保証しません。ゲーム UDP や長時間 TCP だけが重いケースでは、別途 fallback や用途別グループを分けるほうが現実的です。

fallback の実装手順（並び順が仕様）

fallback はリストの先頭が最優先です。優秀なメインノードを上に、帯域の広い予備をその下に、最後に DIRECT や安価な出口を置く、といった優先度設計がそのまま障害時の挙動になります。測定のキーは url-test と同様に url と interval を使います（実装により省略可能な場合もありますが、明示しておくと期待が読みやすいです）。

proxy-groups: fallback (example) 
proxy-groups:
  - name: "PRIMARY-THEN-SPARE"
    type: fallback
    proxies:
      - "Paid-Primary"
      - "Paid-Backup"
      - "DIRECT"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

ここで DIRECT を候補に入れている点がポイントです。fallback の子は「プロキシ名」だけでなく、ビルトインの DIRECT／REJECT を並べられるため、プロキシがすべて死んだら国内直結に落とすといった逃げ道を同じグループ内で表現できます。広告ドメインを落としたいルールでは、右辺を REJECT にするか、REJECT だけを含む小さな selector を用意する、が定石です（REJECT はルール側に直接書くことが多いです）。

測定 URL の選び方とよくある失敗

代表的な測定先として、小さな応答を返す generate_204 系 URL がよく使われます。自前で置く場合は応答が軽いこと、プロバイダや国によってブロックされにくいこと、HTTPS で TLS まで通ること（証明書検証の挙動と整合すること）を確認してください。

rules から DIRECT／REJECT／グループへ渡す

ルールエンジンは上から順に最初の一致で停止します。したがって DIRECT にしたいローカル帯域や社内ドメインは、広い MATCH や海外向けグループより必ず上に置きます。REJECT も同様で、広告・トラッキング用のドメインを早い段階で落とすと、下流のプロキシ負荷も減ります。

rules excerpt (conceptual) 
rules:
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - DOMAIN-SUFFIX,ads.example,REJECT
  - DOMAIN-SUFFIX,cdn.example.com,PRIMARY-THEN-SPARE
  - GEOIP,JP,DIRECT
  - MATCH,AUTO-BEST

この例では、国内向けは GEOIP,JP,DIRECT で直結し、それ以外の「残り全部」は AUTO-BEST（url-test グループ）へ送られます。特定の CDN だけ主備にしたい場合は PRIMARY-THEN-SPARE を挟む、というようにルールで送り先グループを分岐させます。分流と型の組み合わせが多いほど、GUI での見通しが難しくなるため、命名規則を揃えると長期運用が楽です。

ロードバランス（load-balance）の位置づけ

ロードバランスは「最速一択」ではなく、複数ノードへトラフィックを分散する用途です。同一サイトへの接続を一定期間同じノードに粘らせたい（consistent-hashing など）場合に効きますが、サブスクの規約やターゲットサービスの利用規約との整合は利用者側で確認してください。url-test や fallback と目的が異なるため、「遅延で一番速い一筋にしたい」ならロードバランスは第一選択になりません。

切り分け：名前・DNS・二重プロキシ

設定を入れても挙動が変わらないときは、次の順で確認すると早いです。（1）proxy-groups[*].proxies の各文字列が proxies: の name と一致するか。（2）rules の右辺が、意図したグループ名を指しているか。（3）クライアントのダッシュボードで、該当グループに遅延数値が付いているか（付かない＝測定が回っていないか候補が死んでいる）。（4）DNS が fake-ip のとき、ルールが期待通りドメイン段階でマッチしているか——は よくある質問 の DNS まわりとも照応します。

さらに踏み込む機能や構文差を吸収したい場合は、カーネルを Clash Meta（Mihomo）へのアップグレード を検討する価値があります。コアのソースや変更点を追うときは GitHub も有用ですが、クライアントの入手と更新はサイトの ダウンロードページ を主にすると、配布物とドキュメントの対応が取りやすいです。

まとめ

Clash ポリシーグループのうち、url-test は測定 URL と interval、tolerance、lazy をそろえて初めて「自動で最速寄り」の挙動が安定しやすくなります。fallback は並べ順がそのまま優先度であり、DIRECT を末尾に置くとプロキシ全滅時の逃げ道を同じグループで表現できます。rules では DIRECT と REJECT をビルトインとして明示し、それ以外をグループ名で橋渡しする——この対応関係が噛み合えば、購読後の「手動選びっぱなし」から脱しやすくなります。ロードバランスは帯域分散用と割り切り、遅延最適化とは使い分けるのがおすすめです。

同じ設定でも GUI の表示やログの見え方はクライアントによって差があります。ポリシー名と測定結果を同じ画面で追いやすいクライアントを選ぶと、今回のような調整ははるかに楽になります。一般的な VPN ツールに比べ、ルールとグループを分けて持てる点が Clash 系の強みです。

→ Clash を無料ダウンロードし、url-test／fallback と接続ログを同じ操作導線で扱えるクライアントから、自動ノード選択と主備切替の検証を始めましょう。