QuickQ分应用代理功能支持哪些规则模式？

分应用代理到底在解决什么问题

QuickQ分应用代理（Split Tunneling，直译为“隧道拆分”）指的是把“哪些应用的流量进入代理隧道、哪些走本地直连”从全局一刀切，改为按应用进程粒度决定。它要回答的不是“能不能连上”，而是“连上之后这笔账划不划算”。

一次全局代理意味着设备上所有联网程序——包括网盘后台同步、系统更新下载、本地银行客户端、局域网投屏——都要从远端出口绕一圈再回来。带宽被重复消耗，端到端延迟被拉长，部分对登录地敏感的服务还可能触发额外的安全校验。分应用代理的价值就在于：在保证目标应用可达的前提下，把隧道占用压到最小。换句话说，它衡量的不是“代理能不能用”，而是“这条流量是否真的必须从远端出口出去”。

这里必须先划清一条边界。分应用代理和“按域名/IP 分流”（常见的 PAC 规则、规则集模式）不是同一层的东西。域名规则是在同一个应用的连接内部，按目标地址逐条决定走不走代理，粒度细但需要持续维护规则表；分应用代理是在进程层面画线，配置一次长期有效，代价是粒度粗——一个应用要么整体代理、要么整体直连，无法只代理它的部分请求。两者并非替代关系，只是切在了不同的层面上，先分清这一点，后面的模式选择才不容易跑偏。

判断口诀：痛点是“同一个浏览器里，某些站点要走、某些不要走”，那是域名规则该干的事；痛点是“这几个 App 必须走，其余全部别碰”，才是分应用代理的战场。

四种规则模式的差异与适用面

各家客户端对规则模式的命名不完全统一，但底层逻辑基本收敛为四种。理解它们的差别，比记住某个按钮叫什么名字更重要，因为界面文案会随版本调整，而判断逻辑不会。下表按“隧道内流量”与“维护成本”两个维度横向对照，可以先建立整体印象，再逐条看后面的展开。

全局模式：把“确定性”放在“效率”之前

全局模式不参与任何判断，所有流量一律进隧道。它的好处是行为可预测——出了问题只需要排查一个变量。当你在陌生网络环境下发现某个应用异常，第一步往往就是把模式临时切到全局，确认“是不是分流规则导致的”，这比逐条比对名单快得多。

但它不该成为长期状态。经验性观察是：在移动设备上长期开启全局，后台同步类应用的唤醒次数与流量开销都会有可见增长，原因很直接——原本几十毫秒可达的本地服务，被迫多走一段公网往返。示例：在酒店 Wi-Fi 下某应用登录失败，先切全局确认能否连通，再切回原分流观察症状是否复现，两步就能判断问题出在规则还是出在网络上。何时不该用：设备上存在局域网设备发现需求（投屏、无线打印、NAS 访问）时，全局模式几乎必然导致这些功能失效。

绕过模式：清单越短，越不容易腐坏

绕过模式（黑名单）默认全代理，只把勾选的应用放出去直连。它适合大多数日常使用，因为默认路径最安全——新装的应用自动进隧道，不需要你想起来去加白。风险点在于清单的“腐坏速度”：装的本地服务越多，需要维护的排除项越多，一旦漏掉一个，症状往往是“某某功能时好时坏”，很难归因。这也解释了它为什么更适合作为日常默认或过渡方案，而不是一劳永逸的终点。

举个具体场景：一台经常需要投屏到客厅电视的手机，把投屏相关应用和系统媒体服务加入绕过清单后，投屏恢复稳定；但如果系统更新后又出现一个负责设备发现的系统组件未被排除，问题会以“电视搜不到手机”的形式重现。所以绕过清单需要定期复核，而不是一次性配置完就遗忘。复核时机也有讲究——系统大版本更新、客户端升级、新装一类常驻后台的应用之后，都是值得重看一遍的节点。

仅代理选定应用：成本最优，维护最重

白名单模式默认全部直连，只把勾选的应用送进隧道。从“性能与成本”的准绳看，这是隧道占用最小的方案：只有真正需要代理的进程才付带宽与延迟的代价，其余流量全部走本地最优路径。

