对抗刷流攻击：我是如何通过Nginx防御“绅士刷流”并拯救服务器性能的

📉 序幕：一次普通的 robots.txt SEO 优化

故事的开始非常偶然。昨天早上我本来只是看到一篇博文在介绍现代搜索引擎对robots.txt文件格式的适配，里边提到对于WordPress博客已经不再推荐屏蔽/wp-includes/，我核实了一下确实是这样的，于是计划修改一下博客的 robots.txt 文件，优化一下 SEO 策略。
然而，当我登录面板准备操作时，首页的负载引起了我的警觉。在这个本该平静的时间点，服务器的状态却显得异常亢奋，负载持续在70左右。

🔍异象：服务器负载异常——负载的“虚假繁荣”

我果断先去一眼到底是什么进程在吃我的资源，结果：

• php-fpm 加上 nginx 一直维持在 CPU 占用 50~70 %的区间内 （绝了，刚好在报警阈值以下）
• php-fpm 的 CPU 占用大概20%左右，nginx 则是在 50%左右（1、说明大部分流量都命中缓存了，2、处理网络流量占用了大量 CPU 资源，要知道平时 Nginx 很少会超过 2% 占用）
• 网站的出站流量持续维持在 2MB/s以上 （同样也压的非常精准，正好不会触发报警）
• umami统计里今天的访客到至今（我查询的时候）才300多人。

这个数据绝对有问题，而且是有大问题！先不说umami里在线访客只有2个人的情况，也不说PHP占用也不低的事情。就算是有大量真实用户访问，PHP 的负载应该会很高（毕竟 WordPress 是动态博客，缓存做的再好也不对劲）。但现在 Nginx 居然比 PHP 还忙，这种诡异的情况，一般意味着：

1. 我被恶意抓取了？
2. 我被盗链了？
3. 我被 CC 攻击了？
4. 亦或者我的服务器被植入恶意脚本了？

直觉告诉我： 恶意爬虫或 CC 攻击的可能性最高，于是先从这个方向查。

🧐侦查：从 access.log 中寻找蛛丝马迹

常规起手，先看 Nginx 的 access.log

1. 实时查看日志（看看现在正在疯狂刷新的请求是什么）：

# 我这里打的默认路径，如果你想参考，请根据你的实际情况调整
tail -f /var/log/nginx/access.log

这屏幕日志刷的哗哗的，滚动的飞快，1秒怕不是有10条以上了，我还没看清就刷上去了，额，算了，还是统计一下吧，直接看日志超过我的目力限制了。

🤔疑点：Nginx日志分析——IP分散、参数固定、流量精准控制

1. 统计攻击 IP Top 20（找出攻击者IP）：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 20

粗看一切正常，并没有哪个IP在疯狂请求我的站点。

2. 统计被请求最多的 URL（找出受害文件）：

awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

返回结果的前几条是这样的：

 129007 /
 60547 /?local_ga_js=f78e59fd91e18c7a2940a914030e9743
 1620 /feed
 246 /tutorial/971
 88 /robots.txt
 80 /favicon.ico

啊，这……对于我这个日均几百人的博客，8个小时内，首页 / 被访问 12.9 万次，带特定参数的 URL 被访问 6 万次，这显然是有人在疯狂刷我的首页和特定资源。

3. 针对性看一下请求来源 （都有谁在请求异常文件）

首页的日志不好分析，毕竟有正常人在，那个奇怪的local_ga_js就好分析多了，让我看看都有谁在请求这个文件

grep "local_ga_js" /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 50

所有 IP 的请求次数都是8次，这也过于稳定了吧！

我追溯了本周的历史日志，他一直维持着一个大概有 400 个 IP 的 IP 池，用这些 IP 轮询，每个 IP 使用了 7~8 次后就弃用，重新拨号获取新的 IP 。既然这是正常的家宽 IP 而且攻击者释放 IP 的速度也很快，直接屏蔽整个广东电信的 IP 或者封禁 IP 一段时间就显得不合适且毫无意义了。

⚔️ 破局：Nginx防御配置——拦截特定查询字符串

先干死请求local_ga_js=XXXXX的，攻击特征这么统一不干你干谁，首页的问题先放到一边。

先改一下站点的 nginx 配置

# 放在 location / 之前
if ($query_string ~* "local_ga_js=") {
    return 444;
}

这里使用 Nginx 特有的 444 状态码。相比返回 403，444 会直接关闭连接且不返回任何数据包，能最大限度节省出站流量以及服务器性能。（Nginx官方关于444状态码的介绍）

😏追击：对抗刷流攻击——伪造的浏览器指纹

