OpenVPN 的 UDP 隧道里跑 TCP 上的 NFS：两种传输

在承载 UDP 的隧道里承载 TCP 上的 NFS 会话完全自洽，它让人困惑，是因为它同时点了两种传输的名。TCP 是客户端与 NFS 服务器之间的文件服务会话。UDP 是 VPN 两端之间的加密承载。两者谁都不意味着对方如何。

排障之前先把两样分开写下来；这类事故大多始于有人改错了层。

两层，两个设置

挂载选项 proto=tcp 描述的是 NFS 客户端如何与 NFS 服务器对话。VPN 配置里的 proto udp 设置描述的是隧道两端如何交换封装后的数据包。改挂载选项不会改变隧道，改隧道传输也不会改变 NFS 客户端谈定的内容。有效挂载选项要用 nfsstat -m 确认，而不是看 fstab 那一行；VPN 传输则要从实际在用的配置里确认。

然后把它们作为两个独立字段写进事故记录。只有记录写清哪一层变了，表面上的改善才追得下去。

浏览不等于批量读取

能列出目录，只能证明某些操作完成了。它不能证明持续读取、写入、加锁或后端存储会在同样条件下完成。大文件读到一半卡住，和挂载始终失败是两种不同的观察，指向的层也不同。

把失败的操作描述准确：路径、方向、卡住的大致位置，以及客户端、服务器和 VPN 日志里最后一条相关事件。然后比较流量在哪里还继续、在哪里停住。

MTU 是假设，不是诊断

隧道承载大分段时，随包长变化的丢包确实可能存在，它产生的正是「浏览能用、读取就卡」的形态。但这个形态并不能证明 MTU 有问题，因为服务器慢、防火墙把长连接超时掐断、磁盘繁忙时，也会出现同一个形状。要用可控探测去验证假设，而不是到处降 MTU 然后宣布胜利。

单看超时并不能说明该不该换掉 UDP。它是一个有多个可能归属的症状。

一次只改一个变量

比较传输时，保持 NFS 负载和其他所有设置不变。在同一个维护窗口里改挂载传输、隧道协议和 MTU，得到的结果没人能归因。改动前后跑同一个文件操作，并逐步记录结果。

把原来的值也留在工单里。一旦改动让情况更糟，回退应该是记录在案的数字，而不是某个人记得以前是多少。

读失败的那一层

如果隧道还在、NFS 请求在等，那么失败的就不是 VPN，而是文件服务。如果隧道掉了，NFS 请求失败是结果而不是原因。把两层的日志行对上，是区分这两种情况最快的办法，比从文件管理器里猜要强。

结论写成两句话，一层一句。这足够让下一个人复现测试，而不必重新推导哪种传输是哪种。