在配置透明代理、TUN模式网卡或WireGuard等封装隧道时，很多技术人员遭遇过离奇故障：网络Ping延迟很低且稳定，甚至DNS解析也正常，但一旦在浏览器中打开特定网页或上传大文件时，连接便会陷入无限期等待（Stall），随后超时报错。这种“小包通畅，大包蒸发”的典型症状，绝大多数源于链路中的最大传输单元（MTU）与最大报文段长度（MSS）协商不匹配，进而触发了严重的Path MTU Discovery（PMTUD）黑洞。核心结论非常明确：所有代理隧道都会为数据包附加额外报头，压缩了物理链路留给原始载荷的净空间；一旦外层报文超过路径最小MTU且禁用了分片，数据包就会被中间路由器静默丢弃。解决该问题的关键在于合理配置TUN网卡MTU，并在传输边界强制开启TCP MSS钳制。
基础物理概念：MTU、MSS与封装开销的数学关系
要理清故障根源，必须回归底层网络数据帧的长度计算标准：
在标准以太网中，网络接口的默认MTU几乎固定为1500字节。这意味着从网卡发出的任何单个IP数据包，总长度（包含IP报头与载荷）不能超过1500字节。
在标准TCP/IPv4连接中，基础IPv4报头占用20字节，标准TCP报头占用20字节。因此，留给TCP单次传输载荷的最大长度——即MSS——理论上限为1500 - 20 - 20 = 1460字节。通信双方在握手阶段会通过SYN包中的MSS选项互告对方自己所能接受的MSS最大值。
然而流量进入代理体系后，这个数学等式被打破了： 用户开启TUN模式或使用VLESS、Hysteria2等隧道时，外层协议必须为原始数据包套上新外壳。嵌套封装可能包含：外层以太网头（14字节）、外层IP头（20或40字节）、外层UDP/TCP头（8或20字节）以及加密头与代理私有字段。
层层叠加后，封装可能会吃掉40到80字节甚至更多开销。若内层虚拟网卡MTU依然保留1500字节，当本地应用生成1460字节满载TCP段时，加上内层IP头就达到1500字节；代理软件再打包加上外层报头，最终从物理网卡发出的报文总长度会膨胀到1560字节，超越了以太网1500字节的极限。
致命的PMTU黑洞：大包为何凭空蒸发
当超过1500字节的数据包试图穿过网络时，底层通常有两种处理路径：分片或丢弃。
现代操作系统为了追求性能与安全性，在发送绝大多数TCP报文时，都会在IP头强制打上“禁止分片（DF=1）”标志位。因为一旦大包在中间路由器被切碎，只要其中一个碎片丢失，整组数据必须全部重传，反而增加了丢包率与重组压力。
由此互联网设计了“路径MTU发现机制（PMTUD）”： 当打上DF=1标记的超长数据包抵达MTU较小的中间路由器时，路由器无法转发只能将其丢弃。根据标准，路由器在丢包的同时，应当向源端回复一个ICMP差错报文（Type 3, Code 4，即Fragmentation Needed），告知瓶颈链路的下一跳MTU具体是多少字节。源端收到后会自动调小MSS重新切片发包。
然而在现实网络环境中，为了防止恶意攻击或出于安全策略，大量运营商骨干路由器、云服务商安全组和家用光猫防火墙，都会粗暴过滤或拦截所有ICMP报文。
此时，毁灭性的PMTUD黑洞正式形成： 路由器丢弃了超长大包并向你发送告警ICMP；但该告警被防火墙拦截，发送端永远收不到反馈。客户端还在痴痴等待ACK确认并不断超时重传超长包，而服务端根本不知道数据已丢失。 在用户直观感受中：握手包很小（几十字节）成功建立；发送小文本请求成功；但当服务端回传巨大的TLS证书链或用户上传文件时，连接瞬间死锁，直至浏览器报错连接重置。
TCP MSS钳制与TUN MTU调优实战
彻底消除PMTU黑洞并保障隧道大流量畅通，必须采取两项工程措施：
第一项措施：在代理网关与TUN接口实施TCP MSS钳制。
MSS钳制是一种实用的防火墙代理拦截技术。无论是Linux下的iptables/nftables，还是Clash/sing-box内核的TUN模块，都会在本地监听所有经过的TCP握手SYN报文。
当检测到客户端向外部宣告MSS=1460时，网关防火墙会在转发过程中强制将其修改为一个预设的安全较小值（例如1360或1280字节）。对端服务器收到钳制后的SYN包时，会认为客户端只能接收较小报文段，从而在后续传输时主动限制每个TCP分段尺寸，从源头上杜绝超长包。
第二项措施：科学配置虚拟网卡（TUN）与客户端的MTU值。
对于采用TUN虚拟网卡接管全机流量的客户端，必须在配置中显式将TUN接口MTU设在保守区间，切忌保留默认的1500。
通用MTU设定基准如下：
对于普通VLESS、Trojan等基于TCP的代理，TUN网卡MTU推荐设为1400或1420；
对于基于UDP和QUIC的协议（如Hysteria2、TUIC），推荐将TUN网卡MTU配置为1380；
对于在移动4G/5G蜂窝网络或多层嵌套复杂内网中运行的客户端，推荐将TUN MTU进一步下压至1280字节（IPv6规范强制要求的最小MTU底线）。
命令行诊断与分片测试排查
在排查特定节点或网络是否遭受MTU黑洞时，可通过操作系统终端执行实测：
在Windows命令提示符下，使用Ping命令指定数据包大小并开启不分片标志进行步进探测。例如发送指定长度为1472字节且带有禁止分片标记的数据包。若提示需要分片，说明该长度超过了链路承载力；逐步下调字节数，直至找到能够通畅返回的临界值，该数值加上28字节（20字节IP头+8字节ICMP头）即为当前链路的真实极限MTU。
在Linux或软路由环境中，若使用iptables，可通过向mangle表添加规则，对TCP SYN报文开启clamp-mss-to-pmtu，确保所有转发流量自动适应路径MTU。
总结与行动指南
MTU与MSS是网络数据包穿透链路时的物理限高杆。忽视封装带来的字节增量，就会让大流量在不经意间撞上无声丢包的黑洞。在TUN配置中合理扣除开销余量并在传输层推行MSS钳制，是构建坚固、抗丢包代理网络的基本功。
掌握了MTU与报文分片的物理机制后，建议进一步阅读TCP与UDP应用语义取舍理解两种协议在报文边界上的根本差异；若想了解TUN网卡在全局接管时如何避免环路，请参考TUN路由环路防范与接口配置；关于多路复用中的阻塞问题，请阅读TCP多路复用队头阻塞深度剖析。
参考资料
- IETF RFC 1191：Path MTU Discovery
- IETF RFC 4821：Packetization Layer Path MTU Discovery
- Cloudflare 架构博客：Path MTU Discovery in Practice
资料核验：2026-10-15。本文讨论的MTU与MSS计算规则基于以太网与TCP/IP协议标准，具体配置字段以各代理软件TUN模式的官方文档为准。