QuickQ分流规则如何按应用设置代理？

在代理客户端里，「分流」与「按应用设置代理」经常被混着说；围绕 QuickQ分流规则 的讨论中，这个问题出现频率尤其高。用户想让工作浏览器走代理、让网盘和游戏直连，于是在设置里到处找「按应用」的开关，却只看到全局、规则、直连几个选项。先说结论——所谓按应用设置代理，本质是把「哪些流量需要代理」的判断依据，从域名或 IP 换成进程身份；而分流规则负责的是这些流量判断完之后怎么走。换句话说，前者决定谁上车，后者决定车往哪开，两者不在同一层。

理解这一点，后面的操作就不会走偏：如果你的客户端版本提供应用级入口，就在那一层勾选；如果没有，就要用规则分流去「近似」实现，或者退回到系统级方案。本文按问题定义、最短可达路径、例外与副作用、验证与回退的顺序展开，平台差异会逐段标注，并在关键处给出可复现的验证方式。

一、问题定义：什么叫「按应用设置代理」

传统代理配置只有两个变量：代理服务器地址，以及系统是否启用代理。这种模式下，只要开关打开，所有走系统代理栈的程序都会受影响。分流规则引入了第二个维度——匹配条件，常见的有域名后缀、IP 段、地理位置库、进程名。前三种属于网络层判断，第四种才触及应用层；把这两类判断分开看，后面的菜单差异就不难理解。

判断依据与执行动作是两个独立环节

可以把代理客户端想象成一个分拣中心。分流规则是分拣标准，按应用设置代理是给包裹贴上「寄件人」标签。标签贴好之后，仍然要按标准分拣：寄件人是 A 公司的包裹走国际线，B 公司的走本地线。所以你在界面上看到的「应用分流」「分应用代理」「Per-App Proxy」这类入口，实际控制的是「哪些进程的流量进入代理管道」，而不是「这些流量用哪条规则」。反过来说，即使客户端没有应用级入口，你也可以通过规则把某些域名固定走直连，效果在多数场景下接近，只是粒度不同。

三档分流的能力边界

多数代理客户端把分流抽象成三档，理解这三档的差异，比记住菜单位置更有用。

从这张表能读出一个结论：应用级不是「更强」，而是「换了一种判断维度」。它解决的是规则分流解决不好的问题，比如同一个域名在浏览器里想走代理、在某个同步工具里想直连，这种情况纯靠域名规则是无解的。

二、版本演进：从全局开关到应用级选择

以版本演进的视角看，代理客户端的分流能力大致走过三个阶段，这条脉络能解释为什么不同版本、不同平台的入口位置差别这么大。

第一阶段：全局开关为主

早期客户端基本只有「连接/断开」两个状态，分流依赖用户手动切换。这一阶段的典型痛点是：打开代理后，公司内网 OA、打印机、局域网投屏一起失效，用户只能反复开关。这个痛点直接催生了规则分流。

第二阶段：规则分流成为默认

规则分流把「国内直连、国外代理」这类判断交给内置规则集，用户几乎不用配置。它的边界也很清楚——判断发生在域名或 IP 层，一旦遇到「同域名不同用途」或「客户端不走系统代理」的情况就会失效。经验性观察：很多「开了代理但某个软件不生效」的反馈，根源是那个软件自己实现了网络栈，绕过了系统代理，而不是规则写错了。

第三阶段：应用级与应用组

为了绕开上面的问题，较新的客户端开始引入按进程、按应用的控制，通常需要虚拟网卡（TUN）接管流量，再根据进程归属决定走向。这也是为什么应用级分流往往和「TUN 模式」「增强模式」这类开关绑定出现——没有流量接管能力，就无从判断进程。至于 QuickQ 客户端是否在某个平台提供独立的应用分流页，截至当前可公开查证的版本信息并不足以一概而论，请以你实际安装版本的界面为准；下面给出的路径会同时覆盖「有入口」和「无入口」两种情况。

三、Android：最短可达路径与替代方案

Android 是三个平台里应用级分流最成熟的，原因是系统允许应用申请 privacy tool 服务权限后自行接管流量，并能拿到发起连接的包名。

