QuickQ分流规则如何指定应用走代理？功能入口在哪里？

在 QuickQ 中文客户端的日常使用中，真正让人反复搜索的往往不是节点速度，而是分流规则——一套用来决定哪些流量交给代理、哪些流量走本地直连的策略。很多人的需求非常具体：浏览器要走出去，公司 privacy tool 客户端不能被打断，局域网 NAS 和网络打印机必须保持本地访问。这三种诉求指向的方向彼此冲突，塞进同一个开关里，结果必然是互相踩脚，于是才需要按应用（按进程）来指定代理范围。

本文按“问题—约束—解法”的顺序展开：先说明分流规则管什么、不管什么，再给出 Android、iOS 与桌面端的功能入口位置与最短可达路径，接着对比白名单、黑名单与全局加例外三种做法，最后落到验证方法、故障排查和“什么时候不该用”的判断标准。需要提前说明的是，QuickQ 各平台客户端的菜单命名会随版本调整，本文以“能力描述 + 常见命名”的方式给出定位，并在每处标注替代入口，请以你实际安装的版本显示为准。

一、分流规则到底管什么：先划清三条边界

分流规则（也叫路由规则、代理规则）本质是一张匹配表：对每一条出站连接，客户端读取目标地址、端口，部分实现还能读到发起连接的进程名，然后从“走代理”“直连”“拒绝”三种动作里选一个执行。它解决的是路径选择问题，不解决线路质量问题——把这两件事混为一谈，是后续大量无效试错的根源。

1.1 与“智能分流”“绕过局域网”的区别

智能分流是内置的粗粒度策略，通常依据目标 IP 归属地或内置域名清单判断，不需要你逐个应用配置。它的便利之处在于开箱即用，局限在于无法表达“同一台机器上，A 软件走代理、B 软件必须直连”这种按进程的诉求。经验性观察是：一旦需求从“按网站”迁移到“按软件”，智能分流就开始力不从心，此时才需要回到应用列表。

1.2 与节点选择、协议设置的区别

节点决定“从哪条线路出去”，分流规则决定“哪些流量需要出去”。二者调优方向相反：节点选错，表现是整体都慢；规则配错，表现是某个软件时好时坏、换个应用就正常。定位问题时先分清属于哪一类——如果是所有应用一起变慢，先查线路；如果只有特定客户端异常，先看规则——如此能省掉大量盲试。

1.3 能力的现实边界

按应用分流对系统能力有要求，这一点必须提前认知。Android 依赖系统的 privacy toolService 单实例机制，同一时刻通常只能有一个 privacy tool 类应用处于生效状态，两个代理客户端同时开启会互相顶掉；iOS 的 Network Extension 对“按进程”的可见度更弱，多数客户端只能做到按域名或 IP 分流；桌面端在 TUN／虚拟网卡模式下识别进程最完整，而在“系统代理”模式下往往只能看到 HTTP/HTTPS 流量，UDP 流量与部分自带网络栈的应用会直接绕过代理。三条限制叠加起来，就决定了同一个功能在不同平台上的表现并不对等。

二、功能入口在哪里：分平台的最短可达路径

QuickQ 把与分流相关的配置统一放在“设置”层，而不是首页加速按钮旁边。因此第一步不是去找“分流规则”这四个字，而是先进入设置区域，再找与路由、模式、应用相关的条目。换言之，先认清所在平台的设置结构，比背下某个具体菜单名更有用。

2.1 Android 端

最短路径是：打开客户端，进入底部导航或侧边抽屉中的“设置”，找到“分流设置”“路由模式”或“应用分流”一类条目，进入后会出现应用列表或模式选择页。若要按应用指定，需要在列表里逐个勾选；勾选完成后一般要断开重连一次，规则才会随新会话加载。

