S3兼容对象存储通过代理时，小文件PUT成功，大文件却频繁失败，往往不是“带宽不够”一个原因。大文件通常使用Multipart Upload：先创建上传任务，再并发上传多个分片，最后提交分片清单。代理连接池、超时、请求头改写和重试都会参与其中。
一、先分清上传方式
| 方式 | 请求特征 | 重点检查 |
|---|---|---|
| 普通PUT | 单个请求上传对象 | 总超时、大小限制、校验 |
| 预签名URL | URL包含签名参数和有效期 | Host、路径、查询参数、时间 |
| Multipart Upload | 创建、分片、完成多个请求 | 并发、Upload ID、Part Number、ETag |
| SDK流式上传 | 可能自动分片和重试 | SDK版本、阈值、连接池与重试 |
二、预签名URL为什么怕改写
签名通常与HTTP方法、对象路径、主机、有效期、查询参数及部分请求头相关。代理若重写Host、规范化路径、丢失查询参数，或客户端添加了未按预期签名的头部，都可能导致签名不匹配。排查时应比较签名生成端与实际发送请求的规范化信息，但不要把完整预签名URL贴到公开日志。
三、系统时间会影响签名吗
会。预签名URL有明确有效期，部分签名验证也会检查请求时间窗口。签名机器、客户端和对象存储的时间偏差过大，可能出现尚未生效或已经过期的判断。时间同步属于基础检查，不能通过无限延长有效期代替。
四、分片上传为什么更容易暴露代理问题
分片会提高并发连接或HTTP流数量，放大代理连接上限、NAT端口、带宽整形和尾延迟问题。某个分片超时后，SDK可能自动重试；若客户端没有记录Upload ID、Part Number和ETag，就难以判断服务端是否已收到该分片。
容量规划可参考代理带宽、并发与连接数评估。
五、Expect: 100-continue会造成什么现象
部分HTTP客户端在发送较大请求体前使用Expect: 100-continue，等待服务器确认。代理、网关或对象存储若对该流程处理不一致，可能出现发送前等待或超时。应抓取授权测试环境中的时间线，确认是等待100响应、上传请求体，还是等待最终响应。
六、502或超时后如何安全重试
客户端没收到成功响应，不等于服务端没写入分片。Multipart Upload应保留Upload ID和Part Number，通过列出已上传分片或SDK状态恢复，再决定重试。最终完成请求要提交正确的分片清单。对普通PUT，也应结合对象元数据、版本和校验判断结果。
重试语义可参考超时、幂等键与安全恢复。
七、校验值为什么不能只看ETag
在部分S3兼容实现和分片上传中，ETag不一定等同于整个对象的单一MD5。应根据服务端和SDK支持，使用明确的校验算法、对象大小及业务侧哈希进行验证。不要仅因HTTP返回成功就跳过完整性检查。
八、代理切换后旧上传会怎样
SDK连接池可能继续使用旧代理连接，进行中的Multipart Upload也保留原Upload ID。切换节点时应停止创建新分片、等待或取消在途请求，建立新客户端和连接池，再按状态恢复。直接在共享客户端中修改代理可能导致同一次上传跨越不清晰的网络状态。
九、DNS和虚拟主机风格的影响
S3兼容服务可能使用虚拟主机风格或路径风格访问。前者会把Bucket名称放入主机名，影响DNS、证书和签名。自建对象存储、私有域名或带点的Bucket名称还需检查证书通配范围。代理是否在本地或上游解析域名，也会改变排查位置。
十、日志至少需要哪些字段
- 请求阶段、目标主机和对象键的脱敏标识；
- Upload ID、Part Number和请求ID；
- 连接、首字节、上传和总耗时；
- 代理状态码与对象存储错误码；
- 分片大小、并发数、重试次数和校验结果；
- SDK、代理节点和配置版本。
不要记录完整预签名URL、访问密钥、会话令牌或敏感对象名。
十一、最小测试流程
- 用小文件分别测试直连和代理PUT；
- 测试短有效期的授权预签名URL；
- 逐步增加文件大小和分片并发；
- 模拟单个分片超时并验证恢复；
- 切换代理后重建客户端连接池；
- 校验对象大小、内容哈希和元数据；
- 中止测试产生的未完成Multipart Upload。
十二、结论
S3代理上传要同时看签名、请求头、连接池和分片状态。用小文件验证网络只是第一步；只有覆盖分片重试、完整性校验和中止清理，才能说明真实大文件流程可靠。
