QuickQ是否支持按应用分流并让指定软件走代理？

先把问题说清楚：应用分流到底在分什么

你之所以会搜到这个问题，多半是有一个具体诉求：让某一个软件单独走代理，而浏览器、网盘、游戏、内网办公系统这些流量维持本地出口。这类能力在中文里通常被叫作应用分流，也叫按应用代理、分应用代理，指的是客户端以“发起流量的程序”为单位决定走不走隧道，而不是以“目标地址”为单位。换句话说，它关心的是“谁在发起连接”，而不是“连接要到哪里去”。

它和全局代理的差别不在速度，而在匹配粒度。全局模式按网络接口接管，规则简单、副作用少；应用分流按进程或包名匹配，粒度细，但每个平台能拿到的进程信息并不对等。Android 的 privacy tool 服务可以拿到应用列表，iOS 的 Network Extension 是否支持逐应用规则取决于客户端实现，桌面端则要处理进程、子进程、系统代理等多层关系。因此同一个产品在 Android 上做得到的事，iOS 上未必做得到，这是系统权限与实现成本决定的，不能简单归为“阉割”。这也解释了为什么同一个客户端在不同平台上的设置页可能长得并不一样。

还有一个常被混进来的概念是规则分流——按域名或 IP 决定走不走代理。它和应用分流是两条正交的轴：一个按“谁发起”判断，一个按“去哪里”判断。本文只讨论前者，但验证时会发现两者互相干扰，所以后面会给出隔离方法。把这两条轴分清，是读懂任何一个代理客户端设置页的前提，也是后面做自查时不至于把“规则命中”误认成“应用分流”的关键。

QuickQ 的分流能力边界：先分清三种形态

截至当前的最新版本，QuickQ 中文客户端的界面与功能会随平台和版本迭代，任何写死的菜单名都可能在下一次更新后失效。与其赌一个具体路径，不如先学会识别形态：只要你能在客户端里找到下面三类中的某一类，这个问题就基本有答案了。下面不押注某个具体菜单名，而是给出可复用的识别方法。

形态一：全局接管，没有分流入口

特征是设置页只有连接与断开、协议选择、节点列表这类选项，没有任何与应用、进程、包名、程序相关的字样。此时“让指定软件走代理”无法在客户端内完成，只能借助系统层或其他软件搭建等效链路。这是最常见的形态，也最容易被误读为“功能藏得深”；若你的界面符合这一描述，就不必再在二级菜单里反复寻找。

形态二：规则分流，但没有按应用维度

特征是能看到“智能模式”“规则模式”“绕过局域网”“大陆网站直连”这类开关。它解决的是“哪些地址走代理”，不是“哪些软件走代理”。这里有一个高频误判：在只开浏览器的场景下打开智能模式，发现其他软件似乎没走代理，就以为实现了应用分流。实际上那些软件的流量只是没有命中规则，换个目标地址立刻就会现形。因此，智能模式只能证明规则分流存在，不能证明应用分流存在。

形态三：明确出现按应用选择

特征是列表里出现已安装应用的清单，可以逐个勾选，并且语义上能区分“仅代理所选应用”（白名单）与“所选应用不代理”（黑名单）。有的产品只提供其中一种，这属于设计取舍，不影响功能成立的判断。只有到这一步，才能肯定该客户端支持按应用分流，也才谈得上按应用配置。

判断口径建议只认第三种。前两种都只能算“行为相似”，不能算“功能存在”，否则你会在排障时反复怀疑自己。

分平台的最短自查路径

下面给的是“到达候选入口”的最短方向，而不是保证存在的路径。界面文案随版本变化，请以实际安装版本为准；如果找不到，就跳到下一节用行为反推，不要在这一步反复纠结。这样即使界面改版，也能用同一套顺序重新核对。

Android：先看主界面，再看设置分组

从主界面进入设置类页面（通常在侧边栏、底部标签或右上角），依次查看“模式”“分流”“代理范围”“应用管理”这类分组。Android 的权限模型允许客户端通过系统 privacy tool 服务读取应用清单，所以这里是三种形态中最可能出现逐应用勾选的平台。若设置页只有“全局/智能”二选一，基本可判定为形态二，此时应转去验证规则分流是否够用；如果连模式切换都没有，则更接近形态一。

iOS：能力受限于扩展实现，不要用重装试探

iOS 通过系统扩展提供隧道能力，是否支持逐应用规则取决于客户端是否实现了 per-app 规则。经验性观察：iOS 上以“全流量接管”和“按域名规则”为主的客户端更多，出现完整应用勾选列表的比例低于 Android。路径同样是从设置页找关键词，找不到时不要反复卸载重装——重装改变不了能力边界，只会浪费时间并丢失已有配置。

桌面端：先分清是隧道模式还是系统代理模式

Windows 与 macOS 的匹配对象是进程而不是包名，实现难度更高。检查顺序建议：先看主界面有无模式切换，再看设置页有无“应用/进程”分组。更关键的是先判断客户端的工作方式——如果它通过设置系统代理来转发流量，那么按进程分流在原理上就不成立，因为系统代理是一个全局设置，是否生效取决于每个程序是否遵循系统代理。这类客户端即使列出了应用列表，往往也只对“愿意走系统代理”的程序有意义，直连的程序完全不受影响；顺序反过来看列表，容易把“列表存在”误判成“分流可用”。

