QuickQ分应用代理模式支持哪些应用？如何设置应用代理范围并保存配置？

一、功能定位：分应用代理真正管的是什么

很多人在检索 QuickQ 分应用代理模式时，脑子里想的其实是另一个问题：能不能只让某几个 App 走代理，其余的照常直连。这个问题看起来简单，却触及了代理软件最底层的一层逻辑——不是“连不连得上”，而是“哪些流量被接管”。把这一点想清楚，后面所有的设置步骤才有意义。

分应用代理（有些界面叫“应用分流”“按应用代理”“应用白名单”）的本质，是在系统创建 privacy tool 隧道时，向操作系统提交一份应用清单：清单内的应用，其流量被导入隧道；清单外的应用，流量走物理网卡直出。整个过程发生在网络层，应用本身通常感知不到，也不需要单独配置。正因如此，它和你打开某个 App 再手动设置 HTTP 代理完全是两件事——后者只对支持代理协议的应用生效。

由此可以推出一个关键结论：分应用代理的“支持范围”，不是由代理软件自己决定的，而是由操作系统的隧道接口能力决定的。客户端能做的，是把这份清单传下去；做不到的，是去接管一个操作系统不允许它接管的进程。这解释了为什么同一个功能在不同平台上可用性差异很大，也解释了为什么有些应用明明加进了列表却依然直连。遇到这类现象，先怀疑能力边界，通常比反复改配置更有效。

提示：本文涉及的具体菜单名称与入口位置，随平台和客户端版本不同而变化。文中给出的路径为通用描述，请以你实际安装版本的界面为准；若找不到对应入口，请参考第五节与第九节给出的替代路径与回退方案。

二、与全局代理、规则分流的边界

代理客户端常见的流量处理方式大致有三种，理解它们的差别，能帮你少走很多弯路：全局代理是把所有流量都送进隧道，最简单也最“重”；按域名或 IP 的规则分流，是在隧道内部做判断，依据是目标地址而不是发起应用；分应用代理则是在隧道入口处做判断，依据是发起进程。三者的判断时机不同，能表达的策略也不同——入口处的判断更确定，隧道内部的判断更灵活。

2.1 三种模式的取舍

如果你只是想让浏览器看海外站点、同时不希望国内办公系统被绕一圈，规则分流通常更省事，因为主流站点与国内服务的地址库已经比较成熟。但规则分流有一个绕不开的短板：同一个应用可能同时访问境内和境外地址，规则库判断错一次，体验就会掉一次。分应用代理从这个角度看更“粗暴但确定”——它不猜地址，只认应用。

代价是维护成本转移到了你身上。规则库是别人维护的，应用清单是你自己维护的：装一个新软件，就要决定它进不进清单。应用越多，这份清单越容易变成历史包袱。所以在实际使用中，分应用代理更适合“应用集合稳定、目标明确”的场景，而不是“什么都想加速一点”的场景。

2.2 什么时候分应用代理是错的选择

有三个信号说明你可能选错了模式。第一，你的清单超过一屏还在不断增加，这说明你真正需要的是规则分流或全局代理，而不是逐个点名。第二，你频繁在“这个应用要不要走代理”之间反复切换，说明需求本身不稳定，此时按域名规则反而更省心。第三，你的主要诉求是降低延迟而不是改变出口，那么应用层分流带来的收益有限，瓶颈大概率在链路上。这三个信号其实指向同一件事：你的需求不适合用一份清单来表达，此时换成规则分流，往往比继续扩充清单更省力。

三、“支持哪些应用”：三类判定与真实上限

网上常见的问法是“支持微信吗”“支持某个游戏吗”，这种问法其实得不到有用的答案。更实用的问法是：这个应用属于哪一类流量形态，它落在隧道接口的能力范围之内还是之外。按这个思路，可以把应用分成三类来看：通常能纳入的、需要谨慎纳入的，以及常被误判为不支持的。

3.1 通常能纳入的类型

绝大多数普通用户态应用都可以纳入，包括浏览器、社交软件、邮件客户端、笔记与文档协作工具、在线音乐与视频播放器、以及大部分手机游戏。它们的共同点是：以自己的进程身份发起 TCP 或 UDP 连接，走系统标准的网络栈。只要系统允许按进程筛选，这类应用就能被准确接管。

