QuickQ分应用代理功能如何设置指定软件单独走线路？

QuickQ 分应用代理（部分版本界面显示为“应用分流”或“分应用 privacy tool”）要解决的是一个很具体的问题：让设备里的一小部分软件走代理线路，其余流量保持直连。如果你曾因为开着全局代理导致网银验证失败、局域网投屏找不到设备，或者反过来，只希望某个海外应用能稳定连通，那么需要的正是这个功能。下面按“问题—约束—解法”的顺序，把判断依据、平台路径、验证手段和取舍边界一次讲清楚；文中涉及的菜单名称与文案可能随版本调整，请以你实际安装的客户端为准。

一、功能定位：它解决的到底是什么问题

分应用代理属于“流量选择性接管”这一类能力。传统全局代理会把设备上几乎所有出站流量都送进隧道，好处是省心，代价是本地服务也会被绕一圈：打印机发现、投屏、局域网共享、部分银行与政务类客户端的本地校验，都可能因为出口地址突变而失败。分应用代理把选择权交回给用户——你只勾选需要走线路的那几个应用，其余流量继续按系统默认路由出去。

需要先明确一点：它是“按应用”划分，不是“按网站”划分。同一个浏览器里打开的两个网站，无法靠这个功能一个走代理、一个直连——那是规则分流（按域名/地理位置的策略路由）负责的事。把两者混为一谈，是新手最常见的预期错位。

与全局代理、规则分流的区别

三者的判断维度不同。全局代理不判断，全收；规则分流按目标地址判断，同一个应用的不同连接可以走不同路径；分应用代理按发起连接的程序判断，粒度更粗但更可控。工程上的取舍是：分应用代理实现简单、行为可预测、对系统侵入小，代价是同一应用内部的流量无法再细分。因此，如果你遇到“浏览器里 A 站要走代理、B 站要走直连”的需求，应当去找规则分流，而不是在这里反复调整。

三条硬性边界

先看三条硬性边界。第一，分应用代理只能识别到系统能给出身份标识的流量。安卓侧依赖应用的包名（对应系统分配的 UID），桌面侧依赖进程与虚拟网卡的路由归属；系统级服务、共享网络栈的进程，以及部分通过其他应用代发的请求，可能被归到意料之外的一侧。第二，它对协议没有偏好，但对网络类型敏感——部分语音通话与游戏依赖的 UDP 行为，与 TCP 表现不同，勾选后仍可能出现单通。第三，它不改变目标站点对你的识别结果：出口地址变了，风控策略随之变化，这是使用者需要自行评估的部分。

二、决策树：先判断你是否真的需要它

在动手之前花两分钟做判断，比事后排查一小时更划算。下面这组问题按顺序回答，基本能定位到你应该用哪种模式。

1. 是否有本地设备或本地服务必须保持可达（打印机、NAS、投屏接收端、局域网数据库）？有，则不能使用全局接管，分应用代理是合适选项。
2. 需要走线路的应用数量是否明显少于需要直连的数量？是，选白名单（只勾选需要走线路的）；否，选黑名单（勾选需要排除的）。
3. 目标应用是否依赖 UDP 或需要稳定长连接（实时语音、在线对战）？是，先小范围试用并观察，别一次性把整套依赖都切过去。
4. 是否有合规或账号安全方面的硬性要求（企业内网准入、金融类客户端）？有，这类应用一律排除在代理之外。

四问的答案基本能确定模式方向与配置范围，接下来再把它们对应到具体场景。

三类典型需求，对应三种配法

场景一：远程办公。公司内网客户端必须直连，同时要访问若干海外协作服务。做法是把协作类应用加入白名单，内网客户端保持默认。场景二：跨区内容访问。设备上装了几十个应用，只有两三个需要换出口，其余全部直连，这也是白名单最典型的用法。场景三：本地开发调试。需要让某个命令行工具或调试器走代理，同时本机数据库、容器网络必须可达，此时应把代理范围压到最小，并明确记录被纳入的进程名，方便日后复核。三种场景的共同点，都是先划清边界，再决定谁进谁出。

两类不该用的场景

一是把分应用代理当成“稳定性修复工具”。如果某个应用在全局模式下不稳，换成按应用分流通常不会自动变好，因为瓶颈可能在链路本身而不是分流方式。二是把它当成访问控制的替代品。它决定的是流量走哪条路，不是能不能访问，家里有未成年人设备管理需求时，应使用设备自带的应用限制能力。

三、原理速览：系统层是怎么“按应用”分开的

理解机制有助于你判断“为什么某个应用没生效”。不同平台实现差异较大，但总体思路一致：先建立一个虚拟网络接口接管默认路由，再决定哪些应用产生的流量被导入该接口。