如果设置里没有对应条目，可以回到主界面查看是否存在“全局／智能／规则”这样的模式切换开关，部分版本把应用选择藏在模式切换的二级页面里。另一种可能是首次连接时系统弹出的 privacy tool 授权对话框被拒绝了——这种情况下列表仍然可以编辑，但规则不会真正生效，重新连接并在系统弹窗中允许即可。

2.2 iOS 端

iOS 的入口通常在“设置 → 分流／路由 → 模式选择”，能看到的档位取决于版本。若只有“全局”与“智能”两档、找不到应用清单，说明当前版本未向该平台开放按进程选择能力。这不一定是配置错误，而是平台限制下的取舍：iOS 上更现实的做法是改用“全局 + 域名/IP 例外”，或直接采用智能分流近似实现。

2.3 Windows 与 macOS 桌面端

桌面端一般在“设置 → 网络／代理 → 分流模式”中，同一页面下方常会附带应用列表或“添加应用”按钮。Windows 上需要以管理员权限运行客户端才能写入系统路由表，非管理员启动时会出现“模式不可用”或勾选后不生效的情况；macOS 上首次启用网络扩展需要在系统设置里完成授权，未授权时虚拟网卡不会建立，按应用分流自然无从谈起。

2.4 找不到入口的三类原因

• 安装渠道不同导致功能裁剪。应用商店版本与官网分发版本在部分模块上可能存在差异，建议以客户端内实际显示为准，而不是对照他人截图逐字查找。
• 权限未授予。Android 的 privacy tool 授权、Windows 的管理员权限、macOS 的网络扩展授权，缺一个都会让入口“看起来存在但点不动”。
• 当前处在系统代理模式而非 TUN 模式。此时软件只接管浏览器类流量，按进程的配置项往往被置灰或隐藏。

排查顺序也值得说明：先看权限，再看模式，最后才怀疑安装渠道。前两项都在客户端内可自查，耗时以分钟计；渠道差异需要比对版本信息，成本更高，放在最后更划算。

三、三种做法：白名单、黑名单、全局加例外

确认入口可用之后，真正的设计问题才出现：默认值设成什么。三种组织方式的差别不在功能强弱，而在“未列出的流量怎么办”这条默认规则上。

3.1 方案 A：白名单——只让列出的应用走代理

做法是把默认动作设为直连，然后逐个把需要代理的应用加入列表。这样做的收益很直接：出口带宽消耗最小，本地服务零打扰，也不会因为某个后台更新程序偷偷吃掉代理流量。适用的典型场景是机器上大多数软件都属于“本地事务”——办公套件、财务软件、打印驱动、内网 OA。

示例：一位做跨境电商运营的用户，只让浏览器和店铺后台客户端走代理，其余全部直连。结果不仅代理带宽稳定，视频会议软件的抖动也消失了，因为会议流量不再绕一圈境外节点再回来。这个例子说明白名单的价值不在“省”，而在“隔离干扰”。

它的边界同样清楚：当需要代理的应用超过十几个，或者你经常临时安装新工具、每次都要回设置里补规则时，维护成本会迅速超过收益。此时白名单反而变成负担。

3.2 方案 B：黑名单——除列出的之外全走代理

做法相反：默认全部走代理，再把必须直连的应用挑出来加进例外。好处是新装软件默认可用，不需要每次都回来补配置，适合“主业高度依赖境外服务”的机器。

代价也很具体。开发机上常常跑着包管理器、镜像同步、容器拉取这类工具，如果忘记把它们放进直连名单，一次依赖拉取就可能把代理带宽打满，同时让本地构建延迟明显上升。这不是理论风险，而是黑名单模式最常见的翻车点。

3.3 方案 C：全局加例外——按地址而非按应用

第三种做法不区分应用，整体走代理，再按域名或 IP 段加例外，例如私有网段、内网域名后缀、特定服务器地址。配置量最小，适合“只有个别目标需要直连”的情形。

