QuickQ中文如何设置分流规则以优化网络访问？

分流规则在 QuickQ 中文里到底解决什么问题

在 QuickQ 中文里，分流规则（业界常称 Split Tunneling，也译作分应用代理、流量分流）要回答的核心问题只有一个：让必须走代理的流量走代理，让不该走代理的流量留在本地直连。它本质上不是一枚「加速开关」，而是一组路由判据——由你告诉客户端哪些目标属于「代理侧」，剩下的交回操作系统，按本地网络的方式处理。

为了避免后面出现大量误操作，先把三个容易混淆的概念分开。第一是节点选择，那是在换出口位置，并不改变「哪些流量被接管」；第二是系统代理或虚拟网卡开关，那是总闸，决定代理能力在操作系统层面是否可用；第三才是分流规则，它只在前两者之上做筛选。换句话说，节点再快，规则写反了照样白搭。

边界同样要提前说清楚。分流规则通常只约束经过客户端的流量，路由器级或企业级的路由策略不受客户端规则影响；反过来，如果某个应用使用私有协议栈直接建连、绕过了系统代理层，客户端根本抓不到这条流量，规则自然也无从生效。后面讨论排查思路时，这个前提会反复用到。

先定指标：你优化的到底是延迟、带宽还是可用性

很多教程一上来就让你填规则，但规则本身没有对错，只有是否匹配目标。所以在动手之前，先明确自己属于哪一类需求。三类需求对应的规则设计差异很大，混在一起写，往往两头都不讨好。

• 延迟敏感型：视频会议、实时协作、联机游戏。判定指标是首包时间与抖动，规则要尽量精简，避免多层匹配拖慢建连。
• 带宽敏感型：大文件同步、代码仓库拉取、素材上传。判定指标是长连接的稳定吞吐，规则要防止中途切换出口导致连接重置。
• 可用性敏感型：内网系统、NAS、打印机、本地开发调试服务。判定指标是「必须直连成功」，这类目标一旦被误代理，表现为超时而非报错，排查成本最高。

把这三类需求写下来贴在旁边，再去看下面两种方案，你会更容易判断自己该选哪一套。反过来说，如果只是「感觉网慢」，先不要动规则，先确认慢在哪一段——延迟、带宽与可用性三者的表现形态并不相同，混着改只会让变量越来越多。

分流的判定顺序：域名优先，其次 IP，最后才是应用

绝大多数客户端的分流引擎，判定顺序都是从具体到宽泛：先看目标域名是否命中规则表，再看目标 IP 是否落在某个网段，最后才回退到「按应用」这一层。「按应用」听起来最直观，实际上它是最粗的粒度，因为一个应用内部往往会同时访问内网和外网。

举一个具体场景：某个办公客户端既需要连公司内网的接口，又要加载外部的静态资源。如果你把这个应用整体划进代理侧，内网接口会因为绕行而超时；整体划进直连侧，外部资源又加载不出来。此时更合适的做法是在域名层做区分，让内网域名走直连、外部域名走代理，而不是在应用层做一刀切。

理解这个顺序还有一个好处：当规则「看起来写了却没生效」时，你能快速判断它是不是被更高优先级的规则提前命中了。经验性观察是，多数「规则失效」案例并非引擎坏了，而是存在一条更靠前的宽泛规则把流量截走了。

动手前的三项准备

分流规则属于那种「改错一次要排查半天」的配置，所以前期准备比手速更重要。下面三项建议在修改前完成，成本很低，却能省下大量回滚时间。

1. 记录当前配置：把现有的规则列表、开关状态截图或另存一份。不同平台的导入导出能力不一样，截图是最稳妥的兜底。
2. 列一张目标清单：写下三到五个「必须直连」和「必须代理」的具体目标，作为后续验证的基准，而不是凭感觉判断快慢。
3. 确认客户端版本与平台：分流能力的粒度与客户端版本、操作系统强相关。以下涉及的界面名称均以实际安装版本为准，不同平台可能叫「分流」「分应用代理」「规则」或「路由」。

操作路径：三大平台的最短可达路线

下面是各平台常见的操作入口。由于客户端会随版本调整布局，这里给出的是「逻辑层级」而非固定按钮名，你按层级去找，基本都能定位到。

Android：粒度最细，优先用这一端做实验

最短路径通常是：打开客户端 → 进入「设置」→ 找到「分流」或「分应用代理」类入口 → 选择「按应用」模式 → 在应用列表中勾选需要走代理的条目。Android 端一般同时提供「按应用」和「按规则」两种粒度，这是它相对其他平台的优势——既能按进程切分，也能按目标切分。

失败分支与回退：如果勾选后目标应用仍无法访问，先切换回「全局」验证代理本身可用，再切回「按应用」逐条排查。若列表里找不到某个应用，可能是安装来源导致包名识别异常，可尝试改用域名规则兜底。

iOS：粒度偏粗，规则要写得更保守

