宝塔Nginx防御CC，Fail2ban封禁教程详解

本文深入剖析了CC攻击防御的合理分层策略：明确指出Fail2ban仅能作为辅助“精准清剿队”，用于事后封禁绕过WAF的顽固恶意IP，而绝不能承担主防职责——因其基于日志的滞后封禁机制无法应对CC攻击“合法请求+分散IP+低频节奏”的本质，更无法缓解Nginx/PHP-FPM等资源层压力；真正的实时流量管控必须依赖Nginx原生limit_req实现毫秒级速率限制，并配合宝塔WAF模块进行首道拦截；同时详解了CDN环境下获取真实IP、Fail2ban对接WAF日志的精准配置、永久封禁设置及Nginx原生geo+map方案封禁IP段等关键实践，帮助运维人员构建高效、稳定、可落地的多层防御体系。

Fail2ban 本身不能直接防御大规模 CC 攻击，它不处理请求速率限制，只做日志驱动的 IP 封禁；真正在 Nginx 层拦截高频请求的，是 limit_req 和宝塔 WAF 的 CC 防御模块。Fail2ban 在这里只适合补位：封掉已确认恶意、且绕过 WAF 的顽固 IP（比如低频扫描 + 高危路径访问组合）。

为什么不能靠 Fail2ban 主防 CC？

CC 攻击的核心特征是“合法请求 + 分散 IP + 低频节奏”，Fail2ban 默认规则（如 nginx-http-auth）依赖 401/403 状态码或登录失败日志，而真实 CC 流量往往返回 200，压根不触发匹配。即使你自定义 filter 匹配高请求数，Fail2ban 的 findtime/maxretry 是基于日志行数统计，不是实时请求流控——等它数完 100 行，服务器可能已经 OOM 了。

更关键的是：Fail2ban 封 IP 走的是 iptables 或 firewalld，属于网络层拦截；而 CC 请求在到达防火墙前，早已消耗完 Nginx worker 进程、PHP-FPM 连接池或数据库连接。封得再快，资源早被榨干。

所以别把 Fail2ban 当主力，它只是最后一道“守门人”，不是“流量闸门”。

真正该在 Nginx 配置里加的，是 limit_req

在宝塔面板中，进入「网站」→ 对应站点 → 「配置文件」，在 server 块内插入以下片段（注意位置：必须在 location / 或具体 path 内）：

limit_req_zone $binary_remote_addr zone=cczone:10m rate=15r/s;
limit_req zone=cczone burst=30 nodelay;

说明：

• rate=15r/s：单 IP 每秒最多 15 个请求，超了就 503；博客类站点可设为 10r/s，API 接口建议 30r/s 以上
• burst=30：允许突发 30 个请求缓存，避免用户点“刷新”被误杀
• nodelay：不延迟响应，立刻拒绝超额请求（不加它会排队，反而加重后端压力）
• 别用 $remote_addr：CDN 回源时它永远是 CDN 节点 IP，必须用 $binary_remote_addr 配合宝塔的 real_ip 设置才准

如果用了 CDN（如 Cloudflare），务必先在宝塔「网站」→「设置」→「配置修改」里开启「获取真实 IP」，否则 limit_req 全部失效。

Fail2ban 只能当“精准清剿队”，不是“城墙”

如果你坚持要用 Fail2ban 辅助防 CC，请只用于识别明确攻击行为，例如：

• 1 分钟内访问 /wp-login.php、/admin.php、/phpmyadmin/ 超 3 次
• 日志中出现大量 404 + 敏感路径（如 .git/config、/.env）
• 同一 IP 在 60 秒内触发宝塔 WAF 的多个规则（需解析 WAF 日志）

配置要点：

• logpath 必须指向宝塔 WAF 日志：/www/wwwlogs/waf/*.log，不是 Nginx access.log
• filter 文件里正则要严格：用 ^.*"GET /wp-login\.php.*" 404，避免匹配到正常 404 页面
• actionban 不要用默认的 iptables，改用 firewallcmd-ipset（宝塔默认用 firewalld），否则封禁无效
• 封禁时间设为 bantime = -1（永久），因为 CC 攻击者不会反复用同一个 IP 扫描，临时封等于放水

验证是否生效：不要刷网页看 403，而是执行 sudo firewall-cmd --list-rich-rules | grep f2b，确认规则已写入 firewalld。

IP 段封禁必须绕开 Fail2ban，走 Nginx geo+map

Fail2ban 根本不支持 CIDR，写 192.168.0.0/16 会直接导致 fail2ban-client reload 报错 Invalid ip address。想封段，只能靠 Nginx 自身机制：

在宝塔「网站」→「配置文件」里，http 块开头加入：

geo $bad_ip {
    default 0;
    include /www/server/panel/vhost/blacklist/ip_blacklist.conf;
}
map $bad_ip $blocked {
    1 1;
    0 0;
}

然后在 server 块里加：if ($blocked) { return 403; }

维护 /www/server/panel/vhost/blacklist/ip_blacklist.conf 文件，内容格式为：

1.2.3.0/24 1;
5.6.0.0/16 1;

每次修改后手动重载 Nginx：nginx -s reload。这个方案稳定、无兼容问题，且支持任意 CIDR 段。

复杂点在于：IP 段列表得自己生成并去重，不能指望 Fail2ban 自动转；另外，Nginx 的 geo 模块对超大列表（>10 万行）有性能衰减，别一股脑塞进威胁情报全量数据。

今天关于《宝塔Nginx防御CC，Fail2ban封禁教程详解》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！