未接收ICMP PTB消息致AWS S3上传失败的可能原因咨询

问题场景 #

向AWS S3上传客户文件失败，故障持续约10分钟后自行恢复。排查发现：

• 执行命令 sudo ping -D -s 1000 xxxxx.com 返回错误：

  $ ping -D -s 1000  xxxxx.com
  PING xxxxx.com (39.156.66.10): 1000 data bytes
  ping: sendto: Message too long
  

• 使用 -s 500 参数时ping正常：

  $ ping -D -s 500  xxxxx.com
  PING xxxxx.com (39.156.66.10): 500 data bytes
  508 bytes from 39.156.66.10: icmp_seq=0 ttl=64 time=0.377 ms
  508 bytes from 39.156.66.10: icmp_seq=1 ttl=64 time=0.664 ms
  

原本推测故障源于网络路径MTU配置过小，但按TCP/IP协议逻辑，MTU变小时应收到ICMP type=3、code=4的PTB（Packet Too Big）消息，TCP会自动调整数据包大小保证传输。有人提出是负载均衡器丢弃ICMP消息，但该说法存疑，现梳理可能的故障原因如下：

可能的故障原因 #

• 中间设备临时MTU调整且未发送PTB：网络路径中的运营商路由器、AWS内部转发节点等设备临时调整了MTU值，但因配置错误、临时负载过高或设备本身不支持，未正确发送ICMP PTB消息。当设备恢复原MTU配置后，故障自动消失，匹配10分钟后自愈的特征。
• TCP PMTUd机制失效：本地主机的路径MTU发现（PMTUd）机制异常，比如PMTUd缓存过期时间配置不合理、缓存被异常清空，或者本地防火墙误拦截了PTB消息，导致TCP无法触发MSS调整，无法适配路径MTU变化。
• S3端点/边缘节点临时故障：S3的区域接入节点或边缘层（如CloudFront作为前端时）出现临时MTU相关配置异常，无法处理大包传输。这类AWS内部服务异常通常会在短时间内自动恢复，符合故障时长特征。
• 中间设备临时大包限流：网络中的防火墙、QoS设备因流量突增触发大包丢包的限流策略，直接丢弃大包而非返回PTB消息。当流量回落或策略自动重置后，传输恢复正常。
• 负载均衡器临时资源耗尽：若上传路径经过ALB/NLB，负载均衡器可能因连接数过载、CPU/内存耗尽，无法处理大包转发，也无能力生成PTB消息。当负载均衡器资源恢复后，故障消失——这并非主动丢弃ICMP，而是服务异常的连带结果。

内容的提问来源于stack exchange，提问作者yaodongen