VPN如何实现流量分流？

凌晨两点，城市已经沉入寂静，但位于科技园B座18层的运维室里，灯火依旧通明。李工盯着监控大屏上那条几乎被红色填满的带宽曲线，手指不自觉地敲打着桌面。这是一家跨境电商公司的核心办公区，两百多名员工正在通过VPN远程连接海外服务器处理订单、上传商品、与客户沟通。但从一小时前开始，不断有人反馈：“VPN连上了，但打开海外后台慢得像蜗牛”“视频会议卡成PPT”“上传一个50MB的产品图要五分钟”。

李工很清楚，问题不在VPN的加密隧道本身——隧道是通的，延迟也正常。真正的元凶，是所有流量都被一股脑塞进了VPN隧道。员工访问公司内网的OA系统、访问国内的百度网盘、甚至刷一个国内的短视频，全部被强制绕道海外VPN节点，再绕回来。这就像一条原本只用来运送跨境货物的专用通道，突然被要求同时承担市内快递、外卖、甚至居民散步的功能。拥堵，是必然的。

“我们需要做流量分流。”李工对身边的实习生小陈说，“让该走VPN的走VPN，不该走的，直接走本地宽带。”小陈一脸困惑：“VPN不是一开就全走隧道吗？还能挑着走？”李工笑了笑，打开终端，敲下第一条命令——从这一刻起，一场关于VPN流量分流的实战教学，在深夜的运维室里悄然展开。

VPN流量分流：不是所有数据都该翻山越岭

要理解流量分流，先要理解VPN默认行为。绝大多数商业VPN客户端（无论是OpenVPN、WireGuard还是IPSec）在建立连接后，会修改操作系统的路由表，添加一条“默认路由”指向VPN虚拟网卡。这意味着：所有网络请求，无论目标是公司内网、国内网站还是海外服务器，都会先进入加密隧道，到达VPN网关后，再由网关决定下一步去向。

这种“全量隧道”模式简单、安全，但代价极高。对于跨境电商公司来说，员工需要同时访问：

• 海外电商平台后台（必须走VPN，因为IP被平台白名单限制）
• 公司国内自建的ERP系统（走VPN反而绕远路，延迟从10ms变成200ms）
• 国内的企业微信、钉钉、腾讯会议（走VPN会导致音视频卡顿）
• 本地打印机、NAS文件服务器（根本不需要出公网）

如果所有流量都挤进VPN隧道，结果就是：海外业务没快多少，国内业务全被拖垮，VPN网关的带宽和CPU还被无效流量吃满。李工指着监控图上的红色区域说：“你看，这60%的流量都是国内视频和文件同步，它们根本不需要VPN。”

分流的本质：让路由表学会“看人下菜碟”

流量分流的核心思想，是基于目标地址、域名、应用类型或用户组，决定数据包是走VPN虚拟网卡，还是走物理网卡直接出去。在Linux系统中，这通常通过策略路由（policy routing）和iptables/nftables标记来实现；在Windows/macOS上，则依赖VPN客户端自带的分流规则或第三方工具。

李工首先在OpenVPN服务端配置中启用了`--redirect-gateway def1`的替代方案：不再强制所有流量走隧道，而是只推送特定网段的路由。例如：

 push "route 10.8.0.0 255.255.255.0"   # 公司内网VPN网段 push "route 192.168.100.0 255.255.255.0" # 海外服务器专用网段 

这样，客户端只会将发往这两个网段的流量送入VPN，其他流量依然走本地默认网关。但问题来了：海外电商平台的域名对应的IP是动态的，不可能手动维护IP列表。于是，李工引入了基于域名的分流。

实战：三种主流的VPN流量分流方案

凌晨三点，小陈已经搬了把椅子坐在李工旁边，手里拿着笔记本疯狂记录。李工一边操作一边解释：“分流没有银弹，要看你的VPN架构和客户端类型。我今晚给你演示三种最常用的。”

方案一：路由表分流——最基础，也最粗暴

这是最原始的方法，适用于OpenVPN、WireGuard等支持自定义路由的协议。原理很简单：不推送默认路由，只推送需要走VPN的目标网段。客户端收到路由后，系统路由表会变成：

• 目标10.8.0.0/24 → VPN网卡
• 目标192.168.100.0/24 → VPN网卡
• 默认路由 → 本地物理网卡

李工在测试机上执行`route print`（Windows）或`ip route show`（Linux），果然看到默认路由仍然指向本地网关。他打开海外电商后台，发现无法访问——因为该平台的IP不在推送列表中。于是他又添加了一条基于IP的静态路由，但很快发现平台有几十个CDN节点，IP经常变。

“所以路由表分流适合目标IP固定的场景，比如公司内网、固定IP的数据库。对于动态域名的海外服务，它不够灵活。”李工总结道。

方案二：域名分流——用DNS和代理规则精准导航

