先判断 413 是谁返回的
上传图片、压缩包或备份文件时，页面突然提示 413 Request Entity Too Large，直觉上很多人会以为是网站程序坏了。实际上，413 的意思很直接：请求体太大，前面的某一层拒绝继续接收。这里的“某一层”可能是浏览器到网站之间的 Nginx，也可能是反向代理、CDN、WAF、PHP、应用框架，甚至是后端对象存储网关。
排查 413 的第一步不是马上改配置，而是先判断错误来自哪里。最简单的方法是看响应页面样式和响应头：如果页面是 Nginx 默认白底黑字，或者响应头里能看到 server: nginx，大概率是 Nginx 层直接拦截；如果页面带着网站主题样式，可能已经进入应用；如果页面像 CDN 或安全防护厂商的错误页，就要先查 CDN/WAF 的上传限制。
还可以用浏览器开发者工具观察上传请求。打开 Network 面板后重新上传，点开失败的请求，看状态码、响应体和请求大小。如果请求还没到应用接口就被拒绝，多半是入口层限制；如果接口返回 JSON 错误，则更可能是应用或 PHP 限制。
Nginx 的 client_max_body_size
Nginx 控制请求体大小的核心参数是 client_max_body_size。它可以写在 http、server 或 location 块里，作用范围从大到小覆盖。很多 413 问题就是因为默认限制偏小，用户上传稍大的图片、主题包、插件包或备份文件时直接被拦住。
常见写法如下：
client_max_body_size 50m;
如果是整站都允许较大上传，可以放在对应站点的 server 块中；如果只有某个上传接口需要放宽，建议放在特定 location 中。不要为了省事直接把全局限制改到特别大，因为这会增加被大请求拖垮的风险。
修改后需要先执行 nginx -t 检查配置语法，再执行 nginx -s reload 或通过 systemd 重载服务。只改文件不重载，线上不会生效；重载前不检查语法，可能因为一个小错误导致服务异常。
PHP 上传限制也要一起看
如果 Nginx 已经允许 50MB，但 WordPress、PHP 后台或自建程序依然提示上传失败，就要继续检查 PHP 配置。PHP 中最常见的三个参数是 upload_max_filesize、post_max_size 和 memory_limit。其中 post_max_size 应该大于或等于 upload_max_filesize，否则表单请求整体仍可能被拒绝。
例如希望允许上传 50MB 文件，可以设置为：upload_max_filesize = 50M，post_max_size = 64M，memory_limit = 128M。如果应用还要处理图片压缩、解压缩或导入数据，内存限制也要留出余量。
使用 PHP-FPM 时，修改 php.ini 后通常还要重启或重载 PHP-FPM。不同系统和不同 PHP 版本路径不一样，常见服务名可能是 php-fpm、php8.2-fpm 或面板自定义名称。排查时可以通过 phpinfo()、命令行 php --ini 或面板配置页确认实际生效的配置文件。
反向代理和 CDN 不能忽略
很多网站并不是浏览器直接访问源站 Nginx，中间还会经过 CDN、负载均衡、WAF 或另一层反向代理。只改源站 Nginx 并不能突破上游入口的限制。如果上传请求先到 CDN，而 CDN 产品本身限制单次请求体大小为 20MB，那么源站配置 100MB 也没有意义。
这类场景可以临时绕过 CDN 测试源站，或者查看 CDN 控制台的请求大小限制、缓存规则和安全规则。有些 WAF 会把大文件上传识别为异常请求，有些负载均衡也有独立的 body size 参数。排查时要画出链路：浏览器 → CDN/WAF → 负载均衡 → Nginx → PHP/应用 → 存储。哪一层有上限，最终都可能表现为上传失败。
如果业务经常需要上传大文件，更推荐把大文件上传和普通页面访问分开处理。例如普通网站入口保持较小限制，大文件上传走专门接口、对象存储直传或分片上传。这样既能满足业务需求，也不会让所有页面都暴露在超大请求压力下。
日志里应该看什么
Nginx 拦截大请求时，错误日志中通常能看到类似 client intended to send too large body 的记录。它会告诉你客户端准备发送的 body 大小，以及当前配置允许的上限。这个日志比盲目猜配置可靠得多。
如果 Nginx 日志没有相关记录，就继续看 PHP-FPM 日志、应用日志和 CDN/WAF 日志。WordPress 场景还可以检查媒体库上传错误、PHP 错误日志和安全插件拦截记录。对于自研接口，则要看接口网关和应用框架是否有独立的请求大小限制。
线上排障时建议记录三组信息：失败文件大小、失败接口路径、失败发生在哪一层。只要把这三点确认清楚，413 问题通常很快就能定位。
安全放宽限制的建议
上传限制不是越大越好。过大的请求体会占用连接、内存、临时文件和磁盘 IO，在高并发或恶意请求下可能成为 DoS 风险。对普通企业官网来说，图片上传限制 10MB 到 30MB 已经够用；如果是备份包、视频或数据导入，则应当单独设计上传通道。
更稳妥的做法是按业务分层设置：普通页面保持较小限制；后台上传适当放宽；大文件走分片上传或对象存储直传；上传目录设置类型校验、大小校验和权限隔离。这样既不影响正常使用，也能降低安全风险。
如果网站部署在云服务器上，还要关注带宽、磁盘和备份策略。上传大文件会快速消耗流量和存储空间，日志与临时文件也可能占满磁盘。使用 速维云服务器 这类云服务器方案时，可以结合业务体量选择合适的带宽、磁盘和地区节点；如果只是普通企业官网，不必一开始就把上传限制和资源规格拉得过高。
一套实用排查顺序
遇到 413，可以按这个顺序处理：先用浏览器开发者工具确认失败请求和响应来源；再查 Nginx 错误日志是否出现 too large body；随后检查 client_max_body_size 的实际作用位置；接着确认 PHP 的 upload_max_filesize、post_max_size 和运行环境是否已重载；最后检查 CDN、WAF、负载均衡和应用框架限制。
如果修改后仍然不生效，重点看“改的是不是当前站点配置”“有没有重载正确服务”“是否还有更前置的一层代理”。很多问题不是参数没用，而是改错了文件、改到了另一个 PHP 版本，或者入口请求根本没有到达源站。
总结一下，413 不是复杂故障，它只是提醒你上传链路里有一层认为请求太大。按入口层、Web 服务、运行环境、应用程序、存储链路逐层核对，就能避免在一个参数上反复试错。