可复现的对照实验：用行为反推功能

找不到入口时，实验比猜测可靠。核心思路是选两个“出口可观测”的软件，一个作为候选分流对象，一个作为对照，然后对比它们看到的公网出口是否一致。整个过程不需要任何特殊工具，浏览器加一个带网络诊断的程序即可。为了让结论可复查，最好在每一步都记录时间、网络环境与当前模式。

1. 准备观测点：用浏览器访问任意 IP 查询页，记录返回的 IP 与归属地；第二个软件优先选有连接日志或能看到服务器地址的客户端。
2. 记录基线：断开代理，分别记录两个软件看到的出口 IP，作为对照。
3. 开启代理：保持客户端默认模式，不做任何额外设置，再记录一次两个软件的出口。
4. 读结果：两个都变且一致，说明是全局接管；一个变一个不变，说明存在某种分流，进入第 5 步；两个都没变，说明你选的软件本身不遵循该客户端的接管方式。
5. 联动验证：在客户端内切换模式或勾选状态，重复第 3 步。只有当结果随勾选项严格联动时，才能确认是按应用分流，而不是规则分流的巧合。

预期可观测的指标有三类：出口 IP 与归属地的变化、建立连接所需时间的量级变化（定性描述为亚秒级到数十秒，具体因节点与线路而异）、以及是否出现域名解析异常。第三类最容易被忽略，也最容易让结论跑偏，因此不要只看网页能不能打开。

性能与成本：分流真正省下的是什么

很多人以为应用分流的收益是“更快”，实际上主要收益是避免无关流量被绕路。把内网办公系统、局域网投屏、大文件同步这类流量排除在隧道外，能减少不必要的往返和带宽占用；把游戏或实时音视频放进隧道，则是为了改变出口位置。这两种诉求方向相反，所以分流规则不是越细越好，而是要与使用场景对齐。配置前先问自己：是要保护本地访问，还是要改变某类应用的出口。

测量方法建议固定下来，便于横向对比。CPU 与内存占用：用系统自带的活动监视器或任务管理器，观察连接前后各一分钟的平均水平，只看趋势不看瞬时峰值。电量：在移动端同一场景下跑固定时长，对比系统电池页面的前台耗电排行，多次取中位数。延迟：对同一目标做 ping 与路由追踪，分别记录直连与代理下的表现，注意不要用不同节点互相比。记录时把节点、时段和网络环境一并标注，后续回看才不会把变量混在一起。

成本端有两块。第一块是枚举与匹配本身的开销，通常很小，属经验性观察中的“可忽略”级别，不必为此纠结。第二块才是真成本：规则需要持续维护。应用更新后包名变化、同一软件多开、主程序拉起下载子进程、内嵌浏览器组件另起进程，都会让原本生效的勾选悄悄失效。举一个常见场景：某视频剪辑软件主进程已加入代理，但它调用的素材下载子进程不在列表中，结果素材拉取仍然直连，用户只会觉得“分流没生效”，实际上是匹配层级没覆盖到。这类失效往往不是客户端坏了，而是匹配粒度没有覆盖到实际发起连接的进程。

例外与副作用清单

应用分流的坑大多不在“怎么开”，而在“开了之后哪些东西悄悄变了”。下面几条属于高频副作用，建议在正式使用前逐条确认。

• 域名解析路径不一致：应用走了直连、解析走了代理，或反之，结果是访问变慢、部分站点证书告警。验证办法是同时查看解析结果与实际连接 IP。
• UDP 与 QUIC 类流量：部分客户端对 UDP 支持有限，被选中走代理的应用如果强依赖 UDP，可能出现语音断续、视频卡顿。可尝试在应用内关闭 QUIC 或强制走 TCP 做对照。
• 局域网与投屏：把设备发现、投屏、打印机这类局域网流量误纳入代理后，表现为“设备搜不到”。分流规则里应显式排除私有网段。
• 双栈环境：IPv6 可用时，部分流量会优先走 IPv6 出口，导致你只针对 IPv4 做的规则看起来失效。验证时分别观察两种协议的出口。
• 应用自带的网络检测：少数软件会校验出口一致性，出口突变时触发风控或要求重新登录。这类情况应把该应用放进直连名单，而不是强行代理。

故障排查：按现象找原因

排障的关键是先分类再动手，不要一上来就重装。下表按“现象→可能原因→验证→处置”组织，覆盖了应用分流场景下最常见的几类问题。

现象	可能原因	验证方法	处置
勾选后出口未变化	该应用不遵循客户端接管方式	换一个已知生效的应用做对照	改用系统层方案或放弃对该应用分流
主程序走了，功能仍直连	子进程或辅助进程未匹配	连接时观察进程列表变化	把辅助进程一并纳入规则
页面能开但很慢	解析与连接路径不一致	比对解析结果与实际连接地址	统一解析出口，或把该应用改回直连
搜不到局域网设备	私有网段被纳入代理	断开代理后重试同一操作	在规则中排除私有网段
刚配置好，隔天失效	应用更新导致匹配标识变化	复核应用列表中的条目是否仍存在	重新添加并记录变更时间

