ロードバランシングとフェイルオーバー：複数ノードで安定した接続を作る
1つのノードだけに頼っていると、いつか速度制限や不調、あるいは完全な切断に遭遇します。fallback と load-balance という2種類のプロキシグループタイプは、まさに「あるノードに問題が起きる」ことが「ネットワーク全体の問題」にならないようにするためのものです。この記事ではそれぞれの判定ロジック、設定方法、そして複数の戦略を階層的に組み合わせて本当に安定して使える構成を作る方法を解説します。
単一ノードでは対応しきれない理由
ノードは常に一定ではありません。「プロバイダーが一時的にメンテナンス中」「上流回線が不安定」「同時接続数が多すぎて速度制限がかかる」——こうした状況ではノード自体がダウンしていなくても、実際の体験は明らかに悪化します。
プロキシグループが手動の select モードの場合、ノードに問題が起きたことに自分で気づいて手動で切り替えるしかなく、その間のすべての接続が引っかかったりタイムアウトしたりします。fallback と load-balance はそれぞれ「障害時の切り替え」と「負荷の分散」という異なる角度からこの問題を解決するもので、両方を同時に使い、異なるシナリオをカバーすることもできます。
fallback フェイルオーバーの判定ロジック
fallback グループは設定した順序で先頭のノードを継続的にヘルスチェックし、現在使用しているノードが「不健全」と判定された時点で、順序内の次のノードに切り替えます：
proxy-groups:
- name: フェイルオーバー
type: fallback
proxies: [メイン, バックアップA, バックアップB]
url: "https://www.gstatic.com/generate_204"
interval: 300
max-failed-times: 3重要なフィールド：
url：ヘルスチェック要求の宛先です。容量が小さく、世界的にアクセスしやすいテストエンドポイントを使い、チェック自体が過剰なトラフィックを消費したり、そのURL自体が制限されて誤判定を起こしたりしないようにします。interval：ヘルスチェックの周期（秒）です。短すぎると不要な検査トラフィックが増え、長すぎると障害からの復旧が遅れます。300秒が比較的よく使われる妥協点です。max-failed-times：何回連続で失敗したら「不健全」と判定するかを決めます。1回の偶発的なタイムアウトで誤って切り替わらないようにするためです。
fallback は「現在のノードが不健全」な場合のみ切り替えます。バックアップノードのレイテンシがより低くても、メインノードのヘルスチェックが正常な限り自発的に切り替わることはありません——これが url-test との最大の動作上の違いであり、「メインの回線」を固定しておき、他のノードは緊急時の予備として使いたい場合に向いています。
load-balance の2つの分散戦略
load-balance は「最良のものを選ぶ」わけではなく、異なる接続をグループ内の複数ノードに能動的に分散させます。具体的な分散方法は strategy フィールドで決まります：
consistent-hashing（一致性ハッシュ）
- 接続元アドレスに基づいてハッシュを計算し、同じ発信元はほぼ同じノードに固定される
- 「セッションの継続性」が必要な場面に向いており、接続が切り替わることに敏感なサイト/ゲームなどに適する
- あるノードが除外されても、そのノードにマッピングされていた一部の接続だけが影響を受け、全体が再割り当てされることはない
round-robin（ラウンドロビン）
- 新しい接続をグループ内のノードに順番に割り当てるため、分散がより均等になる
- 同じ発信元が常に同じノードに落ち着くとは限らず、「セッションの切り替わり」が発生する可能性がある
- 短時間で独立した接続が多く、セッションの継続性を求めない場面に向いている
proxy-groups:
- name: ロードバランス
type: load-balance
strategy: consistent-hashing
proxies: [ノードA, ノードB, ノードC]
url: "https://www.gstatic.com/generate_204"
interval: 300特別な理由がなければ、consistent-hashing のほうが接続の安定性への影響が小さいため、通常はより安全なデフォルトの選択と言えます。
実践：階層的に組み合わせて安定した設定を作る
3つの戦略は互いに排他的ではなく、実際の設定でよく使われるのは階層的にネストする方法です——外側の層に select を置いて自分用の手動マスタースイッチとし、中間層に url-test や load-balance で自動スケジューリングを行い、極端な状況に備えて fallback を最後の保険として使います：
proxy-groups:
- name: PROXY
type: select
proxies: [自動スケジューリング, 手動指定]
- name: 自動スケジューリング
type: fallback
proxies: [高速プール, バックアップ回線]
url: "https://www.gstatic.com/generate_204"
interval: 300
- name: 高速プール
type: load-balance
strategy: consistent-hashing
proxies: [ノードA, ノードB, ノードC]
url: "https://www.gstatic.com/generate_204"
interval: 300この設定の効果は次の通りです：通常時は「高速プール」が接続を3つのノードに分散させ、この層全体に異常（例えば所属するデータセンターの障害）が起きると、最外層の fallback が自動的に「バックアップ回線」に切り替わります。そして PROXY の層では常に手動での介入手段が残されています。
よくある間違い
- ヘルスチェックのURLをアクセス頻度の低い普通のサイトに設定する：この種のサイトは応答時間の変動が大きく、正常なノードを「不健全」と誤判定しやすくなります。必ず軽量で安定したテストエンドポイントを使ってください。
- load-balance内で速度差の大きいノードを混在させる：ラウンドロビンやハッシュによる分散はノードの速度を考慮しないため、混在させると接続ごとに体験が良くなったり悪くなったりします。同じload-balanceグループ内のノードはできるだけ品質を近づけてください。
- intervalを短く設定しすぎる：頻繁なヘルスチェックはノード側のリソースと自分のトラフィックの両方を消費します。ほとんどの場面で300秒より短くする必要はありません。
設定後に切り替えの動作が想定と異なる場合は、応用設定ガイドのプロキシグループの章と照らし合わせて各フィールドの意味を再確認するか、Dashboardを開いて各プロキシグループの現在のヘルス状態を直接観察してください。