使用Boto上传S3本地测试异常：小文件可传大文件连接超时

兄弟，这个问题真的挺奇葩的——相同凭证、相同Dockerfile，偏偏本地大文件上传就卡壳，小文件和EB环境都完全正常。我之前碰到过类似的情况，给你梳理几个最可能的原因和排查方案：

你提到的1391字节刚好是个很关键的临界值——这通常和**MTU（最大传输单元）**有关。以太网默认MTU是1500，但Docker有些环境默认MTU会设得更低（比如1400），当文件大小加上TCP/IP头部超过MTU时，数据包需要分片传输，如果MTU不匹配，就会出现丢包、超时的情况，而小文件刚好不用分片就能顺利通过。

• 怎么排查：
  先在本地Docker容器里执行 ip addr 或者 ifconfig，查看网卡的MTU值；再对比EB实例里的MTU（EB默认一般是1500）。如果本地容器MTU比1500小，那大概率就是这个问题。
• 解决办法：
  • 临时测试：启动容器时手动指定MTU：

    docker run --mtu=1500 [你的镜像名称]
    

    再试上传大文件，要是能成功，就坐实了MTU的问题。
  • 永久修复：修改Docker守护进程配置文件（比如 /etc/docker/daemon.json），添加MTU设置：

    {
      "mtu": 1500
    }
    

    然后重启Docker服务：sudo systemctl restart docker

Boto默认会对超过一定大小的文件启用分块上传，可能本地环境的网络（比如代理）对分块传输的支持有问题，导致大文件上传超时。

• 怎么排查：
  在代码里临时禁用分块上传，强制用单请求上传大文件试试：

  import boto3
  from boto3.s3.transfer import TransferConfig
  
  s3_client = boto3.client('s3')
  # 把分块阈值设得极大，禁用分块上传
  config = TransferConfig(multipart_threshold=100 * 1024 * 1024)
  s3_client.upload_file('your_large_file.txt', 'your-bucket-name', 'remote_file_name.txt', Config=config)
  

  如果这样能成功，说明分块上传时的网络有问题。
• 解决办法：
  • 调整分块大小：把分块设小一点，比如 multipart_chunksize=1 * 1024 * 1024（1MB），避免单个分块数据包过大。
  • 检查代理：如果本地用了代理，试试关闭代理后再上传，有些代理对大分块的处理有bug。

本地的防火墙、杀毒软件可能会“误伤”Docker容器发出的大流量请求，导致上传超时。

• 怎么排查：
  临时关闭本地的防火墙、杀毒软件，再尝试上传大文件。如果能成功，就是它们在搞鬼。
• 解决办法：
  给Docker容器或者Boto的请求添加白名单，允许容器访问S3的域名（比如对应区域的s3.xxx.amazonaws.com）。

本地Docker的DNS解析如果出问题，可能小文件上传时的单次请求能正常解析，但大文件分块上传时的后续请求就会失败，导致超时。

• 怎么排查：
  在容器里执行 nslookup s3.amazonaws.com（换成你实际用的S3区域域名），看解析结果是否正常，对比EB实例的解析结果。
• 解决办法：
  修改Docker的DNS配置，在 /etc/docker/daemon.json 里添加公共DNS：

  {
    "dns": ["8.8.8.8", "8.8.4.4"]
  }
  

  重启Docker后再测试。

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