举一个具体的小例子。假设你的日常工作流是：浏览器访问外部资料站，公司 OA 走内网，微信需要保持低延迟。这三者可以形成一个非常干净的分应用配置——浏览器进清单，OA 与微信出清单。这样做的效果是，OA 的内网地址解析完全不受隧道影响，微信的通话与消息走本地链路，而浏览器的出口被替换。这是一个“应用集合稳定”的典型场景，也是分应用代理收益最高的场景。反过来说，如果你没法用一句话说清哪些走、哪些不走，这个场景大概率还不适合用分应用代理。

3.2 需要谨慎纳入的类型

第一类是涉及账户与资金的应用。把银行、支付、证券类应用放进代理清单，可能触发风控，表现为登录异常、验证码频繁或交易受限。这类应用通常自身还会做环境检测，隧道带来的出口变化有时会被判定为风险。经验性观察是：这类应用即使技术上能走代理，业务上也未必希望你这么做。纳入之前，先确认它是否真的需要改变出口。

第二类是强依赖低延迟的实时应用，比如语音通话、云游戏、远程桌面。隧道会引入额外的加解密与转发开销，最终延迟取决于链路质量而非客户端设置。第三类是带版权保护的内容应用，部分流媒体在检测到出口变化后会限制清晰度或拒绝播放，这属于服务方的策略，不是客户端能绕开的。这三类应用的共同点在于，它们并非技术上一定不可用，而是收益与风险往往不成比例。

3.3 常被误判为“不支持”的情况

有一种情况经常引起误解：用户把某应用加入了清单，但该应用内的网页视图或内嵌浏览器依然走直连。原因是那部分流量并非由该应用进程发起，而是交给了系统组件。类似的还有系统级更新服务、推送通道、以及由其他后台进程代发的请求。它们不在你勾选的那个进程名下，自然不受清单约束。换句话说，你勾选的是“发起者”，而不是“内容来源”。

另一种误解来自连接复用。某些应用在代理开启前已经建立了长连接，切换配置后旧连接仍在沿用物理网卡，直到超时重建才切换到隧道。表现就是“设置了但好像没生效”。验证方法很简单：强制结束该应用进程再重新打开，观察出口是否变化。如果变化了，就说明配置本身没问题，只是连接生命周期的问题。

四、分平台最短可达路径

在讲具体路径前，需要先说明一个平台层面的前提。Android 侧的应用分流基于系统的 privacy tool 服务接口，客户端在建立隧道时可以提交允许或排除的应用列表，能力相对完整。iOS 侧的网络扩展框架对第三方应用的按进程筛选开放程度有限，因此严格意义上的分应用代理在 iOS 上通常不可用或仅提供有限形式。桌面端则更多依赖进程识别与路由规则的组合。以下路径为通用描述，请以实际界面为准。

4.1 Android

最短路径通常是：打开客户端主界面 → 进入设置或“代理设置”区域 → 找到“分应用代理 / 应用分流 / 应用代理范围”一类的条目 → 进入后选择模式（常见为“仅代理所选应用”与“所选应用不走代理”两种反向逻辑）→ 勾选目标应用 → 返回并重新连接使配置生效。

需要留意两点。其一，模式的正反两种逻辑容易点错，勾选完最好回看一眼标题是“代理以下应用”还是“跳过以下应用”。其二，部分系统会对后台应用做电池优化，导致隧道在息屏后被回收，表现是切回应用时需要重新连接。若遇到，可在系统设置中对该客户端关闭电池优化。

4.2 iOS

iOS 端通常不提供按应用勾选的分流入口。若你的版本界面中确实存在类似“应用分流”的选项，也请以实际呈现为准，不要假定其行为与 Android 一致。在 iOS 上更现实的做法是使用全局模式配合规则分流，或者直接接受“全量接管”。这一点不是客户端偷懒，而是平台框架的约束。

4.3 Windows 与 macOS

