QuickQ分流规则如何设置实现按需加速？

一、先厘清边界：分流规则管的是“哪些流量进隧道”

在 QuickQ 这类网络加速与代理客户端里，出口策略通常只有三类：全局代理、全部直连、以及按规则分流。所谓 QuickQ 分流规则，本质上是一张“流量归属表”——命中规则的请求进入加密隧道，未命中的请求按本地原路由直接发出。它不负责挑选线路，也不负责压缩数据，只负责一件事：判断这条连接该不该被接管。把这一点想清楚，后面所有的模式选择与规则写法才不会混淆。

也正因为职责如此单一，分流经常被误解。很多人以为把规则配好就会“更快”，实际上规则只决定流量走向，速度变化来自“让不必要的流量别绕路”。举个具体的对照：一台开发机同时打开了内部代码仓库和海外文档站，若两者都走全局代理，内网访问会因为绕行而变慢甚至失败；改成“内网域名直连、文档站走代理”之后，两边都恢复到各自应有的速度。这里的收益不是代理变强了，而是被代理的东西变少了。

在进入配置之前，还需要提前说清三条不适用边界。第一，分流规则不能提升物理链路带宽，线路拥堵时配得再细也没用；第二，它不能替代 DNS 与路由层面的排障，规则正确但存在 DNS 污染的情况下依然会失败；第三，分流规则不是安全策略，它不提供访问控制、不做内容审计，把它当作合规工具会造成误判。理解这三点，后续的配置决策才不会走偏。

二、规则可用的四种维度，以及各自的能力上限

不同平台的客户端开放的维度并不一致，能否使用某个维度，取决于你安装的版本是否实现了它。以下四种是最常见的归类方式。理解它们的匹配粒度，比记住菜单名字更重要——菜单会随版本改名，匹配逻辑相对稳定。

2.1 域名维度：最贴近“业务意图”

按域名匹配是分流里可读性最好的一种。你写进去的是 example.com 这样的业务标识，半年后再看规则文件，仍然知道当初为什么这么写。后缀匹配（把子域名一并纳入）通常比精确匹配更实用，因为大多数站点的主域与 API 子域不同源，只写主域会漏掉接口请求。

它的能力上限也很明确：域名规则对直接以 IP 访问的连接无效，对使用 CDN 共享 IP 的站点也可能产生误判。经验性观察是，纯域名规则在常规网页浏览场景覆盖度很高，但在客户端软件、游戏、物联网设备这类“硬编码 IP”的场景里会明显漏流量。遇到漏流量，先判断对方是怎么寻址的，再决定要不要补 IP 规则。

2.2 IP 与网段维度：兜住不走域名的连接

IP / CIDR 规则适合两类情况：一是某些服务确实以固定地址提供服务，二是你需要把一个内网段整体排除在外。CIDR（无类别域间路由，可以理解为“用斜杠位数表示一段地址范围”的写法）比逐个列 IP 更可维护，例如把整个办公网段放进直连列表，就不必担心新增设备漏配。

需要提醒的是，公网服务的 IP 会漂移。把某个 SaaS 的 IP 写死进规则，短期有效，长期会随对方扩容而失效，而且失效时往往没有明显提示，只表现为“某天忽然连不上”。所以 IP 规则的定位应该是“补充”而不是“主力”，主力仍然交给域名。

2.3 应用维度：区分“谁在发请求”

按应用分流（有的客户端写作“分应用代理”）的思路是不看目标地址，只看发起请求的进程或 App。它在移动端与桌面端的可用性差异较大：Android 与桌面系统上这一维度较为常见，iOS 受系统网络扩展机制限制，是否提供取决于客户端实现。

应用维度的优点是“一劳永逸”，装上就不必关心域名；缺点是不可审计——半年后你很难从“允许列表里有某个 App”反推出当初的合规理由。因此在需要留痕的环境中，建议应用维度只用于粗粒度划分，细粒度仍写域名，让规则的“为什么”留在文字里，而不是留在勾选框里。

2.4 内置地区与规则集：省事但不可审计

不少客户端会提供“国内直连 / 国外代理”这类预设。它的价值是上手成本几乎为零，代价是规则内容对你不可见，也无法版本化管理。如果你的场景只是个人日常使用，预设足够；如果涉及团队协作或需要说明“数据去了哪里”，预设就不能作为唯一依据。比较稳妥的做法是把预设当成起点：先用它跑通，再逐步把关键业务替换成自己写的显式规则。

三、分平台最短可达路径（以当前最新版本为例）

下面给出的是“进到分流配置区”的经验性路径归纳。QuickQ 各版本界面迭代较快，菜单文案可能写作“分流设置”“分应用代理”或“路由模式”，位置一般在设置页的网络/代理分组下。请以你实际安装版本为准；路径不通时，优先在设置页搜索关键词，而不是逐个菜单翻找。