iOS 因为系统网络扩展的权限限制，多数客户端不提供真正的「按应用」选择，只提供「全局」与「规则（按域名）」两档。最短路径一般是：客户端首页 → 设置 → 代理模式/分流 → 选择规则模式。如果你在 iOS 上找不到应用列表，通常是平台限制而非客户端故障。

正因为粒度粗，iOS 上的规则列表要写得更保守：把内网域名、局域网网段明确加入直连，把必要的外部目标加入代理，其余保持默认。经验性观察是，iOS 端的误伤成本高于 Android，因为它缺少应用层这一道缓冲，一旦出错只能回到规则表层去定位。

桌面端（Windows / macOS）：规则表是主战场

桌面端通常提供三档模式：全局、规则（也写作 PAC 或规则表）、直连。最短路径是：主界面 → 设置/偏好 → 代理与网络 → 分流模式 → 选择规则模式，然后进入规则编辑区。桌面端更适合维护较长的域名后缀列表，也更容易做版本化的备份。

需要留意的是，桌面端可能同时存在「系统代理」与「虚拟网卡」两种接管方式，两者对分流的支持程度不同。部分应用（尤其是自带网络栈的开发工具）在系统代理模式下不会被接管，此时规则写得再细也不生效，需要改走虚拟网卡模式。这属于典型的「规则没问题、接管层没到」。

方案 A：规则优先，直连为默认

规则优先的思路是「默认直连，只有明确列出的目标走代理」。它的配置点少、影响面小，适合绝大多数以本地办公为主、只有少数外部服务需要加速的场景。

代价也很明确：新出现的域名不会自动被接管，你需要手动补充规则。换句话说，它把维护成本前置了，换来的是内网访问、本地服务、局域网设备几乎不会受到干扰。如果你所在的环境网络结构经常变动，这套方案会让你频繁回来改规则。

什么时候不该用：当你需要访问的外部目标非常分散、且难以提前枚举时，规则优先会让你疲于奔命。此时更适合下面的方案 B。

方案 B：全局优先，白名单做例外

全局优先的思路正好相反：默认全部走代理，只把「确定不能绕行」的目标列入直连白名单。它的好处是覆盖面完整，新增目标基本不需要维护；坏处是误伤范围大，一旦某个内网地址被代理，你会同时看到多个本地服务不可用。

白名单的内容通常高度稳定，主要就是内网网段、本地回环、局域网私有地址段以及少数内部域名。这恰恰是它的优势——需要维护的规则少且变化慢。缺点则在于：如果白名单写漏了一台内网设备，你在那台设备上的操作会静默超时，而不是弹出明确的错误，排查时缺少明显的报错线索。

什么时候不该用：如果你对当前网络环境的内网构成不够熟悉，直接上全局优先会制造大量难以定位的问题。建议先在 Android 端用按应用模式验证一圈，再迁移到全局方案。

两种方案的对照与选择建议

一个折中做法值得考虑：在桌面端用方案 A 做日常，在移动端用方案 B 兜底，因为移动端的使用场景本身就是「以外部访问为主」，内网暴露面更小。这不是官方推荐，只是从维护成本出发的经验性取舍。

规则怎么写：域名后缀、通配与网段的实际写法

规则表的书写规则各家略有差异，但基础元素是共通的。绝大多数实现都支持域名后缀匹配、简单的通配符，以及 CIDR 形式的网段匹配。书写时最重要的原则是从窄到宽、从具体到宽泛，否则容易被更靠前的宽规则截胡。

下面是一份示意性的规则片段，域名使用了 RFC 保留的示例域名，仅用于说明格式，不指向任何真实服务。具体关键字（如 PROXY / DIRECT）请以你所使用客户端的实际写法为准。

注意上面两行的顺序：具体的子域名写在通配之前。若把通配放在前面，具体行永远不会被命中，这也是「明明加了一条规则却没反应」的最常见原因。写完规则后，务必用你前面列好的目标清单逐条验证。

五类必须进例外的流量

不管你选择哪种方案，下面五类流量都建议放在直连侧。它们共同的特点是：绕行没有收益，但误代理的代价很高。

• 内网域名与办公系统：这类目标一般只在内网解析，一旦走代理会直接解析失败或连接超时。
• 私有网段：如 10.x、172.16–31.x、192.168.x 以及回环地址，属于局域网通信范畴。
• 本地开发与调试端口：本地起的服务绑定在回环地址上，代理接管后反而会打断调试链路。
• 局域网设备：打印机、NAS、投屏设备，通常依赖组播或局域网发现协议，绕行后设备直接「消失」。
• 系统更新与证书校验：部分系统的更新与证书校验链路对中间转发较为敏感，绕行可能出现反复重试。此处属于经验性观察，具体表现因系统版本而异。

实际配置时不必逐条背诵，抓住一条原则即可：凡是只在本地网络内可达、或只在本机自用的目标，一律放直连侧。这样即便后续新增了设备或服务，也不容易踩到误代理的坑。

副作用与缓解：分流不是只赚不赔

分流带来的第一个副作用是DNS 解析路径的分裂。当同一域名在不同规则下由不同服务器解析时，可能出现拿到 CDN 节点与出口不匹配的情况，表现为「能连上但很慢」。缓解方式是让代理侧域名的解析尽量走代理解析，直连侧走本地解析，不要交叉。

