OpenVPN 性能调优入门

OpenVPN 已经用了很长时间，选项也多得惊人，这既是优点也是陷阱。网络论坛里充斥着带十几项调整的配置片段，从一个环境复制到另一个环境，却没人测量过它们是否真的有帮助。这些调整大多数毫无作用，少数反而有害，真正能改变性能的只有寥寥几项。

本文讲解 OpenVPN 性能调优的基础：究竟什么限制了速度，哪些设置值得动，按什么顺序，以及如何确认改动确实有帮助。它面向能够控制自己配置的人，例如自建服务器或手上有配置文件的人，同时也能帮助任何想弄明白同一个协议为何在某套环境里很快、在另一套里却很慢的读者。文中不声称任何具体服务使用 OpenVPN。如果你用的是隐藏了这些选项的消费级应用，合理的做法是保持其默认设置，而这里的通用道理仍然能解释发生了什么。刚接触该协议的话，请先读 OpenVPN 是什么。

先测量，再调整

不测量就调整，等于瞎猜。改任何东西之前，先收集基线。

1. 尽可能用网线连接，并关闭后台应用。
2. 记录三次下载和上传速度，取中位数。
3. 用一百次 ping 记录空闲延迟，并记下范围作为抖动以及丢包情况。
4. 记录大文件下载进行时的延迟。
5. 观察运行隧道的设备的处理器占用。
6. 把以上内容连同日期、时间和服务器一起写下来。

处理器的数字比多数人想象的更重要。OpenVPN 的数据路径传统上运行在单个线程上，因此某一个处理器核心会成为限制，而其他核心空闲。如果该核心已满载，任何网络设置都无济于事，你需要更快的核心、更轻量的加密算法，或硬件加密支持。如何测试 VPN 更详细地讲了测量的部分。

设置一：UDP 还是 TCP 传输

OpenVPN 可以通过 UDP 或 TCP 承载隧道。这是最大的单项选择。

• UDP 发送封包，自身不做重传，延迟低，并避免了所谓的 TCP-over-TCP 问题。
• TCP 可靠，但把一条本身就承载 TCP 流量的隧道再包上一层 TCP，丢包时可能导致重复重传和急剧变慢。

两者都可用时，UDP 通常在速度和响应性方面更好。TCP 主要是针对封锁或干扰 UDP 的网络的后备。完整对比以及什么时候 TCP 才是正确答案，见 OpenVPN 的 TCP 与 UDP。

实用规则：如果你的连接用的是 TCP 且感觉迟钝，尤其在有丢包时，先试 UDP，再动别的。

设置二：封包大小、MTU 与 mssfix

每条网络链路都有最大封包尺寸。隧道会添加自己的头部，因此应用在隧道内能发送的最大封包比平时更小。封包过大就必须分片，这会损失性能，或者被丢弃，导致卡顿。RFC 1191 描述了沿路径发现最大可用尺寸的机制，但它依赖路径上每台设备的配合，而且有些网络会过滤它所使用的消息。

封包大小问题的症状：

• 有些网站只加载一部分，或页面前半部分之后就卡住，而其他网站正常；
• 大文件上传卡住，小文件却成功；
• 速度远低于预期，处理器和网络方面都找不到原因。

常见的补救措施是配置文件中的指令：

• mssfix 让隧道限制通过它的 TCP 数据段大小，使封包无需分片即可通过。常见做法是设为一个保守的值，例如 1400，然后测试。
• tun-mtu 设置接口的封包大小。通常没有 mssfix 那么必要。
• fragment 让隧道自己拆分较大的 UDP 封包。它只适用于 UDP 并增加开销，应视为最后手段。

一次只测试一个值。如果降低 mssfix 能让卡住的页面恢复而速度没有损失，就保留；如果变慢，就改回去。不要比必要的程度更缩小封包，因为封包越小，每字节的开销越大。

设置三：加密算法与处理器成本

加密需要处理时间，选择的算法会影响耗时多少。现代配置中常见两大类：

• AES 的 GCM 模式在内置 AES 加速的处理器上很快，包括大多数现代笔记本、手机和许多服务器。
• ChaCha20-Poly1305 设计上在软件中也很快，因此在没有 AES 硬件支持的设备上，如部分旧手机、小型路由器和单板计算机，可能是更好的选择。

正确的选择取决于你的硬件。测试方法很简单：打开处理器监视器，分别用每种算法运行吞吐量测试，比较速度和处理器占用。选择能达到所需速度又留有处理器余量的那种。不要为了速度选择弱的或过时的算法；在现代硬件上收益很小，而安全上的代价是真实的。关于它存在的原因，可参阅简短的 ChaCha20-Poly1305。

记住，隧道两端必须就算法达成一致，所以对于你不能控制的配置，这是该问服务器运营者的问题。