3.1 Android

最短路径：打开 QuickQ → 底部“设置” → 找到“分流”或“路由模式” → 切换为“自定义/规则” → 进入规则列表添加入口。Android 端通常还能看到“应用分流”开关，开启后可按 App 勾选是否走代理。若你的版本没有“自定义”选项，说明该版本仅支持预设模式，此时应升级，或改用桌面端维护规则。

3.2 iOS

最短路径：QuickQ → “我的/设置” → “分流设置” → 选择模式。iOS 端受系统网络扩展的约束，可配置项通常比 Android 少，多数版本只提供模式切换与域名列表，应用维度的可见性不稳定。若你在 iOS 上找不到某个选项，不要反复重装；先在桌面端把规则整理成清单，再回到 iOS 按清单手工录入，效率更高。

3.3 桌面端（Windows / macOS）

最短路径：主界面右上角或侧栏的“设置”齿轮 → “网络/代理设置” → “分流规则” → 编辑规则列表。桌面端通常是维护规则最舒服的地方：可以批量粘贴、可以对照文档逐条核对。如果在桌面端也找不到该入口，先确认当前是否处于“全局”模式——部分客户端只在非全局模式下才展开分流配置区。

四、以合规与数据留存为主线：为什么要把代理范围压到最小

分流规则有一个常被忽略的属性：它同时是一条数据边界。进了隧道的流量会经由代理节点转发，未进隧道的流量则在自己所在的网络里闭环。因此“哪些域名走代理”这个问题，等价于“哪些业务数据会离开本地网络”。在需要留痕的组织里，这句话必须能被回答，而不是“大概就是那些吧”。

最小化代理范围带来的好处有两层。业务层面，它减少了不必要的绕行，让内网系统、本地打印、局域网共享这类流量保持在原网络内，避免出现“代理开着就连不上共享盘”的窘境。合规层面，它把“数据出站”的清单从模糊变成可枚举——你能拿出一份规则表，说明只有这几个域名会走隧道，其余一律直连。反过来，如果采用“全局代理 + 少量例外”，默认状态就变成了全部出站，例外清单反而成了唯一的安全网，一旦漏写就会扩大暴露面。

所以取舍很清楚：能白名单就不要黑名单。白名单模式默认不出站，漏配的后果是“某个站点打不开”，可感知、可修复；黑名单模式默认全出站，漏配的后果是“某份数据悄悄出去了”，不可感知。后者的风险等级明显更高——前者是体验问题，后者是事故。

4.1 让规则变成可审计资产：三个可落地动作

第一，给规则表加注释列。每条规则旁边写清楚“业务用途 + 责任人 + 添加日期”，哪怕只是纯文本文件。第二，纳入版本管理。若客户端支持导出规则，导出后放进 Git 或共享文档；若客户端不支持导出（多数消费级客户端确实不提供），退而求其次，用截图 + 手工整理的清单双份留存，并在每次修改后更新。第三，设置复核节奏，例如每季度对照业务系统清单过一遍，把已下线的服务从规则里删掉。

这套做法听起来笨，但它的价值在于“出事时能自证”。当你需要回答“过去三个月有哪些流量走了代理”时，一份带注释的规则变更记录，远胜过回忆。换句话说，你维护的不是配置文件，而是一段可以复述的历史。

五、场景映射：三种典型配置形态怎么选

5.1 白名单形态：跨境办公与研发联调

做法是把模式切到“仅代理以下规则”，然后只把确实需要境外访问的域名写进去。原因在于这类场景的流量构成中，内网系统、代码托管、即时通讯往往占大头，全部代理会让内网访问失效。边界是：白名单需要持续维护，新上线的境外服务如果不补规则就会访问失败，因此要约定“谁引入新服务谁补规则”的流程。一个可直接复用的例子是：把公司内网域名段、本地打印服务地址放进直连排除项，把境外文档站与包管理源放进代理项，其余保持默认直连。

5.2 黑名单形态：个人日常与临时排障

做法是保持全局代理，只把本地网络、内网地址、需要低延迟的服务排除。原因是这类用户对“漏配”的容忍度高，而对“配得太细导致天天出问题”的容忍度低。边界同样明显：一旦涉及敏感数据，黑名单形态就不再合适，因为它默认放行一切。经验性观察是，黑名单模式下的规则条数通常远少于白名单，维护成本低，但可审计性差，不适合需要对外说明数据流向的场景。

5.3 混合形态：按设备分而治之

