プロキシグループ(Proxy Group)は、ルールがマッチした後に実際にどのノードを使うかを決定します。サブスクリプションを設定した後、プロキシグループを一度も触らずプロバイダーが用意したデフォルトのグループのまま使っている人は多いですが、デフォルト設定は大抵「使える」だけで、「使いやすい」にするにはまだ調整の余地があります。
3種類のタイプがそれぞれ解決する課題
| タイプ | 解決する課題 | コスト |
|---|---|---|
| select | 手動で特定のノードに固定でき、動作が完全に予測可能 | ノード障害時に自動切り替えされず、手動対応が必要 |
| url-test | 遅延が最も低いノードを自動選択し、手動での速度測定・切り替えが不要になる | 測定自体が多少の通信量と時間を消費し、パラメータが不適切だと頻繁に切り替わる |
| fallback | メインノード障害時に、順番に次の利用可能なノードへ自動切り替え | 「利用可能」は接続できることを意味するだけで、遅延が最も低いとは限らない |
| load-balance | 接続を複数のノードに分散させ、単一ノードへの帯域負荷を軽減 | 同時刻の異なる接続が異なるノードを通る可能性があり、「同一IPの維持」が必要な用途には向かない |
url-test:自動速度測定の2つの重要パラメータ
url-test は最も一般的に使われるタイプですが、多くの人は proxies リストだけ設定してそのままにしています。実際には interval と tolerance という2つのパラメータが、使い心地の良し悪しを左右する鍵になります。
proxy-groups: - name: Auto type: url-test proxies: [HK-01, HK-02, SG-01, JP-01] url: http://www.gstatic.com/generate_204 interval: 300 # 300秒ごとに速度測定。頻繁すぎると通信量が増える tolerance: 50 # 遅延差が50ms未満なら切り替えない。揺れによる頻繁な切り替えを防ぐ lazy: true # 実際の通信がない時は測定を一時停止し、省電力・省データに
tolerance は見落とされがちですが、最も影響が大きいパラメータです。0に設定すると、2つのノードの遅延差が1msあるだけで切り替えが発生してしまい、長く使うと「なぜかずっとノードが切り替わっている」と感じるようになります。50〜100msあたりが妥協点として良く、通常のネットワークの揺れをフィルタリングし、本当に遅延差が大きい時だけ切り替えるようになります。
fallback:メイン回線に控えを用意する
遅延は低いものの時々不安定になる「メインノード」がある場合、切断を手動で監視して切り替えるより、fallback で一段包んでおく方が良いです。通常時は常に優先度が最も高いノードを使い、利用不可を検知した瞬間に自動的に次のノードへ移ります。
proxy-groups: - name: Fallback type: fallback proxies: [HK-Premium, Auto, SG-01] url: http://www.gstatic.com/generate_204 interval: 180
ここでの順序は重要です:HK-Premium はメインノードとして最初に、Auto は先ほど設定した url-test グループで「より賢い控え」として、SG-01 は最後の保険として配置します。fallback は順番に確認していき、前のノードが利用不可の場合だけ次のノードを使います。普段はほとんど存在を意識しませんが、メインノードに本当に問題が起きた時にその価値を発揮します。
load-balance:本当に必要になるのはいつか
load-balance は「速くなる」機能だと誤解されがちですが、実際に解決するのは「単一ノードの帯域が足りない」または「接続を複数の出口に分散させたい」という課題です。1つのダウンロードタスクの速度向上には限界があります――1つのTCP接続は常に1つのノードを通るため、複数の並行接続がある場合にのみ分散の効果が現れます。
- 動画視聴や日常的な閲覧が主な用途であれば、load-balance はほぼ不要で、url-test だけで十分です。
- 複数のクライアント端末で同じノード群を共有している場合や、複数の並行ダウンロードタスクを頻繁に行う場合は、load-balance によって負荷をより均等に分散できます。
- load-balance は round-robin(ラウンドロビン)と consistent-hashing(一致性ハッシュ。同じ宛先アドレスはできるだけ同じノードを通る)の2つの方式に対応しています。後者は「同じサイトへは常に同じ出口IPを使いたい」場合に向いています。
組み合わせる:実用的な3層構造
実際の設定では、1種類だけを選ぶのではなく、3種類を重ねて使うことをおすすめします:
- 最下層では url-test グループを使って同一リージョンのノードをまとめ、最速のものを自動選択する。
- 中間層では fallback で一段包み、「メインノード」と「url-test グループ」を優先度順に並べて、障害時に自動的にバックアップされるようにする。
- 最上層ではルールに公開する select グループを1つ用意し、その候補リストに fallback グループと手動で選べる控えノードをいくつか入れておくことで、いつでも手動介入できるようにする。
ルールは常に最上層の select グループだけを参照するようにします。速度測定とフェイルオーバーのロジックはすべてその候補リストの中に隠蔽されているため、プロキシグループ内部のロジックを調整する際にルールを変更する必要が一切ありません。