ノードの数がいくら多くても、スケジューリングがうまくできなければ意味がありません。混雑する時間帯にいちいち手動でノードを切り替えたり、深夜に放置している間にノードが落ちても誰も気づかなかったり……この記事では3種類の自動化されたプロキシグループを使って、スケジューリングをすべてClashクライアントに任せる方法を紹介します。目指すのは速いときはより速く、落ちたときは気づかせないことです。
3種類の自動プロキシグループのおさらい
| 種類 | スケジューリングの考え方 | 最適なシーン |
|---|---|---|
url-test | 定期的に全ノードの速度を測定し、常に最速のノードを使う | 日常的なブラウジング、低遅延を重視する場合 |
fallback | リストの順に生存確認を行い、最初に生きているノードを使う | 主系・副系の優先順位が明確なシーン |
load-balance | 異なる接続を複数のノードに分散させる | マルチスレッドダウンロード、単一ノードの帯域制限回避 |
url-test：toleranceでチャタリングを防ぐ
デフォルト設定のurl-testには厄介な問題があります。2つのノードの遅延が近いと切り替えが頻発してしまい、切り替えのたびに進行中の接続が切れてしまう可能性があります。解決策はtoleranceを設定することです。
proxy-groups: - name: "自動速度テスト" type: url-test proxies: [香港 01, 香港 02, 東京 01, シンガポール 01] url: "http://www.gstatic.com/generate_204" interval: 300 tolerance: 50 # switch only if 50ms+ faster than current
意味は「新しいノードが現在のノードより50ms以上速くなければ切り替えない」ということです。数値は必要に応じて調整し、大きくするほど安定志向、小さくするほど積極的な切り替えになります。
fallback：主系・副系構成の正しい使い方
高品質な専用回線と数本の一般的な回線を持っている場合、fallbackが最適です。通常時は専用回線を常に使い、専用回線に障害が起きると自動的に格下げされ、復旧すれば自動的に元に戻ります。
proxy-groups: - name: "主系・副系切り替え" type: fallback proxies: [香港-専用回線, 香港-一般01, アメリカ-バックアップ] # priority order url: "http://www.gstatic.com/generate_204" interval: 120 # check more often for faster failover
ここで注意したいのは、proxiesの並び順がそのまま優先順位になるという点です。検知間隔はurl-testより短めに設定しておくと、フェイルオーバーが十分に速くなります。
load-balance：2種類の振り分け方式
proxy-groups: - name: "ロードバランス" type: load-balance proxies: [香港 01, 香港 02, 香港 03] url: "http://www.gstatic.com/generate_204" interval: 300 strategy: consistent-hashing # or: round-robin
- consistent-hashing：同じ宛先サイトへの通信は常に同じノードに固定されるため、ログイン状態が乱れません。通常はこちらを推奨します。
- round-robin：接続を各ノードへ順番に割り振ります。マルチスレッドダウンロードの速度向上には効果的ですが、一部のサイトではIPの変化により再ログインを求められることがあります。
組み合わせ技：ネストで「速くて安定した」体系をつくる
プロキシグループは他のプロキシグループを参照できます。次の3階層構成はコミュニティでも評判の良い方法です。
proxy-groups: # Layer 1: user-facing switch - name: "ノード選択" type: select proxies: [自動スケジューリング, 香港専用回線, 手動選択] # Layer 2: auto scheduling with failover - name: "自動スケジューリング" type: fallback proxies: [低遅延グループ, ロードバランスグループ] url: "http://www.gstatic.com/generate_204" interval: 120 # Layer 3: workers - name: "低遅延グループ" type: url-test proxies: [香港 01, 香港 02, 東京 01] url: "http://www.gstatic.com/generate_204" interval: 300 tolerance: 50 - name: "ロードバランスグループ" type: load-balance proxies: [シンガポール 01, シンガポール 02, アメリカ 01] url: "http://www.gstatic.com/generate_204" interval: 300 strategy: consistent-hashing
普段の通信は「低遅延グループ」で自動速度テストされたノードを使い、グループ全体が利用できなくなるとfallbackによって自動的に「ロードバランスグループ」に切り替わります。手動で切り替えたい場合は「ノード選択」でワンクリックで変更できます。3つの階層がそれぞれの役割を担う構成です。
結局どれを選ぶべきか：一言でまとめると
細かいパラメータの話を読んでも判断に迷う場合は、こう考えてみましょう。どのノードでもいいから、とにかく最速がいい→url-test。主系・副系の優先順位がはっきりしている→fallback。帯域を極限まで使い切りたく、時々の再ログインも気にしない→load-balance。ほとんどの人は日常使いであればurl-testグループ1つで十分で、fallbackとload-balanceは「はっきりした要望が出てきたとき」に追加する上級者向けの選択肢です。最初から複雑な構成を目指す必要はありません。
プロキシグループが機能していないときの調査方向
設定したのにスケジューリングが機能していないように見える場合は、次の順で確認しましょう。
- rulesがそのグループを本当に参照しているか確認する：プロキシグループを定義しただけでは使われません。何らかのルール（または最終的な
MATCH）がそのグループを指していなければ機能しません。これは最も見落とされやすいポイントです。 - コントロールパネルのプロキシページでグループ内のノードの状態を確認する：グループ内のノードがすべてタイムアウトまたはオフラインになっていれば、url-test/load-balanceが「機能していないように見える」のは当然で、実際には選べるノードがない状態です。
urlの速度テスト先が到達可能かを確認する：デフォルトのgenerate_204アドレスは、一部のネットワーク環境ではブロックされていることがあり、その場合すべての測定がタイムアウトになります。別の同種の検証用アドレスに変えて試してみましょう。- fallbackの
intervalが長すぎないか確認する：検知間隔を600秒以上に設定していると、ノード障害の検知と切り替えに時間がかかり、体感的には「機能していない」ように感じられます。
スケジューリングに一発で正解となる設定はありません。まずは最もシンプルな単層のurl-testグループでしばらく運用し、実際に困った点を観察してから、必要に応じてfallbackやload-balanceを重ねていく方が、最初から3階層構成を組むよりも維持しやすくなります。
多層ネスト構成に時間をかける価値があるのはどんなときか
この記事の前半で紹介した3階層構成は、すべての人に必要なものではありません。複雑なスケジューリングを組む前に、次の点を自問してみましょう。自宅やオフィスに品質の異なる複数の回線があり、主系・副系を分ける必要があるか。マルチスレッドダウンロードを頻繁に行い、単一ノードの帯域では明らかに不足しているか。「ノードが突然落ちたのに誰も気づかなかった」という経験がすでにあるか。これらの答えの多くが「ない」であれば、シンプルなurl-testグループだけで十分で、「見た目が本格的」という理由だけで設定を積み重ねる必要はありません。逆に、家族やチーム全体のネットワーク出口を提供している場合は、多層スケジューリングによる安定性の向上は実質的なメリットとなり、時間をかけて調整する価値があります。
もう一つ、プロキシグループの名前はできるだけ直感的に付けましょう（例えば「香港専用回線」「ロードバランス-シンガポール」など）。半年後に自分で設定ファイルを開いたときも、なぜこの設計にしたのかが一目でわかり、select/fallback/url-testが並ぶ中で頭を抱えることもなくなります。
まとめ
3種類のプロキシグループはそれぞれ役割が異なります。url-testは「常に最速」を追求し、ほとんどの日常的なシーンに適しています。fallbackは「主系・副系の明確な区別」を追求し、回線の優先順位がはっきりしているユーザーに適しています。load-balanceは「帯域を使い切る」ことを追求し、マルチスレッドダウンロードや単一ノードの帯域制限を避けたいシーンに適しています。toleranceとintervalという2つのパラメータを軽視してはいけません。正しく調整すれば、原因不明の「ノードのチャタリング」や「切り替えが遅い」といった悩みをかなり減らせます。まずはシンプルなurl-testグループから始め、本当に必要になったタイミングで機能を積み重ねていく方が、最初から複雑な構成を組むよりも、多くの人の実際の使い方に合っています。