桌面端的分流通常有两种呈现：一种是在客户端内提供“按应用/按进程”的列表，另一种是提供规则编辑界面，由你填写进程名或路径。最短路径一般是：主界面 → 设置 → 分流 / 规则 / 应用代理 → 新增条目 → 选择已安装程序或手动填写进程名 → 保存 → 断开重连。macOS 上由于权限模型不同，部分实现需要你在系统设置中授予网络扩展或辅助功能权限，未授权时列表可能是灰的。

桌面端最容易踩的坑是进程名写错。浏览器可能有多个进程（主进程、渲染进程、更新进程），只写主进程名通常足够，但如果你的客户端要求完整路径，就要指向安装目录下的可执行文件。具体路径因版本与安装方式而异，请以实际安装位置为准。

五、一次完整设置流程（含小案例）

把上面的碎片拼起来，一次完整的配置大致分为五步：确定目标、选择模式、勾选应用、保存并重连、验证结果。下面用一个假设的场景串一遍。

假设你是一位需要频繁查阅外部资料的内容工作者。你的诉求是：浏览器与文献管理工具走代理，公司内部系统、即时通讯、以及本地影音播放器直连。第一步，明确这份清单只有两个条目，属于“应用集合稳定”的类型，适合分应用代理。第二步，选择“仅代理所选应用”的正向模式，因为需要代理的少、直连的多，正向列举维护成本更低。

第三步，在列表中勾选浏览器与文献管理工具。如果列表按安装来源分组，注意不要漏掉通过其他渠道安装的副本。第四步，保存后断开连接再重新连接，让新的隧道参数生效——很多“设置了没反应”的情况，根源就是没有重建隧道。第五步进入验证环节，方法见第七节。

这里顺便回答一个高频疑问：能不能给同一个应用设置不同规则？不能。分应用代理的粒度就是进程，一个进程要么在清单内、要么在清单外，没有中间态。如果你需要更细的控制，只能退回到规则分流，按目标地址做判断。

六、保存与恢复：配置存在哪里、何时会丢

配置的持久化通常发生在客户端本地，与账户绑定的云端同步则取决于该产品是否提供此能力，本文不做假定。经验性观察是：大多数客户端会把分流清单写入本地配置，正常退出后重新打开仍然保留；但在更换设备、重装应用、清除应用数据这三种情况下，清单大概率需要重新配置。

另一个容易被忽略的点是“配置生效的时机”。保存动作只是写入配置，隧道参数的更新往往发生在下一次建立连接时。因此在保存后主动断开再连接，是一个成本极低但收益明确的习惯。若你的客户端提供“应用配置后自动重连”的选项，打开它可以省掉这一步。

注意：系统级 privacy tool 配置在同一时刻通常只能有一个生效。如果你同时安装了其他使用 privacy tool 接口的应用（包括部分企业办公客户端），两者可能互相顶掉，表现为分流配置“时好时坏”。排查时先确认当前生效的 privacy tool 是哪一个。

七、验证：三个可复现的观测方法

设置完成不等于生效。下面三种方法都不依赖任何未公开的工具，普通用户即可完成，建议至少用一种做闭环确认——三种方法各有盲区，组合使用才比较可靠。

7.1 出口 IP 比对

做法：保持代理连接，用清单内的应用访问任意可显示出口地址的查询页面，记录结果；再断开代理重复一次。若两次结果不同，说明该应用确实被接管；若相同，说明未生效。这个方法的优点是直观，缺点是只能验证“是否改变出口”，无法验证“是否走了预期链路”。

7.2 客户端流量计数

做法：在客户端主界面观察上下行流量计数，先只使用清单外的应用一段时间，再只使用清单内的应用一段时间。预期可观测指标是：前者期间计数基本不动，后者期间计数明显增长。若两者都增长，说明分流没有按预期工作，需要回到第四节的模式选择环节检查正反向逻辑。

7.3 断连与重连测试

做法：在清单内的应用正常使用时，主动断开代理。预期是应用立即出现网络异常或明显卡顿；恢复连接后恢复正常。若断开代理后应用毫无反应，说明它本来就没走代理。这个方法对长连接类应用尤其有效，能一次性排除连接复用带来的误判。

八、性能与成本：该给哪些应用开口子