代价是配置负担转移到了人身上。新装的应用默认不进隧道，需要你主动添加；某些应用内部调用系统组件发起请求（例如通过系统浏览器打开登录页），可能出现“主应用已代理、登录环节却走了直连”的割裂现象。何时不该用：如果你连“到底哪几个应用需要代理”都列不出来，白名单会让你在上线初期频繁踩坑，此时先用绕过模式过渡更稳妥。反过来看，一旦这份名单稳定下来，它的日常维护量其实很低，因为需要代理的应用通常变化缓慢。

按网络类型分流：解决“同一台设备两种身份”

同一个应用，在蜂窝网络下需要代理、在家里 Wi-Fi 下不需要——这是很常见的真实需求。部分客户端允许对 Wi-Fi 与移动数据分别指定规则模式，本质是把上面三种模式叠成两套配置，按当前网络接口切换。

这套配置的维护成本最高，因为你要同时维护两份清单，还要记住每份清单在哪种网络下生效。适用前提很明确：你的 Wi-Fi 环境本身就有稳定、合规的出口，代理在那种场景下是纯负担。如果你的 Wi-Fi 和蜂窝环境差别不大，这份复杂度换不来收益。排查时也要多留一个心眼——同一症状在两种网络下出现，未必是同一个原因。

用三个问题走完决策树

与其背模式名称，不如按顺序回答三个问题。这三个问题覆盖了绝大多数实际配置场景，且不依赖任何具体版本的界面文案。顺序本身也有意义：前两问决定名单往哪个方向列，第三问只在确有必要时才追加一层复杂度。

第一问：设备上是否存在“绝不能进隧道”的应用？典型候选是本地银行客户端、企业内网工具、依赖局域网发现的应用。只要答案是“有”，绕过模式就是天然起点，因为这些应用一旦被代理，症状往往不是变慢而是直接不可用。

第二问：能不能把它们列全？如果能列全，说明你对设备上的应用组合有清晰认知，可以考虑白名单反转——把“需要代理的少数”作为名单，其余全部直连。经验性建议是：当需要代理的应用数量明显少于需要直连的应用数量时，白名单的维护成本反而更低，因为你要维护的条目更少。

第三问：Wi-Fi 与蜂窝下的需求是否一致？只有当两者的答案明显不同，才值得引入按网络类型分流。若两者一致，多这一层只增加排障难度。

兜底原则：任何时候拿不准，先切全局跑一轮对照，再改分流。一次只改一个变量，是排障效率最高的做法。

操作路径：Android、iOS 与桌面端的最短可达路线

进入分应用代理的入口，各平台大致落在同一位置：客户端的设置类页面——通常在侧边栏、底部导航或右上角菜单中，分组名称多为“代理模式”“分流设置”“高级设置”一类。具体分组名与层级会随版本调整，请以你实际安装的版本为准，下文给出的是通用可达路径而非逐字界面对照。

Android

打开客户端 → 进入设置类页面 → 找到与代理模式或分流相关的分组 → 选择规则模式 → 在应用列表页逐项勾选。Android 端通常能读到完整的已安装应用列表，勾选后即刻生效，无需重启连接。

需要注意系统层面的限制：部分定制系统会对后台应用做省电管控，若某个被代理的应用长期处于冻结状态，它发起的流量可能在你切换规则后才被延时处理。验证方式是操作后立即在目标应用内触发一次网络请求，观察是否按预期走通。如果结果与列表配置不符，先排除省电策略的影响，再回头怀疑规则本身。

iOS

iOS 端的入口同样在设置类页面内，但由于系统沙盒限制，应用列表的呈现方式可能不同于 Android——部分版本以“已安装应用扫描”的形式提供，部分版本需要你手动添加目标的 Bundle 标识。如果列表中找不到某个应用，先确认该应用确实安装在本机并可正常联网，再检查客户端是否具备读取应用列表的系统权限。

iOS 上还有一个容易被忽略的变量：系统的网络扩展权限状态。若权限被撤销或配置描述文件失效，分流规则会表现为“配置看起来还在，但实际不生效”。此时的做法是先关闭代理再重新开启，必要时重新走一遍授权流程。经验性观察是，这类“配置还在但不生效”的情形多数与权限状态有关，而不是名单写错了。

