目次
自動選択に求めるものは人によって異なります。遅延を減らしたい場合も、主な接続が使えなくなったときだけ予備を使いたい場合も、ログイン中の接続経路を固定したい場合もあります。必要な結果を決めてから、ポリシーグループとテスト方法を選びましょう。似て見える設定でも、長時間の接続やアカウントのセッションに与える影響が変わります。
url-test、fallback、select、load-balance の選び方
ポリシーグループの選択方式
| type | 判断方法 | 適した用途 |
|---|---|---|
| select | ユーザーが手動で選択 | トラブルシューティング、アカウント出口の固定、重要な長時間接続 |
| url-test | ヘルスチェックの遅延に基づいて選択 | 同等ノードの日常的な自動選択 |
| fallback | リスト順で最初に利用可能な項目を選択 | 明確な優先順位による主系・予備系の切り替え |
| load-balance | ポリシーに従って接続を複数の項目へ分配 | 同時接続を分散する方式で、固定の主系・予備系の順序では選ばない |
候補ノード：可用性、フィルター、空の一覧
自動グループを作る前に、select で候補ノードを固定し、それぞれで実際のリクエストを完了させます。現在のコアがプロトコルに対応していない、サブスクリプションが無効、または現在のネットワークからまったく到達できないノードは候補から外してください。残すとヘルスチェックのエラーが続き、同じエラーが大量に出て有用なログを探しにくくなります。
ノードは proxies に直接書くか、use で proxy-providers を参照できます。provider の更新で候補一覧が変わるため、名前や地域のフィルター、空の一覧を確認し、ノード名で地域や回線を区別できるようにします。
ヘルスチェック用 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 と fallback を組み合わせる
候補ノードが多い場合、すべてを一つの 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: 300独立したテストグループで選択と障害時切り替えを観察する
前述の YAML 断片はポリシーグループだけを定義しています。完全な設定のコピーを編集し、既存の proxy-groups リストに新しいグループを追加して、元のノード、proxy-providers、rules は残します。断片で設定全体を置き換えたり、proxy-groups キーを重複させたりしないでください。
Clash Verge Rev v1.6.2 以降では、完全な YAML のコピーをクライアントにドラッグしてローカル設定を作り、使用する設定として選択します。新しいグループが Proxies に表示されるはずです。読み込めない場合は元の設定を選び直してログを確認し、元のサブスクリプションファイルは上書きしないでください。
普段のセッションを妨げない検証方法
設定のコピー内の専用テストグループを使う
ダウンロード中、会議中、重要なアカウントへログイン中には切り替えを試さないでください。
ヘルスチェックを一度手動で実行する
各候補の結果と現在の選択を記録します。この例の下位 select グループは、DIRECT ではなく実際のプロキシノードを選んでいる必要があります。
ブラウザの通信をこのポリシーグループへ通す
Connections に上位グループ、下位ノード、実際の出口が表示されることを確認します。
次のチェック周期を観察する
url-test では許容範囲内で選択が維持されるか、fallback ではリストの先頭項目が優先されるかを確認します。
fallback をテストする際は、失敗することを確認済みで機密情報を含まないテストノードを、独立したグループの先頭へ一時的に置き、二番目の項目へ切り替わるか観察できます。完了後はすぐに削除してください。ネットワーク切断、システムプロキシの無効化、本番設定の破壊によって障害を作らないでください。一度に多くの変数が変わってしまいます。
空の一覧、測定失敗、頻繁なノード変更への対処
グループが空白で表示される
proxies / use の参照、provider の更新日時、ノードのフィルター結果を確認します。
すべての候補が Timeout
health URL を単独でテストし、現在のネットワークと実際のノード経由リクエストを比較します。
url-test が二つのノード間で切り替わり続ける
tolerance または interval を大きくし、プローブ先が安定していることを確認します。
fallback が常に二番目の項目を選ぶ
最初の項目がヘルスチェックに合格していません。順序を変える前に、具体的なエラーを確認します。
切り替え後、アカウントで何度も再ログインを求められる
機密性の高いセッションは固定 select グループへ入れ、出口が自動で変わらないようにします。
provider の更新後、グループが突然空になる
フィルター式と新しいノード名を照合します。以前は古いキャッシュが問題を隠していた可能性があります。
Web 閲覧、長い回答、ダウンロードで自動グループを検証する
対象サービスのルールを自動グループへ向け、ウェブ閲覧、ストリーミング応答、ダウンロードを数回続けて完了します。Connections には想定した上位グループと具体的なノードが表示されるはずです。url-test はわずかな遅延差で頻繁に切り替わらず、fallback は主回線が利用可能な間、最初の項目を維持する必要があります。
ヘルスチェックは正常でも元の用途で失敗する場合は、select に切り替えて現在のノードを固定して再テストし、プロトコル、DNS、対象サービスを確認します。