Nginx提示413 Request Entity Too Large怎么办？

在WordPress上传主题、提交备份、调用API或上传大文件时，页面突然返回 413 Request Entity Too Large。这表示请求体超过了某一层允许的大小，不代表VPS磁盘空间不足。

最常见的限制来自Nginx的 client_max_body_size，但使用PHP、CDN、面板或多层反向代理时，前后每一层都可能有自己的上限。本文按请求经过的顺序排查，避免改了配置却一直不生效。

一、413错误到底限制了什么

Nginx官方文档中，client_max_body_size 用于限制客户端请求体大小，默认值是 1m。请求超过配置值时，Nginx会返回413。

请求体不只包含浏览器上传的文件，也可能是API提交的JSON、表单、网站备份和反向代理转发的数据。磁盘还有大量空间，照样可能因为请求入口限制而失败。

二、先确认413是由哪一层返回

查看浏览器开发者工具中的响应头，再检查Nginx错误日志：

sudo tail -n 100 /var/log/nginx/error.log
sudo nginx -T | grep -n client_max_body_size

日志出现 client intended to send too large body 时，基本可以确认当前Nginx拦截了请求。若Nginx日志没有对应记录，应继续检查CDN、WAF、负载均衡、面板代理或上游应用。

有多层Nginx时，外层限制为10MB、内层限制为100MB，实际仍只能上传10MB。整条链路中最小的上限决定最终结果。

三、Nginx应该在哪里修改

该指令可放在 http、server 或 location 中。只想调整某个网站时，更建议放在对应的 server 块：

server {
    server_name example.com;
    client_max_body_size 100m;
}

只允许某个上传接口接收大文件，也可以放在特定 location。配置越靠近具体业务，影响范围越小。

不建议随手设置为 0。虽然它会关闭Nginx的请求体大小检查，但大文件或恶意请求仍会消耗带宽、临时磁盘和上游资源。

四、修改后为什么没有生效

先测试语法，再平滑加载：

sudo nginx -t
sudo systemctl reload nginx

然后用 nginx -T 查看Nginx真正加载的完整配置。常见问题是改错虚拟主机文件、同一域名匹配到另一个 server、面板自动生成的配置覆盖修改，或服务器同时安装了系统Nginx与容器Nginx。

仅重启PHP-FPM不会让Nginx配置生效；只修改WordPress后台上传限制，也无法绕过Nginx入口的413。

五、PHP和WordPress还要改哪些限制

请求通过Nginx后，PHP还会检查 upload_max_filesize 和 post_max_size。常见配置如下：

upload_max_filesize = 100M
post_max_size = 110M
max_execution_time = 300
max_input_time = 300

post_max_size 应略高于实际上传文件大小，因为请求还包含其他表单数据。修改后要重启对应版本的PHP-FPM，并通过 phpinfo() 或 php -i 确认生效文件，避免改到CLI使用的另一份 php.ini。

WordPress多站点、导入插件和备份插件还可能有自身限制。页面显示的最大上传大小，往往是多层配置共同计算后的结果。

六、有CDN或反向代理时怎么查

先临时通过源站地址或仅本地访问测试，但不要让源站长期暴露。源站直连可以上传、经过CDN就失败，说明上游平台可能限制单次请求大小。

反向代理链路还应检查网关、Ingress、面板和容器配置。Kubernetes Nginx Ingress、OpenResty和不同云厂商网关的配置方式并不完全相同，不能把原生Nginx指令直接套到所有环境。

平台硬性上限无法通过修改源站Nginx突破。大文件业务可考虑分片上传、对象存储直传或使用平台支持的专用上传方式。

七、上传限制设置多大比较合适

配置值应覆盖实际业务文件，并留出少量余量，不必无限放大：

上限提高后还要关注 client_body_timeout、临时目录空间、PHP执行时间和上游超时。一个500MB文件能进入Nginx，不代表应用能在规定时间内处理完成。

八、怎样避免放大安全和资源风险

只对确有需求的域名或上传路径提高限制，并配合登录鉴权、文件类型校验、速率限制和病毒扫描。公开接口不应允许匿名用户无限上传大文件。

上传目录不要赋予不必要的执行权限，应用也不能只依靠文件扩展名判断类型。定期清理失败上传产生的临时文件，避免413解决以后又遇到磁盘空间被临时文件占满。

常见问题

问：413代表服务器磁盘满了吗？
答：不是，它表示请求体超过某一层配置的大小限制。

问：client_max_body_size默认是多少？
答：原生Nginx官方文档给出的默认值是1m。

问：设置为0可以彻底解决吗？
答：0会关闭Nginx这一层的大小检查，但不建议无限制开放，其他层也可能继续限制。

问：改完配置需要重启服务器吗？
答：不需要，先执行nginx -t，通过后reload Nginx即可。

问：Nginx改成100M为什么WordPress仍不能上传？
答：继续检查PHP、WordPress插件、CDN和其他反向代理层的上限。

温馨提示

处理413最省时间的方法，是先确认报错来自哪一层，再从外到内逐层核对。不要一开始就把所有限制调到无限大；刚好覆盖业务需求，并保留鉴权和资源保护，长期更稳。