桌面端（Windows / macOS）

桌面端的典型路径是：客户端主界面 → 设置 → 代理/分流相关分组 → 选择模式 → 从进程列表中勾选可执行文件。与移动端的差别在于，桌面端通常需要指出可执行文件路径而非应用名称，因此同一个程序的不同安装位置会被视为两个条目。

这里常见的失败分支是：你代理了主程序的 exe，但它启动后唤起的更新器、子进程或独立渲染进程并未被覆盖，导致部分请求仍走直连。处置方法是观察实际联网的进程名，把它们一并加入名单，而不是只勾选最外层那一个。程序升级后路径发生变化，同样会表现为规则失效，这一点在桌面端尤其需要留意。

失败分支与回退方案

改完规则后如果目标应用反而不通，按下面的顺序回退，不要一次尝试多个修复动作：先切回全局模式，确认代理本身可用；再切回原模式，只把该应用单独加入名单，验证是否为名单遗漏；最后才怀疑规则冲突。若三步之后问题依旧，把客户端配置导出或在另一台设备上复现，可以快速区分“账号/线路问题”与“本机配置问题”。回退顺序之所以固定，是为了让每一步都留下一个可对照的状态。

性能与成本：测什么、怎么测

讨论分流收益时，最容易出现的错误是拿“感觉变快了”当结论。更可靠的做法是选定两三个可重复的观测项，在规则切换前后各测一轮，且保证测试条件一致——同一网络、同一时段、同一目标应用、同一操作路径。观测项不必多，能形成前后对照即可。

观测项一：目标应用的首次内容呈现时间。操作步骤是清空该应用缓存后冷启动，记录从点击图标到主要内容可读的时间。预期可观测的差异是：走隧道时通常可见增长，直连时更接近本地网络基线。这里不做秒级断言，因为结果高度依赖线路与设备，只需要你能看出方向性差异即可。

观测项二：出口地址是否符合预期。在目标应用内或系统浏览器中访问任意 IP 查询页面，记录显示的出口地址；切换到直连规则后重复一次。若两次结果一致，说明规则没有真正生效，问题在配置而非线路。

观测项三：后台流量开销。在设备的流量统计页面观察一段时间内的移动数据用量，对比“全代理”与“分流”两种状态下的增长幅度。这是定性的量级判断，用来支撑“分流是否值得维护”的决策，而不是用来做精确核算。

何时不该做这套测量：当你只有一两个应用需要代理、且对延迟不敏感时，测量的成本高于收益，直接按决策树配置即可。测量本身也是要花时间与注意力的，它服务于决策，而不是为了凑出一组数字。

例外清单该放什么、不该放什么

无论用哪种模式，例外清单的质量决定了这套配置能稳定运行多久。判断标准只有一条：这个应用是否依赖“与你在同一网络位置的设备或服务”。依赖的，一律排除出隧道。

• 局域网发现类：投屏、无线打印、智能家居控制、NAS 与共享文件夹访问。
• 位置敏感类：本地银行与支付客户端、需要与本地 SIM 或设备指纹协同的服务。
• 大流量本地类：系统更新、网盘全量同步、局域网内文件传输。
• 企业内网工具：只有在公司网络内才可达的内部系统。

上面四类的共同点，是它们的通信对象离你很近，绕远路只会把可达性换掉。不该放进例外清单的，则是那些“偶尔慢就想排除”的应用。排除一个应用意味着它的所有流量都失去了代理保护，如果它本身包含需要代理的请求（例如内置的海外资源加载），你会得到一个更难排查的半通状态。遇到这类情况，正确做法是判断这个应用是否真的需要代理，而不是把它塞进例外里试。

副作用与风险：三个必须提前知道的问题

一是 DNS 归属不一致。当应用走直连、而系统 DNS 仍指向远端时，可能出现解析结果与实际出口不匹配，表现为“页面能打开但加载很慢”。验证方法是分别在两种规则下访问同一站点，对比解析到的地址是否属于同一地区。处置思路是让 DNS 与流量的归属保持一致，具体开关位置因客户端版本而异。

