主要是路由器版adbyby有bug，进程死了后不清除tcp连接，导致路由器上开了上千TCP连接。。。导致其它设备不能进行TCP连接
刚查了一下这东西有点像privoxy这样的代理软件来过滤广告。所以既然代理进程挂了那只能去判断重启进程。不然后续连接肯定有问题。
tcp udp连接dd tt都有参数可以直接调整内核idle timeout,但是做过qos的效果更明显。只能用脚本去侦测ip并发数再去实施iptables limit或者tcp reset之类。显然你的不属于tcp timeout的问题更像是进程不再响应后续连接。

经过测试，大概6小时左右会影响到网速，如果让路由器每6小时释放一次TCP应该怎么弄?

照理说，进程结束后，所有未关闭的文件句柄会由父进程接手，最后由init释放。
tcp sock也是文件句柄。
是服务死了但进程还在么？
还是父进程没处理？

http://www.groad.net/bbs/thread-8832-1-1.html
没用过adbyby看看这介绍吧。
iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8118
有这样的语句存在进程崩溃，当然后续连接无法代理了。所以应该研究的是如何用cron配合shell脚本进行进程守候处理。

adbyby会弄出来好几十个子进程。。。。

按4楼的做法，kill父进程，可以温和一点，SIGTERM
几十个子进程不是问题，问题是父进程没有帮子进程释放资源。
这时候只能kill父进程，让init处理
cron每分钟加一条iptables规则这算几个意思？


刚才试了一下，killall adbyby只能释放极少一部分TCP连接

那剩下的给谁了？
还是说CLOSEWAIT？
CLOSEWAIT只能调低timeout，因为这是内核设计

tcpkill 行不行