安卓：基于包名的包含与排除

安卓系统提供的 privacy toolService 接口支持按应用包名声明“允许列表”或“禁止列表”，这是绝大多数分应用代理功能的通用实现基础。也就是说，分流判定发生在连接建立之前，依据是发起连接的应用身份，而不是目标地址。由此可以推出两条实用结论：其一，通过其他应用代发的请求（例如系统下载管理器代替浏览器下载）会按代发者的身份归类；其二，未在列表中出现、又无法被系统识别身份的连接，其行为取决于当前选的是允许列表还是禁止列表模式。

桌面端：虚拟网卡、路由表与进程匹配

Windows 与 macOS 上的常见做法是创建一块虚拟网卡并调整路由优先级，再通过进程识别把连接归类到对应策略。相比移动端，桌面端更容易受第三方安全软件、其他虚拟网卡（虚拟机、容器工具、企业 privacy tool）干扰，因为它们同样会改写路由表。经验性观察是：当设备上同时存在两个以上会改写路由的软件时，分流行为出现偏差的概率明显上升，此时应逐个停用做对照。

四、安卓端：最短可达路径与分支处理

安卓端是三个平台里路径最短的，通常三步之内可以完成。以下描述基于通用结构，具体文案以实际界面为准。

1. 打开客户端，进入设置（多在首页右上角或底部导航的“设置”“我的”页签）。
2. 找到“分应用代理”“应用分流”或“分应用 privacy tool”一类的条目，进入应用列表。
3. 选择模式：只让勾选的应用走线路，或只让勾选的应用直连；随后在列表中定位目标应用并保存。

保存后建议立刻断开再重连一次隧道。部分系统版本在隧道建立期间修改分流规则不会立即生效，重连是成本最低的复位手段。

列表里找不到目标应用怎么办

多数情况下是列表尚未刷新。可以退出该页面再进入，或直接重启客户端；如果目标应用是刚安装的，重启客户端通常即可看见。另有一种情况是应用以多开、分身或工作资料（工作空间）形式存在，这类副本可能以不同的包名出现，列表中显示的名称也可能带有后缀。此时应按照实际显示的条目勾选，而不是按记忆中的名称寻找。至于系统预装应用，部分版本会默认折叠或隐藏，需要展开“显示系统应用”一类的选项才会出现。

勾选后仍然全部走代理的排查顺序

先确认模式方向是否反了——白名单与黑名单的语义相反，这是最高频的误操作。其次检查是否有第二个代理类或加速类应用在运行，两者会争抢虚拟网卡的控制权。最后确认系统是否对该应用启用了“后台数据限制”或省电策略，被系统冻结的应用可能在网络层被重建，导致实际流量归属发生变化。

五、苹果端：路径更短，但可见范围不同

苹果端的入口位置与安卓接近，同样在设置的网络相关分组里，但呈现方式更简洁：通常是一个开关加上一个应用列表，列表项数量可能少于设备实际安装的应用。这属于平台差异而非故障。

操作上建议按同一顺序：进入设置 → 找到分应用代理类条目 → 选择方向 → 勾选目标应用 → 断开重连。苹果端首次启用时，系统可能弹出添加 privacy tool 配置的授权框，需要允许，否则隧道无法建立。如果误点了拒绝，可在系统设置的通用 → privacy tool 与设备管理 中删除旧配置后重新启用。

与安卓的两点实质差异

第一，苹果端对后台网络的管控更严格，被系统挂起的应用在恢复前台时会重建连接，短时间内的流量归类可能出现抖动，这属于正常现象而非配置错误。第二，部分系统级流量由系统进程统一发起，不在应用列表的可选范围内，因此即使你把所有可见应用都设为直连，仍可能有少量流量走代理。判断标准应以你实际关心的那个应用是否按预期工作为准，而不必追求“列表中每一项都精确对应”。

六、电脑端：Windows 与 macOS 的路径与坑

Windows

桌面端通常不在主界面直接给出应用勾选，而是在设置里以“分应用代理”“应用分流”或“分流设置”的形式出现，进入后是一个已安装程序的列表，可勾选需要走线路或需要排除的可执行文件。路径大致为：主界面 → 设置 → 分流相关条目 → 勾选 → 保存并重连。若列表未收录你需要的程序，部分客户端提供“手动添加”或“浏览选择可执行文件”的入口；没有该入口时，应以实际版本能力为准，不要尝试通过重命名文件绕过，容易造成识别失败。

