快连围绕一件事做产品：让每个连接都走到它真正该走的那条路径上。国内服务直连不绕行，海外服务走加速通道，实时应用优先时延，大文件任务不挤占实时通道。
网络加速领域最常见的设计是把所有流量都送进加速通道。这看起来最省心，但有两个实际问题：一是访问本地服务本来直连就很快，绕行反而增加时延并占用通道容量；二是当所有流量走同一条路径时，一旦出现卡顿就无法判断问题出在通道还是目标服务，可解释性很差。
分流的思路是把"决定权"还给具体场景：按应用类别决定路径，而不是一刀切。代价是需要解决识别问题——判断一个连接请求属于哪个应用。这件事比看起来难：现代应用普遍是多进程架构，浏览器会派生多个渲染进程，开发工具会拉起后台索引进程，游戏客户端会启动独立的反作弊进程。识别只看可执行文件名，很容易出现部分流量分错路径的情况。
在识别层，快连解析每个进程发起的连接请求，结合进程归属、目标端口与协议特征判断类别；对同一可执行文件目录下的子进程做归并，避免同一应用被拆成多个条目；对同一目标域名的连接做聚合判断，避免逐连接重复计算带来的性能开销。
在决策层，规则按优先级从高到低匹配：用户自定义规则优先于自动识别结果，具体规则优先于全局默认策略。规则匹配完全在本地完成，服务端不参与连接目标判断。这一设计同时带来了可解释性（用户能看到命中的规则编号）与隐私边界（服务端不需要知道目标是什么）。
不做"识别率百分之百"这类无法验证的宣称——任何识别机制都会遇到未知应用，合理的做法是提供可解释的兜底策略和手工补充入口。不做"日志完全为零"的表述——为了帮助用户判断规则是否生效，客户端会记录规则命中次数与编号，只是不含目标地址。把边界讲清楚，比给一个漂亮但含糊的承诺更有价值。
识别错误的条目、规则建议与仿冒域名举报均可通过页脚公示渠道提交。若能附上客户端版本号、操作系统版本与出现问题的应用名称，可以显著提高定位效率。数据更新日期：2026-09-15。