Cloudflare防火墙需自定义规则才能有效拦截恶意流量：威胁分＞20质询、＞50阻断；限制后台路径访问仅限运维IP；针对高危ASN的POST洪峰设质询；宝塔需配置real_ip_from和CF-Connecting-IP头以协同工作。
Cloudflare防火墙规则怎么写才能真正挡掉恶意流量
直接在Cloudflare Dashboard里开“WAF自动模式”基本没用，它只拦截已知攻击指纹，对定制化CC或慢速攻击完全失效。关键得自己写表达式，且必须配合真实日志分析。
常见有效规则组合：
-
(not cf.client.bot and cf.threat_score gt 20)：威胁分＞20就质询，＞50直接阻断（注意cf.threat_score每天更新，不是静态阈值） -
http.request.uri.path contains "/wp-login.php" and ip.src not in {"127.0.0.1", "202.96.134.0/24"}：只放行运维IP访问后台，其他全拦 -
ip.geoip.asnum in {37963 45090} and http.request.method eq "POST"：针对特定ASN的POST洪峰，这类AS常被黑产租用
别盲目套用“拦截所有非中文UA”之类规则——大量合规爬虫（如百度、微信）UA不含中文，会误伤SEO和分享预览。
宝塔Nginx防火墙和Cloudflare怎么协同不打架
两者叠加时最常出问题：Cloudflare把真实IP藏在CF-Connecting-IP头里，但宝塔默认只看remote_addr，结果白名单失效、CC规则乱判。
必须做三件事：
- 在网站配置的
nginx.conf中加入set_real_ip_from段，显式声明Cloudflare IP段（截至2026年4月，最新段见https://www.cloudflare.com/ips-v4） - 把
real_ip_header CF-Connecting-IP加到http{}块里，否则$remote_addr永远是Cloudflare节点IP - 检查
/www/server/nginx/waf/init.lua里ip_white_list是否包含Cloudflare全部IP段（不是只加几个常用段），漏一个就可能触发521错误
改完必须nginx -t校验再systemctl restart nginx——重载（reload）不会重新加载real_ip配置。
Fail2ban怎么把攻击IP同步到Cloudflare而不是只封本地
Fail2ban默认只操作iptables，对CDN后的真实攻击者无效。要让它把IP推到Cloudflare防火墙，得用官方API对接。
核心步骤：
- 在Cloudflare Dashboard生成Global API Key（不是API Token），权限必须含
Zone.Zone和Zone.Firewall - 编辑
/etc/fail2ban/jail.local，在对应jail下加action = cloudflare[cfuser="your@email.com",cfkey="xxx"] - 确保
/etc/fail2ban/action.d/cloudflare.conf存在（宝塔用户可用一键脚本：curl -sS-O https://gitee.com/dayu777/open_shell/raw/main/fail2ban-c.sh && chmod +x fail2ban-c.sh && ./fail2ban-c.sh）
注意：Cloudflare防火墙规则有1000条上限，Fail2ban频繁触发会导致规则溢出失效，建议搭配bantime = 3600（1小时）而非永久封禁。
大流量攻击时宝塔面板本身卡死怎么办
面板卡住不是因为CPU爆了，而是Nginx日志写满磁盘或fail2ban扫描日志文件太慢。这时候手动操作比等面板响应更可靠。
应急命令清单：
- 立刻清空日志缓冲：
echo "" > /www/wwwlogs/nginx_error.log（别用rm，防止程序写入失败） - 临时停掉耗资源服务：
systemctl stop fail2ban && systemctl stop bt（宝塔面板进程名就是bt） - 用
ss -tnp | grep :80 | wc -l看真实连接数，超过3000说明已遭CC，此时应优先在Cloudflare开启“Under Attack Mode”
真正危险的是日志轮转配置缺失——宝塔默认不自动压缩旧日志，/www/wwwlogs目录塞满后整个Nginx会静默崩溃，这个点90%的人根本想不到去查磁盘空间。