前边的规则配置后效果立竿见影， 几个查询扔出去，果然看到 CPU 压力已经大幅下降了。
有效果就好，我先去喝口水，大早上这么半天连口水都没喝呢，喝水时脑内复盘了一下目前的现状：

• Nginx还是保持在15%左右的占用
• php-fpm保持4%左右的CPU占用。
• RX（入站）基本维持在几十KB/s，
• TX（出站）还是持续在500KB/s到2MB/s之间。

第一阶段的防御（拦截恶意 PHP 请求）已经大获全胜！首页的 Redis 缓存被命中。Nginx 直接吐出了静态 HTML，没有调用 PHP，PHP 不再处理那些垃圾请求了。但是他一直在刷首页，还是有点烦人的，毕竟这依然会造成一个持续的 0.5MB/s 的出站流量，虽然这和整体带宽相比并不大，但一天下来也 40 GB 了。倒完水回来喝一口，和同事聊几句工作，咱们继续处理。

1. 首先清空日志，不然日志太大了不好分析

echo "" > /var/log/nginx/access.log

2. 等 60 秒

3. 查看文件大小：

ls -lh /var/log/nginx/access.log

额，短短60秒，日志文件就有100KB了，一行请求基本是 200 B，一秒内还是有接近10次请求……

4. 先看下60秒内的拦截和放行的比例（看状态码）确保前边的措施生效了。

> awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
    842 444
    744 200
    712 301
    8 304
    5 414
    3 302
    1 404

• 拦截成功 (444): 842 次。说明前边针对 JS 的规则生效了，拦住了 36% 的攻击。
• 重定向 (301): 712 次。说明攻击者很蠢，在访问 HTTP 或者非 www 域名，被 Nginx 自动纠正到 HTTPS。
• 穿透防线 (200): 744 次。这是我唯一需要担心的。这意味着有 744 个请求被认为是“合法”的，Nginx 处理了它们（返回了网页）。

5. 再次看看它在访问什么 URL （再看一次新的日志）

> awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10
1941 /
1160 /?local_ga_js=f78e59fd91e18c7a2940a914030e9743
19 /feed
9 /robots.txt
5 /?local_ga_js=1
4 /music/
4 /favicon.ico
3 /tutorial/971
3 /music/fonts/element-icons.535877f5.woff
2 /wp-content/themes/JieStyle-Two-2.6.2/webfonts/fa-solid-900.woff2

看来不是自动化的脚本，因为针对JS的规则已经生效了，444这种直接断开的行为，在对方看来应该类似于对方关机了，我倒水喝水都过去10分钟了，他还在请求那个JS。

6. IP太分散，我们来看看User-Agent