但它有一个无法绕过的盲区：当直连诉求来自应用本身而非目标地址时，按地址做例外根本覆盖不到。某些软件会校验出口 IP 归属地或强制走本地回环，这类情况只能靠按应用规则或干脆关闭代理解决。换言之，方案 C 的前提是“直连需求可以被地址描述”，一旦前提不成立，再细的域名清单也无济于事。

对比项	白名单	黑名单	全局 + 例外
默认动作	直连	代理	代理
配置粒度	按应用	按应用	按域名／IP
适合	本地事务为主的机器	多数工作依赖境外服务	仅个别目标需直连
主要风险	漏配新应用	后台工具消耗带宽	覆盖不到应用级诉求

3.4 怎么选：三条决策规则

第一条，看比例。需要代理的应用占日常使用应用总数不足三成，选白名单；超过七成，选黑名单；介于两者之间，说明需求本身不稳定，先别急着长期维护一套规则。

第二条，看变更频率。经常安装新软件、做环境试验的机器，白名单的补配成本会持续累积，此时黑名单更省心；反之，一台长期固定的办公机，白名单一次配好可以几个月不动。

第三条，看是否存在“应用级刚性直连”。若某个软件必须完全不经过代理，无论它访问什么地址，那么按地址做例外就注定失败，只能选前两种方案之一。

四、常见副作用与缓解

4.1 DNS 是分流之后的第二道坎

规则只决定流量走哪条路，不决定域名怎么解析。如果 DNS 查询仍然走本地运营商，可能拿到距离最优但并非代理侧最优的地址，出现“规则生效了、速度却没起色”的错觉。排查方法是分别记录开启与关闭代理时同一域名的解析结果，若两者一致且延迟偏高，说明解析未随代理走。这一步最好在改完规则后立刻做，时间一长，前后两次结果的对照就失去意义。

4.2 UDP 与实时音视频

在系统代理模式下，UDP 流量通常不被接管。结果是浏览器里的网页走代理、而语音通话或游戏却仍走本地线路，表现成“规则看起来只对一半软件生效”。这不是规则写错，而是模式限制。需要完整接管时，应切换到 TUN／虚拟网卡模式。

4.3 局域网设备与打印机

把全局模式打开后，局域网内的 NAS、打印机、投屏设备可能突然无法访问。原因在于私有网段的流量也被送进了代理。缓解方式是在例外中加入常见的私有网段，或在按应用规则里让本地发现类服务走直连。

4.4 双栈环境下的漏流

当网络同时具备 IPv4 与 IPv6 时，如果规则只覆盖了其中一栈，另一栈的流量会悄悄绕开代理。验证方法是分别用两种协议的地址查询页确认出口地址，若其中之一仍是本地地址，说明该栈未被接管。

五、验证：怎么确认规则真的生效

配置完成后不要凭感觉判断。一个可复现的验证流程是：先在代理开启状态下访问出口地址查询页，记录显示的地址；再单独打开被列入直连的应用，让它去访问同类查询页；对比两次结果是否不同。若两者相同，说明分应用规则没有起作用，问题出在模式或权限，而不是勾选本身。先排除模式、再怀疑规则的顺序很关键，它能避免在错误的层面上反复修改。

第二个观测点是连接日志。多数客户端会提供实时连接记录，列出每条连接命中的规则与走向。观察被列入直连的应用是否仍有连接被标记为代理，是最直接的证据。第三个观测点是系统层：桌面端可以查看路由表，确认目标网段是否被指向虚拟网卡；移动端则可以通过系统的网络使用情况页面，粗略判断某个应用在一段时间内的流量是否异常增长。三个观测点由内到外，越往后越接近系统真相，也越费时间。

六、故障排查：按现象定位，而不是逐项乱试

现象一：勾选了应用，但它依然直连。可能原因包括客户端当前处于系统代理模式、应用使用了独立的网络栈、或规则改动后未重连。验证方式是查看连接日志是否出现该应用的记录，以及系统里是否存在虚拟网卡。处置顺序是先切模式，再重连，最后才考虑该应用是否根本不支持被接管。

