負荷分散とフェイルオーバー：安定したプロキシグループの構築

プロキシグループと戦略の概要

Clashのproxy-groupsは、トラフィックが複数のノードまたはサブグループ間でどのように選択されるかを決定します。ルールマッチ後、あるプロキシグループ（PROXY・自動選択・フェイルオーバーなど）に向かい、グループ内の戦略が最終的に使用するノードを決定します。

手動選択のselect以外に、安定性と体験を大幅に向上させる3つの自動化戦略があります：

• url-test：定期的に速度テストを行い、最も遅延が低いノードを自動で選択します。
• fallback：順番通りに使用し、現在のノードが利用不可になると自動で次のノードに切り替えます。
• load-balance：接続を複数のノードに分散させて負荷を分担します。

これらの戦略を適切に組み合わせることで、「ノードを手動で切り替える」「単一ノード障害で接続が切れる」といったよくある悩みから解放され、プロキシ接続を速くて安定したものにして、日常的な使用をより安心にできます。

select：手動選択

selectは最も基本的なプロキシグループタイプで、ユーザーがクライアントまたはダッシュボードで手動にノードを選択します。「どの回線が最良かわかっている」シーンや、自動戦略の補完として適しています。例えば「自動選択」（url-test）と「手動選択」（select）を同時に設定し、普段は自動で必要な時は手動で介入するなどの使い方ができます。

プロバイダーのサブスクリプションでは通常、「ノード選択」「香港」「日本」などのselectグループが提供されており、地域や用途に応じた切り替えができるようになっています。

url-test：自動最適化選択

url-testはグループ内の各ノードに対して定期的にHTTPリクエストを送信し（デフォルト速度テストURL：http://www.gstatic.com/generate_204など）、遅延に基づいて最速のノードを選択して自動切替します。「常に最速のノードを使いたい、手動での速度テストはしたくない」ユーザーに適しています。

主要パラメータの説明：

• interval：速度テストの間隔（秒）。デフォルト300秒で、短すぎると頻繁な切替を招くため注意が必要です。
• tolerance：許容誤差（ミリ秒）。新しいノードが現在のノードよりこの値を超えて速い場合にのみ切り替わり、頻繁な切替を防ぎます。
• lazy：遅延ロード。トラフィックがある時だけ速度テストを行い、リソースを節約します。

fallback：フェイルオーバー

fallbackはproxiesリストの順序でノードを使用し、現在のノードの速度テストが失敗するか到達不可能になった場合にのみ次のノードに切り替えます。「明確なメインノードがあり、メインが落ちたらバックアップを使う」シーンに適しています。例えばメインが香港・バックアップが日本・予備が米国などの設定です。

url-testとの違い：fallbackはより速いノードへの積極的な切り替えは行わず、現在のノードが機能しなくなった時だけ切り替えます。そのため安定性が高く切替頻度が少ないです。遅延の変動に敏感で特定の回線を固定して使いたいユーザー（ライブ配信やリモートデスクトップ接続など）に適しています。

load-balance：負荷分散

load-balanceは異なる接続をグループ内の複数のノードに分散させて、単一ノードへの負荷を軽減し全体のスループットを向上させます。選択できる戦略：

• round-robin：ラウンドロビン。各ノードを順番に使用します。
• consistent-hashing：一貫性ハッシュ。同じ宛先（ドメイン+ポート）は常に同じノードを通り、セッション維持が必要なサイト（ログイン状態など）に対してより親切です。

負荷分散は複数ノード・高並列シーンに適しています。個人ユーザーの日常使用ではurl-testまたはfallbackで通常十分です。サブスクリプションのノード数が多い場合は、地域ごとにurl-testグループを作成して、その上位でさらに最適化する構造が複数ノードのメリットを最大限に活かせます。プロキシグループの構造を適切に設計することはClashの体験向上の鍵であり、初心者から熟練ユーザーへと成長するための重要なステップです。

プロキシグループのネスト

プロキシグループのproxiesにはノード名だけでなく、他のプロキシグループ名も指定でき、ネストが可能です。例えば：

各地域グループ内で最速のノードを選択し、さらに地域グループ間で最速を選ぶという構造で、整理されていてメンテナンスしやすいです。ネストの深さは多すぎないように注意してください。一般的には2〜3層で大多数のニーズを満たせます。深すぎるネストは速度テストのオーバーヘッドと理解のコストを増加させます。

パラメータ調整とトラブルシューティング

自動切替が頻繁すぎる場合は、toleranceまたはintervalを大きくしてください。ノードが頻繁に誤検知で切断判定される場合は、速度テストURLがアクセス可能か、ノードがブロックされていないか確認してください。特定のノードを固定して使いたい場合は、selectまたはfallbackを使い、そのノードを先頭に置いてください。速度テストURLにはレスポンスが速くトラフィックが少ないgenerate_204系の軽量インターフェースをお勧めします。ノードへの余分な負荷をかけません。

ClashダッシュボードのProxiesページで各グループの現在選択されているノードと遅延をリアルタイムで確認できるため、デバッグに役立ちます。プロバイダーのサブスクリプションを使用している場合、一部のサブスクリプションには最適化済みのプロキシグループが含まれており直接使用できます。設定を自分で書く場合は本記事の例を参考に段階的に調整してください。

典型的なユースケース

日常的なインターネット使用：ルールのPROXYをurl-testの「自動選択」に向けることで、速度と手間なしの運用を両立します。特定のノードを一時的に固定したい場合は、クライアントでselectグループに切り替えればOKです。多くのプロバイダーのサブスクリプションには既にこのような構造が組み込まれており、インポートしてそのまま使えます。

ライブ配信・ビデオ会議：遅延と安定性への要求が高いため、低遅延のノードを先頭に置いたfallbackの使用、またはselectで速度テスト最優の回線を固定することをお勧めします。url-testの自動切替が瞬間的な切断を引き起こすことを避けられます。

大容量ファイルのダウンロード：複数ノードへのload-balance、またはselectで帯域幅の大きい専用回線ノードを選択するのを試してみてください。一部のプロバイダーは単一接続の速度制限を設けているため、負荷分散でも単一回線の帯域幅上限を超えられない場合があることに注意してください。どのシーンでも、Clashダッシュボードでしばらく実際のパフォーマンスを観察してからinterval・toleranceなどのパラメータを調整することをお勧めします。過度な最適化が不安定さをもたらすことを避けるためです。

まとめ

url-test・fallback・load-balanceの3つの戦略はそれぞれ異なる特性を持ちます：速度を追求するならurl-test、安定性を追求するならfallback、負荷を分散させるならload-balanceです。tolerance・interval・lazyなどのパラメータで微調整し、selectによる手動介入とネストしたプロキシグループを組み合わせることで、速くて安定した途切れにくいプロキシ方案を構築できます。「自動選択 + 手動選択」の2グループ設定から始め、実際の体験に基づいて段階的に最適化していくことをお勧めします。プロキシグループ設定はClash上級者への重要なスキルであり、習得すれば他のプロバイダーに切り替えたり自分でノードを構築したりする際にも、すぐに使いやすい接続戦略を組み上げられます。各戦略の違いを理解するために少し時間を投資することは、長期的に見てノードを手動で切り替える時間を大幅に節約でき、インターネット体験もより快適でスムーズになります。