grep "local_ga_js" /var/log/nginx/access.log | awk -F'"' '{print $6}' | sort | uniq -c | sort -nr | head -n 10
1292 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.0.0 Safari/537.36
1290 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/110.0.0.0 Safari/537.36
1289 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/129.0.0.0 Safari/537.36
78 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/142.0.0.0 Safari/537.36
64 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
18 Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36 Edg/143.0.0.0
7 Mozilla/5.0 (Macintosh; Intel Mac OS X 12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 YaBrowser/22.7.0 Yowser/2.5 Safari/537.36
7 Bun/1.3.0

额，这Chrome版本号是不是有点过于统一了。现在的最新 Chrome 版本已经是 140+ 了。就算为了MV2扩展，也不应该停留在 113、110、129这种版本上吧。
至于最后那个Bun/1.3.0，也非常眼熟嘛，明显是个脚本。

7. 直接Nginx屏蔽这3个版本号试试，反正看了眼统计数据除了攻击者，压根就没人用。

# 屏蔽特定的虚假 Chrome 版本
if ($http_user_agent ~* "Chrome/(110|113|129)\.0\.0\.0") {
    return 444;
}

🎉 最终战果：立竿见影

配置重载后，重新看一下系统占用

• Nginx CPU： 从 25% 瞬间暴跌至 1%~2%。
• 出站流量 (TX)： 从 700KB/s 降至 20KB/s（偶尔跳动至 500KB/s，应该是真实用户的访问）。
• 应用层： PHP-FPM 继续保持 4% 的养老状态。

这才正常嘛，搞定收工。

🕵️‍♂️真相大白：这不是攻击，而是“刷流”

战局已定，服务器恢复了往日的宁静。但作为一个技术人，好奇心驱使我必须把这件事琢磨透：这到底是个啥？
回顾整个事件，它和传统意义上的DDoS或CC攻击截然不同
1. 目的非致死：攻击者精准地将负载和流量控制在报警阈值之下，显然不想让我立刻发现并全力封堵。他的目的不是“打死”我的网站或者一次性薅干我的流量包，而是“持续地、悄悄地偷走”我的出站带宽。
2. 技术特征诡异：固定且无意义的 local_ga_js 参数、集中且陈旧的 Chrome User-Agent（110，113，129）、完全由广东家宽IP构成的庞大且轮换的IP池……这不像黑客工具，更像某种为了模拟“真实用户浏览行为”而设计的工具。
3. 流量流向：我的服务器 RX（接收）: TX（发送） 比例严重失衡，高达1:10以上。这意味着攻击者在用极小的请求成本（入站），换取我服务器返回的大量网页数据（出站）。

把这些线索拼起来，一个合理的推测浮出水面：这很可能是一种新的 “PCDN流量平衡” 又名 “刷下行” 行为。

攻击者（或其背后的平台）控制着一个庞大的家庭宽带设备网络（就是那些“广东电信”IP）。这些设备在使用 PCDN 设备赚钱或 获取 PT 站的积分的时候，为了防止因为上行带宽的比例过高而被运营商发现。于是设备被指令去“访问”一些目标网站（比如我的博客），通过持续请求首页和本地谷歌统计代码这类缓存良好的资源，产生大量的下行流量数据。这些流量数据被记录为“他的正常访问”，而我的服务器则成了默默奉献带宽的“奶牛”。
所以，这不是一场充满恶意的破坏，更像是一次精打细算的“白嫖”。我的服务器，不幸成为了别人赚取小钱钱的一个高质量、稳定的下行带宽资源。这种新型刷下行的手段，抛弃了之前单(几个) IP 直接拉满线程，一晚薅干流量包的行为，不再竭泽而渔，而是改为使用大量 IP 轮换，请求的也是体积不太大的资源，请求频率也控制在适当的范围。

对此我只想说：

对我来说，分享行为在于有效传递信息，即使对方是个伸手怪，白嫖党（虽然我不赞同这种白嫖行为），但只要他真的使用了我的数据。无论是看了一个教程解决了问题，还是看到了我的碎碎谈有了一些启发，还是发现了一个有趣的程序，哪怕他不同意我的看法和我激情对线。我的付出兑现了价值就行！数据发挥了作用，成为了他人的养料。这是一种基础但实实在在的价值实现，我可以接受数据服务于个体价值。
而刷流者呢，他们伪装成一个正常的用户，欺骗我宝贵的上行带宽和服务器资源。他们根本没有对数据的实际需求，其唯一目的就是制造虚假流量来应对 ISP 的监控，给他自己获取利益。这是一种彻头彻尾的欺诈性索取。本质上是将个人利益（无论合理与否）粗暴地建立在牺牲、欺骗、并摧毁其他真正分享者的有限资源之上。它非但不是对抗 ISP 强权的“侠客行为”，反而是对同行者的“背后捅刀”，是数字世界的公敌与污点。对于这类披着 P2P 外衣的流量刷子、电子垃圾虫、损人不利己的赛博脑残，必须予以最强烈的鄙视、唾弃和防范！

🛡️ 尾声：系统恢复与安全启示

1. 监控的阈值，也是攻击者的标尺：攻击者显然针对性研究过参数，将攻击力度精准控制在阈值之下。这提醒我，需要设置更复杂的异常检测规则（如流量同比暴增、非常规时间段的活跃度），而不能只依赖静态阈值。
2. “低频分布式”攻击成为新常态：高调、暴力的攻击容易发现也容易防御。但这种低频、IP海量轮换、模仿正常行为的“慢性消耗”更难察觉。防御思路必须从“封堵单点”转向“识别行为模式”。本次是通过固定参数和异常User-Agent进行拦截。
3. 444状态码是个好东西啊：面对明确定义的恶意请求，直接返回 444（连接关闭） 而非403或404，能最大程度节省服务器资源（尤其是出站流量），让攻击者“偷不到”任何数据包，把损失降到最低。
4. 那个/?local_ga_js=XXXX其实是本地化 Google Analytics 统计代码，这样谷歌分析才能对中国用户生效（虽然谷歌分析的域名没被墙，但访问并不稳定）所以实际上最后用的 Nginx 配置文件是

# 放在 location / 之前
if ($arg_local_ga_js = "f78e59fd91e18c7a2940a914030e9743") {
    return 444;
}

要放过正常用户嘛。
5. 不过鉴于这位刷量的说不好也是订阅了我的博客，所以我又做了一些监控措施，以防他变招。