路径 A：客户端内置应用分流入口

最短路径通常是：打开客户端 → 底部或侧边栏进入「设置」 → 找到「分流」或「路由」分组 → 选择「应用分流 / 分应用代理」 → 在应用列表里勾选需要走代理的程序。列表一般有两种勾选语义：白名单（仅选中项走代理）和黑名单（选中项直连），界面上会以「仅代理选中应用」和「绕过选中应用」区分，选错方向会得到完全相反的结果。因此动手前先确认当前是白名单还是黑名单，这一步比记住路径更关键。

示例：一位用户同时装着公司 privacy tool 客户端、个人网盘、两个浏览器。他的诉求是浏览器走代理，网盘和公司 privacy tool 直连。做法是在白名单里只勾选两个浏览器，然后观察网盘下载速度是否恢复到不使用代理时的水平。如果速度没有变化，说明网盘客户端本体也走了代理，需要检查是否漏选了它的后台服务组件——部分应用会把下载拆到独立进程，应用列表里通常能看到多个同名条目。

路径 B：没有应用级入口时怎么办

如果设置里找不到对应入口，不要反复重装——先判断是版本未提供入口，还是当前接管模式不满足条件。可行的替代有两条：其一，退回规则分流，把必须直连的服务用域名规则固定为 DIRECT（直连），例如内网域名、网盘的上传下载域名；其二，在系统层面用「工作资料」或分用户隔离，让不同用途的应用分处不同空间，再配合全局模式切换。第二条偏重，仅适合确有强隔离需求的场景。

失败分支与回退

常见失败有三种表现：勾选后全部应用断网、勾选后完全不生效、部分应用首次可用重启后失效。第一种通常是白名单模式下漏选了系统组件（如 Captive Portal 检测、推送服务），补选后恢复；第二种多见于客户端未获得 privacy tool 权限或与其他 privacy tool 类应用抢占，需在同一时间只保留一个 privacy tool 服务；第三种与后台进程被系统清理有关，把客户端加入电池优化白名单可缓解。回退方式统一为：切回「规则」或「全局」模式，确认网络恢复，再重新配置。

四、iOS：平台限制下的近似实现

iOS 的情况需要单独说明。受系统网络扩展框架限制，iOS 上的代理应用通常只能对整个设备的流量生效，按进程分流的能力非常有限。这意味着在这个平台上，你很难做到「A 应用走代理、B 应用直连」这种精确控制，实际能做的是在规则层做区分。

可行的替代路径

最短路径是：客户端内进入「设置」 → 「分流」 → 选择「规则分流」，再在自定义规则里为特定域名指定直连。比如让公司邮箱的服务器域名、iCloud 备份域名走 DIRECT，其余走代理。这样虽然不能按应用切，但对「某些服务必须直连」的诉求已经够用。另一个可选手段是利用系统的按需连接（On-Demand）规则，按网络类型触发代理开启——例如仅在使用蜂窝网络时启用，Wi-Fi 下不启用，这属于间接的「按场景分流」。

什么时候不该在 iOS 上折腾应用级

如果你的核心诉求是「同一个 App 内的部分请求直连」，在 iOS 上基本没有优雅解法，继续投入时间收益很低。此时更实际的做法是把需求拆开：把必须直连的服务迁移到不需要代理的网络环境，或者用支持规则分流的桌面端承担这部分工作。经验性观察：跨平台客户端在 iOS 上的功能通常是最保守的，这与审核政策和系统能力都有关，不必把它当成客户端缺陷。

五、桌面端：系统代理与 TUN 模式的关键区别

Windows 与 macOS 上的分流，首先要分清客户端当前处于哪种接管模式，因为这直接决定「按应用」是否可能。

系统代理模式：只能整体接管

系统代理模式修改的是操作系统的 HTTP/HTTPS/SOCKS 代理设置。它的问题在于，只有主动读取系统代理配置的程序才会走代理，其余程序（很多游戏、部分同步工具、命令行工具）完全不受影响。在这个模式下谈「按应用设置代理」意义不大——不是你在选应用，是应用在选你。

TUN / 虚拟网卡模式：具备进程判断的基础