第二个副作用是规则表的可读性衰减。规则积累到几十条之后，没人记得哪条还在生效。建议每季度做一次清理，把命中率为零的条目删掉，删之前先备份。这是一个纯粹的维护习惯问题，与客户端能力无关。

注意：清理规则前请务必备份。规则一旦删除，若某条目标依赖它，问题不会立刻显现，而是在下次访问时以超时形式出现，回溯成本很高。

与第三方工具协同时的最小权限原则

有些用户会把规则表交给外部脚本或第三方工具生成，这在目标数量多的时候确实省事。但要注意两点：一是脚本生成的内容应当先人工过一遍再导入，避免宽泛的兜底规则把内网一并接管；二是不要把包含内网地址、主机名的完整规则表上传到不可信的在线服务。

最小权限原则在这里的具体落地方式是：只给生成工具提供「需要代理的目标列表」，不要提供「需要直连的内网清单」。前者即便泄露也只是暴露访问偏好，后者则可能暴露内部网络结构。授权范围越小，后续出问题的可能性越低。

监控与验收：怎么确认规则真的生效

规则改完不等于生效，需要一次可复现的验收。下面这套流程适用于所有平台，不需要额外工具，用你前面列的目标清单即可完成。

1. 打开规则列表，逐条核对：直连目标是否都在直连侧，代理目标是否都在代理侧，且没有更靠前的宽泛规则覆盖它们。
2. 依次访问清单中的直连目标，预期是连接建立成功、耗时与改动前没有明显差异。若出现明显变慢，说明它可能被接管了。
3. 依次访问清单中的代理目标，预期是成功建立连接。若失败，先切回全局模式确认代理链路本身是否正常，再判断是不是规则问题。
4. 观察一段时间内的连接稳定性，重点看是否有中途断开或反复重连。这类现象通常指向出口切换而不是规则错误。

验收的关键是「有预期」。如果你没有事先写下清单，那么「感觉好像快了点」这种判断几乎无法支撑后续决策，也无法在出问题时回滚到确定的状态。

故障排查：现象、可能原因、验证方式与处置

排查的核心是先分类，再动手。下面按常见现象分组，每一组都给出了可复现的验证步骤，你可以照着做一遍再决定改什么。

特别提醒「部分应用完全不受影响」这一类：它和规则无关，属于接管层的问题。很多人会在这里反复改规则，最后发现改的是无关变量。遇到这种情况，先确认接管方式，再回头动规则表。

适用与不适用场景清单

把边界写清楚，比再多给十条技巧都有用。下面这份清单可以直接拿来做准入判断。

适合配置分流规则的场景：同时存在内网访问与外部访问需求；有若干明确的、长期不变的目标清单；对本地设备发现、调试端口有依赖；愿意每季度花半小时维护一次规则表。

不太适合的场景：只有单一出口需求、无需区分目标；所在网络结构频繁变动，规则追不上变化；不具备基本的网络排错能力，一旦出问题无法自行定位。后一种情况建议先保持默认模式，等到确实遇到具体痛点再考虑分流。

最佳实践检查表

最后把前面散落的要点收拢成一份可以直接执行的清单。它的作用不是教你新东西，而是防止你在改配置时漏掉某一步。

• 改动前先备份当前规则与开关状态。
• 先写下三到五个必须直连、必须代理的验证目标。
• 规则顺序遵循从窄到宽，具体行永远在通配行之前。
• 内网域名、私有网段、回环地址一律放直连侧。
• 一次只改一类规则，改完立刻用清单验收。
• 出现「规则无反应」时，先怀疑顺序，再怀疑引擎。
• 出现「应用完全不受影响」时，先检查接管方式。
• 定期清理长期未命中的规则，删除前先备份。

这份清单不需要逐条背下来，更实际的做法是把它存成一份本地备忘，每次动配置前扫一眼。真正容易出问题的往往不是复杂的那几条，而是被忽略的基础动作。

结语：先定目标，再写规则

回到最初的问题，QuickQ 中文的分流规则之所以容易配错，往往不是因为界面复杂，而是因为目标没定清楚。先回答「我要优化的到底是延迟、带宽还是内网可用性」，方案的选择就会自然收敛：目标固定、以内网为主就选规则优先；外部目标分散、需要稳定覆盖就选全局优先并维护好白名单。

下一步建议很具体：现在就写下你的三到五个验证目标，备份当前配置，然后在 Android 端用按应用模式做一次小范围实验。确认行为符合预期后，再考虑迁移到桌面端的规则表。整个过程不需要一次做对，只需要每一步都可回退。

从更长的周期看，分流能力的粒度与界面文案会随客户端版本迭代而调整，因此本文给出的路径描述应以你安装后实际看到的界面为准。经验性观察是，版本升级后规则表本身通常会被保留，但开关状态与接管方式有可能回归默认；升级之后重新核对一遍规则与模式，是成本最低的一次保险。