排查时建议一次只改一个变量，并留下记录。应用分流涉及应用、客户端、系统三层，同时改两处会让结论失去意义。经验性结论是：绝大多数“分流不生效”的反馈，最终都落在子进程未匹配或解析路径不一致这两类上，而不是客户端本身的缺陷。把每次改动和结果记在同一处，下一次遇到相似现象时就能直接对照。

如果确认客户端内做不到，有哪些等效思路

假如按上面的方法确认当前版本没有逐应用入口，也不必立刻否定整个方案。可以退一步，用“规则分流 + 使用习惯”逼近目标：把需要走代理的流量收敛到固定域名或固定端口，再用规则命中，其余保持直连。代价是你需要知道目标应用的通信特征，维护成本从“勾选应用”变成“维护地址清单”。这种做法不承诺结果完全等价，但能把不可控范围缩小到可观测的地址维度。

桌面端还有一条思路是分账户或分环境隔离：为代理用途单独准备运行环境，让需要走代理的程序与其他程序不在同一网络策略下。这种做法在合规和运维上更清晰，但会牺牲一些便利性，是否值得取决于使用频率。移动端受系统限制更多，通常不建议绕开客户端去改系统设置，容易在系统升级后失效且难以回滚。

需要明确边界：上述思路都属于通用工程手段，不构成对任何特定产品的功能承诺。具体能否落地，取决于你所用系统版本是否提供对应入口，请以实际核对结果为准。

适用与不适用场景清单

判断“要不要用应用分流”，比判断“能不能用”更重要。下面按准入条件划分，供快速对照。

适合启用的情形：需要走代理的应用数量少且稳定（例如只有一两个客户端）；本地有大量局域网访问、投屏、打印需求，不希望被隧道打断；设备性能或电量敏感，希望减少不必要的转发开销；团队协作场景中，需要让代理只影响特定工作软件而不干扰聊天与同步工具。这些条件同时满足时，应用分流的维护成本通常更容易被收益覆盖。

不建议启用的情形：应用存在大量子进程或动态加载模块，维护成本高于收益；应用自带出口一致性校验，分流会触发重复验证；对稳定性要求极高的长连接业务，规则变动带来的抖动难以接受；多人共用同一设备，规则被频繁改动会导致排障困难。

还有一个常被忽略的判断维度是可观测性。如果出问题后你无法快速判断某个连接到底走了哪条路径，那么这套分流配置就不该上线。可观测性不足时，宁可先用全局模式，等确认清楚流量特征后再细化。换句话说，先能看见，再谈精细化。

最佳实践检查表

把下面几条当作上线前的固定动作，可以省掉大半反复。它们不是硬性规定，而是从排障成本倒推出来的经验规则。

• 先用对照实验确认能力形态，再决定是否投入时间配置。
• 优先使用白名单（仅代理所选应用），默认直连，出错时影响面最小。
• 规则里显式排除私有网段，避免投屏、打印、NAS 访问被误伤。
• 一次只改一个变量，并记录改动时间，便于回溯。
• 应用大版本更新后复核一次匹配是否仍然成立。
• 为关键业务保留一条“全局模式”的回退路径，随时可切换。
• 选择低峰时段做验证，避免把网络波动误判为配置问题。

验证与回退：怎么确认自己没把路走窄

配置完成后，做一次完整的回归验证：把日常使用的应用分三类——必须走代理、必须直连、无所谓——分别抽查一个，确认出口符合预期。然后断开再重连一次，观察规则是否被正确加载。最后模拟一次失败：手动关闭客户端，确认关键业务能否自动回落到直连，而不是直接不可用。回归验证的目的不是证明配置复杂，而是确认关键业务在异常时仍有退路。

回退方案要提前写下来，而不是出问题再想。最简回退是切回全局模式或关闭分流开关；次简回退是清空自定义规则恢复默认；如果已经影响到系统网络设置，则需要按平台方式重置网络配置。建议在改动前截图保存当前设置页，这在跨版本升级后尤其有用；截图之外，最好再写一句当前使用的模式与关键勾选项，方便日后快速恢复。

常见问题（FAQ）

结语：先确认形态，再谈配置

回到最初的问题——QuickQ 是否支持按应用分流并让指定软件走代理，答案取决于你手上那个版本的具体形态，而不是一个固定的是或否。与其依赖某条写死的菜单路径，不如掌握识别三形态的方法、跑一次对照实验、并提前想好回退方案。这三步做完，你对自己环境的判断会比任何一篇教程都准确。从版本演进的角度看，入口名称和位置仍可能调整，但识别顺序相对稳定：先确认形态，再跑行为验证，最后准备回退。

下一步建议很具体：先在 Android 或桌面端花几分钟找一次入口，找不到就用浏览器加一个带日志的客户端做对照实验，记录两组出口 IP；确认能力之后，再决定用白名单还是规则分流，并把关键配置截图存档。整个过程控制在半小时内，比反复试错要划算得多。