QuickQ分流规则支持哪些模式及如何设置？

QuickQ分流规则（在部分版本里也被叫作路由规则、代理规则）本质上是一张由客户端提前写好的判定表：哪一类流量送进代理通道，哪一类直接走本地网络，哪一类在两者之间按条件切换。它决定的是「路径」，而不是「速度」或「安全等级」。本文以合规与数据留存为主线，把模式差异、三端最短设置路径、例外取舍、验证与回退串成一条可复现的操作链，帮助你在不依赖猜测的前提下把配置落地。

一、先厘清定位：分流规则管什么，不管什么

很多人第一次打开分流设置时，会把它和「节点选择」「加速效果」混为一谈。实际上，分流规则只回答一个问题：这条连接应该从哪个出口出去。至于出口本身快不快、稳不稳，属于节点质量和本地网络环境的问题。把这两件事分开看，后面的排错路径会清晰很多。

分流规则同样不承担内容过滤、账号权限校验或终端安全策略的职责。它不会因为你写了某条规则就自动拦截某类访问，也不会替代企业内网的准入控制。如果你的诉求是「让某些应用彻底无法联网」，那属于系统级的应用管控，不在分流设置的语义范围内。理解这条边界，能避免大量无效配置尝试。

与全局模式、直连模式的分界

全局模式把所有流量都送进代理通道，判定最简单，但内网设备发现、本地打印、投屏这类依赖局域网广播的行为往往会被打断；直连模式则等于让分流规则「空转」，所有流量都不经过代理。分流规则的价值恰好落在两者之间：把必须走代理的业务精确挑出来，其余保持原样。什么时候该用哪一个，取决于你对「可控性」和「维护成本」的权衡，而不是哪个听起来更高级。

经验性观察：在日常办公场景中，多数用户最终会停留在「智能分流 + 少量自定义条目」的组合上，因为它把维护量压到了最低，同时保留了处理特殊域名的能力。这一趋势属于定性描述，具体表现因网络环境而异，建议按后文的验证步骤自行确认。

二、常见分流模式盘点：四种模式各自适合谁

不同平台与不同版本在文案上存在差异，但功能语义大体收敛在以下四类。下表用于建立心智模型，界面上的实际名称请以你安装的最新版本为准。

模式	判定依据	典型场景	需要注意的副作用
全局模式	全部流量走代理	临时排查、单一出口需求	局域网设备发现、本地打印易受影响
智能分流	内置规则库自动判定	日常办公、混合访问	规则库更新节奏不由用户控制
直连模式	全部流量不经代理	纯内网作业、临时对照测试	需要代理的业务会直接失败
自定义规则	用户定义的匹配条目	有明确域名清单的业务	写错顺序会导致与预期相反的走向

智能分流的优点是「几乎不用维护」，代价是判定逻辑对用户不透明。当某天你发现一个本该直连的域名走了代理，往往无法在界面上直接看到原因，只能通过自定义规则去覆盖。这一点在需要留痕的场景里尤其重要：如果你的团队需要解释「为什么这条流量这样走」，自定义规则的显式条目会比智能判定更好交代。

自定义规则则是另一种极端：完全可控，但完全依赖你的维护。它的可靠性上限，等于你清单的准确度。一个常见的失败模式是「只加了必须走代理的域名，忘了加必须直连的内网段」，结果内网访问在切换后集体超时。

三、规则优先级：为什么同一个域名两次走向不一致

分流设置里最容易踩坑的地方，不是「选哪个模式」，而是「同一条流量被多条规则命中时听谁的」。经验性观察，多数实现遵循「越具体越优先」的思路：应用或进程级规则优先于域名级规则，域名级规则优先于 IP 段规则，最后落到一条兜底策略上。但这条顺序并没有跨平台统一的强制标准，不同客户端可能给出不同结果。

因此更稳妥的做法不是背顺序，而是自己测一遍。构造一组互相冲突的规则——例如同一个域名同时写入直连和代理——然后观察实际走向。预期的可观测指标是：客户端连接日志中该域名的出口类型，或者访问 IP 归属查询页面时显示的出口地区。如果两次测试结果不一致，说明存在缓存或规则未重载，需要重新连接后再测。

四、三端最短可达路径：Android、iOS 与桌面端

下面给出的是通用的路径形态，而非逐字复刻的界面文案。不同平台、不同版本在命名与层级上确有差异，遇到对不上的情况，请以客户端内的实际显示为准，并按「设置 → 网络/路由相关分组」的思路逐层查找。

Android：连接前切换，切换后重连

打开客户端，进入设置分组，找到分流或路由模式入口，选择目标模式后保存，返回主界面断开再重新连接。Android 端的一个常见细节是：模式切换后如果未重连，部分系统版本上仍会沿用旧的连接会话，表现为「设置已改但行为没变」。验证方法是切换后先断开，等连接状态完全回落到未连接，再重新建立连接。

