php上传超2m失败主因是nginx的client_max_body_size默认仅1mb，请求在入口即被拦截返回413，根本未到达php；需在对应location/server/http块中显式设置该值（如100m），并重启nginx，同时检查client_body_timeout、php侧参数及反向代理链路各层限制。
PHP上传超2M失败，90%不是PHP配置的问题，而是Nginx在第一道关卡就拦下了请求。 你改了 php.ini 里的 upload_max_filesize 和 post_max_size，但依然报 413 Request Entity Too Large，说明请求根本没进PHP——Nginx在解析HTTP头时就拒绝了。
为什么改了PHP配置还是413？
Nginx默认的 client_max_body_size 是 1m（即1MB），它检查的是整个HTTP请求体（包括文件内容 + 表单字段），只要 Content-Length 超过该值，Nginx立刻返回413，压根不会把请求转发给PHP-FPM或后端应用。
- 这个限制独立于PHP，哪怕PHP允许100M，Nginx也会在入口处拦截
- 它生效位置优先级为：location > server > http，越靠近具体路径，覆盖力越强
- 修改后必须重启Nginx（
sudo systemctl restart nginx），热重载（nginx -s reload）有时不生效，尤其涉及body大小逻辑
怎么查当前生效的client_max_body_size？
不能只看配置文件里写了什么，得确认它实际落在哪个作用域、是否被覆盖：
- 运行
nginx -T | grep client_max_body_size，输出会显示所有匹配行及其所在块（http/server/location） - 重点看你的上传接口所在的
location块有没有显式设置；如果没写，就继承上一级（比如server块）的值 - 注意：有些Docker镜像或Ingress Controller（如Nginx Ingress）会把配置生成到临时文件，直接改宿主机
/etc/nginx/nginx.conf可能无效
client_max_body_size和client_body_buffer_size的关系
这两个参数常一起调，但作用完全不同：
-
client_max_body_size是硬性上限，超了就413 -
client_body_buffer_size是内存缓冲区大小，默认8k或16k；小文件走内存，大文件会写入临时磁盘（路径由client_body_temp_path指定） - 如果
client_body_buffer_size太小，高频上传可能触发大量磁盘I/O；但设太大又浪费内存。一般设为128k～512k较平衡 - 务必确保
client_body_temp_path目录存在，且Nginx worker进程用户（如www-data）有读写权限，否则会静默失败或报open() "/var/lib/nginx/body/xxx" failed (13: Permission denied)
上传大文件时还必须同步检查的点
只调 client_max_body_size 不够，漏掉下面任意一项都可能卡在半路：
- PHP侧：确认
upload_max_filesize、post_max_size、max_execution_time、max_input_time全部调高（例如都设为120M和300） - Nginx超时：大文件上传慢，需加大
client_header_timeout、client_body_timeout（建议 ≥ 300s） - 反向代理场景：如果Nginx后面还有一层（如另一台Nginx或云WAF），它们也有自己的body size限制，必须逐层检查
- 浏览器或客户端：某些前端库（如axios）或移动端SDK对单次请求有隐式大小限制，需确认是否分片上传更稳妥
最易被忽略的是：多个 location 块中，上传接口路径是否真的命中了你修改了 client_max_body_size 的那个块——用 curl -v 看响应头里的 Server 和实际返回的错误页来源，比盲猜配置更可靠。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
