分流配置出错时，表现往往不是"不能用"，而是"某个场景莫名变慢"。本文列出六类最常见的配置误区，每类都给出可自行验证的检查方法。
最常见也最容易犯的错误。游戏带宽需求极小但对时延极其敏感，而吞吐优先型的路径取向允许更长时间的排队以换取更高总吞吐，两者目标冲突。表现是画面看起来流畅，但操作有明显延迟感。
验证方法：把该游戏的类别改为游戏预设后重新连接，对比操作延迟是否有改善。若改善明显，说明此前确实分错了通道。
浏览器是流量类型最复杂的应用：视频播放、网页资源加载、扩展程序更新、后台同步都在其中。按进程整体归入某一类别，必然有一类流量被错误对待。如果整体归入吞吐优先，网页小请求会被大流量排队拖慢；如果整体归入时延优先，视频播放的持续吞吐可能不足。
验证方法：在状态页查看浏览器的连接条目数量。健康的配置下，浏览器名下应有反映出多类通道的多条条目与对应类别，而不是清一色的同一类别。
游戏的反作弊模块、办公软件的更新服务、开发工具的语言服务，都会独立联网。它们被漏识别后走默认路径，表现往往是间歇性的异常——例如登录偶尔失败、队内语音偶尔断续，因为只在特定阶段才触发。
验证方法：找到该应用在状态页中的全部连接条目，逐条确认类别。若存在未知类别的条目，就是被漏掉的辅助进程。
镜像拉取、系统更新、素材下载这类任务会把通道带宽用满，如果与实时应用共享通道且没有占用上限，会直接导致会议卡顿、游戏延迟飙升。这类问题在用户主动发起大文件任务时出现，容易被误判为"通道不稳定"。
验证方法：在出现卡顿时检查是否有大流量任务在运行。给大文件类别设置带宽上限后复测，若实时应用恢复正常，即可确认原因。
访问国内服务的流量本来直连路径最短，进加速通道反而要绕行一段再回到国内，时延上升且占用通道容量。这个错误常出现在"图省事直接开全局"的配置里。
验证方法：对某个国内服务分别测直连与加速两种状态下的时延。若加速后更慢，说明该域名不该进通道。
分流配置最容易出问题的地方是"以为生效了"。修改规则后如果不重新建立连接，旧规则可能仍在生效；添加了域名规则但匹配顺序被更具体的规则抢先命中，实际生效的是另一条。
验证方法：修改规则后断开重连一次，然后在状态页确认目标连接显示的规则编号与预期一致。这是唯一可靠的验证方式。
| 检查项 | 判断标准 | 不通过时的动作 |
|---|---|---|
| 实时应用是否在时延优先类别 | 类别显示为游戏/办公预设 | 改为对应预设 |
| 浏览器是否有多个类别条目 | 连接条目多于一条且分类合理 | 检查域名分组配置 |
| 关键应用是否有多条连接 | 覆盖其辅助进程 | 把安装目录整体归入类别 |
| 大文件类别是否设上限 | 有明确的占用上限 | 设置上限 |
| 国内服务是否保持直连 | 时延不低于直连基线 | 移出加速通道 |
| 改动后是否重新连接 | 规则编号与预期一致 | 断开重连后复验 |
这六类误区覆盖了绝大多数分流配置问题。它们的共同特征是：都不是功能缺陷，而是类别与路径取向的错配。因此排查时不必怀疑客户端本身，优先检查配置与识别结果即可。