宝塔免费版nginx防火墙可通过设置触发周期60秒、触发频率10–30次/分钟实现基础cc拦截，但需避免误封正常用户；专业版支持智能学习、post防护及会话级限流；推荐结合nginx原生命令limit_req精准限流，并注意cdn下ip识别问题。
怎么用宝塔免费版防火墙做基础CC拦截
宝塔免费版的Nginx防火墙能拦住大部分低强度CC攻击，但不是“开箱即用”，得调对两个关键数字：触发周期和触发频率。它统计的是「同一IP在指定秒数内对任意URI发起的请求数」，超了就临时封——不是封1小时，而是封默认的60秒（不可改），所以必须让阈值足够敏感又不误伤正常用户。
- 进【软件商店】确认已安装并启用
Nginx防火墙(免费版)；没装就先装，装完别忘了点「启动」 - 进插件设置 → 【网站配置】→ 找到你的站点 → 点【配置】→ 切到【CC防御】页签
- 勾选【开启CC防御】，设
触发周期为60秒，触发频率建议从15开始试（博客类站点可压到10，API接口类建议30以上） - 保存后，立刻去【黑名单】页签看有没有新IP自动进来；如果全是搜索引擎IP（如
googlebot），说明阈值太低，得调高
坑点在于：它不区分GET/POST、不看Cookie、也不管是不是真实用户。刷首页轮播图、点“加载更多”连发5次，就可能被当成CC干掉。所以别盲目压到个位数。
专业版的智能模式到底强在哪
专业版的CC防御不是简单加个数字，而是把「封谁」「封多久」「凭什么封」拆开了控制。比如你开「智能模式」，它会先默默学你站点24小时的正常访问节奏，再动态定阈值；而「严格模式」则直接按UA+Referer+请求路径组合打分，对模拟浏览器的脚本更狠。
- 进【网站】→ 【防火墙】→ 【全局配置】→ 【CC防御】，选
智能模式（比普通模式多一层基线学习） - 单独点某个站点的【配置】→ 【CC防御】，可以额外打开
POST请求CC防护（防暴力提交）或Cookie会话级限流（防账号爆破） - 在【全局配置】→ 【恶意容忍度】里设
连续恶意请求封禁阈值，例如填3，系统就会记IP的“坏行为次数”，满3次就封24小时，比免费版的固定60秒靠谱得多 - 别忘了开【蜘蛛池】，否则百度、Bing爬虫更新索引时可能被当成CC源误杀
注意：专业版规则由宝塔云端实时更新，但首次启用后要等约15分钟才开始学习流量基线，这期间建议手动盯一下【防火墙日志】，确认没把正常用户拖进黑名单。
为什么推荐手动加 limit_req 而不是全靠防火墙
防火墙是应用层过滤，走完整HTTP解析流程；而 limit_req 是Nginx原生命令，在请求刚进worker进程时就掐住，CPU和内存开销几乎为零。尤其对付高频但合法的请求（比如监控探针每秒轮询健康接口），用 limit_req 更精准、更稳。
- 进站点【设置】→ 【配置文件】，在
server块开头加：limit_req_zone $binary_remote_addr zone=perip:10m rate=8r/s;
- 在
location /块里加：limit_req zone=perip burst=16 nodelay;
（意思是：允许突发16个请求，但平均不能超8qps） - 保存后点【重载配置】，不是重启Nginx——重载即可生效，且不会中断现有连接
- 如果只想限API接口，把第二步的
location /换成location ^~ /api/即可，不用动全站
常见错误：burst 设太大（比如100），等于白限；nodelay 没加，会导致请求排队卡顿，用户感知就是“页面转圈半天”。这两个参数必须一起理解着调。
怎么验证限流真起了作用
别只信后台日志，得从攻击者视角实测。用 curl 或简单Python脚本发几轮请求，看返回状态码和响应头，才能确认是“挡住了”还是“只是慢了”。
- 终端里快速测：执行
for i in {1..20}; do curl -s -o /dev/null -w "%{http_code}\n" https://your-site.com/; done | sort | uniq -c，如果大量出现503，说明limit_req生效；如果是444（Nginx静默关闭），说明防火墙在起作用 - 检查Nginx错误日志：
tail -f /www/wwwlogs/your-site.error.log，看到limiting requests就是limit_req在拦；看到CC attack detected就是防火墙在拦 - 观察【安全】→ 【防火墙】→ 【防火墙日志】，重点看被封IP的「触发规则」字段：写的是
CC-PerIP还是CC-URI，对应你配的是IP级还是URL级策略
最容易被忽略的一点：所有限流都依赖客户端IP准确。如果你用了CDN（比如Cloudflare），$binary_remote_addr 拿到的是CDN节点IP，不是真实用户IP——这时必须配合 $http_x_forwarded_for 并在Nginx里做可信代理配置，否则限流全乱套。