二是局域网能力被削弱。这是全局模式最典型的副作用，也是黑名单遗漏时最常见的症状。可复现的验证步骤：在设备上打开投屏或打印机发现功能，观察是否能列出同一网段内的设备；若列表为空，把相关应用加入直连名单后重试，列表恢复即说明归因正确。

三是合规与协作边界。在受管设备上自行更改流量走向，可能与组织的网络使用规范冲突。这不是技术问题而是流程问题，判断标准很简单：设备是否由组织统一管理、是否签署过相关使用协议。属于此类场景时，先确认规范再动手，而不是先配置后解释。

提醒：分流规则只决定“走不走隧道”，不改变应用自身的安全策略。把某个应用排除出隧道，并不等于它的流量就“更安全”，两者不可混为一谈。

与第三方工具协同：权限最小化是底线

部分用户会尝试用自动化脚本或第三方的流量统计工具来辅助验证分流效果。这类协同是可行的，但边界要说清楚：辅助工具只应读取统计信息，不应被授予修改网络配置或安装证书的权限。

一个可复现的最小化方案是：用系统自带的流量统计页面替代第三方工具做前后对比，用任意 IP 查询页替代专用检测客户端确认出口归属。这样做的好处是零额外授权、可随时复现、结论不依赖某个第三方应用的可信度。只有当系统自带能力确实不满足需求时，才考虑引入外部工具，并在验证完成后及时收回权限——验证是一次性的动作，权限却会长期留在系统里。

故障排查：现象、原因与处置

排查时请坚持一个原则：一次只改一个变量。同时改模式和名单，即便问题解决了，你也不知道是哪一步起的作用，下一次遇到同样症状仍然要从头试。表格里的“验证方式”一列，作用正是把“猜”换成“看”。

适用与不适用：一份清晰的准入清单

适合启用分应用代理的情况：设备上同时存在“需要代理”和“必须直连”两类应用；有明确的局域网使用需求，如投屏、打印、NAS 访问；移动数据流量有限，希望压低后台开销；应用数量较多，全局代理带来的延迟可被明显感知。

不适合启用的情况：只有单一应用需要联网，此时全局模式的心智负担最低；正处于排障期，需要减少变量而非增加变量；设备由组织统一管理且规范未明确允许；刚更换客户端版本、界面尚未熟悉，此时先跑通默认配置再谈优化。

判断“是否值得”的一个实用尺度是：如果这套规则你预计只会用几天，那就别配；如果它需要长期运行，那么花半小时把名单理清楚，收益会在后续每次使用中兑现。这也解释了为什么同一套模式在不同人手里体验差异很大——差别往往不在客户端，而在名单是否与设备实际相符。

最佳实践检查表

下面这份检查表按执行顺序排列，可以直接对照落地。它不是必须全做完才算合格，而是帮你判断哪一步被跳过了。

1. 先用全局模式跑通一次，确认线路与账号本身没有问题。
2. 列出“必须直连”的应用，优先保证本地服务可用。
3. 再列出“必须代理”的应用，比较两份名单的长度，短的那份作为主名单。
4. 配置完成后立即做一次出口地址复核，确认规则真的生效。
5. 在一周内复核一次例外清单，重点看新装应用是否需要补充。
6. 更换网络环境（Wi-Fi ↔ 蜂窝）后重测一次，确认没有出现规则错位。
7. 把最终配置记下来（模式 + 名单），便于换设备时快速复现。

把这份检查表放在手边，配置的稳定性会比凭印象调整高得多：前一步的结论构成了后一步的前提，跳过任何一环，后面都得回头补。至于版本演进的方向，经验性观察是客户端界面会持续调整分组命名与列表呈现方式（例如应用列表的扫描与手动添加方式可能变化），但“哪些应用必须走、哪些不能走”这一判断逻辑本身始终由你的使用场景决定，不会随界面改版而改变。因此更值得长期保值的，是一份写清楚理由的名单，而不是对某个菜单位置的记忆。

最后需要说明的是，客户端的具体入口名称与列表呈现方式会随版本演进调整，本文给出的是通用路径与判断逻辑，不构成对某一版本界面的逐字描述。若你的界面与上述描述存在差异，以实际安装版本的显示为准，判断标准始终是那三个问题与那张例外清单。

常见问题（FAQ）