网站出现413错误怎么办？请求体大小限制与上传配置详解

浏览器提交表单或上传文件时，页面直接弹出 413 Request Entity Too Large，或者接口返回 413 Payload Too Large，后台日志却干干净净什么都没有——这是很多站长和运维会碰上的一类问题。413 的含义其实很明确：服务器认为你发来的请求体太大了，直接拒绝接收。关键在于，返回它的可能是 Nginx、Apache、IIS、Tomcat、Node、CDN 或 WAF 中的任何一环，每一环都有自己的大小上限，改错地方自然无效。

这篇文章专门围绕 413 展开：先讲清这个状态码的准确定义和它到底由谁返回，再按不同技术栈（Nginx、Apache、IIS、Tomcat、Node、以及 Spring/Express/.NET 等应用框架）给出真实的配置位置和改法，然后讲 CDN/WAF 这类容易被忽略的外围层，最后教你如何判断"413 到底是谁发的"。读完你能根据响应的特征快速锁定是哪一层在拦，并按业务量级把上限设对。

先说结论：413 是"请求体超限"，不是"响应太大"，也不是网络问题。它多半发生在请求还没进业务逻辑之前，所以后端日志里看不到——这正是它让人困惑的原因。

一、413 的准确含义

HTTP 状态码 413（旧称 Request Entity Too Large，新称 Payload Too Large）的定义是：服务器拒绝处理当前请求，因为请求的载荷（body）超过了服务器愿意或能够处理的大小。

要理解它，得区分几个容易混淆的概念：

• 请求体（body）：POST/PUT 携带的数据，包括文件。413 说的是它太大。
• 响应体：服务器返回的内容。响应太大是另一回事，不叫 413。
• 请求头（header）：头部过大对应的是 431（Request Header Fields Too Large），跟 413 不是一回事。

所以遇到 413，第一反应应该是"我这次请求发了多大的 body"，而不是去查网络或后端逻辑。

二、413 通常由谁返回

这是排查 413 的核心。请求穿过一条链路，链路上任何一层都可能因为体积限制先返回 413：

浏览器 → CDN/WAF → 负载均衡 → Nginx/Apache/IIS → 应用服务器(Tomcat/Node/...) → 框架
         每一层都可能返回 413 ↑

判断技巧：看响应头里的 Server、CDN 特征头，以及源站日志有没有对应记录。如果源站 Nginx 日志里根本没这条请求，那 413 就是它前面的 CDN/WAF/负载均衡发的。

三、Nginx 侧：client_max_body_size

Nginx 是最常见的 413 来源。它用 client_max_body_size 限制请求体大小，默认约 1MB。

# 可以放在 http / server / location 任一层，就近覆盖
server {
    listen 80;
    server_name www.example.com;

    # 允许最大 100MB
    client_max_body_size 100m;

    location /api/upload {
        client_max_body_size 100m;          # 也可只对上传接口放宽
        proxy_pass http://127.0.0.1:8080;

        # 大文件上传时同步放宽超时
        client_body_timeout 300s;
        proxy_read_timeout 300s;

        # 直传后端，避免先缓存整个文件到本地磁盘
        proxy_request_buffering off;
    }
}

要点：

• 支持单位后缀：k、m、g（如 100m、2g）。
• 超限时 Nginx 返回 413 且不转发给后端，所以后端无日志。
• 具体在哪一层生效，可以用 nginx -T | grep client_max_body_size 确认。

改完的标准动作：

nginx -t && nginx -s reload

定位 Nginx 413 的证据在错误日志：

grep -i 'too large\|413' /var/log/nginx/error.log | tail
# 典型记录：
# client intended to send too large body: 52428800 bytes

这行会给出发送的实际字节数，对照配置值即可判断需要调到多大。

四、Apache / IIS / Tomcat 等其他栈

不是所有环境都用 Nginx，换一套栈配置位置和参数名就完全不同。

Apache（httpd）

LimitRequestBody（单位是字节）默认 0 表示不限制，但很多发行版默认包会限制。

# /etc/httpd/conf/httpd.conf 或虚拟主机配置

    # 允许 100MB（104857600 字节）
    LimitRequestBody 104857600

# RHEL/CentOS/Rocky
sudo systemctl restart httpd
# Debian/Ubuntu
sudo systemctl restart apache2

IIS（Windows）

默认 maxAllowedContentLength 约为 30MB（30000000 字节）。

IIS 返回的 413 常带较长的 HTML 页面和 IIS 头，看到 Server: Microsoft-IIS 基本可确认。

Tomcat

Tomcat 有两个相关参数：maxPostSize（表单 POST 大小）和 maxSwallowSize（连接器吞掉未读请求体的上限）。

           maxSwallowSize="104857600" />

改完重启 Tomcat 生效。

五、应用框架层的 413

即使 Nginx 放行了，后端框架仍可能再拦一次。

Spring Boot：

spring:
  servlet:
    multipart:
      max-file-size: 100MB
      max-request-size: 100MB

超限时抛 MaxUploadSizeExceededException，应用日志可见；务必也让全局异常处理返回清晰的错误，而不是 500。

Express（Node.js）：

