プロキシグループの応用：負荷分散とフェイルオーバーの設定方法

多くのサブスクリプションでデフォルトで生成されるプロキシグループのタイプは select（手動選択）か url-test（自動測速で最適なノードを選択）で、この2種類だけで日常のニーズはほぼ満たせます。ただ、ノードを多く持っている場合や、安定性をより重視したい場合は、fallback と load-balance の2種類がより良い耐障害性と負荷分散の効果を提供してくれます。

014種類のプロキシグループタイプ一覧

タイプ	選択ロジック	適したシーン
select	完全に手動で選択。コアは自動切り替えを一切行わない	自分でどのノードを使うか厳密に管理したい
url-test	定期的に速度を測定し、自動で最も低遅延なノードを選択	日常使用、手間をかけたくない。多くのサブスクリプションのデフォルト設定
fallback	リストの順序で最初に使えるノードを使用し、現在のノードが失敗した時のみ次に切り替える	明確な「メイン・バックアップ」の優先度があり、特定のノードを優先的に使いたい
load-balance	アルゴリズムに基づいて異なる接続を複数のノードに分散し、同時に使用	ノードが多く、通信を分散させて単一ノードの過負荷を避けたい

02Fallbackフェイルオーバーの設定例

Fallbackは記載したノードの順序通りに接続を試みます。リストの最初のノードが使える限りそれを使い続け、ヘルスチェックが失敗したときだけ次のノードに切り替えます。つまりノードの記載順序そのものが優先度になります。

proxy-groups:
  - name: "Fallback-Group"
    type: fallback
    proxies: ["HK-メイン", "HK-サブ", "SG-サブ"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

上記の例では、「HK-メイン」のヘルスチェックが正常な限り、通信は常にそのノードを使います。ヘルスチェックが失敗した場合のみ「HK-サブ」、続いて「SG-サブ」の順に試します。

03Load Balance負荷分散の設定例

Load Balanceは（同一接続内のパケットではなく）異なる接続をグループ内の複数ノードに割り振ることで通信を分散させます。同時に、あるノードが故障した場合は新しい接続が他の健全なノードに割り振られるため、自然に一定の耐障害性も備えています。

proxy-groups:
  - name: "LoadBalance-Group"
    type: load-balance
    proxies: ["HK-01", "HK-02", "HK-03"]
    strategy: consistent-hashing
    url: "http://www.gstatic.com/generate_204"
    interval: 300

strategyフィールドの2つの値

consistent-hashing：接続先アドレスに基づいて一貫性ハッシュを行い、同じ宛先はほぼ常に同じノードに割り振られます。「セッション維持」が必要な場面（送信元IPの変化に敏感なサイトなど）に向いています。
round-robin：順番にグループ内のノードへ均等に割り振ります。分散はより均一になりますが、同じ宛先が常に同じノードになる保証はありません。

ヒント：負荷分散は「複数ノードで同じ接続を高速化する」機能ではなく「異なる接続を異なるノードに割り振る」機能です。そのため、1つの大きなファイルのダウンロード速度がグループ内のノード数に応じて速くなるわけではありません。実際に最適化されるのは複数タスクを同時に行う際の全体的なスループットと安定性です。

04どれを選ぶべきか

安定したノードが1〜2個しかない場合は url-test で十分です。特定のノードの品質が明確に優れていて優先的に使いたい、他は予備として使いたい場合は fallback を使いましょう。品質が近いノードを複数持っていて、1つのノードでは複数デバイスの同時使用に耐えられないか心配な場合は load-balance がより適しています。3種類のタイプはネストして組み合わせることも可能で、例えば fallback グループを別の策略グループの候補の1つとして使うこともできます。実際の構成は手元のノードの状況に応じて判断してください。

05ヘルスチェックに関わる2つのフィールド

fallback と load-balance はいずれもバックグラウンドのヘルスチェックによってノードが使用可能かを判断します。この動作は url と interval の2つのフィールドで制御され、設定を誤ると切り替えが遅れたり、チェックが頻繁すぎて無駄に通信量を消費したりします。

url：ヘルスチェックがアクセスするアドレス。一般的には軽量な測定用アドレス（http://www.gstatic.com/generate_204 など）を使い、正常な応答が返ればノードは使用可能と判断されます。実際のサービスサイトに変更する必要はありません。
interval：チェックの間隔（単位：秒）。小さすぎるとクライアントが頻繁に探測リクエストを送り、不要な通信量とバッテリー消費が増えます。大きすぎるとノードの故障が検知され切り替わるまでに時間がかかります。一般的には300秒前後がバランスの良い設定です。

ヒント：fallbackグループで「明らかにノードが死んでいるのに切り替わるまでとても時間がかかる」と感じた場合は、まず interval が長すぎないかを確認してください。最も見落とされがちな部分です。

06よくある質問

Q：load-balanceグループ内のノード数に上限はありますか？
厳密な上限はありませんが、ノード数が増えるほどヘルスチェックの負荷も大きくなります。実際には品質が近い3〜6個程度のノードで良好な分散効果が得られることが多く、ノードが多すぎると問題の切り分けがしづらくなります。

Q：策略グループを切り替えると通信は切断されますか？
fallbackとload-balanceが影響するのは「新しい接続」の割り振り先のみで、既に確立された接続が強制的に切断されることは通常ありません。ただし、元のノードが実際に故障している場合、その接続自体もすでに使えなくなっている可能性が高く、クライアント側で再度接続をやり直す必要があります。