小请求正常、大文件卡住：MTU与PMTUD排查思路
把MTU列为假设，需要一组相关现象
网站首页能打开，上传到某个阶段停住；远程会话建立正常，一输出大量内容就卡顿。这些现象值得检查路径MTU，但也可能来自应用限制、存储读取、代理超时或丢包。单次下载失败不足以证明MTU设置错误。
MTU描述链路能够承载的最大IP报文大小，路径MTU受沿途最小可用值约束。隧道和封装会占用额外空间，所以物理接口配置看起来相同，实际路径允许的报文大小也可能不同。排查的目标是确认哪段路径和哪类报文出现问题，而不是先为全网选择一个固定数字。
PMTUD依赖什么反馈
传统IPv4路径MTU发现使用禁止分片的报文和相应ICMP反馈，让发送端调整发送大小。若报文过大且中间设备无法转发，反馈能够帮助源端发现限制。RFC 1191
IPv6中，沿途路由器不负责对报文进行分片；路径MTU发现依赖Packet Too Big消息通知发送端。把全部ICMPv6都当作无关流量丢弃，可能影响这种反馈以及其他必要的IPv6功能。RFC 8200、RFC 8201
不过，“没有看到反馈”仍需结合抓取位置分析。反馈可能没有生成、被中间规则丢弃、走了别的返回路径，或者测试本身没有触发限制。不能因为某个中间节点不回复普通探测，就认定它是故障点。
设计能够排除其他原因的对照
先选择自己管理的测试入口和一个可重复下载的对象，记录文件大小、校验值和应用超时。对照同一时间的IPv4与IPv6访问、经过隧道与不经过隧道的访问、较小与较大响应。每次只改变一个条件，让结果能支持明确判断。
假设同一个文件经普通出口可以完成，经新启用的隧道反复停在传输初段，而小响应两边都正常。这时应优先核对隧道端点的封装开销、路径配置与反馈规则。如果不同路径都在同一业务处理时间失败，则应用限制或代理超时可能更值得先查。
可以在受控环境中逐步改变测试报文大小，观察哪一段区间开始异常。但探测工具的“数据长度”往往不等于完整IP报文长度，IPv4与IPv6头部也不同，不能把命令中的数字直接当作路径MTU。记录工具、参数、协议与方向，才能让网络支持人员正确解释结果。
修改前保存现场和恢复入口
有权限时，在通信两端按目标地址和短时间窗口记录报文摘要，重点寻找重复发送、反馈消息及返回路径差异。尽量保留时间戳和报文长度，避免采集与问题无关的业务内容。与此同时导出当前接口、路由、隧道及防火墙配置，建立变更前基线。
不要在仅有一条远程管理通道时随意调整承载管理连接的接口。先准备控制台或其他恢复入口，再在测试环境或可回退的小范围内验证。临时降低发送大小后恢复正常，可以增加对MTU问题的怀疑，但它仍不是根因证明，也未必是最合适的长期配置。
长期修复应对应实际原因：纠正隧道接口参数、恢复必要的反馈路径，或按设备与协议说明调整相关策略。修改后复测大文件、长连接以及两个方向的传输，并检查其他业务没有受到影响。
工单最好附上故障起止时间、源和目的地址、经过的隧道、对照结果与已做变更。这样的证据比“帮我改成某个MTU”更有用，也能避免把应用问题交给网络团队后长期来回排查。