const express = require('express');
const app = express();
// body-parser 默认 limit 100kb，很小
app.use(express.json({ limit: '100mb' }));
app.use(express.urlencoded({ limit: '100mb', extended: true }));

Express 超限会抛 PayloadTooLargeError，默认也返回 413。

ASP.NET Core：

builder.WebHost.ConfigureKestrel(o => {
    o.Limits.MaxRequestBodySize = 104_857_600; // 100MB
});
builder.Services.Configure(o => {
    o.MultipartBodyLengthLimit = 104_857_600;
});

要点：应用框架的 413 通常会留下异常日志，而 Nginx 的 413 不会。用"后端有没有日志"可以区分是 Nginx 拦的还是应用拦的。

六、容易被忽略的 CDN / WAF / 负载均衡

如果源站日志里找不到这条请求，但客户端明明收到 413，那问题就在源站之前。常见情况：

• CDN 边缘节点对请求体有上限（不同厂商、不同套餐值不同，读写请求限制往往不一样），超过就由边缘直接拒。
• WAF 常对请求体大小、单请求体积设策略，超限返回 413 或自有错误码。
• 云负载均衡也可能有请求体转发上限。

这类问题没法靠改源站解决，需要去对应控制台调整策略或改用分片上传绕过单请求体积限制。判断方法：对比"直连源站 IP"和"走 CDN 域名"的表现。

# 直连源站测试（绕过 CDN/WAF）
curl -v -X POST --data-binary @small.bin http://源站IP/upload -H 'Host: www.example.com'
# 对比走域名
curl -v -X POST --data-binary @small.bin https://www.example.com/upload

如果直连正常、走域名 413，基本锁定是 CDN/WAF 层。

七、确认 413 到底是谁发的

一套可复用的判断流程：

# 1) 加大 body 复现，看客户端收到的响应头
curl -v -X POST --data-binary @test_10m.bin https://www.example.com/upload
# 关注响应里的 Server 头，是 nginx 还是其他

# 2) 同时看源站 Nginx 访问日志/错误日志有没有这条请求
tail -f /var/log/nginx/access.log
grep -i 'too large' /var/log/nginx/error.log

# 3) 看后端应用日志有没有超限异常
journalctl -u myapp -n 50 --no-pager | grep -i 'too large\|MaxUpload'

结论对照：

八、上限设多少合适

把 client_max_body_size 设成 0（不限）看似省事，实则危险：任意大请求都能打进来，容易被占满带宽、写满临时磁盘、变相 DoS。合理做法是按业务场景设一个刚好够用的值。

经验建议：单请求上限一般不超过几百 MB；超过这个量级就应改成分片上传，把每层的 client_max_body_size 保持在能容纳单片的水平（如 10MB），既安全又便于重试。

风险提示：调整 Nginx、防火墙或临时目录相关配置前先备份；client_body_temp_path 所在分区要预留足够空间，设置上限过大时一旦被异常请求占满磁盘，可能连带影响其他服务。误改配置可用备份还原并 nginx -t && nginx -s reload 恢复。

常见问题

Q：413 和 431 有什么区别？
413 是请求体（body）太大，常见于上传文件；431 是请求头（header）太大，常见于 Cookie 过多或 header 超长。两者限制的参数、配置位置都不同，别混。

Q：Nginx 里 client_max_body_size 设了还是 413，怎么回事？
三查：一查改的是不是生效配置（nginx -T 看最终值）；二查是否有更内层 location 的小值覆盖了外层（就近覆盖原则）；三查 413 是不是源站前面的 CDN/WAF 发的——直连源站 IP 试一下就知道了。

Q：为什么后端日志里没有 413 相关记录？
因为 Nginx 在收到请求头阶段就判断 body 超限并直接拒绝，不会转发给后端，所以后端无感知。这正是"Nginx 型 413"的典型特征。

Q：把上限设很大一定好吗？
不好。上限越大，被大请求拖垮的风险越高，临时磁盘、内存、带宽压力都增加。应按业务设合理值，超大文件走分片上传，并对上传接口单独放宽、其余接口保持小值。

Q：走 CDN 时 413，但源站没问题，怎么处理？
这是 CDN 边缘节点的请求体限制。要么在 CDN 控制台调大（若支持），要么改用分片上传，让单次请求体积变小。也可以让上传流量走不经 CDN 的域名直连源站。

总结

413 的本质是"请求体超过某一层的上限"，返回它的可能是 Nginx、Apache、IIS、Tomcat、Node、框架，也可能是源站前面的 CDN/WAF。

排查的第一步是确定是谁发的：看响应 Server 头、看源站访问/错误日志有没有这条请求、看后端有没有超限异常日志——三者结合就能锁定层次。

Nginx 场景最常改的是 client_max_body_size，注意它就近覆盖、支持单位后缀，且超限时不会转发到后端；其他栈分别对应 LimitRequestBody、maxAllowedContentLength、maxPostSize 和框架的 multipart 配置。

上限要按业务量级设合理值（表单 1～2MB、图片 10～20MB、文档 50～100MB），不要一律设 0；几百 MB 以上优先分片上传。

改配置的固定流程不变：改前备份、改后 nginx -t、用 reload 生效、保留回滚路径。