分流还是全量代理？Split tunneling 的优缺点怎么选
分流让部分 App、域名或网段直连，兼容性和性能更好；全量接管边界更简单，但增加代理依赖。选择应按风险、用途和可验证规则。
先看重点银行、局域网、国内服务或大流量更新需要直连时，分流更实用；公共 Wi‑Fi、受控工作流或无法接受意外直连时，全量接管更清晰。无论哪种，都先定义哪些流量允许直连，并用日志验证。分流不是天然泄漏，全量也不保证每个 App 都被接管。
Split tunneling（分流）指只把选定流量送进代理/VPN，其余继续使用系统网络。它可以按 App、域名、IP 网段或路由规则实现。相对的“全量接管”希望所有目标流量先进入同一隧道，再统一处理。
两者没有绝对高低，关键是你是否能清楚说明哪些流量允许直连。
分流的实际优点
- 局域网 NAS、打印机和路由器后台保持可用；
- 银行、政务或本地服务不因异地出口触发额外验证；
- 软件更新、云盘等大流量可不消耗机场套餐；
- 不需要代理的实时服务少一跳；
- 公司管理 App 与个人流量可以隔离。
Apple 把 per-app VPN 描述为让受管 App 进入安全隧道，同时排除其他 App；Android 也支持允许列表或排除列表，但不能同时使用两套名单。
分流的代价
- 规则过期时，新域名可能走错出口；
- 一个 App 会调用登录、推送、CDN 等多个域名，只列主域名容易漏；
- 域名规则最终还会受 DNS 和 IP 变化影响；
- 排障时要先判断请求走了哪条路；
- 对“绝不能直连”的场景，错误规则会带来隐私风险。
分流本身不是泄漏：如果某项流量被你明确允许直连，它按规则直连就是设计结果。只有超出预期边界，才叫绕过。
全量接管的优点和限制
全量模式的主要价值是边界简单：先让流量进入 TUN/VPN，再统一决定出口。公共 Wi‑Fi、受控测试或需要一致出口的工作流更容易验证。
代价是代理断开时更多 App 一起失联，局域网和本地服务需要显式排除，全部流量会消耗套餐并增加节点负载。Android“无 VPN 时阻止连接”能强化边界，但 VPN 失败时会按设计断网。
“全量”也不自动保证完整接管：浏览器扩展只覆盖浏览器，系统代理会被部分 App 忽略，TUN 若缺少 IPv6/路由也可能有旁路。仍需用日志验证。
按需求选择，而不是按按钮名字
| 需求 | 更适合的起点 |
|---|---|
| 日常网页，兼顾本地服务 | 规则分流 |
| 只让一两个 App 使用代理 | 分应用允许列表 |
| 大多数 App 代理，银行/局域网直连 | 排除列表或精确规则 |
| 公共网络且不能接受意外直连 | TUN/全量接管并验证 kill switch |
| 公司受管设备 | 遵循组织配置，不自行改规则 |
怎样建立可维护的分流
从少数有明确理由的例外开始。每条直连规则记录用途和验证方式；优先用域名/规则集，不要凭一次解析固定 CDN IP；涉及局域网时只排除实际子网，不把全部私网段盲目放行。
查看 Mihomo 日志中的规则命中，测试登录、推送、上传和后台刷新，而不只是打开首页。应用更新后再复核依赖域名。
定期做一次反向检查
在允许的情况下临时切换全量模式，看关键 App 是否仍正常；再恢复分流，确认直连项确实命中预期出口。规则越少、理由越明确，越容易发现漂移。为了追求一张很长的“完美规则表”而复制陌生配置，通常只会增加隐形旁路。
资料来源
以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。
持续更新
收到新教程，也欢迎纠错
想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。
读者互动
这篇内容对你有帮助吗？
最新评论
- 正在加载评论……