设置四：保持压缩关闭

旧教程建议用压缩指令挤出更多数据。如今这一建议已经过时，有两个原因。其一，研究人员已经证明，加密隧道内的压缩可能泄露关于数据的信息，所以目前的指导意见是避免使用。其二，大多数流量本来就已加密或压缩，比如视频、图片和一切 HTTPS 内容，无法再压缩，收益接近于零，而处理器成本依旧存在。如果你接手的配置里有压缩行，请先向来源确认再删除，但不要自己添加。

设置五：套接字缓冲区

缓冲区保存隧道与操作系统之间正在传输的数据。如果在高速链路上过小，突发数据到来时封包可能被丢弃，吞吐量就会受损。相关指令是 sndbuf 和 rcvbuf。

• 许多系统的默认值相对快速连接所需来说偏小。
• 把两者都设为更大的值，例如 512 KiB，可能对高速链路有帮助，尤其是在隧道接口上看到丢包而底层连接没有丢包时。
• 操作系统会限制最大值，过大的值可能被悄悄降低。

两者一起改，测试，只有确实有帮助才保留。在慢速链路上，更大的缓冲区没有作用，还可能增加延迟。

设置六：保活与重连

保活设置不会让连接更快，但决定了失效的隧道多快被发现并重建，当你在不同网络之间移动时，这会像性能一样被你感受到。

• keepalive 指令会定期发送 ping，并在 ping 不再到达时重启隧道。典型的一对数值是每十秒一次 ping，沉默六十秒后重启。
• 更短的间隔能更快发现失效链路，但会略多用一点流量和电量。
• 在经常于 Wi-Fi 与移动数据之间切换的移动设备上，较短的间隔加自动重连能带来更好的体验。

如果你主要关心保持连接，改善 VPN 连接稳定性 讲了实际操作方面。

其他有时会有影响的选项

• **多核利用。**OpenVPN 的经典设计是每条隧道单线程，因此在多核服务器上，运行多个隧道进程，或在你的版本支持时使用较新的数据通道卸载功能，是用上更多硬件的办法。
• **硬件加密卸载。**如果可用，它能把加密算法的工作从主处理器上移走。
• **DNS 设置。**网页起步慢可能来自域名解析慢，而不是隧道。单独测试一次解析。
• **服务器负载与位置。**即使配置完美，也无法修复过载或遥远的服务器。较近的位置往往比上面所有的调整都更有效。更全面的清单见 为什么我的 VPN 很慢。

一次完整的调优过程示例

下面是一个虚构但贴近现实的过程，用来展示节奏。

用户在家里的小型计算机上运行自建的 OpenVPN 服务器，并用笔记本通过 300 Mbps 线路连接。不走隧道的基线为 280 Mbps；走隧道时只有 45 Mbps，家里那台计算机的处理器在一个核心上占用 100%。

步骤	改动	结果
0	带隧道的基线	45 Mbps，一个核心满载
1	从 TCP 改为 UDP	70 Mbps，仍然满载
2	把加密算法从旧默认值改为 AES-GCM 选项，因为这台小计算机有硬件 AES	160 Mbps，核心占用 70%
3	删除继承来的压缩行	165 Mbps，处理器占用略降
4	增大 sndbuf 和 rcvbuf	190 Mbps，隧道接口上的丢包消失
5	尝试更低的 mssfix	速度无变化，两个卡住的网站现在能加载
6	为会休眠的笔记本调整 keepalive	速度无变化，休眠恢复后重连更快

最大的收益来自传输方式和加密算法，这与本文的顺序一致。后续步骤带来了较小但真实的改善。没有一步需要用到冷僻的选项。还要注意，用户每一步只改一项，并每次都做了测量。

不要这样做

• **不要照搬论坛里的长配置，**除非你理解每一行。
• **不要为了速度关闭加密或认证。**那等于让隧道失去意义。
• 不要因为更轻量就选用旧的加密算法。
• **不要同时改很多项。**你将无法知道是什么起了作用或造成了损害。
• **不要在客户端上去弥补过载服务器的问题。**如果服务器过载，就换服务器或位置。
• **不要在没有客服指导的情况下改动受管理应用的设置，**默认值是为那项服务选定的。

总结

OpenVPN 的性能主要取决于几件事：尽可能用 UDP 而不是 TCP，封包大小与路径相匹配，加密算法与硬件相称，保持压缩关闭，缓冲区按高速链路设置，以及与你移动方式相符的保活。先测量基线，一次改一项设置，记录结果，只保留确有明显帮助的改动。如果处理器已满载或服务器很远，任何设置都救不了结果，所以先检查这两项。

如果你更想跳过配置，直接使用现成的应用和短期固定天数的通行证，请查看 价格页面，免费的 VPNclient 应用可在 下载页面 获取。