分流（Split Tunneling）指：在已建立 VPN 或 TUN 全局代理 的前提下，只把选定流量送进隧道，其余仍走本地网络。2026 年桌面与手机客户端里，「全局 / 规则 / 直连」几乎都是分流策略的不同预设。选对策略的关键不是开关名字，而是让「谁解析、谁出站」与你的意图一致。

分流到底在分什么

一个可独立引用的定义句：分流是按规则拆分出站路径，不是关掉加密。

隧道建立后，系统仍可同时存在两条（或多条）出站路径：

  1. 隧道路径：包进入虚拟网卡或系统 VPN 接口，由客户端封装后发往节点；
  2. 直连路径：包按物理网卡默认路由离开，不经过节点。

分流规则决定某一连接落在哪条路径。规则维度常见有域名、目标 IP、进程/应用、端口与协议。没有规则时，客户端往往退回「全部进隧道」或「全部直连」两种极端预设。

策略名（常见叫法）实际含义典型代价
全局 / Global默认几乎所有 IP 进隧道延迟与耗电通常更高
规则 / Rule按域名、IP、进程匹配配置与维护成本
直连 / Direct默认几乎不进隧道只有显式规则才走节点
按应用 VPN系统只把指定 App 导入接口覆盖面依赖系统 API

这与 VPN 是什么 中的基本模型一致：加密与出口选择是两件事；分流只回答「哪些包要进你选的出口」。

为什么需要分流，而不是永远全局

全局简单，但不是所有流量都适合绕远。常见合理动机包括：

  • 内网与打印：公司、学校、打印机、NAS 走节点后可能无法到达；
  • 延迟敏感：部分游戏、会议对往返时延敏感，本地直连更稳；
  • 流量与套餐：大文件更新、系统商店不必消耗节点流量；
  • 合规与银行类 App：部分应用对虚拟网卡或非常见出口敏感；
  • 排障：临时让某一域名直连，用来区分「节点问题」和「本机问题」。

动机不成立时，盲目分流会扩大旁路面：本地运营商仍能看到直连域名的解析与连接元数据。是否可接受，取决于你关心的是延迟、费用，还是统一出口。

三种常见分流粒度

1. 按域名 / 规则集

客户端在连接前或连接中查询规则：匹配则代理，否则直连（或相反）。规则集可来自本地列表或远程订阅。优点是粒度细；风险是解析出口与连接出口不一致——域名在规则里写「代理」，DNS 却在本地完成，或 Fake-IP/虚拟 DNS 与真实连接策略脱节。

2. 按目标 IP / CIDR

对已知网段（如 RFC1918 私网、特定 CDN 段）写路由例外。优点是不依赖域名；缺点是 CDN 与任播地址会变，硬编码 IP 容易过期。

3. 按应用 / 进程

桌面端按进程路径或包名，移动端按「分应用 VPN」把指定 App 导入隧道。优点是符合「这个软件走节点」的直觉；缺点是子进程、更新器、WebView 容器可能不在名单里，造成半进半出。

粒度更适合更易踩的坑
域名浏览器与普通 HTTPSDNS/DoH 与规则不一致
IP/CIDR内网、固定服务地址变更、IPv6 遗漏
应用/进程指定客户端软件子进程与系统组件旁路

分流时 DNS 为什么必须一起看

DNS 泄漏检查 说明过：解析路径可以与数据路径分开。分流把这个问题放大——同一台机器上，有的名字在隧道内解析，有的在运营商 DNS 解析。

对照时至少确认三点：

  1. 进隧道的连接：其域名是否也由隧道 DNS（或与出口一致的解析器）回答；
  2. 直连的连接：是否故意使用本地 DNS，且你接受本地可见这些查询；
  3. 浏览器 DoH/DoT：是否绕过了客户端的分流 DNS，导致「规则写了代理、解析却在别处」。

测试环境写法示例：2026 年 9 月，家庭宽带，Windows 11 + 规则模式客户端。先打开需要代理的站点与需要直连的内网地址各一，再分别记下出口 IP 与解析器地址。

没有「期望表」时，不要根据单一检测页分数判断分流是否正确。

怎么验证分流是否按预期工作

目标不是追求「全部绿灯」，而是核对意图与路径：

  1. 列出两类目标：应走隧道的站点/App，应直连的内网或本地服务；
  2. 分别访问，记录出口 IP（可用客户端状态页或对外查询页）与 DNS 解析器；
  3. 对照规则：域名/进程是否真的命中，IPv4 与 IPv6 是否都符合；
  4. 改动一项后复测（只改 DNS、或只改某一规则），避免一次改太多无法归因；
  5. 把日期、设备、客户端模式写进笔记，便于版本更新后回归。
现象更可能的原因下一步
该代理的站点出口仍是家庭 IP规则未命中或模式为直连优先查规则顺序与最终动作
该直连的内网不通默认路由仍指向 TUN为私网补直连路由/规则
出口对了但证书/CDN 异常解析地区与出口地区不一致对齐隧道 DNS 与连接
仅手机某一 App 异常分应用列表未包含该包名检查系统 VPN 应用列表
浏览器与命令行结果不同DoH 或工具自带解析统一解析路径后复测

据客户端文档，部分产品提供「连接测试 / 规则命中日志」。有日志时优先读命中行，比反复开关全局更有效。

和全局模式怎么选

没有普遍最优解，可按场景收敛：

  • 需要统一出口、减少遗漏：偏全局，再为内网和节点 IP 写少量直连例外；
  • 只服务浏览器或少数 App：偏规则或分应用，并单独处理 DNS；
  • 正在排障：临时全局排除变量，确认隧道本身可用后，再加回分流；
  • 设备发热或套餐紧张：扩大直连范围前，先确认直连对象不含你在意的敏感解析。

现代 VPN 技术架构里，分流属于控制平面策略；它不改变节点是否可信，只改变哪些包有机会到达该节点。

常见误解

误解 1：分流 = 更匿名。
直连部分对本地网络可见。匿名与否仍取决于出口信任、账号体系与指纹，不取决于规则条数。

误解 2：写了域名规则就不会泄漏。
进程绕过、IPv6、WebRTC、系统组件更新通道仍可能离开隧道。规则覆盖的是匹配到的连接，不是整台设备的所有套接字。

误解 3：全局一定更慢。
节点质量、协议与 MTU 往往比「是否分流」影响更大。全局变慢时，先区分是路径质量问题还是本机封装问题。

误解 4：手机系统「分应用 VPN」等于桌面规则集。
移动端列表通常以 App 为单位；桌面规则常精确到域名和 CIDR。两边都不能直接照搬配置文件。

建议怎么落地

先写一张三列期望表：目标、应走路径（隧道/直连）、依据（域名/IP/App）。再在客户端里用同一种粒度实现，并固定检查 DNS 与双栈。规则稳定后，把「新增 App / 换客户端 / 系统大版本更新」当成回归触发点重测一遍。分流的目标是让意图可验证，而不是堆叠无法解释的例外列表。