更贴近现实的做法，是不追求全组织统一。办公台式机采用白名单，个人手机采用黑名单，测试机采用“应用维度 + 全局”。三套策略各自独立，互不干扰，也让每台设备的维护成本与其重要程度相匹配。这种形态的前提是你接受“策略不统一”这件事，并用文档把差异写清楚——否则半年后没人记得，为什么这台机器和那台机器的行为不一样。

六、优先级与冲突：两条规则同时命中时听谁的

这是分流配置里最容易踩坑的地方。多数客户端并不会在界面上明确展示匹配顺序，于是出现“我明明把 A 放进了直连，它还是走了代理”的困惑。常见的三种裁决逻辑是：按列表顺序自上而下命中即停、按匹配精确度（越具体越优先）、以及显式排除优先于包含。

不同实现之间没有统一答案，所以不要凭直觉假设。可复现的验证方法是：写两条互相冲突的规则（例如把某域名同时加入代理与直连），保存后访问该域名，观察实际走向；然后把两条规则的先后顺序对调，再观察一次。如果行为随之改变，说明是顺序优先；如果行为不变，说明是精确度或排除优先。把结论记在你的规则文件顶部，后续就不用反复试。

由此可以得出一条实践建议：不要依赖优先级，而要让规则集合本身无冲突。同一个对象在表里只出现一次，是成本最低的防错方式。规则表超过二三十条之后，人工去重就变得不可靠，此时按业务分组、每组内保持单一来源，比事后排查更有效。

七、例外清单：该放进去的与不该放进去的

“例外”指的是那些明确不走代理的目标。它决定了哪些数据不出站，因此值得单独列出来讨论。列得太少会打断日常办公，列得太多又会削弱分流的实际意义。

• 应当纳入例外的：内网与办公网段、本地回环与局域网设备地址、公司自建的协同与代码托管服务、需要就近接入的本地化 CDN、以及任何承载敏感数据的内部系统。
• 应当谨慎纳入例外的：公有云的对象存储与 API 端点。它们常与外部依赖共享域名后缀，一刀切排除可能连带影响正常业务。
• 不应纳入例外的：出于“觉得这样更快”而临时加入的公共站点。这类临时项是规则膨胀的主要来源，且没有人会记得清理。

判断标准可以简化成一句话：这条流量如果不出站，会不会造成数据泄露？会，就必须进例外；不会，就没有理由例外。按这个标准过一遍，例外清单通常能从几十条压缩到个位数——数量的下降本身，就是判断标准起作用的信号。

八、副作用与缓解：规则配好之后可能出现的新问题

分流不是只带来好处的单向操作，它会引入几类可预期的副作用。提前知道这些副作用，比出问题再回滚划算，也更容易在同事提问时给出解释。

DNS 解析路径不一致。当代理与直连的流量使用不同的 DNS 解析时，同一域名可能得到不同结果，表现为“有时能打开有时打不开”。缓解方式是把解析也纳入规则考虑：让走代理的域名使用代理侧的解析，直连的域名使用本地解析，并避免两套解析互相污染。验证方法是分别在不同模式下查询同一域名的解析结果，对比是否一致。

CDN 就近失效。把本该本地就近接入的静态资源强行代理，会让访问绕远。这在视频、大文件下载场景下尤其明显。缓解方式是只代理接口域名，静态资源域名交给直连；如果站点把两者混在同一域名下，就只能在“功能可用”与“加载更快”之间做取舍。

登录风控触发。同一账号在短时间内出现来源地跳变，可能被服务方判定为异常。这个副作用没有技术手段完全规避，能做的是保持出口稳定——不要频繁切换节点，也不要把同一账号的流量在代理与直连之间来回切。经验性观察是，稳定的单一出口比“看起来更优”的动态出口更少触发校验。

内网访问断裂。这是新手最常遇到的。症状是配置完成后共享盘、打印机、内部管理后台全部不可达。原因通常是例外清单漏掉了内网网段。处置方式很简单：先把内网常用网段整体加入直连，再逐步细化。先粗后细，几乎可以避免这一类问题。

九、验证与观测：怎么确认规则真的生效了

规则写完不等于生效。建议按下面的顺序做一次完整验证，四步都能过，才算配置闭环。顺序上先看出口归属，再看内网连通，最后确认解析与回退，是因为前两项最容易暴露明显错误。

验证项	操作	预期可观测结果
出口归属	在浏览器访问任一 IP 查询页，观察返回的出口地址	代理名单内的站点返回节点地址；直连站点返回本地运营商地址
内网连通	访问内网共享目录或管理后台	正常打开，无超时
解析一致性	对同一域名分别执行解析查询	代理与直连两条路径的结果符合预期，未出现互相污染
回退可用	临时切回全局模式再切回规则模式	切换后行为可复现，规则未丢失

