VPN 用 TCP 还是 UDP：默认选 UDP，遇到限制再切 TCP
TCP 和 UDP 是 VPN 隧道在传输层可以选择的两种承载方式。TCP 保证数据按序到达，丢了会重传，可靠但有额外开销；UDP 只管发送，不保证到达，延迟低、效率高。多数情况下默认选择 UDP 更合适，只有当所在网络限制了 UDP 出站，或者需要穿过只放行特定端口的网络环境时，才切换到 TCP。这篇文章把两者的差异、隧道里常见的性能陷阱，以及端口的选择讲清楚，并给出一套可以自己验证的对比方法。
两种方式的原理差异
先看它们各自在做什么，才能明白为什么不同场景要选不同方式。
TCP：先握手，丢了就重传
TCP 在传数据之前要先完成三次握手，传输过程中接收方会确认收到的数据，没收到就要求发送方重传，还会根据网络状况调整发送速度。这些机制让数据可靠、按序到达，代价是延迟更高，并且在丢包的网络里速度会被明显压低。
UDP：不握手，不确认，发完就算
UDP 不建立连接，也不保证对方收到，没有重传和拥塞控制。它的开销小、延迟低，适合对实时性要求高的场景。可靠性由上层负责：WireGuard 本身只使用 UDP，OpenVPN 则同时支持 UDP 和 TCP 两种模式。
隧道里再跑 TCP，为什么会变慢
当 VPN 本身用 TCP 承载，而你在隧道里访问的网页、下载同样基于 TCP 时，就形成了“TCP 套 TCP”。丢包发生时，内外两层都会触发各自的重传和降速机制，相互叠加，吞吐可能下降得比单层 TCP 严重得多，这也是为什么普通网络下更推荐用 UDP 承载隧道。
| 维度 | UDP 承载 | TCP 承载 |
|---|---|---|
| 延迟 | 较低 | 较高 |
| 丢包时的表现 | 只影响受损的包 | 内外两层重传，速度下降明显 |
| 穿越受限网络 | 可能被限制 | 更容易通过 |
| 典型端口 | 如 51820、1194 等 | 常用 443 |
| 适合场景 | 日常使用、视频、游戏 | UDP 被限制时的备用方案 |
什么情况下需要切到 TCP 和 443 端口
有些酒店、公共 Wi-Fi 和办公网络只允许常见的网页端口出站，UDP 流量或者不常见的端口会被限制，表现为客户端一直停在“正在连接”。这时可以切换到 TCP，并选择 443 端口，这个端口是 HTTPS 使用的标准端口，几乎所有网络都会放行。切换之后能连上，说明问题出在端口或协议限制，而不是线路本身。
怎么判断是不是协议被限制了
- 同一台设备换一个网络（比如手机热点）连接，如果热点下能连上，说明问题在原网络的限制。
- 在客户端里把 UDP 换成 TCP，再换到 443 端口，各重试一次。
- 能连上以后，用 ping 记录延迟和丢失率，作为这个网络下的参考基线。
- 回到不受限的网络，再切回 UDP，不要长期使用 TCP 模式。
自己动手对比两种方式的速度
在同一网络、同一线路下，分别用 UDP 和 TCP 各连续 ping 50 次，再各测三轮下载速度取中位数，把平均延迟、丢失率和速度记进一张表里。网络质量好的时候两者差距可能不大，网络有丢包时，差距会更明显，这也是日常默认用 UDP 的原因。
切到 443 端口之后，还要留意什么
443 端口通常用来承载 HTTPS 流量，把 VPN 放在这个端口上，在端口层面和普通网页流量混在一起，更容易通过只放行网页端口的网络。但要注意，这只是解决端口被限制的问题，如果网络对流量做了更细致的检查，仍然可能连不上，此时需要在客户端里尝试其他连接方式，或者换一个网络环境。另外，TCP 模式下的吞吐往往低于 UDP，如果切换之后觉得速度明显变慢，可以记录下数据，等回到正常网络再切回 UDP。
想直接在客户端里体验不同连接方式，可以试试 TonBoVPN，具体支持哪些协议和端口选项，以客户端内的设置页为准，按上面的步骤自己对比一遍即可。
小结：默认 UDP，受限再切 TCP
UDP 延迟低、效率高，是日常的首选；TCP 可靠但在隧道里容易叠加重传，适合作为 UDP 被限制时的备用方案。遇到连不上的网络，先换端口和协议排查，再决定是否需要换线路，这样的顺序最省时间。