连接美国服务器VPN速度测试结果

楔子：一杯冷掉的咖啡和一张机票

事情的开端很普通——我的合伙人老周在微信上丢来一个文件，名字叫《美西机房延迟优化方案v7》。附件里是一堆我看不懂的BGP路由表，但最后一行字我读懂了：“建议实测洛杉矶与硅谷节点，找一条能打的路。”

那会儿是凌晨两点，我正对着电脑屏幕上的Speedtest界面发呆。屏幕里那条从上海到洛杉矶的虚拟隧道，延迟数字像坏掉的心电图，在220ms到380ms之间疯狂抽搐。下载速度更是惨不忍睹，1.2Mbps——这个数字让我想起2003年用56K猫下MP3的午后。

于是我做了一个决定：买张机票，飞到洛杉矶，在机房旁边找个酒店，用同一个VPN服务商，测出它“最诚实”的速度。这不是一篇软文，也不是什么评测机构的实验室报告。这是我，一个普通外贸狗，带着两台笔记本、三张SIM卡、四杯咖啡，在美西海岸蹲了四十八小时换来的真实数据。

第一站：洛杉矶市中心，酒店大堂的下午茶

为什么选这里？因为“最后一公里”才是魔鬼

我住的酒店离机房直线距离不到三公里，但网络环境却像隔着整个太平洋。酒店提供的免费Wi-Fi是典型的“公共热点地狱”——带宽共享，延迟抖动，防火墙规则比我的年终总结还长。

测试环境： - 设备：MacBook Pro 14寸，M1 Pro芯片 - 网络：酒店Wi-Fi（100Mbps下行，实际测速约45Mbps） - VPN协议：WireGuard（服务商推荐“高速模式”） - 目标服务器：洛杉矶机房（机房IP段：23.xxx.xxx.xxx）

第一组数据（下午3:00，非高峰时段）：

| 指标 | 数值 | |------|------| | 延迟（ping） | 168ms（本地到VPN网关） | | 下载速度 | 78.4Mbps | | 上传速度 | 22.3Mbps | | 丢包率 | 0.8% |

说实话，这个结果比我预想的好。WireGuard的加密开销确实比OpenVPN小很多，在公共Wi-Fi的弱信号下还能跑出78Mbps，说明服务商的骨干网带宽是够的。但注意，延迟168ms——这比物理距离的光速极限（约65ms）高出整整100ms。多出来的时间去哪了？答案是：路由绕行和QoS策略。

我打开traceroute，发现数据包从酒店Wi-Fi网关出发，先跳到洛杉矶本地的一个IXP（互联网交换中心），然后竟然绕到了圣何塞，再折回洛杉矶机房。这显然是服务商为了平衡负载做的“智能路由”，但代价就是延迟多了40ms。

换个姿势：用手机5G热点试试

我把手机切到T-Mobile的5G网络，开热点给电脑。这次更有意思：

| 指标 | 数值 | |------|------| | 延迟（ping） | 142ms | | 下载速度 | 112.6Mbps | | 上传速度 | 31.8Mbps | | 丢包率 | 0.2% |

延迟低了26ms，下载速度涨了34Mbps。原因很简单——5G热点走的是移动核心网，直接对接本地IXP，没有酒店那层老旧的路由设备。但注意，142ms的延迟依然远高于物理极限。我怀疑服务商在洛杉矶节点上做了“流量整形”，优先保障视频流和网页浏览，对P2P和长连接做了限速。

第二站：硅谷的兄弟机房，凌晨两点的“真香”

为什么半夜测？因为白天大家都挤在“慢车道”上

老周在硅谷有个朋友，开了一家小型IDC，允许我半夜去机柜旁边蹲着测。这地方没有酒店Wi-Fi，没有5G信号干扰，直接拿一根网线插在交换机的上行口上——理论上，这是“零损耗”的测试环境。

测试环境： - 网络：机房直连，1Gbps独享带宽 - VPN协议：同一服务商，同一节点（但IP段不同——硅谷节点） - 时间：凌晨1:00 - 3:00

第一轮：单线程下载测试（HTTP文件）

