清洗后能建立连接，不代表回源路径上的大报文也能顺利通过。小请求正常、上传或响应传输中断，常见原因之一是链路 MTU 不一致，或路径 MTU 探测受阻。排查“流量清洗后回源路径的MTU与分片排查”，应从报文实际经过的每一段入手，而不是只检查源站网卡。
以下六项核对适用于清洗设备串接、隧道回源或经过多段网络的场景。每次只调整一个变量，并保留变更前后的接口配置与测试结果，便于判断问题是否真正消失。
先核对六个容易漏掉的风险点
1. 清洗设备两侧的 MTU 是否一致
分别查看清洗设备面向用户侧、回源侧的接口 MTU，并与相邻路由接口、源站网卡配置对照。以常见以太网配置为例，接口 MTU 经常设为 1500 字节，但这不是所有路径都适用的固定值；专线、虚拟接口或隧道可能采用更小的承载空间。注意区分接口 MTU 与包含二层头部的帧长度，避免比较了不同口径的数据。
2. 封装后是否超过承载链路上限
IP 隧道、加密封装等会给原始报文增加额外头部，外层报文可能因此超过底层链路 MTU。检查清洗设备到源站之间是否存在封装，以及两端的封装参数是否一致。若问题只在经过隧道时出现，应优先测隧道接口的有效 MTU，而非直接降低所有物理接口的 MTU。
3. PMTUD 所需的差错反馈能否返回
PMTUD（路径 MTU 探测）依靠路径中的设备反馈“报文过大、无法转发”等信息。IPv4 下，设置 DF 的报文不能被中间设备分片；若相关 ICMP 差错报文被清洗策略或防火墙丢弃，发送端可能持续重传过大的报文。检查策略日志和双向抓包，确认该反馈既能发出，也能返回发送端；不应为了测试而无差别放行所有 ICMP。
4. IPv4 分片是否被单独处理或丢弃
确认清洗设备、访问控制规则和后续防火墙对 IPv4 分片的处理方式。某些规则只检查首片的传输层信息，后续分片不含完整端口字段，可能被不同策略误判。对比同一目标下小报文与大报文的结果，并在设备日志中查找分片丢弃、重组超时或异常报文计数。
5. MSS 调整是否与实际路径匹配
MSS 是 TCP 报文段中数据部分的最大长度。设备可能通过修改 SYN 报文中的 MSS 来避免 TCP 报文过大，但它只影响 TCP，不能解决所有 UDP 或其他 IP 报文的 MTU 问题。检查清洗设备是否启用了 MSS 调整、调整值是否适用于当前回源路径，并确认双向连接都经过预期设备。不要把修改 MSS 当作修复路径 MTU 的通用替代方案。
6. 清洗后的实测是否覆盖双向和大报文
只测连通性或小请求，容易漏掉大报文问题。应分别从清洗前后可控的测试点检查去程与回程，覆盖短连接、持续传输和较大的应用响应；同时观察源站、清洗设备和相邻接口的丢包及错误计数。单点抓包只能说明该点看到了什么，不能单独证明报文已到达另一端。
按顺序执行，缩小故障范围
记录清洗路径：列出用户入口、清洗节点、回源出口、隧道及源站接口，标明每一段的 MTU 和设备策略。
从最接近源站的测试点开始逐段验证。Linux 环境可用 tracepath 观察路径 MTU；若使用 ping 测试，应注意 ICMP 可能被限速或过滤。Linux 下 IPv4 可用 ping -M do -s 1472 目标地址测试常见 1500 字节路径的探测起点；1472 字节是 ICMP 数据长度，另有 IPv4 与 ICMP 头部，测试结果仍需结合具体路径和设备行为判断。
逐步调整测试报文大小，记录成功与失败的边界，并在另一方向重复。若探测失败，先确认是否收到 ICMP 差错，不能仅凭超时认定 MTU 过小。
在清洗设备入口、出口及源站侧同步观察报文，核对报文长度、DF 标志、分片情况和丢弃计数。对比同一时段的业务日志，确认故障是否与大响应、上传或特定回源路径相关。
确定故障段后，再调整接口 MTU、隧道承载配置、ICMP 策略或 TCP MSS。每次只改一项，复测双向大报文与真实业务；确认稳定后记录配置和回退方式。
常见问题
清洗后只有大文件传输失败，优先查什么？
优先核对回源路径 MTU、隧道封装开销和 PMTUD 反馈，再检查 TCP MSS 是否被不一致地调整。
能否直接把所有接口 MTU 调小？
不建议。降低 MTU 可能增加分包数量，也可能影响其他流量；先定位受限链路，再按设备和路径条件调整。
IPv6 路径也能由中间路由器分片吗？
不能由 IPv6 中间路由器分片。路径受限时，源端需要依据反馈调整报文大小；因此应检查相关 ICMPv6 差错是否可达。
怎样判断排查已经完成？
在实际清洗与回源路径上，双向业务均通过大报文测试，设备不再持续丢弃相关报文，且原有故障场景复测正常，才可认为风险已得到验证。流量清洗后回源路径的MTU与分片排查，最终要以端到端证据和真实业务复测收尾。
