Nube.sh 日本机房与 Vultr LA 之间的 MTU 踩坑与修复小记

昨天偶然之中发现，自己在 Nube.sh 的 Tokyo 可用区购买的 VPS，无法正常访问在 Vultr 上的一台 LA 的 VPS。具体表现为 SSH 端口能通，然而真连接过去的时候，一些操作会中断，无法继续。例如：

• ls 一个文件多一点的目录，显示到一半就卡住了。
• vim 编辑文件，必定黑屏，也是卡住，必须关掉 SSH 会话。

我是在 SecureCRT 中通过在 Firewall 中 Select Session 设置了转发，也就是说 SSH 隧道过去的。不清楚直接在命令行上 SSH 过去会如何，但无论如何这个现象都不正常。

这个问题只在这两台 VPS 之间存在，方向倒过来的情况我没试过。感觉跟两者之间的网络状况有一些关系。现在排查这类问题也算简单：直接问 AI，比我自己想要快，也可能更靠谱，至少能得到一些方向性指引。果然，AI 的回答直指问题的核心——MTU。

我的确是在 Nube.sh 的客服群里面见到过有人在反映日本的 VPS 有问题。回头搜了一下（奇怪 Telegram 的搜索功能我记得不太好用来着？），发现今年五月份的时候就有人回答说是 MTU 不够。老板也认可了这个结论，不过后续当客户催促修正时，老板那边没了下文。Nube.sh 的规矩一向是「只认工单」，我估计那个客户没发工单，所以这个事情直到现在应该都还是这个状况。

仅仅是 MTU 的问题的话，是可以自己动手搞定的。AI 同时也提供了方案：

1. 调整网卡设置，临时或永久地修正。
2. 调整 iptables 设置，针对性修正。

因为我并没有广泛测试，说不定还有哪些机器和 Nube.sh 日本这台 VPS 之间也有类似问题，所以我就选了方案一，直接改网卡设置了。一劳永逸，至少在我或牛肉老板重置 / 还原 VPS 网络设置前都能有效。

我的操作系统是 Debian 13，修改 /etc/network/interfaces 即可。Nube.sh 在 dhcp 后面加了一句post-up，在它前面再加上一句就行了：

post-up ip link set dev eth0 mtu 1400

实际能正常发送的包的大小，我用 ping 测试了一下，应该是 1448：

ping -c 4 -M do -s 1448 <IP Address>

那也就是说实际上的 MTU 应该是 1448 + 28 = 1476，不过 AI 建议我多留点余量。考虑到也没有太大的副作用，我就按它说的直接设到 1400 了。重启之后查看网卡设置：

ip link show eth0

OK，现在的 MTU 是 1400 了。SSH 恢复正常。完结，撒花。