网站上传报413：Nginx与PHP限制配置

上传文件出现413 Request Entity Too Large，或应用提示文件超过限制，可能由CDN、Nginx、PHP或应用本身拒绝。本文针对已经正常运行的Nginx与PHP-FPM网站，处理上传大小限制，不会修复文件类型、目录权限或数据库错误。先记录文件大小、失败请求状态码和时间，不能仅凭页面一句“上传失败”同时改所有参数。

先区分三种大小

此外，应用、CDN、负载均衡和上游服务可能有自己的限制。PHP限制调大而请求先被CDN拒绝，PHP根本没有机会处理；Nginx调大但PHP仍限制，则可能看到应用层上传错误而不是Nginx的413。

确认失败在哪一层

1. 先上传一个小文件，再上传目标大小的同类合法文件，记录成功与失败边界。
2. 浏览器Network面板查看具体失败请求的状态码和响应，不截图Cookie或认证头。
3. 对照同一时刻的Nginx access_log与error_log；出现client intended to send too large body等线索时，检查命中的server/location。
4. 如果经过CDN，先查CDN的限制与日志，再在受控方式下核对源站，不能凭响应头单一字段认定责任。

以单文件16MiB为例设置

以下为解释参数关系的示例，不是所有站点的推荐值。需要上传单个16MiB文件时，可先给POST和Nginx整体请求留出合理空间；多文件请求要另算总量。编辑实际目标站点server块，避免改到其他域名：

client_max_body_size 24m;

检查更具体的location是否覆盖了这个值。再编辑当前网站FPM分支的php.ini，示例为：

upload_max_filesize = 16M
post_max_size = 20M

Ubuntu 24.04默认PHP 8.3 FPM常在/etc/php/8.3/fpm/php.ini；面板及容器应使用对应管理入口。默认CLI的php --ini不是网站配置来源。PHP内存和临时目录也须满足程序需要，但不要顺带把memory_limit、超时和上传值都设置成无限。

检测、加载，再从Web端确认

sudo nginx -t
sudo php-fpm8.3 -t

两项均成功后，分别reload nginx和php8.3-fpm。不同PHP分支要替换服务名。使用站点健康或受限检测页读取Web端真正生效的上传与POST值，结束后移除检测文件。配置路径及扩展核验可参考PHP扩展与配置生效教程。

用目标文件验证边界，而不是只看保存成功

• 小文件和目标大小文件均上传成功，后台记录与前台读取正常。
• 超过业务允许大小的请求应得到可理解的拒绝，不需要为了测试一直提高上限。
• 多文件表单按整次请求总量验证，不用“每个都小于16M”代替POST总量计算。
• 若改完仍是413，检查是否命中了另一Nginx、CDN或更具体location；若变成500或超时，转查应用、图片处理内存、临时目录及磁盘。

修改前记录旧值，出现资源占用或异常请求增多时恢复原值并检测加载。不要将client_max_body_size设为0来长期取消限制，也不要通过关闭安全检查允许任意文件。上传限制属于资源控制，仍需应用验证文件内容和权限。