Nginx服务器配置不当导致的日志文件大量增加

去年给楼上做的nginx--(varnish×2)--((nginx--haproxy--PHP-fastcgi×2)+(apache+php))结构的网站（说明一下，这里的apache+php是以前的老构架，nginx+php正常的话，apache上是没业务的，纯粹做备），这个网站服务器的系统维护已经移交了快大半年了，一直很正常，系统基本上免维护，反正移交以后我没有登上去做过维护工作，只在一个月前把cache上的varnish换了个新trunk版本的（支持后端健康监测的特性），嘿嘿，估计楼上接手的小伙子也从来没上去过（不知道他们有没有做过备份）。
前天来找我，说是出问题了，看上去是磁盘满了，当时我做了logrotate60天日志的，并且前端的cache上每天用webalizer统计，访问量并没有增长，实际上5月以来还是逐月下降的，但实际上web日志的大小却增长得比较明显，accesslog每天从年初的1、2个G到现在竟然有6个G，当天的errorlog竟然有20G。
查看日志和webalizer的统计才发现，前几个月404递增比较明显，几个月内翻了近两倍，近几个月也是递增的，说明网站里的死链越来越多。WEB日志迅速增长的原因就是因为有很多的404条目。但为什么会有这么多的人访问不存在的东西呢？我觉得很奇怪。于是与cache上的nginx日志做对比，觉得问题可能出在nginx的配置文件。但里面似乎还有没弄明白的地方。
当初做这个系统的时候，经验不足，后面php+nginx有时候会有503出来，但这样不太好看，于是出错的话强制404页面，因此在cache上也做了些手脚，前端nginx如果从某个varnish cache得到404（当然也包括503、500等）的话，就再换个后端重新请求一次，觉得这样能够保险一点，有更好的用户体验，也就是下面这句配置。
proxy_next_upstream error timeout invalid_header http_500 http_503 http_404;
很可能发生的事情就是，一个404出现以后，nginx会在upstream里轮流查看，啥时候会结束，我也不知道，也许要等到每个后端默认的max_fails以后才结束轮询，实际上nginx网站上的配置说明对这样的行为也咩有描述。
这两天如果有空打算测试一下看。
但404是客观存在的，其实外面对死链的访问大概只有1%左右，但一旦有爬虫来爬，并经过这个放大过程以后，落到后端服务器上的请求量就非常可观了。另外还有一层，在升级varnish之前，由于varnish没有健康监测机制，所以还在VCL里用了restart，因此varnish如果取后端WEB内容失败的话，还会再试一次，这又是一次放大。更新了新的varnish以后，自己有后端健康监测了，才把restart去掉的。
这里，我也不得不佩服一下nginx，在如此多的垃圾请求下（看了一下，光这样的垃圾请求，起码每秒几个），加上正常的请求，处理起来竟然效果还是不错的。网站的访问上面基本看不出啥问题，所以才会等到楼上的发现磁盘被日志撑满了，PHP报错了才开始处理这个问题。
于是，改成了proxy_next_upstream error timeout invalid_header http_500 http_503; 以后，似乎太平了很多。