nginx反向代理tomcat一段时间后出现的ERR_CONTENT_LENGTH_MISMATCH异常
使用nginx代理tomcat上的web项目。项目上线了一段时候后，访问项目出现了css文件或js文件的ERR_CONTENT_LENGTH_MISMATCH异常，而不能加载这些文件。
查询网上给出的解答，一般是说在nginx的proxy_temp下的缓存文件的所有者不是nginx启动者而导致启动者不能访问这些缓存文件而出现这个问题，需要将所有者改为启动者，ps nginx可以查看启动者是谁；另外还需要在nginx的配置文件nginx.conf中，在worker_processes 1;之前加上user root;比如root为启动者。这样可以正常访问缓存文件，而不会出现这个问题了。
查看自己的服务器，确实proxy_temp的所有者是nobody，而启动者是root，为了方便，直接将proxy_temp下的缓存文件全部rm，并且也修改了nginx.conf文件。果然，再次访问项目，正常了，不报ERR_CONTENT_LENGTH_MISMATCH异常了。
结果，到第二天，访问项目时，又出现这个异常了。为了排查问题，直接使用tomcat的8080端口访问项目，没有问题，说明可能还是nginx代理的问题。于是，试图查看nginx.conf文件，结果vi时，提示出现Write error in swap file问题。查询，同目录下，没有.swap文件，所以不是上次错误退出而导致的nginx.conf.swap文件没有清除的问题。经查，是因为/磁盘满了。df -h确实/挂载点满了。看来需要先解决磁盘满的问题。于是从/开始，du -h --max-depth=1，一层一层追查，到底是哪些个无关紧要的文件过于庞大，以便删除之。最后的结果竟然是nginx/logs/access.log高达几个G的大小，将磁盘撑满。虽然日志文件很重要，但是，正常运行也很重要，如果确实需要日志文件，可以先将其备份出来，再删除。删除access.log文件后，试着访问项目，正常了。
推测，这个问题的原因可能是，由于磁盘满了，nginx尝试将访问记录写入access.log时失败，于是可能不能按照其原来的步骤，也就是写入log，读取proxy_temp下的缓存文件，响应给客户端，由于不能正常读取缓存，导致客户端不能得到缓存中的某些大文件，如css或js等。nginx底层究竟是不是这样运作的，笔者不知道。这个只是猜测。不管怎样，问题解决了。随便，又查看了下tomcat的logs文件，确实也占了很大的空间，看来，就算没有出现这个问题，对于增量大而快的日志文件也是要妥善处理的，否则，服务器迟早会吃饱。