macOS支持PMTUD但不可靠，因ICMP被屏蔽常失效；需手动用ping -D -s探测路径MTU，再通过networksetup -setMTU持久化设置并刷新DNS。
macOS 确实支持路径 MTU 发现（PMTUD），但它是基于标准 IP 协议栈实现的被动机制，不提供用户可见的自动配置或自适应调整功能，也不会在图形界面中显示、提示或修正 MTU 值。
它的核心行为是：当 TCP 或 ICMP 数据包设置了“不分片”（DF）标志，且大小超过某跳设备的 MTU 时，该设备会丢弃数据包，并向源主机返回 ICMPv4 “Destination Unreachable: Fragmentation Needed”（类型3，代码4）消息。macOS 内核收到该消息后，会将该目标地址对应的路径 MTU 缓存降低，并在后续发往同一目的地址的连接中自动减小发送分段尺寸——这个过程对应用透明，仅作用于 TCP 连接（如网页、SSH、SMB），不适用于 UDP 流量或静态接口 MTU 设置。
但现实中这个机制常失效，原因很实际：
- 大量家用光猫、路由器、防火墙或运营商设备会默认丢弃 ICMPv4 类型3代码4 报文（即屏蔽 PMTUD 必需的反馈）
- IPv6 环境下虽强制依赖 PMTUD（无分片能力），但 macOS 默认未禁用 IPv6 分片协商，双栈并行时可能干扰路径判断
- 内核缓存的路径 MTU 值不会持久化，重启、网络切换或连接空闲超时后即重置为接口 MTU（通常是 1500）
- 它只影响“出向连接”的分段策略，完全不改变接口本身的 MTU 配置值，因此 ifconfig 显示的仍是原始设置，Wi-Fi 或 USB 网卡驱动层仍按原值收发帧
所以你看到的现象是：
网页偶尔卡顿、大文件上传失败、HTTPS 握手延迟——这些都可能是 PMTUD 失效后，内核仍在发 1500 字节包，却被中间设备静默丢弃所致；而系统本身不会报警，也不会自动把 en4 的 MTU 改成 1450。
要真正解决问题，不能依赖自动发现，而得主动干预：
- 用
ping -D -s 1472 114.114.114.114手动探测路径上限（这是最可靠的方式） - 查准接口名（如
en4）和服务名（如"USB 10/100/1000 LAN"） - 用
sudo networksetup -setMTU将优化后的值写入服务配置，确保插拔、重启后持续生效 - 刷新 DNS 缓存并可选禁用 IPv6 分片协商（
sudo sysctl -w net.inet6.ip6.forwarding=0），减少双栈干扰
本质上，macOS 的 PMTUD 是一个底层协作机制，不是智能调优工具。它需要完整 ICMP 通路才能工作，而现实网络中这条通路经常被切断。所以“自动发现”存在，但不可靠；真正管用的，还是手动测 + 持久设。
