直接答案：需要手动固定出口用 select；希望按探测延迟自动选择用 url-test；要求主节点不可用时按顺序切换用 fallback；希望把不同连接分配到多个节点才考虑 load-balance。选择依据是业务目标，不是组名越复杂越好。
select：最可控的手动选择
type: select 会把节点或其他策略组列给用户手动选择，适合需要固定地区、固定出口或调试规则的场景。优点是行为直观，缺点是节点失效时不会自动替你判断。可以把 url-test 和 fallback 作为选项放进 select，兼顾手动与自动。
url-test：按健康检查自动选择
url-test 会定期访问指定 URL，根据探测结果选择节点。interval 控制检查间隔，tolerance 可避免节点只因微小延迟差异频繁切换。测试 URL 应稳定、响应轻量并符合你的网络环境；探测快不代表下载一定快。
fallback：按顺序故障转移
fallback 同样会进行健康检查，但更强调优先级：通常优先使用列表前面的可用代理，前项失败时切到后项。适合有明确主备顺序的场景。恢复后的切换行为和连接是否重建，应根据当前内核文档与实际应用验证。
load-balance：分配不同连接
负载均衡不是把单个下载简单叠加成多倍带宽，而是按策略把不同连接分给多个代理。相同业务若需要稳定出口，要选择能保持一致性的策略；账号风控敏感的服务可能不适合频繁变化出口。使用前先理解 consistent-hashing 等策略的含义。
一个易维护的组合
顶层使用 select，里面放“自动选择”的 url-test、“故障转移”的 fallback、几个固定节点和 DIRECT。规则只引用顶层业务策略组，后续更换节点来源时不必改大量规则。节点质量的综合判断见延迟、丢包和抖动说明。
常见问题
url-test 会中断正在使用的连接吗？
策略选择变化主要影响新连接，现有连接行为依应用和内核而定。为避免频繁变化，应设置合理间隔和容差。
fallback 和 url-test 哪个更稳定？
取决于目标。需要固定优先级用 fallback，需要按探测结果择优用 url-test。稳定性还取决于节点本身。
负载均衡能让单线程下载翻倍吗？
不能这样保证。它通常分配的是连接，不是把单个连接聚合成多条线路。
参考资料
内容说明：本文由 HowOClash 编辑部根据项目官方文档与公开发布记录整理，没有使用虚构测速、评价或排名。软件界面和版本可能变化；发现步骤失效时，请以官方资料为准，并查看内容与测试说明。
