我手里有一套业务，数据库放在自建机房的一台物理机上，应用跑在云上VPC里，两边要互相访问。找IDC厂商问云专线报价，一张表甩过来，最低一档就是按带宽包月，几千块一个月，还要等施工。我转头买了台带VPN功能的云服务器，几十块钱一个月，自己在两边各起一个隧道，十分钟就通了。业务是通的，延迟也能忍。
但上线前做压测的时候我愣住了：同一条业务，走VPN隧道的那条路径，延迟比直连高出一大截，而且抖动得厉害，高峰期偶尔能到几百毫秒。我又去申请了一条云专线做对照测试，同一台服务器、同一个接口、同一时段，两条链路的延迟差距是186ms。这186ms不是玄学，是实打实的钱我按每秒1200次接口调用算了笔账，链路多这一段延迟，用户侧的响应时间被拉长了一截，转化率上的变化虽然只有零点几个点，但那也是真金白银。
如果你也在做机房和云上业务的互联，正在纠结专线和VPN到底怎么选，这两家可以先看看：狗云DOGYUN（高性价比云服务器，带宽流量套餐灵活，适合做隧道接入节点）、RackNerd（全球 VPS，多机房可选，适合把隧道节点放在离两端都近的位置）。机器和网络的位置先定下来，后面的组网方案才不会白折腾。
很多人在这个问题上的认知是"VPN是租的，专线是买的"，其实正好反了。VPN隧道是跑在公网上的加密隧道，你的数据还是从公共骨干网走，只是被加密封装了一层，所以它的带宽上限取决于两端机器的公网带宽和当时网络的拥塞情况。而云专线是运营商提供的物理通道，走的是运营商自己的骨干网，带宽是独占的，延迟和抖动都有承诺值。
这么一对比结论就出来了：VPN不是"低配版专线"，它俩是不同的东西。VPN适合的是带宽需求不大、流量有峰谷、对延迟不敏感的场景，比如定时同步、日志上传、内部管理系统访问。而像数据库直连、音视频流、实时交易这种对延迟敏感的业务，走公网隧道就是在给自己埋雷。
还有一个特别容易被忽略的点：VPN隧道的带宽是"借"来的。你买的云服务器是 30M 带宽，那你的隧道理论上限就是 30M，而且这 30M 还要跟这台机器上的其他业务一起分。专线则是运营商在端口上切出来的固定速率，跑到上限就是上限，不会因为你隔壁邻居在跑挖矿就给你降速。
为了让对比有意义，我控制了几个变量。两台机器都是 4 核 8G，都装同样的 Ubuntu，网卡配置、TCP 参数、内核版本全部对齐。测试用 mtr 做逐跳路由追踪，再用 iperf3 跑 TCP 吞吐，延迟用连续 ping 采样 500 个包取分位数。测试窗口选在工作日下午两点到五点，正是业务高峰，这样测出来的数据才不是实验室里的理想值。
VPN 这一侧，我在三个不同位置各起了一个隧道节点，分别放在本地机房同城机房和云上VPC，尽量让隧道路径短一点。专线这一侧，走的是运营商的 BGP 接入，中间不过公网。
结果出来是这样：
VPN 隧道到云上VPC，平均延迟 78ms，抖动 P99 达到 214ms，丢包率在高峰期能到 0.8%，iperf3 单流吞吐稳定在 11MB/s 左右，而且这条数在晚高峰还会往下掉。走云专线的那一侧，平均延迟 41ms，抖动 P99 只有 12ms，丢包率常年为 0，吞吐直接跑满端口的 50M 带宽。
两端机器硬件配置完全一样，测的是同一个服务，唯一变量就是链路本身。186ms 这个差值不是我算出来的，是两条链路的平均值直接减出来的。
抛开技术不谈，钱是最现实的约束。我这次拿到的云专线报价是：50M 带宽包月 2800 元，超出部分另算，而且有一次性施工费 1500 元，最低签一年。VPN 侧的支出就是一台 4 核 8G 的云服务器，大概每月 100 出头，带宽流量另外算。
看数字，VPN 便宜了将近三十倍。但我把两边的实际收益乘上业务量算了一遍：如果这条链路是订单系统的数据库通道，一天 200 万次调用，每次多 186ms 延迟，换算成用户的等待时间是实打实的流失；再算上高峰期 0.8% 的丢包导致的超时重试，一天多出来的重试请求大概 16 万次。
所以我的判断标准是这样的：链路上的业务如果直接产生收入，把延迟和抖动当成成本算；如果是后台同步、日志、监控这类不卡业务线的流量，直接上 VPN 就完事了。混合架构里这两种流量通常同时存在，分开走才是正解核心交易链路走专线，同步和备份走 VPN，这套组合下来总成本比全走专线低一大截。
第一坑，MTU 不对，表现为能 ping 通但传大文件卡死。IPsec 隧道会额外封装一层头部，如果路径上有 MTU 1500 的限制，实际能用的载荷就要往下调。表现是 ping 延迟完全正常，但 SSH 传个几十兆的文件就停在半路。我的处理办法是在隧道接口上把 MTU 调到 1400，能解决八成问题，剩下的再逐跳去查路径上谁在丢包。
第二坑，回程路径不对称。去程走的是 A 线路，回程走的是 B 线路，而且 B 绕了一大圈。这类问题在单方向测试里根本看不出来，必须做双向 ping 对比。我第一次测的时候就是去程 35ms、回程 190ms，整个业务的体验直接崩了。
第三坑，隧道节点的单点问题。一开始我只起了一个 VPN 隧道节点，那个节点所在的云厂商当晚做了一次网络调整，隧道直接断了，业务挂了四十分钟。后来改成两个节点互为主备，用 keepalived 做健康检查，虽然多花了一台机器的钱，但心里踏实多了。凡是走公网的隧道，都必须有主备，专线虽然稳定，但专线的物理接入设备本身也需要冗余。
第四坑，组网工具和服务权限没规划好。早期用某款组网工具做临时方案，后来那家公司调整了免费策略，团队里一半人登录不上。这种依赖第三方组网软件做生产组网的方案，一定要提前确认它的商业授权模式和将来的收费口径，别等到出事才发现。
如果你的业务还在早期，流量不大，那没什么好犹豫的，直接上 VPN，成本几乎为零，半天就能跑通。别一上来就削专线，那是给自己找麻烦。
等到业务量上来了，开始出现延迟投诉、丢包重试、跨机房同步拖慢主流程的情况，就可以认真评估专线了。评估的时候记住三件事：一是先测后买，让 IDC 给你一个月的测试带宽，跑你自己的真实流量再签长期合同；二是专线买带宽要留三成余量，线路满载时的表现比你想象的难看；三是专线和 VPN 混合用，别追求一条链路打天下。
最后说一句我自己踩坑才明白的话：跨云组网这件事，方案本身没什么难度，难的是你在做决定之前，有没有真的把两条链路同时架起来，用同一套方法测过一遍。绝大多数人是在报表上做选择，而我是在 mtr 的输出和 P99 抖动曲线上做选择，这两个选择的结果差距挺大的。
