主题：【求助】关于网站大量 Error 001 应对 -- 铁手

https://addons.mozilla.org/zh-CN/firefox/addon/servstats/

ServStats lets you share statistics about web server connectivity and diagnose network failures. When a network failure occurs, ServStats automatically conducts diagnostic tests and infers the most likely cause of failure

NAT那可是大杀器，一般差点的局域网网关服务器都得仔细着点开NAT，工作原理决定了，这东西得解包、构包，同时还得把解包构包的过程记录下来，等返回的时候再反着来一次，绝对是和CPU八字犯冲型的，您看看您开BT的时候有同时发起了多少链接，小破路由器哪能撑得住这样玩儿法，肯定得自我保护DROP了，至于RST，那也得走NAT，一样被DROP了

前几天看您的帖子没敢回，因为有几个疑问得不到确认：

首先是您server的配置和网络拓扑，防火墙怎么配置的，是不是有反向代理，多域名又是怎么配置的，由此引发的问题点可能各不相同

既然老哥您基本确认了ip_conntrack是罪魁祸首，小羊经验主义一把，应该是您的防火墙在POSTROUTING 和PREROUTING链当中有NAT的操作，SNAT或者DNAT或者REDIRECT这个就不敢确认了，这些都会在ip_conntrack当中添加记录，DNAT多见于防火墙转发包给DMZ中的server，REDIRECT多见于反向代理，因为不了解您的网络拓扑结构，所以还得您自己检查（拓扑图、防火墙配置啥的您千万别往河里贴，这事儿挺敏感的，最近网络安全这块儿事儿蛮多的）。

不管怎么样，ip_conntrack记录保存5天是个默认值，因为NAT得记着每条链接，这样才能进行解包和构包，如果您的防火墙是单独的网关，和web server是分开的，而且有别的任务要做，那么不建议修改，有可能影响正常网络通讯。如果防火墙只为web服务，那么改小点无伤大雅。不过改小了老实说未必有用，ip_conntrack日志里面的记录有UNREPLIED的，也有ASSURED的，前者是没连上的，后面是链接确认的，如果日志满，前者会被正常删除，而后者宁可丢包都不会动，操蛋的是，这个5天的时间还会自己更新，在记录没满的情况下，UNREPLIED的链接在4.9天连上了，都再从头计数（这个记不太清楚了，好象是，建议老哥再查查文档）

把MAX改大是个路数，不过也有到头的一天，还得考虑内存，这玩意太大了，会很消耗内存。

按照主贴的说法，出问题前后没有过变化，那么外部因素的原因会多一点：

1、恶意或者非恶意的异常，首先您局域网当中有没有机器在把您广播成了网关，病毒或者网卡坏了都有着可能，看看路由表，如果不相干的IP后面跟的MAC地址是西河server的，那就基本确认，最好能要求机房管理人员更改一下VLAN设置，单独把您分出来，这种情况比较罕见，机房管理人员愚蠢的VLAN规划和网络异常包同时出现才行，不过还是建议考虑一下。

2、爬虫，而且是专门下河的爬虫，这玩意儿和人不一样，它每天来转悠转悠，他的那条记录就永远不会被删除，再是个并发的爬虫，直接就把记录撑满了，这个查起来倒是不难，看看日志里面user_agent是不是有非常见浏览器的，撵出去就是，如果查不到，那么有可能是做了伪装，这倒是自定义爬虫常见的伎俩，碰见这一号的，编程查日志啥的都不用，直接就挂上google的分析工具，看看报告里面排名靠前的ip是那几个，然后对照网站的用户登录记录，爬虫的特征很明显，会遍历超链，如果能基本确认不是人的，杀无赦。

3、GFW作祟，这条河现在有了支流，ccthere被墙，根据河里有位高人的的分析，恰恰时政类是国内的哥们关注的内容，虽然一准会被旁路的GFW劫持发过来RST，这样的话虽然tcp/ip不管他了，可是日志里头这条记录算是存下了，或者翻墙，那就更简单，无论怎么翻，都是慢速链接，这也挺操蛋的，半死不活。。。小羊解析了一下，俩域名地址不同，如果不是一台服务器，那么按说不会牵连到cchere，不过如果这俩IP在一台机器上。。。再弄台服务器也不便宜，要不咱干脆扔云上去？就我个人而言，反正死亚马逊不死西西河就行。