先说结论：配置项之间存在依赖关系：代理组决定出口，规则决定分流，DNS 影响解析，TUN 则改变流量接管范围。理解顺序比照抄片段更重要。
这篇文章解决什么问题
适合准备阅读 YAML、调整规则、DNS、代理组或 TUN 参数的读者。 本文围绕“Mihomo 代理组怎么选？select、url-test、fallback 与负载均衡”给出判断思路、实际操作顺序和容易遗漏的边界；界面名称会随版本变化，以当前客户端与官方资料为准。
建议按这个顺序操作
- 先保留一份可用原配置，任何调整都应可回退。
- 每次只更改一个模块，例如先改代理组，再验证规则命中。
- 配置重载后用日志或连接记录确认新设置是否真正生效。
- 遇到兼容性问题时优先查阅当前内核版本的官方配置文档。
详细说明
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 编辑部根据项目官方文档与公开发布记录整理，没有使用虚构测速、评价或排名。软件界面和版本可能变化；发现步骤失效时，请以官方资料为准，并查看内容与测试说明。
内容更新说明：本页保留了原有的有效操作信息，并重新整理了问题边界和排查顺序。涉及订阅、节点和第三方服务时，请遵守所在地法律、服务条款与单位网络规范。
