为什么路由器的 Wi-Fi 标称值不能预测 VPN 吞吐
标称的 Wi-Fi 速率与实测的 VPN 速率描述的是不同层次。买更快的路由器之前，请按这个顺序逐项检查。
一台贴着 3,000 Mbps Wi-Fi 标签的路由器，实际转发加密流量的速度仍可能只有这个数字的一小部分，而且这两个数字都不算骗人。无线标称描述的是芯片组所支持链路在最理想调制下的上限；VPN 数字描述的是一台设备能把加密数据包推过路由器 CPU 并送出接入线路的实际速度。这是不同的层次、不同的包长和不同的测量方法。请把盒子上的数字当作没人能达到的天花板，而不是你的隧道速度预报。
步骤 1：画出限制这个数字的四层
我处理过的慢路由器投诉，几乎都落在这四层之一：无线链路、WAN 接入速率、转发路径（NAT、防火墙、连接跟踪），或 VPN 加密路径。它们层层叠加，最慢的那层决定结果。标称的 Wi-Fi 速率只谈第一层，而且谈得很慷慨。
这个数字来自流数乘以信道宽度，再乘以芯片组能协商到的最高调制。5 GHz、80 MHz、1024-QAM 的 2x2 无线常被标称为接近 1,200 Mbps，但 Wi-Fi 是共享的半双工介质：客户端轮流发送，重传和管理帧烧掉空口时间，TCP 又加上自己的开销。即使在理想条件下协商到最高速率的客户端，通常实测也远低于一半；附近网络一多，还会更低。
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
如果表格指向无线，先修无线侧：频段、信道宽度、距离。如果指向无线以下，接下来四步才有意义，买多少根天线都不会改变。
步骤 2：先取有线基线，再动无线
先把笔记本接上网线，测一遍不走隧道的路径，因为这才给你分母。在另一端，也就是终结 VPN 的 VPS 或家用服务器上运行测速工具，把客户端指向它的公网地址，让流量穿过你的路由器和接入线路。
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
这一段里的两个数字回答的是不同问题。单流反映单连接的 ceiling，包含 TCP 窗口行为和沿途任何按流限速。四流则反映链路是否有你没用上的容量，因为并行流能填满单流填不满的管道。
保持诚实：同一台主机、同一时段和同样时长，家里没有别的东西在串流。三十秒的大流量传输是合适的单位，TCP 吞吐测试的框架 RFC 6349 正是建立在这个思路上，因为短促的突发和小请求会让链路显得比实际更好。在改动任何东西之前，先把基线写下来。
步骤 3：用同样的测试穿过隧道
现在对终结端的隧道地址重复一遍：同一客户端、同样时长和流数，隧道保持连接，没有其他流量。两个结果的比值说明这台上加密与封装要付出多少代价；绝对数字说明它够不够用。
传输过程中盯住计数器。WireGuard 上 wg show 会报告每个对端的传输字节；OpenVPN 则用定时写出的状态文件给出同样的视图。
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
如果隧道数字接近有线基线，VPN 就不是瓶颈，你可以停止怪它。如果只有基线的一小部分，损失发生在路由器的加密与转发路径里，下一步会告诉你是哪一段。
一个提醒：出口 IP 一变，某些测速服务会悄悄换一个测量服务器，结果你比较的是两个不同目的地。服务器地址要自己钉死。
步骤 4：把 CPU 当路径读，而不是当平均值读
总 CPU 只有 30% 的路由器仍可能已经饱和：一条隧道的工作往往落在单个核心、单个中断队列或单个内核线程上，平均值把天花板藏起来了。要看每核数字和 softirq，而不是面板上的仪表。
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo这段输出里有三件事值得看。一个核心贴近 100% 而其他核心闲置，说明存在单连接限制。某个 CPU 上 %soft 很高或 ksoftirqd 很忙，说明接收侧包处理没有分摊到多个队列。缺少 aes 标志则说明 CPU 没有 AES 指令，对称加密只能跑在软件里，每包成本高得多。
实现方式同样重要。传统的用户态 OpenVPN 实例基本在一处处理单条隧道的数据包，所以一台很快的多核机器，对这条隧道可能表现得像单核。内核里的 WireGuard 会把工作摊到多个 CPU，OpenVPN 的数据通道卸载也会把包处理移进内核，但只在支持它的构建和平台上。营销页面上的硬件加速宣传，并不能证明你实际跑的代码路径用到了它。
步骤 5：按这个顺序决定改什么
把这份清单往下走，停在第一条成立的地方，因为改它下面的任何一项都不会让数字动起来。
1. 有线直连吞吐低于你付费的水准：去找运营商，隧道变不出接入线路给不了的容量。2. 有线直连没问题，但隧道测试时有单核打满：路由器的加密路径就是上限。3. CPU 闲着隧道却慢：查 MTU 和分片，再查远端终结端自己的容量。4. 只有 Wi-Fi 客户端慢：换频段或信道宽度，并接受标称速率从来不是 VPN 数字。
当路由器确实是上限时，诚实的选项是换一台带 AES 指令、转发路径更快的设备，用 WireGuard 这类内核侧隧道替代用户态隧道，或者把客户端搬到设备本身上，让路由器不再加密。为了跑分而关掉认证加密不在此列；那是拿一项安全属性去换一个仍然对不上盒子的数字。
买任何东西之前，先用同一服务器和同样时长在新设备上重跑步骤 2 和 3，然后比比值，不要比峰值。