プロキシグループが解決するのは「どのノードを使うか」という問題

ルールファイルのDOMAIN-SUFFIX,google.com,PROXYという行では、PROXYは特定のノードではなくプロキシグループの名前です。ルールは「このトラフィックがどのグループを使うべきか」を判断するだけで、そのグループ内で実際にどのノードを使い、どう切り替えるかは、プロキシグループ自身のスケジューリングロジックが決めます。この設計の利点は、サブスクリプションを切り替えてノードが全部変わっても、ルールが常にグループ名を参照しているため、ルールファイルを一切変更する必要がないことです。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 香港01
      - 新加坡01
      - DIRECT

上記の最もシンプルな例では、PROXYグループのタイプはselectです。つまり、どのノードを使うかは自分で手動選択し、クライアントのUIでワンクリックすれば切り替わり、自動的には変化しません。

4種類のスケジューリングタイプを一つずつ解説

1. select：完全手動、自動切り替えなし

selectは最もシンプルなタイプで、クライアントはproxiesリスト内のノードをそのまま表示するだけで、どれを使うかは自分でクリックして選び、絶対に自動で切り替わりません。どのノードの経路が安定しているか既に分かっていて、プログラムに「余計な判断」で切り替えられたくない場合に向いています。

2. url-test：レイテンシが最も低いノードを自動選択

url-testは一定の周期（interval）でテストアドレスにアクセスし、グループ内の各ノードのレイテンシを測定して、現時点で最も速いノードに自動的に切り替えます。UIに表示されるのは読み取り専用の「現在使用中のノード」で、手動で固定することはできません。

proxy-groups:
  - name: 自动选优
    type: url-test
    proxies: [香港01, 香港02, 新加坡01, 日本01]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 50

toleranceは重要なパラメータです。新しいノードのレイテンシが現在のノードよりこの許容値（単位はミリ秒）以上低くならない限り、実際には切り替わりません。これはレイテンシが近い2つのノード間で頻繁に切り替わってしまうのを防ぐためです。toleranceを小さく設定しすぎることが「ノードが勝手に切り替わり続ける」問題の最も多い原因です。

3. fallback：メインノードがダウンしたときだけ切り替え

fallbackも定期的にノードの接続可否を検査しますが、ロジックが異なります。リストの先頭にある接続可能なノードが有効な限りずっとそれを使い続け、「もっと速いものがある」という理由で切り替わることはありません。現在使用中のノードが検査に失敗した場合にのみ、次の順位のノードへ切り替わります。特定のメインノードを固定して使いたく、それが完全に使えなくなったときだけバックアップ回線を有効にしたい場合に向いています。

proxy-groups:
  - name: 主备切换
    type: fallback
    proxies: [主力节点, 备用节点A, 备用节点B]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

4. load-balance：トラフィックを複数のノードに分散

load-balanceは一致性ハッシュまたはラウンドロビンによって異なる接続をグループ内の異なるノードに分配するため、同時に複数の接続がそれぞれ別のノードを使うことがあります。各ノードの帯域幅が十分にあり、負荷を分散させたい場合に向いていますが、代償として同じサイトへの異なるリクエストが異なるIPから来たように見える場合があり、IPの一致性に敏感な一部のサイトで異常が発生する可能性があります。

proxy-groups:
  - name: 负载均衡
    type: load-balance
    proxies: [香港01, 香港02, 香港03]
    strategy: consistent-hashing
    url: "https://www.gstatic.com/generate_204"
    interval: 300

プロキシグループは入れ子にできる：グループの中にグループ

proxiesリストには具体的なノード名だけでなく、別のプロキシグループの名前も書くことができ、これによって階層構造を構築できます。よくある書き方は、まず地域別にいくつかのurl-test自動速度測定グループを作り、次にselectグループでこれらの地域グループをまとめ、「今回は主にどの地域を使うか」を手動で選択できるようにする方法です：

proxy-groups:
  - name: 香港自动
    type: url-test
    proxies: [港01, 港02, 港03]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: 日本自动
    type: url-test
    proxies: [日01, 日02]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: PROXY
    type: select
    proxies: [香港自动, 日本自动, DIRECT]

この書き方の利点は、ルールでは最も外側のPROXYだけを参照すればよく、各地域の内部でどのように自動速度測定・切り替えを行うかは完全に内側のグループ自身の問題であるということです。2つの層のロジックは互いに干渉せず、設定ファイルも保守しやすくなります。

ノードが頻繁に切り替わる？まずこの2つのパラメータを確認

url-testを使って「現在のノード」が頻繁に切り替わり、長時間の接続（ダウンロードやビデオ通話など）が頻繁に中断する場合、通常はこの2つのパラメータの調整不足が原因です：intervalが短すぎて速度測定自体が頻繁すぎる、またはtoleranceが小さすぎるか未設定で、レイテンシが近い2つのノードが「より良い選択肢がある」と判定されて何度も切り替わってしまう。intervalを300秒以上に、toleranceを50ms程度に調整すると、この問題は大抵はっきり改善します。

最後に

プロキシグループのタイプ選びは、結局こう問いかけていることになります：「このグループ内のノードについて、プログラムにどこまで判断を任せたいか？」——まったく任せないならselect、速度を測って最速を選んでほしいならurl-test、障害時のフォローだけしてほしいならfallback、負荷を分散したいならload-balance。この4種類の違いを理解した上で振り分けルールと組み合わせて「誰がどのグループを使うべきか」を決めれば、ほぼ完全で保守しやすい設定が出来上がります。用語の意味が分からない場合は、いつでも用語集で確認できます。