宝塔WAF未启动导致SQL注入规则无效，需先启动服务并启用全局+站点级防护、自定义双引号规则；CC防护须用动态阈值，协同系统防火墙、Nginx并发限制与超时优化。
宝塔WAF没启动，所有SQL注入规则都无效
宝塔面板的WAF模块默认不启用，哪怕你装了专业版或免费版，只要服务状态是“已停止”，union select、sleep(、information_schema 这类载荷进来完全不会被拦。必须先确认服务在运行。
进【软件商店】搜“WAF”，看到状态是“已安装”但右侧按钮显示【启动】，就点它；如果按钮是【设置】，说明已运行，可跳过这步。启动后顶部导航栏会出现「WAF」或「堡塔云WAF」入口——注意区分：「宝塔网站防火墙」和「堡塔云WAF」是两套独立系统，别进错。
常见错误现象：403 Forbidden 日志里看不到 SQL 关键词匹配记录；访问 /test.php?id=1%20union%20select%201,2,3 直接返回正常结果页。这基本能断定 WAF 没跑起来。
SQL注入防护要分层配：全局规则 + 站点级严格模式
只开全局规则容易漏掉大小写混淆（如 UnIoN SeLeCt）、空格绕过（union/**/select）或 Base64 编码参数。必须叠加站点级强化策略。
- 进 WAF 设置 → 【规则管理】→ 展开【SQL注入】→ 勾选全部子项，尤其不能漏掉「SQL注释符检测」和「延时函数调用检测」
- 返回首页 → 【网站防护】→ 找到目标站点 → 点【设置】→ 勾选【启用高级SQL注入防护】
- 在【自定义规则】里加一条：匹配
REQUEST_URI或QUERY_STRING中连续出现两个及以上单引号或双引号，动作设为【拦截】
这条自定义规则能抓到很多绕过官方正则的编码变体，比如 %27%27 或 %22%22，比单纯依赖关键词匹配更可靠。
CC攻击不能只靠“每秒20次”这种静态阈值
静态 CC 防护（如 Nginx 防火墙里的固定频率限制）对真实用户重试、移动端网络抖动极其敏感，误拦率高；而动态 CC（如堡塔云WAF的「动态CC防御」）会学习你站点 7 天内的正常访问基线，自动调整触发水位，抗干扰强得多。
关键操作点：
- 务必关闭宝塔站点设置里的「流量限制」→「基础限速」，否则和 WAF 的动态 CC 冲突，日志里会同时出现
503 Service Temporarily Unavailable和403 Forbidden，根本分不清是谁拦的 - 动态 CC 初始阈值填你日常峰值 QPS 的 1.5 倍（例如监控看到最高 25 QPS，这里填 38），别一上来就拉到 10，前 3 天肯定误拦
- 每天去【拦截日志】里看 IP 归属地，把国内主流宽带段（如 117.136.0.0/14）手动放行，避免封掉真实用户
别忽略系统防火墙和并发限制的协同作用
WAF 是应用层过滤，但 CC 攻击第一波往往是海量 TCP 连接打满 worker 进程。光靠 WAF 拦不住连接洪泛，得配合系统层和 Nginx 层硬控。
三项必须同步配置：
- 系统防火墙：进【安全】→【防火墙】→ 开启，并添加规则只放行
80、443、9443（雷池WAF）等必要端口，其他全拒 - 站点并发限制：进该站点 →【流量限制】→ 开启「并发限制」，数值按服务器配：双核2G设
150，单IP限制填20 - 超时时间压缩：同页把「超时时间」从默认
60改成20，让慢速连接更快释放 worker
这三者真正起效的前提是：它们不互相打架。比如你开了堡塔云WAF，又在站点里开了「流量限制」→「博客」模式，Nginx 就会先扔个 503 给 WAF，导致 WAF 日志空白、溯源失败——这种细节最容易被忽略。