这套验证不需要额外工具，浏览器加系统自带命令就够。把它做成一份检查表，每次大改规则后跑一遍，能省掉大量“感觉不对但说不清哪不对”的排查时间。

十、故障排查：按现象定位，而不是按猜测重装

分流相关的问题大多有明确的因果链。下面按“现象 → 可能原因 → 验证 → 处置”整理常见四类。排列顺序大致按出现频率从高到低，可以自上而下依次排除。

现象一：所有站点都走代理，规则像没生效。可能原因是当前处于全局模式，模式切换覆盖了规则表。验证方式是看主界面的模式标识，或临时改一条规则观察行为是否变化。处置是确认模式处于“规则/自定义”，并检查是否存在更高优先级的预设规则集在生效。

现象二：某个站点时好时坏。可能是域名后缀匹配不全，主域走了代理而接口子域走了直连。验证方式是在同一页面反复刷新，同时观察请求分布。处置是把该服务涉及的子域补全，或改用更宽的后缀匹配。

现象三：内网设备集体失联。可能原因是例外清单未覆盖内网网段。验证方式是临时切回直连模式，看内网是否恢复。处置是把常用内网网段整体加入直连，再按需细化。若切回直连后仍异常，问题就不在分流，应转向本地网络排查。

现象四：规则保存后重启客户端被重置。可能是该版本的规则未持久化，或配置写在临时路径下。验证方式是保存后退出再启动，观察规则是否还在。处置是换用会持久化的版本，或在每次更新后按留存的规则清单重新录入——这正是前文强调留存清单的实际用途。

十一、适用与不适用：什么时候该用分流，什么时候别折腾

适用分流的典型特征有三个：一是流量构成明显混合，既有需要出境的服务，也有大量本地与内网访问；二是对“哪些数据出站”需要给出解释；三是使用设备相对稳定，规则维护成本可控。满足其中两条，分流就值得配。

反过来，以下情况不建议投入精力：只有一两个目标站点需要访问，直接全局代理再切回来更省事；设备频繁更换且无法同步配置，规则永远处于“刚配好就换机”的状态；或者所在网络本身对代理有严格管控，此时应先解决合规前提，而不是研究规则写法。这些场景下，分流的收益会被维护成本吃掉，配置越细反而越像负担。

十二、最佳实践清单：一份可以直接照着做的决策规则

1. 先定形态再写规则。能白名单就白名单，把“默认不出站”作为起点。
2. 内网优先。动手写第一条代理规则之前，先把内网网段与本地服务放进直连。
3. 域名为主、IP 为辅。IP 规则只用于兜底，且定期复核是否仍有效。
4. 同一对象只写一次。规则表内杜绝重复与冲突，避免依赖优先级裁决。
5. 每条规则带注释。写清用途、责任人与添加时间。
6. 修改前后各留一份。截图或文本均可，至少保留最近两个版本。
7. 按季度复核。下线服务对应的规则一并删除，防止规则表膨胀。
8. 改完必跑验证四步。出口归属、内网连通、解析一致性、回退可用。
9. 不要在没有留痕的情况下做“临时例外”。临时项如果没有登记，最后都会变成永久项。

十三、版本差异与迁移：换端换版时怎么不翻车

QuickQ 的客户端在移动端与桌面端之间、不同大版本之间，分流配置区的组织方式并不完全一致。截至当前的最新版本，常见差异集中在两处：一是应用维度是否开放（移动端差异明显），二是规则是否支持批量编辑（桌面端通常更完整）。因此跨端迁移时，不要假设配置能自动同步。

稳妥的迁移顺序是：先在旧设备上把规则导出或抄成清单，再在新设备上按清单重建，最后跑一遍验证四步。如果新端缺少某个维度（例如 iOS 上没有应用分流），就把该维度的规则改写成域名规则作为等效替代。迁移完成后，旧设备不要立刻卸载，保留一段时间作为对照，出问题时能快速判断是“规则写错”还是“新版本行为不同”。

十四、常见问题（FAQ）

十五、收尾：把规则当成一份需要维护的文档

回到最初的问题——QuickQ 分流规则怎么设置才能实现按需加速。技术动作其实不复杂：选对模式、把内网放进直连、按域名把需要出境的服务列进代理、保存后跑一遍验证。真正决定长期效果的，是把它当作一份需要维护的文档来对待：写注释、留版本、定期复核、无冲突。

如果只能记住一句话，那就是默认不出站、例外可枚举、变更可追溯。这三点同时满足时，分流既快得住，也说得清。下一步建议你从最小可用开始：先只配三条规则——一条内网直连、一条境外文档站代理、一条保留观察，跑完验证四步之后再逐步扩充。规则表短的时候最容易被认真对待，等它长到几十条再想治理，成本会高得多。