TUN 模式创建一块虚拟网卡，把流量在系统层接管，此时客户端才具备按进程、按目标地址分流的条件。最短路径一般是：客户端主界面 → 开启「TUN 模式」或「增强模式」 → 进入「分流」 → 「应用分流」，选择按进程名匹配。Windows 上通常显示为可执行文件名，macOS 上显示为应用名。部分版本需要安装额外的网络组件或授权，安装失败时该入口会置灰。

示例：设计师需要在浏览器里访问素材站，同时用本地渲染农场做批量任务，渲染进程会长时间占用带宽。把渲染程序加入直连列表后，代理链路只承载浏览器流量，带宽争抢明显缓解。这类调整的验证很直接——对比调整前后同一任务的完成时间，且在任务进行中观察客户端的连接列表，确认渲染进程没有出现在代理连接里。

边界：哪些情况不该开 TUN

如果设备上同时运行着企业 privacy tool、虚拟机网络、或者你在做依赖真实网卡抓包的调试工作，TUN 模式可能引入额外变量，导致排查困难。此时更稳妥的是保持系统代理模式，用规则分流满足主要需求，把应用级控制放到确有必要的时段再开启。

六、四类典型场景的规则写法

下面四个场景覆盖了多数人的实际诉求。写法均为通用形式，具体语法以你客户端支持的规则格式为准。

场景一：工作浏览器走代理，其余直连

这是白名单模式的教科书用法。做法是在应用分流中只勾选浏览器，其余一律不勾。原因在于浏览器的流量结构最复杂，域名规则很难穷举；而其他工具往往是固定几个域名，用规则处理更省事。副作用是浏览器的自动更新、账号同步也会走代理，如果这些服务对延迟敏感，可再补一条域名规则让它们直连。

场景二：游戏与音视频直连

游戏对延迟敏感，走代理通常得不偿失。优先用应用级把它们排除，其次才是规则。这里有个容易被忽略的点：很多游戏客户端的登录、更新、对战是三个不同的进程或域名，只排除主进程可能仍然卡顿。验证方法是进入游戏后观察客户端连接列表，确认没有该游戏的连接记录。

场景三：内网与本地地址必须直连

私网地址段、本机回环、局域网域名这几类应当无条件直连，无论你选了哪种模式。多数客户端内置了这类规则，但自定义规则集的顺序可能覆盖它。经验性观察：规则一般按顺序匹配、命中即停，把自建的代理规则放在私网直连规则之前，就会出现内网访问被代理的情况。排查时先看规则顺序，再怀疑其他原因。

场景四：按应用组而非单个应用

当应用数量变多，逐个勾选的维护成本会上升。较新的客户端支持把多个应用归入一个组，再对组设置策略。这种做法的好处是策略可复用，坏处是组内应用的网络行为一旦变化，影响面被放大。建议按用途分组（办公、娱乐、开发），不要按「是否常用」分组，后者在需求变化时最难调整。

七、例外与副作用：哪些问题会找上门

应用级分流并非只有好处。下面几类副作用出现频率较高，提前知道能省下不少排查时间。

半代理状态与 DNS 泄漏

一个应用同时访问多个域名时，若部分域名被代理、部分直连，就会出现「页面能开但图片加载慢」「登录成功但消息不同步」这类现象。这不是分流写错了，而是分流粒度与应用实际流量结构不匹配。DNS 层面同理：如果 DNS 查询走了直连、连接走了代理，可能拿到不理想的解析结果。验证方法是在开启分流后，用客户端的连接日志查看同一应用是否出现多条不同走向的记录。

升级后规则失效

客户端升级可能带来规则格式调整、应用识别方式变更（例如从进程名改为包名加签名校验）。表现是原本生效的白名单突然失效或反向生效。建议在升级前导出当前配置，升级后先小范围验证再全量使用。若客户端不提供导出，可手动截图保留关键列表，至少能快速复原勾选状态。

与系统级或企业级方案的冲突

