UDP 未必更快：如何选择 OpenVPN 传输方式

所有指南都说 OpenVPN 用 UDP 比 TCP 快，但这条建议只是默认值，并非实测。传输方式改变的是数据包的投递方式以及路径丢包时会发生什么，而不是隧道如何加密。在强制门户或只允许 443 端口的代理后面，较慢的选项反而是唯一能连上的。下文将协议本身的行为与你接入网络允许的事情区分开来。

传输方式究竟改变了什么

TCP 提供可靠、有序的字节流，并重传所有丢失的内容，正如 RFC 9293 所规定。UDP 把数据报交给网络，而 OpenVPN 在该套接字之上运行自己的可靠性层。把 TCP 封装进 TCP 会叠加两层恢复循环，因此 一个丢失的分段就可能卡住内层数据流，直到外层重传到达。这种相互作用才是支持 UDP 的真正理由，它表现为延迟而不是吞吐量。

影响随丢包和往返时间增大。在干净的本地路径上，两种传输方式感觉完全相同，所以实验室测试很少能复现用户的抱怨。在拥塞的移动链路上，交互式会话会在大文件传输察觉之前很久就显现出差异。

这些都与机密性或完整性无关。TLS 握手和数据通道密码对两种传输方式来说都一样，所以切换无法挽救薄弱的密码套件。

TCP 在哪些场景值得保留

接入网络是选择 TCP 的常见原因。酒店、机场或访客网络可能只放行出站 443 而丢弃其他一切，而该端口上的 TCP 监听器就是唯一可用的配置。这属于可达性而非性能，单凭这一点就足够。

当路径稳定但中间设备不友好时，TCP 也有帮助。有些网络会重置长寿命的 UDP 流，却容忍看起来像普通网页流量的 TCP 会话。这种相似能否奏效取决于具体网络，没有指南能对所有网络打包票。在出问题的网络内部测试，然后再责怪协议。

登录被拒绝不是传输问题。为了强行建立连接而关闭证书验证是另一种改动，后果要糟糕得多。

准备好一份 TCP 配置是务实的折中。大多数客户端两者都保存，并在网络拒绝 UDP 路径时让你切换，这在需要之前不花任何代价。不该做的是提供指向不同端点的两份配置，因为那样你的比较其实是在测服务器。

确认你实际拥有哪个监听器

在比较性能之前，先确认两端对传输方式和端口达成一致。在客户端文件里把 proto udp 改成 proto tcp 并不会在服务器上创建监听器。服务器必须针对该协议进行配置，配置也必须与之匹配。

grep -E '^(proto|port|remote)' /etc/openvpn/server.conf
ss -lunp | grep openvpn
ss -ltnp | grep openvpn

grep 打印服务器被要求使用的内容，而两个套接字列表显示它实际绑定到什么。UDP 监听器只出现在第一个列表里，TCP 监听器只出现在第二个里，所以缺少的那一行是找到从未生效的配置的最快方式。还要比较端口，因为在大多数接入网络中，1194 上的 TCP 配置与 443 上的表现不同。改动后重启服务，并阅读报告绑定情况的日志行。

客户端侧的确认很便宜：用 --verb 4 运行连接，并阅读日志中的传输行。如果客户端说 UDP 而服务器却在监听 TCP，握手根本不会开始，任何调优都无济于事。

比较工作负载，而不是传输标签

公平的比较要让除传输方式以外的一切保持不变。同一设备、同一接入网络、同一目标主机、同一应用，最好还是同一服务器。如果两份配置指向不同主机，你同时也在测那些主机。

每次运行记录三个结果：隧道是否建立、是否保持、任务是否完成。小请求能通过而大传输卡住，说明问题在数据包大小和 MTU，而不是传输方式。反复重连说明路径或中间设备超时。

保留在你实际遇到的条件下可用的配置，另一份也存着。选择属于网络而非个人，所以任何单一的默认答案总会在某处出错。