现象二：应用走代理了，但访问内网服务失败。这通常是例外未覆盖私有网段，或 DNS 解析被代理侧接管后返回了不可达地址。处置方式是在例外中补齐内网网段，必要时把内网域名后缀一并加入直连清单。

现象三：整体变慢，但所有应用都在正常工作。这类问题多半与规则无关，应回到节点与线路层面排查；分流规则只影响“走不走”，不影响“走得快不快”。先把规则全部调回默认，观察速度是否恢复，可以快速区分问题归属。

现象四：桌面端勾选后立刻失效，重启客户端又恢复。这种反复往往与权限有关。Windows 上非管理员启动、macOS 上网络扩展授权被系统回收，都会造成规则时好时坏。处置方式是确认启动方式与系统授权状态，而不是反复重配规则。

七、适用与不适用场景清单

适合启用分应用分流的场景包括：机器上同时存在必须直连的业务软件（内网 OA、财务客户端、银行安全控件）与需要代理的工具；代理出口带宽有限，希望把流量集中在少数应用上；需要做故障隔离，把问题范围锁定在某个软件而不是整机。

不适合的场景同样明确：只需要访问固定几个境外网站时，按域名例外比按应用更省事；仅在移动端临时使用、且平台本身未开放应用清单时，强行追求按进程配置只会浪费时间；团队协作环境中，如果规则写在个人设备上而非统一配置里，成员之间互相对照反而增加沟通成本。

八、最佳实践检查表

• 先确定模式，再动规则。没有虚拟网卡时，按应用配置的精度会打折。
• 规则改动后必定重连一次，并回到验证流程跑一遍，而不是直接开始工作。
• 例外清单按“私有网段 → 内网域名 → 特定应用”的顺序补齐，先粗后细。
• 把规则数量控制在可维护范围内，超过二十条就该考虑换一种组织方式。
• 变更前记录当前配置，尤其是应用列表较长时，回退成本会远高于预期。
• 不要为了一个偶发失败频繁改动规则，先确认问题是否属于节点侧。

这份清单的顺序并非随意：模式与权限决定了规则能不能生效，重连与验证决定了改动是否真的落地，而例外顺序与数量控制决定了后续的维护成本。把它当作每次改动前后的固定动作，比记住某个具体菜单路径更有价值。

九、版本差异与迁移建议

截至当前的最新版本，各平台的菜单命名与分组仍可能存在差异，同一功能在 Android 上叫“应用分流”、在桌面端可能叫“分流模式”或“规则设置”，这属于正常的界面演进而非功能缺失。跨版本升级后，建议先打开设置页比对一次条目是否还在原位，再决定是否沿用旧截图中的路径。

迁移时有一个经验性做法：把旧版本的规则整理成文字清单（哪些应用走代理、哪些走直连、哪些域名排除），升级后按清单重配，而不是试图逐条比对界面。这样即使入口位置变了，规则本身也不会丢。

十、常见问题

结语：先确定默认值，再谈精细配置

回到最初的问题：QuickQ 的分流规则如何指定应用走代理，入口又在哪里。答案可以压缩成三句话——入口在设置层的分流或路由条目中，能否按应用配置取决于平台能力与当前代理模式；做法上先想清楚默认值是直连还是代理，再决定用白名单还是黑名单；配完之后一定要重连并跑一遍验证流程，而不是直接进入工作状态。

下一步建议是：花十分钟把当前机器上的应用分成“必须代理”“必须直连”“无所谓”三类，用这张分类表去对照客户端的规则页，而不是边用边加。规则一旦稳定下来，就不必频繁调整；真正需要动它的时机只有两个——换了网络环境，或者装了会改变网络行为的新软件。从版本演进的节奏看，菜单命名与分组仍会继续调整，但“先定默认值、再补例外”的组织方式短期内不会变。