发布于2026-07-15 阅读(0)
扫一扫,手机访问
先抛结论:真正扛住CC攻击的,是Nginx层的limit_req和limit_conn。TP6.0自身不提供IP级限流能力,应用层黑名单只能补漏,当不了主力。

直接说结论:TP6.0 自身不提供 IP 级限流能力,真正扛住 CC 攻击的必须是 Nginx 层的 limit_req 和 limit_conn;应用层黑名单只能补漏,不能当主力。
这个问题其实很好理解。ThinkPHP6.0 的所有中间件、路由拦截都在 PHP 进程里执行。这意味着什么?请求已经进来了,CGI 启动了,内存分配了,甚至数据库连接可能都建立了。到这一步才去拦截,CPU 和连接资源早就被攻击者耗光了。CC 攻击打的就是这个时间差。
对比一下 Nginx 的做法:limit_req 在 TCP 握手完成、HTTP 头解析之后、转发给 PHP-FPM 之前就判定了。毫秒级响应,不进应用层,不触发任何 PHP 逻辑。这效率差了多少?两个数字说明问题:
limit_req 拒绝一个请求,大约 0.02ms(纯内存查表和计数)所以,让 TP6.0 做主力限流,等于把敌人请进门再动手,代价太大。
很多配置看上去没问题,压测一跑就崩。问题往往出在三个细节上。
第一,zone 的定义位置。limit_req_zone 必须写在 http 块顶层,不能放在 server 或 location 里。否则 reload 时会直接报错“invalid number of arguments”,配置根本不会生效。
第二,key 的选择。务必用 $binary_remote_addr,别用 $remote_addr。前者是二进制压缩的,1MB 内存可以存大约 16000 个 IP;后者是字符串存储,同样内存只能存约 4000 个,zone 很容易爆满。
第三,burst 和 nodelay 的组合。生产环境推荐用 burst=5 nodelay。这个组合的意思是:允许 5 个突发请求立即通过(防止误伤正常用户),超过的直接返回 503 Service Temporarily Una vailable。如果只写 burst=5 不加 nodelay,Nginx 会把超出的请求排队处理,攻击者反而可以靠长连接耗尽 worker 进程。
它解决不了流量洪峰,但能干几件 Nginx 做不了的事:识别登录态用户、关联业务行为(比如 1 小时内下单 100 次)、结合 Redis 实时封禁、记录到审计日志。前提是——请求得先活过 Nginx 这关。
具体怎么用?在 TP6.0 的全局中间件里读取 $_SERVER['REMOTE_ADDR'],查 Redis 黑名单(用 SETNX + EXPIRE)。千万注意:不要用数据库查黑名单。TP6.0 默认没开启查询缓存,每次请求都连数据库,等于自己制造了一个新的性能瓶颈。
封禁动作建议返回 403 Forbidden,并记录到 access.log,方便 Fail2Ban 后续抓取日志自动封 IP。另外,如果用了 CDN,$_SERVER['REMOTE_ADDR'] 拿到的是 CDN 节点的 IP,不是真实用户 IP。这时候需要从 HTTP_X_FORWARDED_FOR 提取真实 IP,但这个 header 可以被伪造,必须配合 Nginx 的 set_real_ip_from 配置来校验。
很多人设了 zone=mylimit:1m,跑两天发现限流失效了。不是配置没生效,是内存满了,旧的 IP 条目被强制清掉,新的攻击 IP 又挤进来,等于限流形同虚设。
这里有三个要点:第一,10MB zone 可以存大约 16 万个 IP 计数状态,中小业务够用;高并发站点建议至少设到 zone=mylimit:50m。第二,Nginx 每次新建条目时,最多删除两条 60 秒未访问的旧记录。如果攻击 IP 持续刷新,老记录根本不会被淘汰,新 IP 就进不来。第三,可以用 nginx -T | grep limit_req_zone 确认配置是否加载成功,再用 curl -I http://your-site/ 看响应头是否有 X-RateLimit-Limit(需要额外加 echo 模块)。
说到底,真正卡住 CC 攻击的,从来不是某一行 PHP 代码,而是 Nginx 配置文件里那几行不起眼的 limit_req_zone 和 limit_req。TP6.0 的黑名单不是盾,是刀——得等敌人冲过第一道门,才轮到它出手。
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
售后无忧
立即购买>office旗舰店
正版软件
正版软件
正版软件
正版软件
正版软件
1
2
3
7
8