直接答案：413 表示请求体超过接收方允许大小，但接收方可能是 CDN、Nginx、上游代理、PHP/应用框架或业务接口。先比较响应头、错误页和各层日志，确认哪一层生成 413，再把 client_max_body_size、PHP 的 post_max_size/upload_max_filesize、应用限制和边缘套餐上限按业务目标协调。不要把所有限制直接改成无限；更大的请求还会占用临时磁盘、连接时间、内存和后端处理能力。
本文适用于表单、文件、备份包或 API 上传出现 413。若上传中途断开并记录 499/504，或应用返回自己的 JSON 业务错误，应同时检查超时、客户端取消和应用校验，不能只看浏览器文字。
本文按 2026 年 9 月可查的官方文档核对。示例命令以只读取证为主；凡涉及删除、覆盖、重启、权限、网络或数据库参数的动作，都应先确认操作对象、备份、维护窗口和带外恢复入口。不同发行版与软件版本的路径可能不同，必须先查询实际配置再改。
先用证据判断故障在哪一层
| 现象或检查点 | 它能说明什么 | 直接证据 | 不要误判为 |
|---|---|---|---|
| 源站日志没有请求 | 413 可能在 CDN/WAF/上游代理产生 | 边缘响应头与安全事件 | Nginx 限制 |
| Nginx error log 写 client intended to send too large body | 命中 client_max_body_size | 错误时间、server/location 与请求大小 | PHP 限制 |
| Nginx 接收后 PHP 无文件 | PHP post/upload 限制或临时目录失败 | phpinfo配置与 PHP 日志 | 网络丢包 |
| 小文件成功、大文件应用JSON失败 | 业务层类型、配额或分片限制 | 应用日志和接口文档 | HTTP 413一定来自Nginx |
| 修改后仍413 | 配置层级、容器或 reload 未生效 | nginx -T 与进程配置 | 浏览器缓存 |
这张表的用法不是“看到一个关键词就改一个参数”，而是把客户端、DNS或边缘、Web 代理、应用、数据层依次分开。至少保留故障时间、完整 URL、状态码、关键响应头、同一时刻的服务日志和一份正常样本。只有时间能够对齐，才能判断两个现象是否属于同一次故障。
六步排查与修复顺序
1. 用两个可控大小样本复现
准备一个明确成功和一个明确失败的测试文件，记录字节数、接口、方法、Content-Length、用户身份和时间。不要拿唯一生产备份反复上传，也不要用含敏感数据的文件做公开测试。
2. 确定 413 由哪一层返回
比较 Server、CF-Ray 等响应头、错误页格式、CDN事件、Nginx access/error log 和应用日志。源站完全没有对应请求时，应先查边缘；Nginx 日志已有请求而应用无记录时，重点查代理层。
3. 读取实际 Nginx 配置层级
用 nginx -T 搜索 client_max_body_size，确认命中的 http、server 或 location。更具体的上下文可能覆盖全局值；面板生成的多个配置文件也可能让你改了未加载的副本。
4. 核对运行时与应用限制
PHP 要同时考虑 post_max_size、upload_max_filesize、临时目录和执行/输入时间；其他框架也有 multipart、反序列化或网关限制。业务还需校验扩展名、MIME、权限和账号配额。
5. 计算资源与安全边界
把目标最大文件、并发上传数、临时磁盘、带宽和超时放在同一预算中。大文件更适合分片、断点续传或直接上传对象存储，而不是让 Web/PHP 进程长期占用连接。
6. 最小调整并做边界验收
备份配置后只调整负责层，语法检查并平滑 reload。分别测试略低于、等于和略高于上限的文件，确认成功路径、拒绝提示、日志、临时文件清理和磁盘使用都符合预期。
可复制的只读取证命令
以下命令中的域名、服务名、路径和时间范围要替换为自己的真实值。先执行查询命令并保存原始输出；不要把“命令能运行”误当成“业务已恢复”。
text
curl -sS -D - -o /dev/null -F '[email protected]' https://www.your-domain.tld/upload
curl -sS -D - -o /dev/null -F '[email protected]' https://www.your-domain.tld/upload
nginx -T 2>&1 | grep -n 'client_max_body_size'
php --ini && php -i | grep -E 'post_max_size|upload_max_filesize|upload_tmp_dir'
df -hT /tmp /var/lib/nginx 2>/dev/null
curl -sS -D - -o /dev/null -F '[email protected]' https://www.your-domain.tld/upload：记录小样本的状态和响应头；使用无敏感内容的测试文件curl -sS -D - -o /dev/null -F '[email protected]' https://www.your-domain.tld/upload：与失败样本对比，注意不要超过业务允许范围nginx -T 2>&1 | grep -n 'client_max_body_size'：查看实际加载配置中的所有上传限制和行号php --ini && php -i | grep -E 'post_max_size|upload_max_filesize|upload_tmp_dir'：核对 CLI 所见配置；PHP-FPM 可能加载不同 ini，需再查池配置df -hT /tmp /var/lib/nginx 2>/dev/null：检查常见临时目录所在文件系统的容量与类型
如命令输出包含公网 IP、用户名、Cookie、令牌、数据库连接串或客户数据，分享工单前先脱敏。对比时保留时间戳、时区和命令本身，否则后来无法复现同一观察条件。
五个最容易扩大故障的误区
- 只改 PHP 不改 Nginx：请求在到达 PHP 前就被代理拒绝，应用参数不会生效。
- 把上限设为 0 或极大：会扩大磁盘、带宽和拒绝服务风险，也可能绕过业务设计。
- 改错配置文件：面板、容器和 include 可能加载另一份文件；以
nginx -T为准。 - 只测成功不测拒绝：错误边界、提示和临时文件清理同样是产品行为。
- 忽略 CDN 套餐上限：源站调大也无法越过边缘固定限制。
变更、回滚与数据边界
保存 Nginx 与运行时原配置、语法检查输出和当前上限。调整后若磁盘、内存、连接或应用错误明显上升，恢复原限制并平滑 reload，同时暂时引导用户走分片或受控上传通道。回滚配置不会自动删除已产生的临时文件，也不会撤销已经接收的业务数据，需按应用规则核对。
如果只能先恢复服务、还不能确认根因，应把措施标记为“临时缓解”，例如限流、摘除单节点、切回上一配置或临时绕过一层代理。恢复后仍要在受控环境复现原因，并验证同类故障不会在下一次重启、发布或高峰重新出现。
统一验收清单
- [ ] 413 生成层已用日志确认
- [ ] Nginx 实际生效配置已核对
- [ ] 运行时与应用上限关系明确
- [ ] 目标大小低于所有链路硬上限
- [ ] 临时磁盘和并发预算足够
- [ ] 低于上限上传成功
- [ ] 高于上限得到明确可控拒绝
- [ ] 日志、监控和临时文件无异常增长
验收必须同时覆盖机器内部和真实外部路径。首页返回 200 不能证明上传、长连接、登录、数据库写入或移动端都正常；同样，控制台显示“运行中”也不能证明应用已能处理请求。至少选一个正常请求、一个边界请求和一个失败请求，记录预期与实际结果。
相关内容与隔离测试入口
建议先阅读Nginx 502和504排查、Nginx反向代理、云服务器端口不通，把本问题放回完整请求链路。若生产环境不适合直接试验，可查看美国弹性云服务器的当前规格与库存，搭建与生产隔离的复现环境；测试机不能替代生产备份，价格、库存和可选配置以实时产品页为准。
常见问题
client_max_body_size 应该放在哪一层？
放在需要该上限的最小合理范围，通常是特定 server 或 location；全局放大可能影响其他站点和接口。
改完为什么 nginx -s reload 仍 413？
可能命中更具体 location、改了未 include 的文件、请求先被 CDN 拒绝，或 reload 失败。查看 nginx -T 和错误日志。
post_max_size 和 upload_max_filesize 谁应更大？
包含文件的 POST 还带表单和编码开销，因此 post_max_size 通常需大于单文件上限；还要考虑多文件和内存设置。
大文件是否应该经过 PHP？
不一定。对象存储直传、分片和异步处理常能减少 Web 进程占用，但需要签名、权限、完整性和回调设计。
413 会影响 SEO 吗？
普通页面抓取通常没有大请求体；但后台发布、图片上传或 API 失败会影响内容生产。不要把管理接口错误直接写成搜索排名原因。