ノードが増えてくると、手動での切り替えが一番の手間になります。Clashが提供する3種類の自動プロキシグループ——url-test、fallback、load-balance——はそれぞれ異なる課題を解決し、うまく組み合わせればノード障害や遅延の変動を「意識せず」に済ませられます。
3種類の自動プロキシグループの概要
| 種類 | ノード選択ロジック | 適した場面 |
|---|---|---|
| url-test | 定期的に速度をテストし、常に最も遅延の低いノードを使用 | 最適な速度を求め、時々の切り替えを許容できる場合 |
| fallback | 順番に使用し、現在のノードが失効したら次に切り替え | 明確な「主・副」の優先順位が必要な場合 |
| load-balance | アルゴリズムで異なるリクエストを複数ノードに分散 | 複数ノードで負荷を分担し、単一ノードの過負荷を避けたい場合 |
url-test：最速のノードを自動で選ぶ
最もよく使われるグループタイプです。Clashはグループ内の全ノードに対して定期的に速度テストを行い、常に最も遅延の低いノードを使用します。
tolerance（許容誤差、単位ミリ秒）は、数ミリ秒の測定ブレによる頻繁な切り替えを防ぎます。新しいノードの遅延が「現在の遅延 − tolerance」より低くなったときだけ、実際に切り替わります。
fallback：明確な主・副の順序
「主力ノード」があり、それが失効したときだけ予備ノードに切り替えたい場合は、fallback がより適しています。proxies リストの順序でチェックし、常にリストの前方にある使用可能なノードを優先します。
load-balance：負荷を分散する
複数のノードの品質が近く、接続の負荷を分担させたい場合は load-balance を使用できます。2種類の分配アルゴリズムに対応しています。
- consistent-hashing：同じ宛先アドレスは常に同じノードに割り当てられ、セッション維持が必要な場面に向いています。
- round-robin：順番に接続を割り当てるため分散はより均等ですが、同じ宛先アドレスが異なるノードに割り当てられる可能性があります。
ヘルスチェックのパラメータをどう調整するか
url、interval、tolerance の3つのフィールドが、グループの「どのくらいの頻度で検査するか」「どのくらいの差があれば切り替えるか」を決めます。攻めすぎても守りすぎても問題が生じます。
| フィールド | 役割 | 調整の目安 |
|---|---|---|
| url | 速度テストの送信先アドレス | 軽量で安定した検査先アドレスを使い、大きなファイルや変動の多いサイトは避ける |
| interval | 2回の速度テストの間隔（秒） | 短すぎるとノード側の負荷が増えるため、300秒前後がバランスが良い |
| tolerance | 切り替えに必要な最小遅延差（ミリ秒） | ネットワーク自体のブレが大きい場合は少し高めに設定し、数ミリ秒差での頻繁な切り替えを避ける |
tolerance の設定が小さすぎないか確認してください。すぐにノード品質を疑う前に確認すべき点です。
プロキシグループは入れ子にできるか
できます。プロキシグループの proxies フィールドには具体的なノード名だけでなく、別のプロキシグループの名前も指定できます。これにより「まず地域別に自動速度テストのグループを作り、次にどの地域を使うか手動で選ぶ」といった階層構造を組み立てられます。ただし、入れ子の階層はあまり深くしないほうがよいでしょう。1段増えるごとに、実際に有効になるロジックの判断も1段増え、問題が起きたときの調査がより煩雑になります。一般的には2〜3層で大半のユースケースをカバーできます。
実践：複数リージョンのノードプールの組み方
よくある多層構造は、まず地域ごとに複数の url-test サブグループ（「香港自動」「シンガポール自動」など）を作り、その上に1つの select 手動グループを置いて、最終的な選択権を自分に残す方法です。自動化と柔軟性の両方を兼ね備えられます。
異なるルールを異なるプロキシグループにマッチさせる
プロキシグループの本当の力は rules と組み合わせてこそ発揮されます。異なる種類の通信を、すべて同じ「なんでも屋」のプロキシグループに詰め込むのではなく、それぞれ別のグループにルーティングできます。例えば、動画配信系のドメインは解除効果の良いノードだけを含む専用グループに、ゲーム系のドメインは低遅延優先の url-test グループに、その他は汎用の自動選択グループにルーティングする、といった形です。こうすることで、それぞれの通信種別に最も適したノード選択ロジックが割り当てられ、1つの基準で全場面をこなす必要がなくなります。
プロキシグループを分けるべきかどうかの判断基準
すべての場面で細かく分ける必要はありません。判断基準はシンプルです。ある種類の通信が「ノード選択ロジック」に明確に異なる好みを持つ場合（ゲームは遅延に極めて敏感、動画配信は解除リージョンに厳格な要求がある、など）は専用のプロキシグループを切り出す価値があります。一方、普通のウェブ閲覧であれば汎用の自動選択グループで十分で、「専門的に見せる」ために過度に分割する必要はありません。それはむしろ後々のメンテナンスやトラブルシューティングの複雑さを増すだけです。
ノードを切り替えた後、既存の接続に影響がないのはなぜか
手動あるいは自動でグループ内のノードを切り替えた後、すでに確立されている接続（ダウンロード中のファイル、再生中の動画など）はすぐに新しいノードに切り替わらず、その接続が自然に終了してから、次に新しく確立される接続だけが新しいノードを使うことに気づくかもしれません。これは想定通りの設計です。プロキシ層のノード切り替えは「新規接続」に対して働き、すでに確立されたセッションは中断しません。これにより、ノードを頻繁に切り替えても進行中のダウンロードや通話が中断されることを避けられます。すべての接続をすぐに切り替えたい場合は、パネルのConnectionsで古い接続を手動で切断し、新しいリクエストを再発行させることができます。
まとめ
どのプロキシグループも「万能」ではありません。速度を求めるなら url-test、明確な主・副の順序が必要なら fallback、負荷を分散したいなら load-balance。実際の運用では、これらを入れ子で組み合わせ、最後に手動の select グループで受け止めるのが、自動化と制御性のバランスを取る最善のやり方であることが多いです。