企业设备上常装有 MDM 配置文件或强制 privacy tool，这类方案优先级更高，可能直接接管流量，使客户端的分流设置形同虚设。判断依据很简单：关闭客户端后网络行为不变，说明流量已被其他组件接管。此时不建议强行绕过，应向设备管理员确认策略边界。

八、验证与观测：三步确认是否真的生效

配置完成后不要凭感觉判断，按下面的三步走，每步都有可观测的结果。

1. 出口 IP 对比：在目标应用内访问任一显示公网 IP 的页面，记录结果；再在未被选中的应用内做同样操作。两者应当不同。若相同，说明分流未生效。
2. 连接列表核对：打开客户端的连接或日志面板，执行一次目标应用的操作，观察是否出现对应记录。出现即代表流量进入了代理管道。
3. 断网反证：临时断开代理服务器，重复操作。走代理的应用应当失败，直连的应用应当正常。这一步能有效识别「以为在走代理其实一直在直连」的误判。

三步之外，还可以观察设备层面的间接指标：开启应用级分流后，若待机耗电明显上升，往往是把系统后台服务也纳入了代理范围，导致频繁重连。这类问题不需要复杂工具，对比开启前后一晚的耗电曲线即可定性判断。

九、回退与迁移：把配置当成资产来管理

分流配置是长期积累的结果，随手重装会让这些工作归零。建议形成两条习惯。

回退的最小步骤

出现异常时，按「先降级模式、再改规则、最后重装」的顺序处理。先把分流切回「规则」或「全局」，确认基础网络恢复；再逐条回滚最近改动，定位是哪一条导致的；只有在配置无法读取时才考虑重装。这个顺序的价值在于，它把「网络不可用」和「配置错误」两类问题分开了，避免在断网状态下盲改。

升级后的迁移检查

升级到新版本后，按清单核对四项：应用分流模式是否仍为原来的白/黑名单方向、勾选列表是否完整、TUN 类开关状态是否保持、自定义规则顺序是否变化。四项里最容易出问题的是方向被重置——很多「升级后全部应用都走了代理」的反馈，实际是白名单被恢复成了默认全局。核对成本很低，几分钟即可完成。

十、适用与不适用：一份准入判断

不是所有场景都值得上应用级分流。下面按条件给出判断依据。

适合的情况：设备上同时存在「必须直连」和「必须代理」两类应用，且它们访问的域名有重叠；你需要长时间保持代理开启，不希望频繁手动切换；你能接受为配置投入一次性的调试时间。不适合的情况：只有单一用途的设备，规则分流已经够用；使用的是受管控的企业设备；你在做需要完全真实网络环境的测试。这些情况下，增加一层应用级判断只会增加变量。

十一、最佳实践检查表

把上面的要点收敛成一份可执行的清单，配置时逐项对照即可。

• 先确认客户端当前接管模式，系统代理模式下不谈应用级。
• 白名单与黑名单方向在配置前先想清楚，改方向比改列表更容易出错。
• 私网地址、本机回环的直连规则放在最前面，避免被后续规则覆盖。
• 应用列表里留意同名多进程，尤其是带更新、下载模块的软件。
• 每次只改一处，改完立刻用出口 IP 对比验证，不要攒着一起改。
• 升级前备份配置，升级后按四项清单核对。
• 企业设备遇到策略冲突时，先确认边界，不要强行绕过。

十二、常见问题（FAQ）

结语：先定边界，再谈配置

回到最初的问题，QuickQ分流规则与按应用设置代理的关系可以概括为一句话：应用级负责筛选对象，规则负责决定走向，两者配合才有意义。不同平台的能力差异是系统约束的结果，不是配置技巧能弥补的——Android 与桌面端在具备流量接管能力时可以做进程级判断，iOS 上则更适合把精力放在规则层。

下一步建议按这个顺序动手：先确认客户端当前的接管模式与是否提供应用级入口，再决定用白名单还是黑名单，配置完成后立刻用出口 IP 对比和断网反证做一次验证，最后把当前配置记录下来。整个过程不必一次做完，每改一处验证一次，出问题时你总能知道是哪一步引入的。平台能力会随系统框架与客户端版本变化，但「先定边界、再做配置、最后验证」的顺序，仍然是排查分流问题时最稳妥的起点。