Maybe it was because I was a bit provocative in last night’s article:

The article was published at 22:19:

The attack started at around 1:30 and lasted until after 10:00 when I wrote this article:

As of 10:37 am on the 11th, the data is as follows:

In fact, I still feel pressure. For the main site where Docker Wordpress is located, the CPU utilization of the M1 MacMini Beggar Edition reached a maximum of 623% (8 cores in total 800%):

Statistics of inbound and outbound traffic of load balancing interfaces:

CPU utilization statistics:

Changting WAF still didn't block any packets. Of course, this is normal. For DDOS, as long as the source IP is dispersed enough, it is just a simple and crude HTTP flood type packet. It is considered a normal access packet for WAF. It will neither trigger any rules nor promote the configuration of high-frequency access:
Note: Changting WAF was wrongly accused. I set the IP address of the host where the cloudflare tunnel is located to the whitelist. After removing it, Changting WAF worked well.

From the uptime statistics:

During the attack, the health check packages will still be affected, which is understandable. However, during the attack, I was able to access the blog and reply to comments normally, but sometimes I might need to refresh the page.

However, I made some changes to the topology structure later. I still did not use the method of limiting concurrency on the Baota panel. Instead, I directly limited the maximum number of connections on the WordPress port on the load balancing, so that one less deployment point can be achieved.

In general, yesterday's transformation was a success. However, the only drawback is that there are still too few free statistical charts in the zevenet community version, and there are too few things to see. I can only say that it is better than nginx.

Now that the stress test is over, the attacker, that's enough. It's not a good idea to keep doing this. I'm getting annoyed by Cloudflare's email notifications.