分离隧道（Split Tunneling）是什么？为什么不是所有流量都要走 VPN

分离隧道到底是什么？先纠正一个常见误会

很多人开 VPN 时有个误会：以为连上之后所有流量都必须走 VPN 隧道才算生效。实际上，分离隧道（Split Tunneling）正是 VPN 客户端里专门解决这个问题的功能——它允许你指定哪些应用、哪些网段的流量走 VPN 隧道，其余流量继续走本地网络直连。理解这个概念，能解释很多人连了 VPN 却发现某些功能变慢、甚至连不上的困惑。对开发者来说分离隧道尤其关键：终端里跑的 CLI 工具、IDE 插件、本地内网服务对网络路径的要求完全不一样，一刀切地把所有流量都塞进同一条隧道，几乎必然会牺牲掉其中一部分的体验。

为什么全部流量都走 VPN 反而会出问题

本地局域网设备突然访问不到了

没有分离隧道时，VPN 客户端默认接管系统的全部出站流量，包括访问同一局域网内的打印机、NAS、路由器管理后台这类本地设备的请求。这些请求本该走本地网关，却被一并塞进了 VPN 隧道发往境外出口，再原路绕回来——轻则明显变慢，重则因为目标设备根本不在公网可达范围而直接超时失败。典型场景是开发者在家用台式机通过 SSH 连接同一局域网内的另一台测试机，VPN 全局模式一开，这条本该走内网直连、延迟几乎为零的连接反而要绕一大圈境外线路才能回来，体验明显变差。

无关流量挤占隧道带宽

视频网站缓存、系统自动更新、云盘同步这些后台流量，本身并不需要通过 VPN 出口访问，一旦全部挤进同一条隧道，真正需要加速的流量反而要跟它们抢带宽。开发者最容易感知的场景就是：明明只是想让 Claude Code、Cursor 这类工具稳定连接，结果因为后台一个大文件同步占满了隧道，agent 任务的请求跟着一起变慢。

部分流量绕远路，速度不降反升

如果你访问的服务本身在本地网络访问效果就很好（比如有 CDN 加速的站点），把它也塞进跨境隧道纯属绕远路，多一段跨境链路只会增加延迟，没有任何加速收益。判断一条流量该不该走隧道，本质上只需要问一句：这个目标服务在本地直连和绕道境外出口两种路径下，哪一种延迟更低——分离隧道存在的意义，就是把这个判断交给规则自动执行，而不是每次都靠感觉去猜。

分离隧道的两种实现方式

按应用分流（App-based）

客户端维护一份应用列表，用户勾选哪些程序的流量需要走隧道，其余程序的流量自动直连。这种方式对普通用户最直观，界面上点几下就能设置好，缺点是命令行工具、后台服务这类没有独立图形界面的程序不一定能被准确识别和归类，配置起来反而没那么省心。

按 IP／域名规则分流（Rule-based）

更适合开发者的方式——按目标 IP 段或域名规则配置，比如把 Anthropic、GitHub、npm 官方源相关域名标记为必须走隧道，把内网地址段和常用本地服务标记为直连，规则一旦配好就对所有程序自动生效，不用逐个勾选应用，新装的开发工具只要走的是同一批域名，也会自动被规则覆盖，不需要每次都手动重新配置。两种方式并不互斥，很多客户端会同时提供应用级和规则级配置，按应用分流负责覆盖日常最常用的几个程序，规则分流负责兜底所有走特定域名的流量。

全局模式 vs 分离隧道模式对照表

开发者常见的三个分流场景

1. 只让 Claude Code、Cursor、终端 CLI 工具的流量走 VPN 隧道，浏览器和本地服务走直连，兼顾稳定性和速度。
2. 接入公司内网 VPN（Site-to-Site）做远程办公的同时，仍保留公网直连能力，避免两套网络策略互相冲突。
3. 下载大文件、拉取系统镜像或者跑本地不需要加速的下载任务时，临时把这部分流量排除在隧道之外，不占用给开发工具用的带宽，下载速度也能跑满本地宽带上限。

分流规则配置好，才是真正把 VPN 用明白

分离隧道不是可有可无的高级选项，而是决定日常体验好坏的关键设置。NasaCode 客户端内置分流规则功能，可以直接把 Claude Code、Cursor 这类开发工具的流量精准划进加速隧道，其余流量保持直连，配置一次之后就不用再逐个应用手动调整。对经常同时处理内网服务和跨境开发工具的团队来说，这一步配置花的时间，换来的是长期稳定的日常体验，而不是每次卡顿都要重新排查到底是哪一类流量出了问题。