上传被截断却返回 200

Caddy 已设置 request_body max_size，超限上传却返回 200，上游只收到一段缩短后的正文。使用 Caddy 2.11.7 且启用了 request_buffers unlimited 时，要检查无限缓冲是否吞掉了正文读取错误。

长度被改成截断后的大小

该版本的无限缓冲分支读取正文时忽略了 io.Copy 的错误。即使大小限制已经终止读取，它也把已读部分视为完整正文，关闭原始流，再把请求的 Content-Length 改成这部分的长度。上游因而可能正常接收一个更短的请求，并返回成功。

这与上游本来允许小文件不同。对照客户端发送字节数、上游读取字节数及收到的长度头，同时确认命中了哪一条代理路由。只有一个 200 状态码，不能证明原上传完整。

去掉无限缓冲

上游不需要完整缓冲时，移除 request_buffers unlimited，保留原正文大小限制和读取超时。确实需要缓冲时，可按上游要求和并发内存预算改成有限值，例如已有代理块中的片段：

reverse_proxy 127.0.0.1:8080 {
    request_buffers 1MB
}

上游地址与数值需要使用项目的实际配置。有限缓冲在遇到非 EOF 读取错误时保留原流，让错误继续传递；1MB 是缓冲范围，不是上传大小限制，更不是所有请求合计的内存预算。

不要通过删除 max_size 或增加业务允许的上传大小来让报错消失。缓冲方式的变化还会影响上游开始收到正文的时机，处理前需要确认它能接受相应转发方式。

响应缓冲也要单独核对

response_buffers unlimited 使用同一条读取路径。上游的 chunked 响应提前结束时，也可能把已读数据交给客户端，看起来像一次正常完成的响应。若启用了这个选项，同样检查是否有必要保留无限缓冲。

这里的验收不只看响应状态。头部已经发出后，错误可能体现为传输中断，而不是改成另一个 HTTP 状态；客户端必须把不完整响应判为失败。

修复已在 2026 年 10 月 13 日合并，但核对的正式 2.11.7 仍有旧分支。等待正式修复时，先在隔离接口比较正常上传、超限上传及截断响应。确认上游没有再把裁短的请求当成完整内容；已接收过的业务写入需要按自身完整性规则检查，不能直接重放所有上传。