VPN 客户端里的「TCP / UDP」通常指隧道外层用哪种传输层把封装后的包送到节点，不是网页本身改用了哪种协议。2026 年桌面与手机上最常见的误判，是把「TCP = 更稳定」或「UDP = 更快」当成绝对结论。选传输层时先分清：你在优化的是外层可达性，还是内层应用的延迟与重传行为。
TCP 与 UDP 在隧道里各自做什么
**UDP（User Datagram Protocol）**按数据报发送，不保证送达、不保证顺序、不在传输层做拥塞控制。一个可独立引用的定义句：UDP 隧道把包尽快交给对端，可靠性交给隧道内的 TCP、QUIC 或应用自己处理。
**TCP（Transmission Control Protocol）**提供面向连接的可靠字节流：丢包会重传，乱序会重排，并参与拥塞控制。把整条 VPN 隧道再套进 TCP，等于「可靠通道里再跑可靠通道」。
| 外层选择 | 隧道在做什么 | 内层应用仍可能是 |
|---|---|---|
| UDP | 封装后的 IP 包尽量原样转发 | TCP 网页、QUIC、游戏 UDP |
| TCP | 先建立到节点的 TCP 会话，再在其上搬隧道帧 | 同样的内层协议 |
这与 VPN 是什么 中的模型一致：加密与封装是一回事，外层怎么穿越你到节点之间的真实网络是另一回事。
为什么多数现代协议默认偏 UDP
结合 WireGuard 与 OpenVPN 对比 与 现代 VPN 技术架构，UDP 成为默认有工程原因，而不是营销口号：
- 避免双重重传：路径丢包时，外层 TCP 与内层 TCP 会同时减速、重传，表现为「已经很慢还越来越卡」；
- 抖动更可控：UDP 不在外层排队重排，内层协议可按自己的节奏恢复；
- 与实时流量更合拍：语音、部分游戏、部分 HTTP/3 路径本身就以 UDP 为主；
- 实现更简单：无状态或浅状态隧道更容易做漫游与快速握手。
OpenVPN 等仍提供 TCP 模式，常见动机是穿越只放行少数 TCP 端口的网络，而不是因为 TCP 在延迟上更优。
测试环境写法示例：2026 年 9 月，同一设备、同一节点地区，先用 UDP 模式测到节点 RTT 与网页体感，再切 TCP 模式复测。记录是否在公司网、酒店 Wi-Fi 或家庭宽带，避免把准入策略差异写成协议优劣。
对照表：什么场景更常选哪边
| 场景 | 更常优先 | 原因（简要） |
|---|---|---|
| 家庭宽带、路径丢包不高 | UDP | 延迟与抖动通常更好 |
| 交互、会议、对抖动敏感 | UDP | 减少外层队头阻塞 |
| 网络明确只放行 TCP/443 等 | TCP（或 TLS 封装） | 先解决「能不能连上节点」 |
| 已经很高的基线丢包 | 先修路径，再谈外层 | 换 TCP 往往加重双重重传 |
| 协议本身只实现 UDP（如典型 WireGuard） | 按实现约束 | 选项不存在时不要强行类比 |
「更常优先」不是排名。同一品牌客户端里，UDP 与 TCP 还可能对应不同端口、不同混淆或不同握手路径；对比时只改一项并写清日期。
队头阻塞：TCP 隧道为什么有时更卡
TCP 保证字节流有序。隧道里许多互不相关的内层连接（多个标签页、多个 App）被塞进同一条外层 TCP 时，一个外层段丢失，后面的隧道帧都要等重传完成才能继续交付。这种现象叫队头阻塞（head-of-line blocking）。
UDP 隧道上，内层各连接的丢失由各自的 TCP/QUIC 处理，通常不会因为「别人的包丢了」把整条管道停住。这也是读 VPN 延迟：RTT、抖动与丢包 时要把「均值尚可、体感很卡」与外层选择联系起来的原因之一。
防火墙友好不等于体验更好
部分网络对「非常见 UDP 端口」限速或丢弃，对 TCP/443 更宽松。此时 TCP 模式的价值是提高外层可达概率。代价可能是：
- 握手与稳态延迟上升；
- 丢包时双重拥塞控制；
- 大文件与多连接网页更容易出现「连得上但吞吐上不去」。
因此排障顺序建议是：
- 先确认节点 IP/端口在未开其他软件时是否可达；
- 同一节点下对比 UDP 与 TCP 的 RTT、抖动与网页结果；
- 核对 MTU：TCP 封装通常更占外层头，大包路径问题可能被误判成「TCP 慢」；
- 核对 DNS 与双栈：传输层换了，解析或 IPv6 旁路仍会导致「测速像通、站点不像通」。
据各客户端文档，选项名称可能叫「Protocol」「Transport」「TCP tunnel」「Obfuscated TCP」等；以实际抓到的外层五元组为准，不要只凭按钮文案推断。
和「协议名」不要混为一谈
日常口语里的「协议」常混了三层：
| 口头说法 | 更精确的含义 |
|---|---|
| WireGuard / OpenVPN / 某商业协议 | 隧道与加密如何构造 |
| UDP / TCP | 外层怎么送到节点 |
| HTTP/2、HTTP/3 | 浏览器到网站的应用层 |
可以在 OpenVPN 上选 TCP 或 UDP；WireGuard 典型部署是 UDP；浏览器是否走 HTTP/3，又是隧道之内的另一次协商。把三者当成同一个下拉框，会出现「我已经选了 UDP，为什么 Chrome 还在用 QUIC」这类错位问题——后者往往仍是预期行为。
常见误解
误解 1：TCP 隧道更安全。
机密性与完整性来自隧道的加密与认证设计，不来自外层是 TCP 还是 UDP。外层只影响可达性与性能形态。
误解 2：UDP 一定会被限速，所以不能用。
是否限速取决于具体接入网与端口，不是 UDP 的固有属性。先测再换，比先改传输层更省时间。
误解 3：换成 TCP 就能修复 DNS 泄漏或 IPv6 旁路。
那是控制平面与路由问题，与外层传输层无关。传输层只回答「封装后的帧如何到达节点」。
误解 4：延迟数字低就说明该模式适合所有 App。
到节点的探测延迟不包含队头阻塞与内层重传。多标签页下载时再看一次体感。
建议怎么选
默认从客户端的 UDP（或协议默认） 开始，在家庭或普通移动网络上建立基线。只有在「UDP 长时间无法完成握手、而同网络其他 TCP/443 服务正常」时，再试 TCP 或文档所述的封装模式，并做同节点前后对照。把日期、网络类型、外层模式与 RTT/体感写进笔记；换客户端大版本后重测一次。传输层选项是可达性与性能的旋钮，不是安全性排名，也不是对所有网络的通用开关。