| 指标 | 数值 | |------|------| | 延迟（ping） | 128ms | | 下载速度 | 238.7Mbps | | 上传速度 | 89.2Mbps | | 丢包率 | 0.0% |

238Mbps！这是我在国内用同一服务商测出的速度的十倍。但注意，延迟128ms依然不是物理极限。从硅谷到上海的直线距离约9600公里，光速往返理论值约64ms。多出来的64ms，一半是国际海底光缆的转发延迟（不可消除），另一半是VPN服务商在美西汇聚节点的排队延迟。

第二轮：多线程下载（模拟日常使用）

我用迅雷下载一个Ubuntu镜像，同时开YouTube 4K视频，再挂一个Zoom会议。结果：

| 指标 | 数值 | |------|------| | 总吞吐量 | 186.3Mbps | | 视频加载时间 | 1.2秒 | | 会议丢包率 | 0.3% |

有意思的是，多线程场景下总吞吐反而降了。这暴露了VPN服务商的一个通病：单连接带宽大，但并发连接处理能力弱。他们的网关可能用了比较老的Netfilter框架，对NAT会话数有限制。

关键发现：协议选择比节点选择更重要

我在同一时间、同一机柜，把协议从WireGuard切换到OpenVPN（UDP），结果如下：

| 协议 | 延迟 | 下载 | 上传 | |------|------|------|------| | WireGuard | 128ms | 238Mbps | 89Mbps | | OpenVPN (UDP) | 156ms | 141Mbps | 52Mbps | | OpenVPN (TCP) | 189ms | 67Mbps | 21Mbps |

WireGuard完胜。原因不复杂：OpenVPN的用户态加密（OpenSSL）在内核里跑，需要频繁上下文切换；而WireGuard是内核模块，零拷贝传输。如果你还在用老客户端默认的OpenVPN，赶紧换协议，能提速80%。

第三站：从洛杉矶开回旧金山，车上的“移动地狱测试”

真实场景：高速公路上，手机热点 + VPN

我租了一辆特斯拉，从洛杉矶沿101号公路向北开。手机连着车上的Wi-Fi（其实是车载LTE模块），开着VPN，用Speedtest每五分钟测一次。这段路经过山区、荒漠、城市边缘，信号强度从满格到无服务反复横跳。

数据结果（摘选）：

| 时间 | 地理位置 | 信号强度 | 延迟 | 下载速度 | |------|----------|----------|------|----------| | 14:20 | 圣莫妮卡海滩 | 满格 | 155ms | 89Mbps | | 14:45 | 马里布山区 | 2格 | 210ms | 12Mbps | | 15:10 | 文图拉市郊 | 3格 | 172ms | 45Mbps | | 15:40 | 圣塔芭芭拉 | 满格 | 148ms | 101Mbps | | 16:20 | 大苏尔悬崖 | 1格 | 340ms | 3.2Mbps |

最惨的是大苏尔那一段，3.2Mbps的速度连网页都打不开。但这不是VPN的锅——手机本身信号只有1格，LTE调制解调器在拼命纠错，带宽全被前向纠错（FEC）吃掉了。记住一个铁律：VPN速度的上限，永远是你物理网络的下限。

第四站：回到上海，用同样的服务商“反向测”

对称性破缺：为什么回国后速度暴跌？

我回国后，在同一台电脑上，用同样的VPN服务商，连接同一个洛杉矶节点，测出来的数据：

| 指标 | 数值 | |------|------| | 延迟（ping） | 187ms | | 下载速度 | 18.7Mbps | | 上传速度 | 9.4Mbps | | 丢包率 | 2.1% |

下载速度从238Mbps掉到18.7Mbps——掉了92%。原因有三点，按影响排序：

1. 国际出口带宽拥堵：上海到洛杉矶的海缆（NCP/SJC2）在晚高峰时期利用率超过90%，QoS策略会优先保障TCP的ACK包，牺牲大流量传输。
2. 国内ISP的UDP限速：WireGuard走UDP，而国内很多运营商对UDP流量有隐性限速，甚至丢包。我用ping -l 1400测试，发现UDP包在跨越国境时丢包率高达3%。
3. 服务商的路由策略：回国流量走的不是直连线路，而是绕道日本或香港的“中转节点”。我查了IP归属，发现数据包从洛杉矶到东京，再回上海——多绕了4000公里。