Windows 上最常见的干扰源是其他虚拟网卡与企业安全软件。验证方式很简单：断开所有其他 privacy tool 与虚拟机网络，只保留当前客户端，观察分流是否恢复正常；恢复则说明是路由抢占，需要在使用时错开。

macOS

macOS 端首次启用需要授予系统扩展权限，授权后可能需要重启客户端甚至重启系统才能生效，这一点与 Windows 差异明显。分流列表一般按应用名称呈现，勾选后立即保存即可。需要留意的是，macOS 上通过终端启动的命令行工具与应用商店应用在身份识别上可能表现不同，若你希望某个脚本走代理，建议用其对应的图形客户端做验证，或查阅客户端是否提供进程级说明。

七、白名单还是黑名单：一条可执行的判断规则

判断规则可以压缩成一句话：需要走线路的应用少，用白名单；需要直连的应用少，用黑名单。之所以强调“少”，是因为列表越长，越容易在应用更新、包名变化、多开分身等情况下出现遗漏，而遗漏在两种模式下的后果完全不同——白名单漏了，是“本该走代理的没走”；黑名单漏了，是“本该直连的走了代理”，后者更容易引发本地服务不可用。

举个具体例子。某位用户的设备上安装了一百多个应用，日常只有两个需要换出口，其余包括网银、智能家居控制、公司内网客户端都必须保持本地出口。按上述规则应选白名单，只勾那两个。如果他反向操作，改用黑名单并逐个排除近百个应用，那么每次安装新应用都要回来补一次，维护成本高且极易遗漏。经验性结论是：应用清单越动态，越应该选择“默认不接管”的那一侧。

混合需求怎么拆

当同一台设备上既有“必须只走代理”的应用，又有“必须绝不走代理”的应用时，正确做法是选定一个方向后，把另一侧当作默认值处理，而不是两边都维护。也就是说，白名单模式下，未被勾选的一律直连，这已经满足“绝不走代理”的要求，无需再额外配置排除项。只有当客户端同时提供包含与排除两组列表时，才需要留意两者的优先级，具体以客户端内的说明为准。

八、配置完成后如何验证：三步可复现流程

验证的目标不是“看起来能用”，而是“我关心的那个应用确实走了预期的路径”。下面三步具备可复现性，且不依赖任何特定站点。

1. 对照组：先在未开启代理的状态下，用目标应用访问一个会显示出口地址的查询页面，记录结果。
2. 实验组：开启代理并保持分应用配置，再用同一应用访问同一页面，比较出口地址是否发生变化。
3. 反向验证：用一个明确被排除的应用重复第 2 步，其出口地址应保持与第 1 步一致。两侧同时符合预期，才算配置生效。

如果第 2 步没有变化，说明该应用的流量未被纳入；如果第 3 步也变了，说明方向选反了或规则未生效。两种情形都可以通过重新检查模式方向、重连隧道来排除。

可观测指标对照表

观测项	预期表现	不符时的含义
目标应用出口地址	与直连时不同	未纳入规则或隧道未建立
被排除应用出口地址	与直连时一致	模式方向选反或规则被覆盖
局域网内设备发现	可正常发现与连接	该发现行为由已被接管的进程发起

九、故障排查：按“现象—原因—验证—处置”推进

排查不要靠猜，按固定顺序走，每次只改一个变量。下面列出四类高频现象，每类给出可执行的验证动作。

现象一：所有流量都走了代理。可能原因是模式方向选反，或同时运行了第二个会接管网络的软件。验证方法是暂时退出其他代理类、加速类客户端后重连观察；若恢复正常即为冲突。处置上，保留一个接管者即可。

现象二：目标应用始终不走代理。先确认该应用是否在列表中以分身或多开形式出现，存在多个条目时需勾选实际运行的那个。其次检查该应用的网络请求是否由系统下载器或其他服务代发，代发时身份归属会变化。处置上，可先用同一应用内的不同功能做对比，判断是全局性未生效还是个别请求未覆盖。

现象三：启用后本地投屏、打印、NAS 不可达。这类能力的设备发现通常依赖局域网内的广播或多播，一旦发起方被纳入代理，发现阶段就会失败。验证方法是在关闭代理时重复同一操作，若正常则确认与分流相关。处置上，把负责发现与投放的应用整体排除，而不是逐个功能尝试。

现象四：语音或对战类应用出现单通、掉线。这类应用常依赖 UDP 与较长的心跳周期，行为与网页浏览差异明显。建议先小范围试用并记录现象，确认问题是否与分流相关；若在直连状态下同样出现，则与分流无关，应从链路本身排查。

十、例外与取舍：哪些应用建议一律排除

