把 MTU 从 1500 改成 1380 的那天，我们知道自己赢了

2017 年 9 月 14 日，星期四，凌晨 2 点 47 分。我们把客户端默认 MTU 从 1500 改成 1380，推到生产环境。第二天早上 9 点打开后台：47 个投诉变成了 6 个。

这一篇文章讲讲那天发生了什么——为什么一个不起眼的数字能救活一个产品，以及 9 年后我们为什么还在坚守它。

一、事情的起点：47 个投诉

2017 年 6 月我们发了第一个版本。三个人的小团队，深圳前海 20 平米办公室，服务器散热靠一台破窗机。当时做这件事的动机很朴素：市面上能找到的工具，要么握手慢得像拨号上网，要么连上三分钟就掉。我们觉得自己能做得更好。

但市场给了我们一记响亮的耳光。

第一个版本上线第一天，47 个用户投诉，全是同一句话：「连不上」。不是连不上服务器，是连上 3 秒就断，再连上再断，反反复复。

那时候我们还没意识到这意味着什么。我以为是协议设计有 bug，拉上王慎之（CTO）一起翻了三天的代码，没发现任何问题。我们试着换加密算法、换握手序列、换重传策略——没一个管用。

二、第 12 个投诉的用户

那 47 个投诉我到现在还记得。第 12 个投诉的用户姓林，他在深圳华强北做硬件。他在留言里写「连上 3 秒必断，麻烦尽快解决，公司要用」——后面跟了一句「我愿意付费，问题修好就买」。

我和他来回发了 20 封邮件。第 5 封的时候他告诉我他在华强北某条光纤接入，我让他跑了一次 tracert 把结果贴给我——我盯着那个路由表看了很久，发现一个奇怪的事情：

他到我们香港节点的路径里，有一段运营商在用 GRE 隧道。结果是实际承载我们数据的物理链路 MTU 不是 1500，是 1480。

但我们的客户端还在按 1500 往外发包。

1500 大小的包走 MTU 1480 的链路，必须分片。分片就意味着每个包都要多一次分片头，分片途中只要丢一片，整个包就废。我们的加密层会判定为"丢包"，然后触发重连。这就是「连上 3 秒必断」的原因。

三、什么是 MTU，为什么 1500 是问题

MTU（Maximum Transmission Unit）是网络层单次能发的最大包大小。以太网默认是 1500 字节。但这个 1500 只在两台机器直连、或同一运营商内网内有效。一旦路径上有 VPN 隧道、GRE 隧道、MPLS 标签、甚至某些 PPPoE 拨号链路，实际可用 MTU 会被吃掉几十字节。

网络协议的标准做法是 PMTUD（Path MTU Discovery）——客户端发大包，路径上的路由器发现太大就回 ICMP "Fragmentation Needed"，客户端收到后就该降下来。但 PMTUD 在 VPN 这种「包被加密，路由器看不到里面」的链路里基本失效。VPN 包在外面又套了一层 IP 头 + UDP/TCP 头，再加上 VPN 协议自己的头，有效载荷被压缩到了 1380 左右。

这就是为什么行业经验值都是「VPN 客户端默认 MTU 设 1400 或者 1380」。但 2017 年 6 月我们不知道这个经验值，因为我们三个之前都在华为阿里腾讯做企业级产品，从来没碰过面向 C 端的网络工具。

我们当时跑过的诊断命令

# 林先生那边运行的诊断
$ ping -M do -s 1472 klb-vpn.example.com
PING klb-vpn.example.com (203.x.x.x) 1472(1500) bytes of data.
From 10.x.x.x icmp_seq=1 Frag needed and DF set (mtu = 1480)

# 我们这边在客户端抓的包
$ tcpdump -i eth0 'host 203.x.x.x' -nn -vv
12:34:56.789 IP 198.18.x.x > 203.x.x.x: ESP(spi=0x...) ...
length: 1500  ← 包太大了

看清楚了吗？mtu = 1480。但我们在发 1500 字节的包。这是教科书级的「PMTUD 失效场景」。

四、改成 1380 之后

我们把客户端默认 MTU 从 1500 改成 1380。1380 不是拍脑袋——它是「1500 - IP 头 20 - UDP 头 8 - VPN 协议头 12 - 加密 padding 80」的算式结果。这个值能保证即使路径上有 GRE 或 MPLS 隧道吃掉几十字节，也能一路畅通。

推到生产 6 小时后，第二天早上 9 点：47 个投诉变成 6 个。剩下的 6 个我们后来逐一排查，是另外的问题——DNS 解析慢、不同地区的运营商路由表不一样。但「连上 3 秒必断」这个问题彻底消失了。

五、1380 不是银弹

读者到这里可能想问：1380 是不是一个神奇数字？是不是所有 VPN 都该用？

答案是否定的。1380 是 2017 年我们那个协议栈的安全余量。8 年来我们的协议头从 12 字节精简到了 8 字节，理论上可以放宽到 1400。但我们没改——因为 1380 在我们过去 9 年的全样本数据里表现最稳定。

网络工程里没有"理论最优"，只有"实测稳定"。1380 是我们用 9 年时间、几十亿次连接验证出来的「实测稳定」值。

你打开客户端的「高级设置」，能直接看到这个数字。普通人不需要知道它为什么是 1380；它就在那里，安安静静地保护每一次连接不掉线。

六、林先生成为 13 号员工

第 12 个投诉的那个林先生，后来成了我们的第 13 号正式员工。他不是写代码的——他在华强北做了十年硬件，对网络设备、对运营商线路、对机房机架这些"硬的东西"比我们都熟。9 月 MTU 改完之后，他在第 18 封邮件里说"这事我能帮上忙"。

10 月他正式入职，第一个任务是帮我们去香港机房蹲点三天，对接本地 ISP 的 BGP。他的工号是 13。从那以后，公司内部一直叫他"13 号"，他不生气——他说 13 是他「把快连救活的纪念日」。

七、这件事教我们的事

做网络工具最反直觉的事：你越想"快"，越要慢下来调参数。

2017 年我们三个人带着"我要做最快的 VPN"的初心入局，被用户投诉、被路径 MTU、被运营商的 GRE 隧道教育了一遍又一遍。最后救活我们的不是某个天才算法，是「把一个数字从 1500 改成 1380」——这种最笨、最基础、最不起眼的功夫。

8 年过去了，MTU 1380 还印在每个客户端的高级设置里。它是我们见过的最朴素、也最可靠的一道护城河。

—— 陈礼 / 2026 年 7 月写于深圳