Nginx 500 Internal Server Error nginx/1.10.3 ubuntu

一个上线的项目，最近产品反映有一个接口用户反馈说不能用了，前端跟我说接口返回500，这个bug我解决了好几天，这里记录一下排查解决过程
简单介绍一下情况，这个接口是一个上传用的接口，包含一张图片
1.我最开始使用postman进行测试，发现成功，没有报错而前端说报错
2.让前端检查端口是否写错了，检查后前端没有写错
3.让前端截图，他用postman测试都不通过，发现参数不带图片确实访问到了准确的接口，而一带图片就报500
4.查看tomcat日志，日常日志和错误日志都检查了，都没有记录到请求

接下来分析，既然返回了500，那么一定是访问到了服务器了，那么问题一定处在服务端（代码或服务器还不确定），而通过查看日志都没发现请求有被记录（代码已经做好了try catch，记录错误日志，日常日志不必说每一个请求都会记录到），那么推断请求还没被接收执行就服务器就已经报错了，由于我测试没问题所以给排查bug增加了困难。
检查日志花了几天，因为我误以为是tomcat返回的500，所以日志应该有记录的，但前端却说报错不带任何信息，后来截图发现是nginx的500报错Internal Server Error，于是重点就转到了nginx上，去查看了nginx的错误日志(/var/nginx/logs/error.log)，发现错误日志记录的日期与发现错误的日期差太远（远比发现的日期要前），但记录的内容引起了注意

No space left on device
马上查看硬盘的情况

/dev/vda1盘符已经沾满了，挂载在根目录
于是查看具体哪个文件占了多少存储

发现etc目录占了15G，是/dev/vda1盘符占用存储最多的，进一步检查，发现/etc/nginx/logs/access.log即nginx（这个路径是nginx里自行配置的）的访问日志占了15G，查看日志最后几行发现日期与error.log的日期一致，那就说明了问题了，连访问日志都只记录到了某一个日期，不是最新日期那就说明确实是存储满了导致写不进日志，因为是访问日志，重要性不是特别大而且已经很久没有记录了，所以停掉nginx
service nginx stop后把access.log删掉再重新开启service nginx start
经过测试，问题得到解决！

至于为什么postman测试时我本机测试成功，前端不成功以及生产环境下不成功的原因我觉得是环境的不同，每个发送请求的环境都不同