iOS：留意系统级授权状态

iOS 端的分流入口位置与 Android 相近，但受系统对网络扩展的约束，切换模式后有可能触发一次系统级确认，或需要重新授权网络配置。如果你的设备上开关置灰、点击无响应，优先检查系统的网络配置授权状态，而不是反复卸载重装。另一个差异点是 iOS 后台驻留能力较弱，长时间切后台再回来，规则可能尚未重新加载，建议观察连接状态指示后再判断是否生效。

桌面端：适合批量维护与导出

Windows 与 macOS 通常可以从托盘或菜单栏图标进入设置，分流配置的编辑体验更适合批量操作——自定义条目较多时，桌面端几乎是唯一实用的维护入口。桌面端的优势还在于配置文件更容易被定位与备份，这对需要留痕的场景很关键：你可以把导出的配置连同变更说明一起归档，形成可追溯的记录。

失败分支大致有三类：入口找不到（多为版本差异，可尝试在设置内搜索关键词）、选项置灰（多为当前未连接或权限未授予）、保存后不生效（多为未重连或缓存未刷新）。这三类的处置顺序建议是「先确认权限，再确认连接状态，最后才考虑重置配置」，因为重置会丢失你此前的规则积累。

五、自定义规则的写法：一个可复现的小例子

假设一个具体场景：某团队的日常工作需要访问公司内网的 OA 系统（域名示意为 oa.example-corp.com），同时使用一个海外 SaaS（域名示意为 app.example-saas.com）。内网必须直连，否则会因出口变化被网关拒绝；SaaS 必须走代理，否则访问不稳定。其余流量希望保持默认判定。

# 以下为示意语法，实际关键字与大小写规则请以客户端内置说明为准
DOMAIN-SUFFIX,example-corp.com,DIRECT
DOMAIN-SUFFIX,example-saas.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

这段示意里有两个设计意图值得说明。第一，把内网地址段显式列为直连，而不是指望「兜底策略恰好对」——兜底一旦被改成代理，内网就会整体失联。第二，末行的 FINAL 是兜底项，它的取值决定了「所有没被前面命中的流量」的去向，因此它应当放在最后，且需要有意识地选择，而不是随手留默认。

为什么强调「显式」？因为在需要审计的场景里，一条明确的规则可以被解释、被复核、被交接；而「当时大概是智能判定生效了」这种说法无法复现。规则条目的可读性，本身就是合规成本的一部分。

六、例外与取舍：哪些流量不该进代理通道

分流的难点从来不是「把该走代理的挑出来」，而是「判断哪些不该走」。以下几类值得优先纳入例外清单，理由各不相同。

• 私有地址段与本地回环。这类流量本就不出本机或本局域网，送进代理既无意义，又可能引入不必要的路径绕行。把它们固定为直连，是最低成本的稳定性保障。
• 局域网设备发现、打印、投屏。这类协议往往依赖广播或多播，代理通道对它们的支持普遍不完整，表现为「设备列表刷不出来」或「隔一段时间就掉」。
• 对出口 IP 稳定性敏感的业务。部分政务、银行、企业网关会做登录地与出口的一致性校验，出口频繁变化可能触发二次验证甚至临时限制。是否属于此类，需向业务方确认，不宜自行假设。
• 实时音视频会议。多一跳转发可能带来额外的抖动。是否值得，取决于会议服务本身的容灾能力，建议用同一场会议在两种模式下的实际感受做对照。

把这些纳入例外并非没有代价：例外清单越长，日后交接与排错时需要核对的面就越多。一个务实的做法是把例外分成「长期稳定」与「临时观察」两组，后者设定复核时间点，到期就清理。否则半年之后，没人说得清某条规则为什么还在。

七、合规与数据留存：让分流配置本身可审计

分流配置有一个容易被忽略的属性：它会间接暴露业务结构。哪些域名走代理、哪些走直连，往往能反推出内部系统的分布。因此配置文件在共享、截图、提交工单时都应视为敏感信息处理，必要时应做域名脱敏。

可审计性的最低要求是「变更可追溯」：谁在什么时间、因为什么原因、改了哪一条。这不需要复杂的系统，一张登记表加一份配置备份就能覆盖大部分场景。关键是养成习惯——在改动之前备份，在改动之后登记，而不是出问题才回头找。

登记项	填写要点	作用
变更时间	精确到分钟，注明时区	关联其他系统日志
变更人	实际执行者，非申请者	责任可追溯
变更内容	新增/删除的具体条目	支持差异比对
变更原因	对应的问题或需求编号	解释「为什么这样配」
回退版本	备份文件名或存放位置	支撑快速还原

关于连接日志：客户端是否提供日志导出、保留多久，不同版本与平台差异较大，本文不做断言。建议先在你实际使用的版本里确认一次，把能力边界写进内部说明，而不是默认「应该有」。如果日志能力有限，替代方案是用变更登记与配置备份构建最小可审计闭环。

