pin_drop当前位置:知识文库 ❯ 图文
秒懂PHP图片上传失败排查:Nginx的client_max_body_size配置详解
目录
我靠,折腾一宿!PHP上传图片老是失败,最后才发现是这个鬼原因!
兄弟们,姐妹们,大家写代码的时候有没有碰到过那种能把你逼疯的问题?
就是你明明觉得这玩意儿简单得跟一加一似的,结果它愣是能卡你一整个晚上,让你怀疑自己这十年程序是不是白写了
我昨天晚上就摊上这事儿了。
事情是这样的
最近不是在捣鼓一个自己的小项目嘛,一个贼简单的后台功能,就是让用户能上传头像。用的PHP,老本行了,心想这还不是手拿把掐?
噼里啪啦敲完代码,move_uploaded_file(),$_FILES,该写的判断都写了,该做的验证都做了。
然后一测试,炸了。
选了个jpg图片,点上传,页面刷了一下,啥反应没有。图片没传上去,也没报错。再试,还是一样。
我当时就我靠了。
怀疑人生的两个小时
一开始我以为是自己代码逻辑有问题,检查了三遍,没毛病啊。
然后我以为是权限问题,把上传目录的权限chmod -R 777给干上了(我知道不安全,但调试嘛,回头再改)。
结果呢?还是不行!
接着我以为是php.ini里头的upload_max_filesize或者post_max_size太小了?打开一看,一个20M,一个50M,我这图片才几百KB,绰绰有余啊。
内存限制?memory_limit也够。
那到底是为啥?!
我当时真的,差点就要把电脑砸了。这种感觉你们懂吗?就是那种你明明觉得是手到擒来的活儿,结果啪啪打脸,特别憋屈。
真相只有一个(但我想不到)
凌晨两点半,我顶着黑眼圈,已经开始在搜索引擎里乱翻,各种奇葩的解法都试过了,什么改nginx配置啊,重启php-fpm啊,统统没用。
就在我准备放弃治疗,去倒杯水冷静一下的时候,我突然瞄见了浏览器控制台。
我靠!
不是,大家听我说,真的是我靠。
我看到了一个鬼东西:413 Request Entity Too Large
413?这啥玩意儿?我下意识地看了一下Request Headers,又看了一眼Response Headers。然后我猛地一拍大腿,我真想抽自己两下。
我光顾着改PHP的配置,完全忘了前面还蹲着一个Nginx!Nginx这关过不去,你就算把PHP内存改成一个G都没用!
罪魁祸首抓到了
问题就在Nginx的配置上。
Nginx这个狗东西,默认的client_max_body_size只有1M。对,你没看错,就是1M。
也就是说,如果你上传的图片超过了1M,Nginx二话不说,直接给你拦下来,返回一个413错误,根本就不会传到后端的PHP去处理。
我上传的图片虽然不大,但也七八百KB,没到1M,但后来我换了个1.2M的图想试试极限,结果Nginx直接给我掐死了。
我当时的心情怎么说呢?就是又好气又好笑。气的是自己太蠢,这种低级错误都能犯;笑的是,总算找到原因了,不至于通宵了。
怎么治这个病?
解决方法简单得你想哭。
找到你的Nginx配置文件(通常是在/etc/nginx/nginx.conf或者你站点单独的配置里,比如/etc/nginx/conf.d/default.conf或者sites-available/下面那个)。
在http {}、server {}或者location {}块里(看你想全局生效还是单站点生效),加上这一行:
代码示例
client_max_body_size 20M;
把20M换成你想要的大小,比如你想让用户传大文件,设成50M、100M都行。
然后保存文件,测试一下Nginx配置有没有写错:
代码示例
nginx -t
如果显示test is successful,那就优雅地重载Nginx,让它生效:
代码示例
nginx -s reload
或者
代码示例
systemctl reload nginx
再回去刷新你的上传页面,点一下上传,卧槽,成功了!
那一刻,看到"上传成功"四个字,我差点热泪盈眶。
给兄弟们的一点忠告
所以啊,以后遇到PHP上传文件失败,尤其是那种一点错误提示都没有,页面刷一下就完事儿的。
千万别死磕PHP!
往前看看,看看你的Web服务器(Nginx/Apache)有没有搞鬼。特别是Nginx,这货的client_max_body_size经常被人忽略。还有Apache也有类似的限制,叫LimitRequestBody,虽然默认是无限制,但保不齐谁手欠改过呢?
另外,多看浏览器控制台,多看服务器日志,它们虽然不会直接告诉你"嘿,傻逼,你配错了",但会给你一些提示,比如那个413状态码。
小贴士
在Web开发中,请求体大小限制可能出现在多个层面:Nginx的client_max_body_size、PHP的post_max_size和upload_max_filesize、甚至CDN或云服务商也可能有自己的限制。排查上传问题时,应该从外向内逐层检查,先检查反向代理/网关,再检查应用服务器,最后检查业务代码。
有时候解决问题就是这么玄学,你往复杂里想,可能绕一大圈,结果问题就出在最简单、最容易被忽视的地方。
好了,吐槽完了,代码能跑了,我也该睡觉了。希望看到这篇的兄弟萌永远不会被这种低级问题坑到。如果你也遇到过类似的"鬼打墙"问题,欢迎在下面留言,让我知道我不是一个人!
常见问题
PHP上传文件没报错也没上传成功是怎么回事?
很可能是请求在到达PHP之前就被Web服务器(如Nginx)拦截了。Nginx默认的client_max_body_size只有1M,超过此大小的请求会返回413错误,根本不会传到PHP。
如何修改Nginx的上传文件大小限制?
在Nginx配置文件的http{}、server{}或location{}块中添加client_max_body_size 20M;(大小按需调整),然后执行nginx -t测试配置,nginx -s reload重载生效。
413 Request Entity Too Large是什么错误?
413是HTTP状态码,表示请求实体过大,服务器拒绝处理。通常由Nginx的client_max_body_size限制、PHP的post_max_size限制或应用层文件大小限制触发。
Apache服务器有类似的文件大小限制吗?
Apache使用LimitRequestBody指令控制请求体大小,默认是无限制。但可能被管理员手动修改过,排查时也需要检查Apache配置。
本文涉及AI创作
内容由AI创作,请仔细甄别list快速访问
poll相关推荐
Python元组命名namedtuple
Python元组解包
Python元组index方法
Python元组count方法