Traefik 放大 proxy-body-size 后，超过 2 MiB 仍返回 413

Traefik 使用 kubernetesIngressNGINX 兼容 provider，Ingress 的 proxy-body-size 已经足够大，动态 Buffering 配置也显示了新上限，但请求体一超过 2,097,152 字节，仍返回 413 Request body too large。如果还启用了针对 HTTP 状态码的多次重试，要同时检查自动生成的 Retry 配置。

这个特定问题在 Traefik 3.7.1、3.7.5 的兼容 provider 路径中出现过：Buffering 接受较大的请求体，Retry 却仍采用旧的 2 MiB 上限。它不适用于所有 Traefik 413，也不能套用到运行 NGINX 入口控制器的部署。

同一个请求，需要检查两个上限

HTTP 状态码重试发生在后端已经返回响应之后。为了再次发送同一个请求，Retry 需要保存可重用的请求体；这项保存操作也有体积检查。Buffering 上限提高，并不自动证明旧版本的 Retry 上限跟着提高了。

先从实际运行实例确认 Traefik 版本、启用的 provider、失败请求命中的 router，以及该 router 引用的中间件。通过现有受保护的管理接口检查 Buffering 与 Retry，不要为排查临时把 dashboard 或 API 公开。

Ingress 中可重点核对这些已有注解，下面是结构示例，64m 应按业务容量确定，并合并到原声明中：

metadata:
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "64m"
    nginx.ingress.kubernetes.io/proxy-request-buffering: "on"
    nginx.ingress.kubernetes.io/proxy-next-upstream: "error timeout http_502 http_503"

还要看 provider 默认值、proxy-next-upstream-tries 和实际后端数量共同生成的重试次数。该路径中的次数 0 会映射到可用后端数量，不能直接理解成只试一次。真正生效为一次尝试时，3.7.5 的 Retry 会直接交给后续处理，不经过这里的请求体保存分支。

因此，需要多次尝试、包含 http_* 状态条件，以及旧的 Retry 请求体上限等条件一起成立，才符合这条故障路径。只有 proxy-body-size 和 413 两个现象，还不足以定因。也不要用未经核对的中间件执行顺序解释错误：两个独立的上限已经能说明为何较大的 Buffering 配置没有消除拒绝。

优先更新包含修复的正式版本

Traefik 3.7.6 已包含这项修复：兼容 provider 构建 Retry 时，会将解析后的请求体上限传入 Retry。准备升级时应选择与现有 Kubernetes、Helm chart、CRD 和其他 provider 配置兼容、仍受维护的正式版本，并确认它包含该修复；3.7.6 是修复边界，不是所有部署今天都应安装的目标版本。

保存当前镜像版本和部署值、Ingress 声明及生成配置，先在可隔离的环境验证迁移和回退。升级后重新检查运行版本以及最终的 Retry 上限，不能只凭镜像标签或 Helm 操作成功判断所有实例已经更新。

保留有业务和并发容量依据的有限上限。把 proxy-body-size 设为 0，或关闭请求缓冲，会改变限制和重试语义，不是修复这项旧配置遗漏的通用办法。

临时减少重试条件，会改变失败处理

暂时无法升级时，在确认正是这条路径后，可以评估去掉 http_502、http_503 等状态码重试条件，只保留实际需要的网络错误条件。这样会改变后端返回这些状态码时的行为，应经过业务判断，并从原部署入口修改。

不要把这种变更描述成“保留原来的全部重试功能”。对于有写入副作用的请求，还要确认重复发送的幂等和去重设计。修复后的版本中，关闭请求缓冲也有专门的请求体重试限制，并不等于无限上传且照常重试。

复测时保留原来的上传方式

使用无敏感内容、不会覆盖业务文件的测试请求，比较 2 MiB 附近、原先失败的大小以及业务允许上限内的请求。核对真正的请求体字节数，而不是只看文件总大小；分块上传可能让一个文件对应多个较小请求。

验证返回状态、最终文件或业务结果、校验和以及小请求是否正常，还要检查后端错误时的重试次数是否符合配置。如果仍是 413，继续定位拒绝请求的实例与层级，不要不断提高上限。入口、上游代理或后端应用的其他限制，可以另外参照上传路径的 413 定位。

出现路由或重试副作用时，按保留的部署版本和配置回退，再核对所有正式实例。回退到受影响版本也可能恢复旧的 2 MiB 拒绝，测试结论需要连同版本一起保留。