目次
「自動」は、低遅延を追うことも、主回線を維持することも意味する
url-test と fallback はどちらもヘルスチェックを行いますが、判断の目的が異なります。url-test は候補ノードのプローブ遅延を比較し、条件を満たす中から低い値を選びます。fallback は設定順で最初の利用可能なノードを使い、現在の項目が利用不能になった場合だけ次へ切り替えます。
前者は同等のノード群から低遅延を優先する用途に、後者は「主回線を優先し、予備回線で補う」用途に適しています。自分でノードを選ぶだけなら select、複数回線へ接続を分散するなら load-balance を使用します。fallback で代用することはできません。
まず目的に合うポリシーグループを選ぶ
| type | 判断方法 | 適した用途 |
|---|---|---|
| select | ユーザーが手動で選択 | トラブルシューティング、アカウント出口の固定、重要な長時間接続 |
| url-test | ヘルスチェックの遅延に基づいて選択 | 同等ノードの日常的な自動選択 |
| fallback | リスト順で最初に利用可能な項目を選択 | 明確な優先順位による主系・予備系の切り替え |
| load-balance | ポリシーに従って接続を複数の項目へ分配 | 同時接続の分散用であり、フェイルオーバーは行わない |
自動グループは候補の中からしか選べないため、質の悪いリストが自動で改善することはない
自動グループを作る前に、select で各候補ノードを固定し、それぞれ一度は実際のリクエストを完了させます。現在のコアがプロトコルに対応していないノード、サブスクリプションが失効したノード、ローカルネットワークからまったく到達できないノードは、先に候補から外してください。そうしないとヘルスチェックが失敗し続け、ログが不要な結果で埋まります。
ノードは proxies に直接記述することも、use で proxy-providers を参照することもできます。provider の更新後は新しいノードも候補に入るため、名前フィルター、地域フィルター、空のリストに注意してください。グループ自体が表示されていても、実際に項目が入っているとは限りません。
候補リストが満たすべき条件
- 各ノードを直接選択した状態で、実際のリクエストを完了できている
- ノード名で地域や回線を区別でき、同名の項目が大量に並んでいない
- provider の直近の更新が成功し、フィルター後のリストが空でない
- 重要なアカウントで出口の固定が必要な場合は、別に select グループを用意する
テスト URL によって「利用可能」の意味が決まる
ヘルスチェックでは、各候補ノードが url で指定したアドレスへアクセスします。そのアドレスが不安定、一部地域で拒否される、またはログインを必要とする場合は、グループ全体の結果が不正確になります。通常は、応答が小さく、アカウント不要で安定した HTTPS アドレスを選びます。たとえば 204 を返すプローブページです。
テスト URL は普段アクセスする内容に近いものが適していますが、個人 token を含む API を使ったり、第三者サイトへ高頻度のリクエストを送ったりしないでください。ノードのプローブ成功が示すのは、その時点でこの URL に到達できたことだけです。動画、AI のストリーミング応答、UDP は、それぞれのアプリで別途検証する必要があります。
proxy-groups:
- name: 自动选择
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
lazy: trueinterval、tolerance、lazy によって不要な切り替えの頻度が決まる
- interval
- ヘルスチェック間の interval を秒単位で指定します。短くしすぎると通信量とサーバー負荷が増えます。
- tolerance
- url-test の遅延許容値をミリ秒単位で指定します。差が小さい場合に現在の選択を維持し、頻繁な切り替えを抑えます。
- lazy
- グループが使われていない間は能動的なチェックを減らすか停止します。常用しないポリシーグループに適しています。
- timeout
- 一回のプローブに対する待機時間を設定できる構成もあります。短すぎると、たまたま遅れた応答まで利用不能と判定されます。
すべてのネットワークに適した一組のパラメーターはありません。家庭内ネットワークが安定し、ノード間の遅延が近い場合は、長めの interval と適度な tolerance を使用できます。モバイルネットワークで切り替えが多くても、間隔を数秒まで縮めないでください。出口が繰り返し変わると、ログインやストリーミング接続が中断します。
変更後はしばらく実際に使用して様子を見ます。Connections でノードが数分のうちに行き来し、候補間の差が数十ミリ秒しかない場合は、ノードを増やす前に tolerance または interval を大きくしてください。
fallback のリスト順が、そのまま主回線と予備回線の優先順位になる
fallback は、二番目の項目の遅延が低いという理由だけでは切り替えません。最初の項目がヘルスチェックに合格している限り、その項目を使い続けます。最初の項目が利用不能になった場合だけ、後ろの利用可能な項目を選びます。そのため、設定順には運用上の優先順位を反映してください。たとえば、安定した主回線を先に、料金が高い回線や別地域の予備回線を後ろに置きます。
proxy-groups:
- name: 主线路
type: select
include-all: true
filter: "(?i)主线"
proxies: [DIRECT]
- name: 同区备用
type: select
include-all: true
filter: "(?i)同区备用"
proxies: [DIRECT]
- name: 异区备用
type: select
include-all: true
filter: "(?i)异区备用"
proxies: [DIRECT]
- name: 主备线路
type: fallback
proxies: [主线路, 同区备用, 异区备用]
url: https://www.gstatic.com/generate_204
interval: 300
lazy: true主回線が復旧すると、fallback はその後のヘルスチェックで再評価します。切り戻し時に既存の接続が移行するとは限らず、新しいリクエストのほうが新しい出口を確認しやすくなります。アカウント管理画面や長時間のダウンロードでは、出口変更でセッションへ影響しないよう、固定 select の使用も検討してください。
地域内では速い回線を選び、地域間では主系と予備系を切り替える構成を二層のグループで表現できる
候補が多くても、すべてのノードを一つの url-test に入れる必要はありません。地域ごとに url-test を作り、その地域グループを優先順で fallback に入れます。これにより「地域内で遅延を比較する」と「地域間で主系・予備系を維持する」を分担でき、Connections でもリクエストが通ったグループを確認できます。
階層が増えるほど、空の provider、循環参照、同名グループを見つけにくくなります。二層で目的を表現できるなら三層目は追加しないでください。各下位グループが単独で機能することを確認してから、上位グループへ渡します。
proxy-groups:
- name: 香港自动
type: url-test
include-all: true
filter: "(?i)香港|HK"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 日本自动
type: url-test
include-all: true
filter: "(?i)日本|JP"
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 80
- name: 地区主备
type: fallback
proxies: [香港自动, 日本自动]
url: https://www.gstatic.com/generate_204
interval: 300url-test では選択過程を、fallback では切り替え順を検証する
普段のセッションを妨げない検証方法
独立したテストグループを新規作成するか、既存のものを使う
ダウンロード中、会議中、重要なアカウントへログイン中には切り替えを試さないでください。
ヘルスチェックを一度手動で実行する
各候補の結果と現在選択されている項目を記録します。
ブラウザの通信をこのポリシーグループへ通す
Connections に上位グループ、下位ノード、実際の出口が表示されることを確認します。
次のチェック周期を観察する
url-test では許容範囲内で選択が維持されるか、fallback ではリストの先頭項目が優先されるかを確認します。
fallback をテストする際は、失敗することを確認済みで機密情報を含まないテストノードを、独立したグループの先頭へ一時的に置き、二番目の項目へ切り替わるか観察できます。完了後はすぐに削除してください。ネットワーク切断、システムプロキシの無効化、本番設定の破壊によって障害を作らないでください。一度に多くの変数が変わってしまいます。
自動グループが機能しない原因は、多くの場合、候補リスト、プローブ、参照のいずれかにある
グループが空白で表示される
proxies / use の参照、provider の更新日時、ノードのフィルター結果を確認します。
すべての候補が Timeout
health URL を単独でテストし、現在のネットワークと実際のノード経由リクエストを比較します。
url-test が二つのノード間で切り替わり続ける
tolerance または interval を大きくし、プローブ先が安定していることを確認します。
fallback が常に二番目の項目を選ぶ
最初の項目がヘルスチェックに合格していません。順序を変える前に、具体的なエラーを確認します。
切り替え後、アカウントで何度も再ログインを求められる
機密性の高いセッションは固定 select グループへ入れ、出口が自動で変わらないようにします。
provider の更新後、グループが突然空になる
フィルター式と新しいノード名を照合します。以前は古いキャッシュが問題を隠していた可能性があります。
実際のリクエストで、自動グループを残す価値があるか判断する
対象サービスのルールを自動グループへ向け、ウェブ閲覧、ストリーミング応答、ダウンロードを数回続けて完了します。Connections には想定した上位グループと具体的なノードが表示されるはずです。url-test はわずかな遅延差で頻繁に切り替わらず、fallback は主回線が利用可能な間、最初の項目を維持する必要があります。
ヘルスチェックがすべて正常でも元のサービスが失敗する場合は、現在のノードを固定して再テストし、プロトコル、DNS、対象サービスを見直します。自動グループを残す基準は単純です。サービスが安定し、出口の変化を説明でき、主系・予備系の順序が想定どおりであることです。プローブページが正常になるだけでは、設定完了とはいえません。