为了解决动态域名问题，李工祭出了第二套方案：基于域名和SNI的分流。他在客户端上部署了一个轻量级透明代理（如Clash、sing-box或v2ray），让VPN客户端只负责建立隧道，而代理程序负责决定哪些域名走隧道、哪些直连。

具体做法是：

1. VPN连接建立后，不修改系统默认路由，而是监听一个本地端口（如127.0.0.1:7890）。
2. 配置代理规则：DOMAIN-SUFFIX,amazon.com,VPN、DOMAIN-SUFFIX,aliexpress.com,VPN、DOMAIN-SUFFIX,qq.com,DIRECT。
3. 将系统代理或透明代理指向该端口。

这样，当员工访问海外电商后台时，代理识别域名后，将流量转发到VPN虚拟网卡；访问国内网站时，直接走物理网卡。李工在测试机上打开一个海外商品页面，抓包显示：TCP握手目标IP是VPN网关，而访问国内某邮箱时，目标IP是本地电信网关。

“域名分流的关键是规则库的维护。”李工说，“你可以用社区维护的规则集，也可以自己写。但要注意，有些应用不遵循系统代理，比如某些桌面客户端，这时候就需要TUN模式或透明代理。”

方案三：应用分流与用户组分流——最精细的控制

凌晨四点，问题又来了。财务部门反馈：他们使用的国内网银U盾客户端，在开启VPN后无法识别U盾，因为该客户端强制绑定物理网卡。而海外业务部门则希望所有浏览器流量都走VPN，但企业微信必须直连。

李工叹了口气：“这就是应用分流的场景。”他介绍了两种实现方式：

• 基于进程的分流：在Linux上使用cgroup+iptables标记，在Windows上使用Windows Filtering Platform（WFP）或第三方工具（如Proxifier）。例如，只将chrome.exe和firefox.exe的流量重定向到VPN网卡，其他进程直连。
• 基于用户组的分流：在VPN服务端根据用户所属部门分配不同的路由策略。例如，海外业务组的用户推送默认路由走VPN，而国内客服组只推送内网路由。

李工在OpenVPN的配置中使用了`client-config-dir`，为不同用户加载不同的`.ovpn`配置片段。海外业务组的配置包含`redirect-gateway def1`，而国内客服组的配置只有`route 10.8.0.0 255.255.255.0`。这样，同一台VPN服务器，不同用户登录后获得完全不同的分流策略。

分流背后的技术细节：路由标记与策略路由

小陈问：“为什么不能简单地把流量分成‘国内’和‘国外’？用IP地理位置库不就行了？”李工摇摇头：“地理库有延迟和误判，而且很多海外服务用的是国内CDN节点。更可靠的方法是在操作系统层面打标记。”

在Linux中，流量分流的经典实现是：

1. 使用iptables的mangle表，根据目标端口、协议或连接状态给数据包打上fwmark标记。
2. 创建多个路由表，例如table 100用于VPN，table 200用于直连。
3. 使用`ip rule`命令，让带有特定标记的数据包查询特定的路由表。

例如：

 iptables -t mangle -A OUTPUT -d 10.8.0.0/24 -j MARK --set-mark 1 ip rule add fwmark 1 table 100 ip route add default via 10.8.0.1 dev tun0 table 100 

这样，只有目标为10.8.0.0/24的流量才会走VPN，其他流量依然走主路由表。对于域名分流，则可以在代理程序中完成DNS解析后，再动态添加iptables规则或使用TPROXY。

李工还提醒：“WireGuard的分流更简单，因为它本身支持`AllowedIPs`参数。你只需要在客户端配置中写上`AllowedIPs = 10.8.0.0/24, 192.168.100.0/24`，那么只有这些网段的流量会进入隧道。但WireGuard不支持域名，所以通常要配合DNS分流或代理工具。”

分流之后：从“网络塞车”到“各行其道”

凌晨五点，李工完成了所有配置。他让海外业务组的小王测试：打开海外电商后台，秒开；上传产品图，速度从五分钟降到二十秒。又让财务组的小张测试：网银U盾正常识别，企业微信视频会议流畅。监控大屏上，那条红色的带宽曲线终于回落，VPN网关的CPU从90%降到35%。

小陈感叹：“原来VPN不是一根管子通到底，而是一个智能交通枢纽。”李工点点头：“对。流量分流的本质，是让每一比特数据都走它该走的路。VPN只负责加密和隧道，而分流负责指路。没有分流，VPN就是一条堵死的单车道；有了分流，它才成为一张立体的交通网。”

窗外天色渐亮，李工关掉终端，喝掉最后一口冷掉的咖啡。他最后对小陈说：“记住，任何VPN部署，第一原则不是‘全走隧道’，而是‘最小必要隧道’。只让必须加密、必须隐藏IP、必须访问内网的流量走VPN，其余的，让它们走本地。这不仅是性能问题，更是安全原则——减少攻击面，也减少单点故障。”

小陈在笔记本上写下最后一句话：VPN流量分流，不是让VPN变复杂，而是让网络回归它本来的样子——各走各的路，各做各的事。