分应用代理不是免费的。每多一个应用进入隧道，就多一份加解密开销、多一份连接跟踪表的条目、多一份后台常驻的可能性。在低配设备上，这种开销会直接体现为发热与耗电。所以清单不是越长越好，而是越准越好。

8.1 需要观察的三个量

第一个量是设备侧的耗电趋势。不需要精确数字，只需对比“清单为空”与“清单含若干应用”两种状态下的续航感受，观察周期建议覆盖一个完整的工作日。第二个量是客户端的上下行速率，观察是否在纳入某个应用后出现持续性的带宽占用。第三个量是连接数，部分客户端会显示当前活跃连接数量，纳入大量后台应用后这个数字会明显上涨。

8.2 经验性阈值

经验性观察是：当清单条目维持在一屏以内、且都是前台高频使用的应用时，配置的可维护性与性能开销都处于舒适区；一旦条目数持续增长到需要滚动查找、并且包含大量后台自动同步类应用，收益就开始被成本吃掉。此时更合理的做法是切换到规则分流，让地址库去承担判断工作。

另一个经验性判断是：如果一个应用你一周都没打开过，它就不该出现在清单里。定期清理清单，比不断添加更能保持体验稳定。

九、失败分支与回退路径

现象一：找不到分应用代理入口。可能原因是你使用的平台不提供该能力，或当前版本未开放。验证方式是在设置内逐项查找是否出现“应用”“分流”“代理范围”等字样；若确实没有，回退方案是改用全局模式配合规则分流。

现象二：勾选后应用仍直连。按顺序排查：连接是否已重建、模式是否选反、该应用是否通过其他进程发起请求、是否存在系统级代理覆盖。逐项验证后仍无效，可尝试将该应用移出清单，观察出口是否与预期相反，以此判断清单是否真的被读取。

现象三：开启分流后整体网络变慢。可能原因是隧道内应用过多导致开销累积，或某个后台应用持续占用带宽。处置方法是先清空清单建立基线，再逐个加回，定位到具体应用。这个过程通常需要重复两三次，但能一次性把问题锁死。

现象四：切换网络后配置失效。移动网络与 Wi-Fi 切换会重建网络接口，部分客户端需要重新触发连接才能恢复分流。若频繁发生，可检查客户端是否提供“网络变化时自动重连”的选项。

这四个现象基本覆盖了大多数使用场景，排查时按“先看平台能力、再核对模式、最后检查连接状态”的顺序走，通常能少绕不少路。

十、适用与不适用清单

适用场景包括：应用集合稳定且数量可控；明确需要“少数应用走代理、多数直连”；对流量走向有可解释性要求（例如需要向同事说明为什么某个系统不受影响）；设备性能充足，能承受隧道开销。这些条件下，分应用代理的确定性优势最明显。

不适用场景包括：需要按目标地址精细控制；应用中混杂大量境内外请求；使用 iOS 且平台不提供该能力；清单需要频繁变动；对延迟极度敏感且链路本身不稳定。这些情况下，规则分流或全局模式往往更合适，强行使用分应用代理只会增加维护负担。

十一、最佳实践检查表

把上面的内容压缩成一份可执行的检查表，便于每次配置时对照：确认平台是否支持按应用筛选；确认选择的是正向还是反向模式；清单条目控制在一屏以内；每纳入一个应用都问一句“它真的需要换出口吗”；保存后主动重建连接；用出口比对或流量计数做一次闭环验证；遇到异常先清空建立基线再逐项加回；定期清理长期未使用的条目。

最后需要强调，分应用代理是一个“边界清晰但需要自律”的功能。它给你的是确定性，代价是你要为这份确定性负责。理解它管的是进程而不是域名，理解平台能力的上限，理解配置生效需要重建连接，这三点想清楚了，后面的操作基本不会出错。

FAQ

如果把整篇内容压缩成一句话：分应用代理的价值在于确定性，而确定性的代价，是你需要为那份清单持续负责。

从可预期的方向看，这类能力的边界主要由操作系统框架的开放程度决定，短期内各平台之间的差异大概率仍会存在；客户端侧更可能出现的变化，是配置入口与验证手段的完善程度，而非底层判断逻辑的改写。至于你手上这个版本究竟提供了哪些入口、行为是否一致，仍以实际界面表现和第七节的验证结果为准。