八、验证：三步确认规则真的生效

配置完成不等于生效。建议按「路径—域名—日志」的顺序做三步验证，每一步都给出可观测的预期结果，便于他人复现。

1. 路径验证。访问一个显示出口信息的页面，观察显示的出口地区是否与你的规则预期一致。这一步验证的是「兜底策略与整体模式」是否正确。
2. 域名验证。针对你显式写入规则的那几个域名逐一访问，确认走向与该条规则一致。这一步验证的是「具体条目是否被正确解析」。
3. 日志验证。在客户端连接记录中查找对应条目，确认其出口类型标注与预期相符。这一步是留痕环节，也是日后复盘的依据。

任何一步不符合预期，都不要急着改规则，先确认三件事：连接是否已重新建立、规则是否已保存并重载、是否存在同名条目造成冲突。经验性观察，多数「规则不生效」最终都指向这三个检查点，而非规则语法本身有问题。

九、回退与止损：出问题时怎么快速还原

回退方案应该在改动之前就准备好，而不是出事之后再想。最简做法是每次调整前导出一份当前配置并重命名保存，文件名带上日期与用途，例如「分流配置-办公-调整前」。这样即便新配置完全不可用，你也有一个明确的还原点。

如果问题表现为「某些关键业务突然不可用」，而手头没有备份，可以先用模式切换做临时兜底：切到直连模式确认内网业务恢复，再切回并逐条排查新增规则。这个方法的价值在于快速区分「是分流规则导致的」还是「是其他因素导致的」，避免在错误的方向上耗时。

十、故障排查：按现象、原因、验证、处置推进

现象	可能原因	验证方法	处置
切换模式后行为无变化	未重连，仍沿用旧会话	断开至未连接状态后重连再测	养成「改完即重连」的操作习惯
个别应用始终走代理	应用级规则优先于域名规则	查看该应用是否有独立规则条目	调整应用级条目或临时移除
内网访问超时	私有地址段未列入直连	切直连模式对比是否恢复	补充私有网段直连条目
规则导入报错	语法或分隔符与内置格式不符	先用单条最小规则试导入	对照客户端内置说明逐步补齐

排查时建议一次只改一个变量。同时调整模式、增删规则、更换节点，最终即使恢复了也无法归因，下一次遇到同类问题依然要从头再来。这个习惯比任何一条具体规则都更有价值。

十一、适用与不适用场景清单

分流规则并非万能。以下判断标准可以帮助你在动手前先确认「这件事该不该由分流设置解决」。

适合的场景包括：内网与外部服务混合访问、需要为特定域名固定出口、多人共用一台终端但使用习惯不同、需要对配置进行留痕与交接。这些场景的共同点是「路径选择」本身就是问题核心，分流设置正好对症。

不适合的场景同样明确：如果你要解决的是「连接不稳定」，那多半是节点或本地网络问题；如果是「某些应用无法启动」，那可能涉及系统权限而非路由；如果是「需要按用户身份区分访问权限」，那属于身份与准入体系，分流规则做不到。把问题放对位置，比把功能用满更重要。

十二、最佳实践检查表：上线前的核对项

把下面这张表当作上线前的最后一道闸门，逐项确认后再交付使用。它不是强制流程，但能显著降低「上线后才发现」的概率。

• 私有地址段与本地回环是否已显式列为直连。
• 兜底策略是否是有意识选择的，而非沿用默认。
• 新增条目是否都在既有条目之前，避免被更宽泛的规则覆盖。
• 改动前的配置是否已导出备份，且文件名可辨认。
• 变更登记是否完成，含时间、执行人、原因三项。
• 是否已在三端各完成一次路径验证与域名验证。
• 是否确认了当前版本对日志导出的支持情况。
• 共享出去的配置或截图是否已做域名脱敏。
• 临时观察条目是否设置了复核时间点。
• 回退步骤是否写下来，且他人能照着执行。

检查表的意义不在于逐条打勾，而在于让「为什么这样配」有一个共同的落点。当团队里不止一个人维护这套配置时，这份共识比配置本身更难重建。

十三、常见问题

结语：把「配好」变成「说得清」

回到最初的问题——QuickQ分流规则支持哪些模式、怎么设置。模式层面，全局、智能分流、直连与自定义四条路径基本覆盖了日常需求；设置层面，三端的入口位置相近，真正的差异在于移动端更依赖重连与授权状态，桌面端更适合批量维护与备份。真正决定这套配置能不能长期用下去的，不是选了什么模式，而是你是否留下了变更记录、备份文件与验证步骤。后续即便客户端在入口或文案上有所调整，这套验证与回退流程仍然适用。

下一步可以从一件小事做起：打开当前使用的客户端，把现有分流配置导出一次，重命名为带日期的备份，然后在登记表里补上第一行记录。等你下次需要调整时，会庆幸当初做了这一步。