CC攻击无法靠简单封IP解决，因攻击者使用代理池或肉鸡导致IP频繁更换；Nginx原生命令limit_req可在请求早期限流，配合map动态识别恶意路径与UA，再通过fail2ban结合iptables实现精准封禁。
CC攻击不是靠“封IP”就能解决的，Nginx本身没有内置防火墙，所谓“Nginx防火墙”实际是靠限流 + 拒绝响应 + 外部工具协同实现的。直接在 nginx.conf 里写 deny 规则对真实CC几乎无效——攻击者用的是代理池或肉鸡，IP每秒换，硬封等于白忙。
为什么 deny 和 allow 在CC场景下基本没用
这些指令只在 http、server 或 location 块中生效，属于静态访问控制，不感知请求频率、User-Agent异常、Cookie缺失等CC典型特征。更关键的是：deny 发生在请求处理后期，Nginx 已完成连接建立、SSL握手、header解析——攻击流量早已吃满 worker 连接和 CPU。
- 单个IP每秒发100个请求？
deny 1.2.3.4顶多拦住这一个IP，但CC通常来自上千个不同IP - 攻击者用 Selenium、headless Chrome 模拟真实浏览器？
deny完全无法识别 - 你手动查日志封IP，速度远低于攻击发起速度，
tail -f access.log | grep "POST /login" | awk '{print $1}' | sort | uniq -c | sort -nr查出来时，这批IP可能已切换
真正有效的第一道防线：用 limit_req 控制单IP请求数
这是 Nginx 原生命令，内核级限流，开销极低，且在请求早期（解析完 header 后、进入 location 前）就触发。必须配合 limit_req_zone 定义共享内存区域，否则会失效。
http {
# 定义限流区域：以 $binary_remote_addr（压缩后的IP）为key，10m内存约存16万IP
limit_req_zone $binary_remote_addr zone=cc_limit:10m rate=10r/s;
<pre class='brush:php;toolbar:false;'>server {
location / {
# 突发允许最多5个请求，超过即503；nodelay可改为burst=5 delay=1
limit_req zone=cc_limit burst=5 nodelay;
proxy_pass http://backend;
}
}}
-
rate=10r/s是关键阈值：正常用户点页面不会每秒刷10次，但CC脚本轻松做到100+，这里先卡死量级 - 别用
$remote_addr，它未标准化，IPv6下可能出错；$binary_remote_addr更稳定、省内存 - 如果后端是 API 接口（如
/api/v1/submit），应单独配更严策略：rate=2r/s burst=1 - 注意：该限流对 HTTPS 的 SNI 阶段无影响，但能有效压低后续 HTTP 请求洪峰
进阶防御：用 map + limit_req 区分正常流量和可疑行为
纯按 IP 限流会误伤 NAT 用户（比如整个公司出口是一个IP）。更合理的方式是结合请求特征动态打标，再限流。
http {
map $request_uri $is_cc_path {
~*"/wp-login.php|/xmlrpc.php|/phpmyadmin" 1;
~*"\.(php|jsp|asp)\??.*" 1;
default 0;
}
<pre class='brush:php;toolbar:false;'>map $http_user_agent $is_bad_ua {
~*(python-requests|curl|httpie|Go-http-client) 1;
~*(HeadlessChrome|PhantomJS|Node-fetch) 1;
default 0;
}
limit_req_zone $binary_remote_addr$host$is_cc_path$is_bad_ua zone=smart_cc:10m rate=3r/s;
server {
location / {
limit_req zone=smart_cc burst=2 nodelay;
proxy_pass http://backend;
}
}}
-
map指令必须在http块顶层定义，不能放在server内 - 匹配逻辑是“或”，所以把高危路径和恶意 UA 合并进同一个
limit_req_zonekey，让它们共用额度 - 不要过度依赖
User-Agent过滤——高级CC会伪造 Chrome UA，但它很难同时伪造 Referer、Accept-Language、Cookie 等字段 - 这个方案仍无法防住真实浏览器集群攻击，需配合下一环
必须搭配系统层工具：用 fail2ban 抓日志+封禁到 iptables
Nginx 只能限流，真要阻断连接，得让内核丢包。fail2ban 是唯一被广泛验证的方案：它监控 access.log，匹配规则后调用 iptables 或 nftables 封禁源IP，且支持自动解封。
- 安装后，编辑
/etc/fail2ban/jail.local，添加自定义 jail：
[nginx-cc] enabled = true filter = nginx-cc logpath = /var/log/nginx/access.log maxretry = 30 findtime = 60 bantime = 3600 action = iptables[name=nginx-cc, port=http,protocol=tcp]
- 再新建
/etc/fail2ban/filter.d/nginx-cc.conf，写精准正则（例如匹配1秒内10个 POST）：
[Definition] failregex = ^<HOST> -.*"(POST|GET).*HTTP.*" 200 .* ignoreregex =
- 关键点：
findtime和maxretry要根据业务调整——电商秒杀期间可能天然高并发，不能照搬默认值 - 封禁走
iptables比ipset更通用，但若 IP 量超5000，建议改用ipset避免规则膨胀 - 务必确认服务器开启了
net.ipv4.conf.all.rp_filter=1，否则伪造源IP的SYN Flood可能绕过 iptables
真正的难点不在配置，而在于区分“攻击流量”和“突发合法流量”。比如发布会开抢、微博热搜导流、爬虫合规采集——它们的表现和CC高度相似。没有银弹，limit_req 是底线，fail2ban 是兜底，中间那层业务特征分析（如登录频次、Token有效性、JS挑战）必须由应用自己承担。
