原文地址：https://lala.im/8289.html，請支持原作者！該處僅作轉載。
前几天习惯性打开vps的探针瞄一眼系统负载，发现有点不对劲，平时一般情况下负载都是0.x，这怎么平均负载都是2.x，而且流量似乎跑的也有点快。。
随后登了vps管理后台查看了一下机器的流量信息，结果发现这个月的流量都直接给我干超了：
从大概8号开始持续了1个星期了，vps一个月1t的流量这个月直接跑了2t多了。。
发现出问题后，立马ssh到vps里面着手解决问题，先看了一下进程占用资源情况，发现主要是nginx/php-fpm/mysql进程占用的资源比平常多，所以基本判断是站点出了问题。
凭经验感觉这又不像是被cc攻击，因为此时站能正常打开，也没有遇到50x类似的错误，但是遇到这种事情也不能完全靠猜，随后还是打开了nginx的access日志，想看看到底是什么东西在跑流量，结果发现日志刷的太快了，不好分析，就想到了goaccess这个东西可以把nginx的日志做成图表来分析。
我通过goaccess分析nginx日志后，最终发现是googlebot的锅，这玩意不知道发什么神经，突然瞎j8爬我的一个chevereto图床站，而且爬的都是些无关紧要的页面。。。
我tm也是佛了，爬了也不见收录，更不用说给权重了，所以googlebot是爬了在自己撸吗？这个月还tm要多付流量费，真可谓是红颜祸水啊。。。
不过话说回来，还是多亏goaccess帮了大忙了，这里记录一下安装和配置。
debian的存储库里面是有goaccess的，可以直接安装的，但是这里还是建议添加goaccess官方的存储库来装最新版：
apt -y update
apt -y install apt-transport-https ca-certificates lsb-release gnupg wget
wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | tee /usr/share/keyrings/goaccess.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg] https://deb.goaccess.io/ $(lsb_release -cs) main" | tee /etc/apt/sources.list.d/goaccess.list
apt -y update
apt -y install goaccess安装好了之后，编辑nginx的主配置文件：
nano /etc/nginx/nginx.conf启用日志记录：
access_log /var/log/nginx/access.log;也可以单独给每个vhost启用日志记录，只是在主配置文件启用的话，默认所有vhost都会启用。
重载nginx使配置生效：
systemctl reload nginx然后就可以启动goaccess来分析日志了：
goaccess -f /var/log/nginx/access.log -o /var/www/html/static-report.html --log-format=COMBINED --max-items=500这里有一个–max-items的参数，个人觉得非常重要，增加这个数值可以让goaccess加载更多的分析数据，从而方便定位问题所在。
goaccess也支持实时日志分析，不过这个记录数值最多只能50，也不能通过–max-items来增加：
goaccess -f /var/log/nginx/access.log -o /var/www/html/report.html --log-format=COMBINED --real-time-html如果你的nginx是通过debian的官方存储库安装的，那么在/var/www/html下面就是一个默认的vhost，所以现在可以直接通过服务器ip来访问static-report.html或者report.html查看分析报告。
可以看到几乎全部都是googlebot的ua：
单一个ua不能说明问题，也许ua是伪造的，再看一下访客ip：
当然ip也可以伪造，这时候再查一下rdns就能确定到底是不是真的googlebot了：
apt -y install dnsutils
dig -x 66.249.64.135被google剑皇了属于是：
我目前的解决办法是，正好我的这个站接入了cf，我干脆就用cf的防火墙把google的爬虫都屏蔽了。。
