🧩 什么是拆分隧道?
拆分隧道(Split Tunnel) 是一种网络配置策略,它允许你选择哪些应用或目的地的流量通过虚拟专用网络(VPN)或代理,哪些流量直接走本地网络。在传统 VPN 中,开启后所有流量都会经过 VPN 服务器,这可能导致访问国内网站速度变慢、内网资源不可达、游戏延迟增加等问题。拆分隧道正是为了解决这些痛点而生的。
在 Clash 语境中,拆分隧道通常指的是在 TUN 模式 下,指定部分应用程序或目标 IP 段“绕过”虚拟网卡,直接使用物理网卡通信,而其他流量则照常被代理。这和基于域名的规则分流有本质区别:规则分流是代理内部的决策(走哪个节点还是直连),而拆分隧道是更底层的“是否进入代理系统”的开关。
❓ 为什么需要拆分隧道?
很多人以为 TUN 模式全局代理就是完美的,但实际上全局代理会带来一系列问题:
- 内网服务不可达: 公司 VPN、打印机、NAS、路由器管理页面等局域网资源,在全局代理下可能因为路由被劫持而无法访问。
- 部分应用不适配: 某些银行客户端、UWP 应用或 DRM 保护内容对代理敏感,强制代理可能导致功能异常或拒绝服务。
- 游戏延迟与封包: 很多网络游戏使用 UDP 协议并检测代理 IP,如果所有游戏流量都走海外节点,不仅延迟高,还可能被反作弊系统封禁。
- 性能损耗: 大流量下载(如系统更新、Steam 游戏下载)经过代理会增加服务器负担和本地 CPU 消耗,拆分隧道可以让这些流量直连满速下载。
拆分隧道正是为了解决“既要全局代理的安全和便利,又要局部直连的性能和兼容性”这一矛盾而设计的。它让你可以精细地控制哪些流量走代理、哪些不走,实现灵活的网络策略。
⚙️ 底层原理:路由表、进程匹配与策略路由
理解拆分隧道,需要先理解 TUN 模式是如何“接管”流量的。当 Clash 启用 TUN 模式后,系统会新增一条虚拟网卡,并修改路由表,让默认路由指向这个虚拟网卡。所有没有更具体路由的流量,都会被送到 Clash 内核处理。
拆分隧道的核心思想是在流量被劫持之前,把它拉回物理网卡。这通常通过以下三种机制实现:
1. 路由表排除(IP 级绕过)
最传统的方式,直接在系统路由表中添加更具体的路由条目,指向物理网卡的网关。例如,如果公司内网是 10.0.0.0/8,我们添加一条路由:
route add 10.0.0.0 mask 255.0.0.0 192.168.1.1 metric 5
这样所有发往 10.x.x.x 的流量都会直接走物理网卡,不会进入虚拟网卡。Windows 上,Clash Verge Rev 等客户端通常会自动处理这类路由。
2. 进程名匹配(应用级绕过)
更精细的控制是让某个特定程序(如 game.exe)的所有流量直连。Clash 本身不直接支持进程匹配,但可以通过外部工具(如 Proxifier 或系统防火墙规则)将特定进程的流量导向物理网卡。一些新锐客户端(如 Clash Verge Rev)也正在探索通过 WFP(Windows Filtering Platform)实现进程级别的绕过。
3. 策略路由(Policy Routing)
Linux 上更强大的方式,通过 ip rule 和自定义路由表,根据源 IP、fwmark 等条件决定流量的走向。例如,给需要绕过的流量打上特定标记,然后将其路由到本地物理网卡而非 TUN 接口。
对于大多数用户,IP 级绕过已经足够应对 90% 的场景。如果你需要更详细的 TUN 原理,请参阅 《TUN 模式原理与优化指南》 以及 《Windows TUN 驱动深度解析》。
🖥️ Clash 中的拆分隧道实现
虽然 Clash 核心配置文件中没有直接名为 split-tunnel 的字段,但我们可以通过现有的机制组合出拆分隧道的效果:
tun.bypass或类似字段: 部分 Clash 内核(如 Clash.Meta)支持在 TUN 配置中直接指定 IP 段或域名排除。例如:tun: enable: true bypass: - "10.0.0.0/8" - "192.168.0.0/16" - "*.company.local"- 规则中的
DIRECT: 通过在规则中使用DIRECT,可以指定某些流量不经过代理节点,但仍然会经过 TUN 虚拟网卡和 Clash 内核处理。这不完全等同于拆分隧道(因为流量还是进入了 Clash),但效果类似。 - 系统防火墙规则: 在 Windows 防火墙中创建出站规则,针对特定程序的流量阻止其发往 TUN 网卡,强制走物理接口。
其中,bypass 机制是最接近纯拆分隧道的方式,它会在内核层面直接放行匹配的流量,不进行任何代理处理,效率最高。如果你的客户端不支持该字段,请参考下载中心获取最新版本或查阅内核文档。
📝 完整配置示例:从简单绕过到精细控制
基础版:绕过局域网和国内 IP
tun:
enable: true
stack: system
auto-route: true
bypass:
- "10.0.0.0/8"
- "172.16.0.0/12"
- "192.168.0.0/16"
- "127.0.0.0/8"
rules:
- GEOIP,CN,DIRECT
- MATCH,PROXY这样,所有局域网地址和国内 IP 的流量会直接绕过 TUN,不进入 Clash 处理流程,而其他流量正常走代理。这比在规则里用 GEOIP,CN,DIRECT 更底层,性能更好。
进阶版:基于域名的绕过
如果你希望某些域名不走代理(例如内网域名),可以在 bypass 中指定:
tun:
bypass:
- "*.internal.company.com"
- "*.lan"注意,基于域名的绕过需要 Clash 内核支持 DNS 劫持和域名匹配,否则可能不生效。更稳妥的方式是使用 自定义规则 配合 DOMAIN-SUFFIX 实现类似效果。
🎯 实战场景:游戏、内网与多网卡
场景一:网游加速
某款游戏使用 UDP 协议,且对代理 IP 敏感。你希望该游戏的流量直接走本地网络,而其他流量(如网页浏览)走代理。可以这样配置:
- 获取游戏服务器的 IP 段(可通过抓包或查询)。
- 将这些 IP 段加入
bypass列表。 - 如果游戏有反作弊系统,还需确保绕过 TUN 后的流量不受其他网络层过滤影响。
对于无法获取 IP 的情况,Windows 用户可以借助 ForceBindIP 等工具将游戏进程绑定到物理网卡 IP 上,实现进程级直连。更优雅的方案是参考 《TCP 与 UDP 深度对比》 中的游戏优化部分。
场景二:公司 VPN 叠加
你同时运行了 Clash TUN 和公司 VPN。公司 VPN 使用了 10.8.0.0/16 网段。如果不加配置,两个虚拟网卡会打架。解决方法是:
- 在 Clash 的
bypass中添加公司 VPN 的网段。 - 确保路由优先级正确,让公司流量优先走 VPN 接口。可能需要手动调整接口跃点数。
- 如果公司 VPN 也强制修改路由表,考虑关闭 Clash 的 auto-route,手动维护路由。
场景三:多网卡(有线+无线)
某些高级用户同时连接有线和无线网络,希望某些应用走有线(低延迟),某些走无线(大带宽)。这超出了 Clash 的范畴,但通过结合拆分隧道和操作系统策略路由可以实现。Clash 的角色是保证代理流量不受影响,同时允许指定流量绕过代理直连有线或无线网卡。
⚖️ 性能与安全权衡
拆分隧道不是银弹。它带来了便利,也引入了需要考虑的权衡:
| 方面 | 全局代理 | 拆分隧道 |
|---|---|---|
| 网络覆盖 | 所有流量加密,安全性高 | 部分流量直连,可能泄漏信息 |
| 性能 | 所有流量经过代理,有额外开销 | 直连流量满速,降低 CPU 负担 |
| 配置复杂度 | 简单,一键开启 | 需要准确识别哪些流量需要绕过 |
| 内网兼容性 | 可能无法访问局域网 | 轻松访问内网资源 |
| DNS 泄漏风险 | 较低(若配置正确) | 绕过流量可能使用本地 DNS,需注意 |
如果你对隐私要求极高,建议谨慎使用拆分隧道,或者确保绕过的流量不涉及敏感数据。对于 DNS 泄漏,可参考 TUN 模式 DNS 泄漏章节 进行加固。
🛠️ 故障排查:当流量走错了路
bypass 字段,确认语法正确(缩进、CIDR 格式)。在日志中搜索 bypass 关键字查看是否有加载错误。
route print(Windows)或 ip route(Linux)查看路由条目,确保 bypass 网段有对应的直连路由且 Metric 更低。
🏆 最佳实践与演进方向
- 优先使用 bypass 而非 DIREC T 规则: 对于明确的局域网和国内 IP 段,直接绕过 TUN 比让 Clash 处理更高效。
- 定期审计绕过列表: 随着网络环境变化,IP 段和域名可能更新。可以结合 《构建可维护的规则集》 的思路进行自动化管理。
- 进程级绕过的未来: Clash Verge Rev 等新兴客户端正在探索 WFP 级别的进程匹配,届时无需手动配置 IP 即可实现按应用绕过。保持关注 更新日志。
- 多网卡场景: 如果你的机器有多个物理网络接口,可以利用操作系统策略路由进一步优化流量走向,但需与 Clash 的 auto-route 配合,避免冲突。
- 安全第一: 绕过代理的流量不会经过加密,请确保这些流量不涉及隐私或敏感数据。
拆分隧道是高级网络管理的重要工具,掌握它,你将能从容应对各种复杂的网络需求。如果你希望深入理解 Clash 内部的流量路径,推荐阅读 《透视 Clash for Windows 内部》 和 《大型配置文件管理指南》,从架构和工程层面进一步优化你的代理方案。