プロキシグループ上級編：ロードバランシングとフェイルオーバーの設定方法

まず基本の3種類のプロキシグループをおさらい

url-test（自動選択）は定期的に速度測定を行い、常にその時点で最も遅延が低いノードを使用します。select（手動切り替え）は使用するノードを完全にユーザー自身が指定します。この2つが最も一般的な初期設定です。ノード数が増え利用シーンが複雑になってきたら、load-balanceとfallbackという2つのタイプがより具体的な課題を解決してくれます。

load-balance：通信を複数のノードに分散する

load-balanceグループは異なる接続リクエストをグループ内の複数のノードに振り分けます。url-testのように常に「最適な」1つだけを使うわけではありません。これにより単一ノードへの帯域負荷を分散できるので、特に複数デバイスが同じサブスクリプションを同時に使い、通信量が多い場面で意味があります。分散方法はstrategyフィールドで指定する2種類があります。

proxy-groups:
  - name: ロードバランス
    type: load-balance
    strategy: consistent-hashing
    proxies: [ノードA, ノードB, ノードC]
    url: http://www.gstatic.com/generate_204
    interval: 300

• consistent-hashing —— 宛先アドレスに基づいて一貫性ハッシュを行い、同じ宛先は常に同じノードに割り振られます。「セッションの維持」が必要な場面（送信元IPが頻繁に変わることで異常検知がかかってしまうサイトなど）に向いています；
• round-robin —— リクエストの順番に沿ってグループ内のノードを順に巡回します。分散はより均等になりますが、同じ宛先アドレスが毎回同じノードを通るとは限りません。

どちらか迷ったらconsistent-hashingを優先してください。多くの場面でより安定した使用感になります。

fallback：メインノードが落ちたら自動で切り替わる

fallbackグループは設定順にノードの可用性を順番にチェックし、通常時はリストの先頭にある使用可能なノードを常に使います。現在使用中のノードが測定に失敗する（利用不可と判定される）と、即座に次に使える候補ノードに切り替わり、メインノードが復旧すれば元に戻ります。url-testの「遅延が低い方を使う」という考え方とは異なり、fallbackは「まず優先ノードを使い、使えなくなったら次善の策に切り替える」ことを重視します。

proxy-groups:
  - name: フェイルオーバー
    type: fallback
    proxies: [メインノード, バックアップノードA, バックアップノードB]
    url: http://www.gstatic.com/generate_204
    interval: 300

組み合わせて使う

実際の設定では、これらのプロキシグループタイプは入れ子にして使われることが多いです。例えば同じ地域内の複数ノードからurl-testで最も遅延の低いものを選び、さらに異なる地域の複数のurl-testグループを1つのまとまりとして扱い、selectで現在どの地域を使うかを手動選択する、といった構成です。帯域を分散したい場面では、あるノード群だけをload-balanceとして独立させ、他のプロキシグループと並べて最終的な手動選択メニューに入れておき、必要に応じて切り替えることもできます。

tolerance を見落とさない――無意味な切り替えを減らせる

url-testとload-balanceグループには、意外と見落とされがちなパラメータtolerance（遅延の許容差、単位はミリ秒）があります。これを設定しないと、クライアントは「常に最も遅延が低いものを使う」という厳格なロジックで動作しますが、測定結果には元々ある程度のブレが存在し、数回の測定の間に数ミリ秒程度の変動が起きるのはごく普通のことです。許容差を設けていないと、遅延が近い複数の候補ノードの間で頻繁に切り替えが発生してしまい、逆に使用感を損ねます(特にダウンロード中や動画視聴中は、切り替えの瞬間に短い引っかかりが起きやすくなります)。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies: [ノードA, ノードB, ノードC]
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

tolerance: 50を設定すると、新しいノードの遅延が現在のノードより少なくとも50ミリ秒低くならない限り、実際の切り替えは発生しません。それ以外の場合は現在のノードを使い続けます。瞬間的な測定値がわずかに高くなっていても構いません。この値を大きくする必要はなく、通常50〜100ミリ秒程度で無意味なブレによる切り替えの大半を抑えられます。

どのタイプを使うべきかは、実際の課題次第

最初の疑問に戻りましょう。単に遅延切り替えが頻発しすぎるだけなら、まずtoleranceを追加すれば解決することが多く、必ずしも複雑なタイプに変える必要はありません。複数デバイスの通信を異なるノードに分散させて単一ノードへの負荷を下げたいならload-balanceが必要になります。「メインノードが落ちたときに自動で補ってくれるか」を気にしているなら答えはfallbackです。3つの課題に対して3つの解決策があり、すべてを一度に使う必要はありません。実際に直面している状況に応じて設定してください。プロキシグループのパラメータについてさらに詳しく知りたい方は上級者向けドキュメントをご覧ください。