经验上，有四类应用适合直接放进排除侧，不必逐个评估。第一类是金融与身份验证类客户端，它们的风控往往对出口地址的稳定性敏感。第二类是局域网依赖型应用，包括投屏、打印、智能家居控制、家庭 NAS 客户端。第三类是系统更新与备份类服务，它们通常在后台长时间传输，接管后既占用线路又难以观测。第四类是企业内网准入客户端，这类应用本身带有安全策略，改动路径容易触发告警。

取舍的核心不是“能不能”，而是“值不值”。把金融类应用纳入代理，收益通常接近于零，风险却由你自己承担；把系统更新纳入代理，收益是可能更快的下载速度，代价是长时间占用带宽并影响其他应用的体验。把这两类想清楚，剩下的判断会快很多。

十一、合规与账号安全边界

分应用代理改变的是流量的出口路径，不改变你与目标服务之间的权利义务关系。使用前应确认所在地区与所属组织对网络接入的相关规定，尤其是涉及企业设备、涉密环境或受监管行业时，应以组织内部的网络使用规范为准，而不是以客户端是否提供该开关为准。

账号层面有一条实用建议：不要在为某应用配置分流的同时频繁切换出口，登录态与设备指纹的变化叠加，容易触发额外的验证步骤。若某个账号出现过异常登录提醒，先把分流配置恢复为默认，再单独验证是配置问题还是账号问题。

十二、适用与不适用场景清单

适用场景包括：设备上只有少数应用需要换出口；存在必须保持可达的局域网设备；开发调试时需要把代理范围压到具体进程；企业设备上需要保留内网客户端的直连能力。这些场景的共同点是“边界清晰、应用数量少、失败后果可观测”。

不适用场景包括：需要按目标网站而非按应用做区分；需要精细到单条连接级别的策略；设备上存在多个会改写路由的软件且无法错开使用；以及希望通过它来实现访问控制或内容管理。这些需求应当交由规则分流、设备管理策略或组织级网络策略处理，用分应用代理去凑，通常只会增加排查成本。

十三、最佳实践检查表

把下面几项当作配置完成后的自检项，逐条确认即可，不必追求一次到位。

• 模式方向与需求一致：需求是“少数走代理”，就选白名单侧。
• 列表中的条目与设备上实际运行的应用一致，特别注意多开与工作资料副本。
• 金融、内网、局域网依赖类应用全部位于排除侧。
• 修改配置后已断开并重连隧道，而非仅切换开关。
• 已用第八节的三步法完成正反两组验证。
• 已记录当前配置清单，便于系统或应用更新后复核。
• 设备上不存在第二个同时接管网络的软件，或已确认二者可共存。

这七项覆盖了模式方向、条目准确性、排除项与验证四个层面，逐条确认之后再进入日常使用，会踏实很多。

十四、版本差异与迁移建议

不同版本之间，该功能最可能出现差异的地方有三处：入口所在的层级、列表的呈现方式（是否折叠系统应用、是否支持手动添加）、以及模式的表述方式（“包含/排除”与“仅代理所选/仅直连所选”混用）。因此不建议照抄某篇教程中的逐字路径，而应把“设置 → 网络相关分组 → 分流条目”当作结构记忆，具体文案现场比对。

迁移到新设备时，最稳妥的做法是先在新设备上重跑第八节的验证流程，再逐步把旧设备的清单搬过去，而不是一次全量复制。原因是新设备的应用组合、系统版本、以及是否装有其他网络软件都不同，旧清单直接套用很容易出现“看起来配好了但行为不对”的情况。至于配置能否跨设备导出，取决于当前版本是否提供该能力，以实际界面为准。

十五、常见问题

写在最后

回到最初的问题：分应用代理的价值不在于“功能多强”，而在于它把选择权精确地限定在“哪些应用”这一层，用最小的改动换取局域网可达性与本地服务稳定性。它的代价是同一应用内部无法再细分，因此当你发现需求开始向“同一个应用的不同目标要分开处理”演进时，就该考虑换用按目标地址判断的方案，而不是在这里继续加配置。

下一步建议这样走：先按第二节的四个问题确认方向，再按对应平台的路径完成一次最小配置——只纳入一个应用，跑完第八节的三步验证。等这一个应用的行为稳定可复现之后，再把其余应用逐个加入，每次加入后重复验证。这种“一次只动一个变量”的做法，看起来慢，实际上省掉了后续大部分排查时间。

从版本演进看，这类功能的入口位置与文案表述大概率还会继续调整，不同平台之间的差异也会长期存在；与其记住某一条固定路径，不如记住“设置 → 网络相关分组 → 分流条目”这个结构，并在每次大版本更新后按第八节的流程复核一次。这样无论界面怎么变，判断依据都不会丢。