网站能打开，大文件却上传失败？从 HTTP 413 理清上传限制

网站能打开，大文件却上传失败？从 HTTP 413 理清上传限制

 摘要：网页访问正常，不代表文件上传链路没有限制。遇到 HTTP 413 时，关键不是盲目增加超时时间，而是找出哪一层拒绝了请求，并区分请求体大小、上传缓冲与应用限制。

一、413 不等于网络超时

上传文件时，如果服务器返回 HTTP 413，通常表示请求内容超过了接收方允许的大小。

这与“网速慢”“连接超时”不是一类问题。只增加超时时间，不能解决明确的大小限制。

浏览器有时只显示“上传失败”，因此应先在开发者工具的网络面板中查看上传请求的状态码和响应内容，而不是仅凭页面提示判断。

二、一次上传可能经过多层限制

常见上传链路可以简化为：

浏览器 → CDN 或网关 → 反向代理 → 应用服务


各层都可能限制请求大小。修改应用配置，不能绕过前置网关；只修改反向代理，也不能替代应用自身的校验。

另外，限制对象不一定是“单个文件”。以常见的 multipart/form-data 上传为例，请求体除文件内容外，还包含表单字段和分隔信息。如果一次请求包含多个文件，请求体通常还包含它们的合计内容。

因此，文件大小刚好等于请求体上限时，也可能上传失败。分片上传则应分别检查单次请求限制和应用的完整文件限制。

三、以 Nginx 为例：先看请求体上限

Nginx 使用 client_max_body_size 限制客户端请求体大小。官方文档列出的默认值为 1m；请求超过配置值时，会返回 413。

该指令可以放在 http、server 或 location 中。排查时必须核对请求实际匹配的配置，不能只搜索到某一行就认为它一定生效。

下面是一个独立教学用 HTTP 反向代理 server 块，应放入 Nginx 的 http 上下文中。假设后端应用监听本机回环地址的 8000 端口，且允许对应上传请求：

server {
    listen 80;
    server_name example.com;

    client_max_body_size 20m;

    location / {
        proxy_pass http://127.0.0.1:8000;
        proxy_set_header Host $host;
    }
}


这里的 20m 是示例请求体上限，不是适合所有业务的推荐值，也不代表单个文件必然可以达到这个大小。示例未配置 HTTPS，不应直接作为生产站点的完整部署方案。

修改已有站点时，应在对应配置中调整，避免直接新增重复站点。常规安装中可先检查语法，再重新加载：

sudo nginx -t && sudo nginx -s reload


以上为依据官方文档编写的教学示例，未在特定部署环境执行验证。

四、关闭缓冲，不等于取消上传限制

proxy_request_buffering 控制的是请求体如何转交给后端。

默认启用时，Nginx 先读取完整请求体，再向后端发送请求；关闭后，则可以边接收边向后端发送，但还需注意协议相关条件。

它与 client_max_body_size 解决的是不同问题：

- 请求体上限： 这个请求允许有多大。
- 请求缓冲： 收到的数据什么时候转交后端。

所以，不能把关闭请求缓冲当成解决 413 的通用办法。关闭缓冲后，若 Nginx 已开始向后端发送请求体，还会影响将请求切换到其他后端重试的能力。

同样，不建议为了省事把请求体上限设为 0。在 Nginx 中，这会禁用该大小检查，而不是自动获得安全、可靠的大文件上传能力。

五、如何确认真正修好了

建议用测试文件进行边界验证：

- 明显低于限制的文件，应能正常完成上传。
- 接近限制的文件，要考虑表单额外开销。
- 超过限制的请求，应被明确拒绝，而不是无限等待。
- 上传成功后，还应确认应用中能找到文件，且内容完整。

同时对照反向代理与应用日志，确认请求在哪一层被拒绝。仅凭响应头中的服务器名称，不能可靠断定错误一定由哪一层生成。

小结

排查大文件上传失败，要先确认状态码，再沿上传链路定位限制。

请求体上限、请求缓冲、超时时间和应用校验是不同机制，不能用一个参数代替所有检查。

参考资料

本文依据 Nginx 官方文档编写，相关条目如下：

- ngx_http_core_module：client_max_body_size
- ngx_http_proxy_module：proxy_request_buffering

可在 Nginx 官方文档中搜索上述指令名称，查阅完整说明。
`