代理组选择
订阅通常把可用节点组织为自动选择、手动选择和故障转移等代理组。用户在代理页切换的往往是组内的线路,而非修改了所有规则。
当“当前节点”和某条规则实际使用的节点不一致时,查看规则匹配到的代理组,以及该组内部的选择结果。
在代理组中切换节点,对比延迟,并通过连接记录核对实际使用的线路。

订阅通常把可用节点组织为自动选择、手动选择和故障转移等代理组。用户在代理页切换的往往是组内的线路,而非修改了所有规则。
当“当前节点”和某条规则实际使用的节点不一致时,查看规则匹配到的代理组,以及该组内部的选择结果。
延迟测试向预设测试地址发出请求,以便快速比较节点响应。测试值受目标地址、当时线路和网络波动影响,不等同于实际下载速率。
同一节点偶尔出现 timeout 时,先间隔重试,再用普通网页验证;连续多次失败才有理由进一步检查节点和订阅。
链式代理让流量按配置经过多个代理节点,可能用于特殊的路由场景,但也增加延迟与故障点。配置顺序应与使用目标一致。
排查链式代理时可先回退到单节点验证基本连接,再逐步增加上游节点;不要用链式代理掩盖源节点不可达的问题。
自动选择与故障转移策略依据配置中的测试规则工作,不同组可能使用不同时间间隔和测试地址。自动化结果方便,但不意味着永远选中最合适的线路。
关键任务前仍建议观察实际网页加载与连接记录;延迟最低未必吞吐最高。
连接页可查看当前连接、目标地址及匹配到的代理路径,有助于解释某个网站为什么没有使用预期线路。与只看测速相比,它更接近真实访问行为。
例如规则模式下某个程序意外直连,应在该程序发起请求时观察连接记录,而不是盲目切换所有代理组。
规则模式按配置中的匹配条件分别路由;全局模式让支持的流量统一经过选定代理;直连模式则不经代理节点转发。三者用于不同的网络测试场景。
排查某个站点时可以短暂比较不同模式的结果,但模式切换不是修复失效订阅的办法。切回日常使用模式后应再做一次实际访问验证。
支持 Windows、macOS、Linux;iOS 请使用兼容客户端。
代理连接还能正常用,但代理组列表偶尔没显示。想手动切线路时,界面状态最好能和实际连接同步。
后台服务如果能按需启动和停止,用完就关闭,会更方便管理。
绕过列表的默认内容和自己添加的规则不容易分清,最好能直接看到最终生效的项目。
不一定。自动选择通常参考测试地址的延迟或可用性,实际视频、下载和网页加载仍受到目标网站和线路负载影响。可以将自动策略作为日常默认,遇到问题再手动对比。
timeout 只表示一次测试没有在时间内收到预期响应,原因可能是节点不可达、订阅失效、被测地址不通或本地网络限制。换测试目标、查看日志以及核对其他节点后才能更准确判断。
打开连接页面,在目标网站发起请求后查看相应域名、匹配规则与最终代理组。若没有相关连接记录,先确认应用是否经过了当前系统代理或 TUN。
规则模式让配置中的匹配条件决定去向;全局模式通常将代理连接交给选定组;直连模式不经过代理节点。测试连通性时可对比这些模式,但日常设置应以实际需求为准。
多数配置更新可以在客户端内完成,不一定要重启。切换后确认配置加载成功和内核正常,若代理组没有按预期更新,再检查日志或重新载入,而不是立即卸载重装。
检查是否有更靠前的规则已匹配请求,并注意域名解析方式与连接记录中的实际目标。把规则写在文件末尾并不一定优先于已有的兜底规则。
不能。代理路径会带来额外网络跳数,最终速度受到节点负载、目标服务器和本地网络的共同影响。规则分流的价值在于灵活控制连接去向,而不是对每个网站都加速。