二零二三年四月九日，这天是个星期天。F君因为熬夜起得很晚，虽然是复活节假期加上周末，下午还是和项目组的成员一起开了一小时的会。接下来的三小时，在B站进行了直播，现场泡了一杯卡布奇诺。没能成功拉花，但味道还是绝对一流。
窗外，夕阳刚好照在院子里还没开花的樱树梢上。平静的傍晚气氛似乎有些微妙。F君在下播后想看看粉丝数的变化，顺手打开lab.fkun.tech却发现加载速度异常的慢，在数据页面更是直接加载不出结果。这当然不是什么罕见的事，就在前几天，电脑突然访问不了B站。有丰富网络经验的F君直接点开了Mac的网络设置，一看IP成了169开头，很高兴一下就找到了问题。登上路由器后台，分配了一个固定IP，并在电脑上手动设置，网络便恢复了。只是打开网页的速度还不够理想，那就改DNS服务器，1.1.1.1，8.8.8.8，再熟悉不过的设置了。保存设置后一切都恢复了正常。

前情概要完毕，以下开始正文。

这回打开网页速度变慢，我自然首先联想到的是DNS服务器，然而检查后发现设置没有问题。并且访问别的网站速度正常，只有fkun.tech下的域名访问极其缓慢甚至打不开。我试了试访问论坛bbs.fkun.tech，访问正常，论坛的服务器在我的卧室里，而其他的网页服务都跑在日本的机房中。这下确认了是日本那边的服务器出了问题。

打开云服务器的后台，CPU已经跑满，不过似乎也不是多久以前发生的事。资源记录显示CPU是十几分钟前开始满负荷工作的。我猜测只是系统遇到了什么BUG，首先在管理后台硬重启。重启后能登陆宝塔后台，算是进了服务器，看到状态和CPU都是100%。不一会儿宝塔也进不去了。这时尝试使用终端SSH登陆，登陆验证速度非常慢，这让我有了不好的预感。等了有二三十秒，还是连进去了。TOP命令查看进程，mysql排在第一个并且吃满了CPU。用sql命令看了内容，没有发现特别耗时的语句，但出现了大片和博客数据库相关的内容。平时我很少查sql正在执行的语句，所以没太当回事。

此时已是国内的深夜，网站已经全线瘫痪，我立即停止了sql服务。CPU占用率瞬间就正常了，宝塔后台也不再卡顿，只是系统状态还是跑满的。我继续排查，关闭了PHP，再开启sql。发现此时CPU资源没有什么变化，系统状态也恢复了正常。在这个服务器上，我运行着两个版本的PHP，一个版本保持最新，一个是旧的版本。在测试后我发现，只有同时运行旧版PHP和Sql的时候高占用才会出现。此时，我认为问题在旧版本的PHP上，于是又装了一个稍新的版本测试。我先关闭了所有运行旧版PHP的网页服务并重新配置了刚安装的PHP版本。接下来一个一个网页开启，观察资源占用情况。好在旧版下只有两三个网页，很快我就确定了是博客的问题。

马上打开日志，恍然大悟。成百上千条的GET请求，内容乱七八糟，时间间隔很短，来源IP没有特定规律，大部分是172和162开头的，参杂着一些其他IP。以前并没有经历过DDoS，看到这日志还是挺吓人的。

好在博客是过了CDN的，上了Cloudflare后台看到请求数已经起飞。

接下来就是解决问题了。Cloudflare的自动DDoS防御没有启动。看过日志后，我发现流量集中在最新的一篇博文，因为日志已经快到1G大了，我不确定是否还有其他页面遭受攻击。我的第一个操作时设置重定向，所有访问这个页面的流量全部转到静态的主页fkun.tech。这一步操作十分有效，立即缓解了高占用的问题。静态页面在Cloudflare有缓存，于是不再消耗服务器的流量。

可以看到从23：00开始，未缓存的流量开始下降。但目前的状态只能应急，普通用户打开页面也会被跳转，不是长久之计。于是我创建了两个规则，一个是短时间内通IP访问次数过高自动banIP，一个是在受影响的页面GET请求触发人机验证。

第二图的截图时间是两小时后，拦截数已经开始下降。

目前仍然在持续遭受攻击，访问量没有明显下降，但是请求数大幅减少，CDN挡下了几乎所有流量，服务器性能已不再受攻击影响。

好了，又折腾到了凌晨两点半，洗洗睡了。