Clash Verge Rev
很多“节点已经选择但流量没有变化”的问题，并不是节点失效，而是选错了代理组。结合 YouTube 入门与进阶教程中常见的操作路径，本文把代理组、延迟测试和实际验证整理成一套可重复的排查流程。操作前请确保配置来源可信，并遵守所在地法律及网络服务条款。
先分清节点与代理组
节点是具体的代理出口；代理组是规则调用的决策入口。规则通常不会直接指向某个节点，而是指向“节点选择”“自动选择”或自定义策略组。你在界面里切换节点后，如果当前访问规则使用的是另一个组，实际出口自然不会改变。
先打开规则页，确认目标域名最终命中了哪条规则，再查看该规则指向的策略组。规则按从上到下的顺序匹配，越靠前的规则优先级越高，最后通常由 MATCH 兜底。
三类常见策略怎么选
- select：由你手动选择，适合需要固定出口或逐个排查节点的场景。
- url-test：定期检测候选节点，并根据探测结果自动选择，适合日常使用。
- fallback：优先使用列表靠前且健康的节点，故障时切换，适合主备线路。
策略组名称由配置提供者决定，界面上不一定直接显示英文类型。不要仅凭“自动”“故障转移”等名称判断，必要时查看配置结构。
一套更可靠的选线流程
- 更新订阅，确认更新过程没有解析或下载错误。
- 根据规则命中结果找到真正承载流量的代理组。
- 执行一次健康检查，排除不可达或明显超时的节点。
- 从延迟接近的候选中选择两到三个，用真实网页、下载或业务请求验证。
- 保留一个不同地区或不同线路的备用节点，便于故障时快速切换。
延迟数字不等于实际速度
健康检查反映的是到测试地址的可达性和往返时间，不直接代表带宽、晚高峰拥塞、丢包率，也不能保证某个应用一定可用。最低延迟节点可能更拥堵，而延迟稍高但线路稳定的节点反而体验更好。因此应把延迟看作筛选信号，而不是最终结论。
常见误区与排查重点
最常见的误区包括：在错误的代理组里切换、只盯住最低延迟、频繁修改全局设置、忽略规则命中和日志。建议一次只改一个变量，并记录“访问目标—命中规则—策略组—实际节点”这条链路。这样即使问题再次出现，也能快速判断是规则、配置、网络还是节点本身。
不要公开分享包含订阅地址、节点凭据或私有控制端口的截图和日志。提交问题前先脱敏，保留时间、错误类型、客户端版本和最小复现步骤即可。