快连分流规则配置指南

一、默认规则的匹配顺序

客户端内置的规则库按优先级从高到低匹配，顺序如下：用户自定义规则最高，其次是进程级识别结果，再次是域名与端口规则，最后是全局默认策略。这个顺序的设计逻辑是"越具体的判断越优先"——用户手工指定的规则代表了明确的意图，理应覆盖自动识别的结果。

理解顺序很重要：如果你手工为某个应用指定了类别，但该应用仍走了另一条路径，可能是更具体的域名规则先命中了。此时应检查规则列表中的命中编号，确认实际生效的是哪一条。

二、识别失败时的兜底

识别不可能百分之百成功。常见失败场景包括：遇到从未见过的新应用、应用使用多进程架构导致网络进程与主进程分离、应用接管了系统代理设置绕过了识别入口。默认策略是把识别失败的连接归入"跟随全局设置"，而不是强行归入某一类别。

这样设计的理由是：强行归类会导致不可预期的结果（例如把未知的视频流归入游戏类别，反而降低体验），而跟随全局至少行为可解释。如果你发现某类连接频繁识别失败，正确做法是手工补充规则，而不是调整全局策略。

三、如何验证一条规则是否生效

• 在客户端状态页找到目标应用的连接条目，确认其显示的类别与命中的规则编号
• 规则编号与你在规则列表中配置的编号一致，说明该条规则确实生效
• 若连接条目显示为未知类别，说明该应用未被识别，需要手工添加
• 修改规则后建议断开重连一次，让新规则在下一次连接时生效
• 对多进程应用，检查其名下是否有多条连接条目，逐条确认类别

四、四类常用配置场景

场景	推荐配置	说明
某应用未被识别	手工指定应用类别	按可执行文件路径匹配，最直接
某域名需要特殊处理	添加自定义域名规则	适用于私有仓库等内部服务
大文件任务影响实时应用	给大文件类别设置占用上限	避免吞吐类任务独占通道
国内服务被误加速	将该应用/域名归入直连	避免绕行导致时延上升

五、关于日志的说明

规则匹配在客户端本地完成，服务端不参与判断，因此也不需要知道连接目标是什么。日志层面只记录规则命中次数与规则编号，用于帮助用户判断规则是否生效以及是否需要调整，不记录目标地址。这是识别机制与隐私设计相互配合的结果，而不是两条独立的策略。