本文目录
“自动”可能是追延迟，也可能是保主线路
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
- 两次健康检查的间隔，单位为秒。太短会增加流量和服务端压力。
- 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: 300验证 url-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 或目标服务。自动组值得保留的标准很简单：业务稳定，出口变化可以解释，主备顺序符合预期。只有探测页变绿，不算完成设置。