真实路径mtu需用ping -m do -s测试：从1472开始逐步减小-s值，成功响应后mtu=成功-s值+28，且必须测实际业务目标而非仅公网dns，因路径中任一节点mtu最小值决定整体能力。
怎么用 ping 测通路真实 MTU（不是本地设置）
本地 ip link show 显示的 mtu 值只是本机网卡配置，不代表整条路径能跑多大包。真正决定 TCP 连接是否稳定、HTTPS 是否握手失败的，是路径中所有设备支持的最小 MTU —— 这必须实测，不能猜。
- Linux 用
ping -M do -s 1472 8.8.8.8：-M do 表示禁止分片，-s 后是 ICMP 载荷大小（不含 IP 头 20 字节 + ICMP 头 8 字节），所以 1472 → 对应 MTU=1500 - 如果返回
Frag needed and DF set，说明路径不支持，要逐步减小-s值（每次减 10～20 更高效） - 成功收到 reply 后，真实路径 MTU = 成功的
-s值 + 28；比如ping -M do -s 1422 8.8.8.8成功，则路径 MTU 是 1450 - 别只测到公网 DNS：如果业务走专线、云厂商内网或跨 VPC，得测实际目标地址，比如
ping -M do -s 1422 your-api.internal
为什么 ip link show 的 mtu 不等于路径 MTU
ip link show dev eth0 输出的 mtu 1500 只表示本机网卡允许发多大的二层帧，它对路径上其他环节毫无约束力。中间任意一跳（如云厂商网关、物理防火墙、运营商 DSLAM）MTU 设为 1450 或 1400，都会导致你的 1500 包被丢弃或静默截断。
- 回环接口
lo的mtu 65536完全无关路径，别拿它当参考 -
ip addr show不保证显示mtu字段，某些精简输出会省略，不能替代ip link show -
ifconfig已被多数现代发行版弃用，在容器或新内核环境里可能根本不可用，也不推荐依赖
测出路径 MTU 后，怎么验证是否真起作用
改完本地 MTU 或调整应用层 TCP MSS 后，不能只信命令返回或配置文件写了就完事。得验证三层是否真的按新值收发。
- 改完立刻再跑一遍
ip link show dev eth0 | grep mtu，确认数值已更新（注意：接口必须处于UP状态，否则静默失败） - 用
tcpdump -i eth0 icmp抓包，看实际发出的 ICMP 包长度是否匹配你设的 MTU（比如设成 1450，载荷应 ≤1422） - 如果跑的是 TLS 服务，用
openssl s_client -connect example.com:443 -servername example.com观察是否还出现 handshake timeout —— 这往往是路径 MTU 不足的典型症状 - 容器环境要进对应 netns：
nsenter -n -t $PID ip link show dev eth0 | grep mtu，host 上改了不影响容器内部
永久生效但被 NetworkManager 覆盖怎么办
临时用 ip link set dev eth0 mtu 1450 成功，重启后恢复默认？大概率是 NetworkManager 或 systemd-networkd 在后台把你改的值又刷回去了。
- Ubuntu/Debian（Netplan）：编辑
/etc/netplan/*.yaml，在对应 interface 下加mtu: 1450，然后sudo netplan apply - RHEL/CentOS 8+（NetworkManager）：用
nmcli connection modify "System eth0" ipv4.mtu 1450，再nmcli connection reload && nmcli connection down "System eth0" && nmcli connection up "System eth0" - 手动写
/etc/sysconfig/network-scripts/ifcfg-eth0（旧 CentOS）加MTU=1450，但需确认NM_CONTROLLED=no，否则 NM 仍会接管 - 改完务必检查服务状态：
systemctl is-active NetworkManager，开着就得走它的配置方式，硬写文件没用