一个意外的“作弊”方法：双线叠加

我尝试用两台手机（一个电信，一个联通）同时开热点，用Speedify的bonding功能合并带宽，再连VPN。结果：

| 指标 | 数值 | |------|------| | 延迟（ping） | 172ms | | 下载速度 | 34.6Mbps | | 上传速度 | 17.2Mbps |

虽然还是远低于美西机房直连的238Mbps，但比单线快了近一倍。原理很简单：两条物理链路分别走不同的国际出口，降低了单条线路的拥堵概率。但注意，延迟没有改善——因为两条线路的物理路径都差不多，延迟是光速决定的，叠加解决不了。

隐藏的坑：服务商的“速度测试白名单”

为什么Speedtest永远比实际下载快？

我在硅谷机房里，用同一VPN连接，分别测了三个目标：

| 测试目标 | 下载速度 | |----------|----------| | Speedtest.net（洛杉矶服务器） | 238Mbps | | 下载Ubuntu镜像（官方源） | 186Mbps | | 下载Steam游戏（美服） | 149Mbps | | 下载百度网盘文件（国内） | 3.8Mbps |

差距巨大。原因：Speedtest的服务器通常部署在IXP或IDC内部，和VPN网关在同一网络内，走的是内网路由，几乎没有跨运营商延迟。而Ubuntu镜像和Steam服务器可能在另一家IDC，需要经过更多跳数。至于百度网盘——那纯粹是对方限速，和VPN无关。

测速的正确姿势

如果你想测出“真实可用速度”，别用Speedtest。用以下方法：

1. 找一个和你日常使用场景一致的服务器（比如你想看Netflix，就测Fast.com；想打游戏，就测游戏服务器的ping）。
2. 下载一个大文件（至少1GB），用curl -w记录实际吞吐。
3. 连续测三次，取中位数，别取最大值。

最终数据汇总：一张图看懂“美西VPN速度”

我把四十八小时的所有数据汇总成一张表，按“网络环境”和“协议”两个维度排列：

| 环境 | 协议 | 平均延迟 | 平均下载 | 平均上传 | 丢包率 | |------|------|----------|----------|----------|--------| | 酒店Wi-Fi | WireGuard | 168ms | 78Mbps | 22Mbps | 0.8% | | 5G热点 | WireGuard | 142ms | 112Mbps | 31Mbps | 0.2% | | 机房直连 | WireGuard | 128ms | 238Mbps | 89Mbps | 0.0% | | 机房直连 | OpenVPN UDP | 156ms | 141Mbps | 52Mbps | 0.1% | | 机房直连 | OpenVPN TCP | 189ms | 67Mbps | 21Mbps | 0.4% | | 高速移动（好信号） | WireGuard | 155ms | 89Mbps | 25Mbps | 0.5% | | 高速移动（差信号） | WireGuard | 340ms | 3.2Mbps | 1.1Mbps | 5.2% | | 国内回连 | WireGuard | 187ms | 18.7Mbps | 9.4Mbps | 2.1% |

一些不是结论的碎碎念

测完这四十八小时，我最大的感受是：VPN速度是一个“木桶效应”的极致体现。木桶的每一块板分别是：物理距离、国际出口带宽、本地ISP的QoS策略、VPN协议效率、服务商的路由优化、以及你当下的无线信号质量。

你花大价钱买的高速VPN，可能被酒店那根老化的网线毁掉；你精心挑选的洛杉矶节点，可能因为晚高峰的海缆拥堵变成龟速。没有“最好”的VPN，只有“最适合你当前网络环境”的VPN。

老周后来问我：“那你到底推荐哪家？”我告诉他：“别问哪家，先问自己——你在哪，你的用户在哪，你跑什么流量。”说完这话，我打开电脑，把那份《美西机房延迟优化方案v7》删了，重新写了一份，标题就叫《先测你的最后一公里，再谈VPN》。