当你的Nginx服务频繁出现CPU飙升、连接数爆满，但业务日志里却看不到明显异常时，很可能正遭受应用层CC攻击。这类攻击不像SYN Flood那样直接冲击网络层，而是模拟真实用户请求，持续消耗应用资源。配置Nginx CC防护模块是缓解此类攻击的有效手段，但首先需要判断攻击特征，再选择匹配的防护策略。
先判断：你的服务是否真的需要CC防护模块？
在动手配置前，先确认攻击类型。CC攻击（Challenge Collapsar）本质是应用层DDoS，通过大量看似合法的请求耗尽服务器资源。你可以通过以下路径快速判断：
- 观察连接状态：使用
ss -s或netstat查看TIME_WAIT和ESTABLISHED连接数，若异常高且集中在特定IP段，可能为CC攻击。 - 分析访问日志：检查Nginx日志中同一IP的请求频率，若单个IP每秒请求数超过正常阈值（如>10次），则需警惕。
- 检查资源占用：
top命令查看CPU和内存，若nginx进程占用极高但业务量未增长，则可能被攻击。
只有当确认是应用层攻击时，配置CC防护模块才有意义。若为网络层攻击（如SYN Flood），则应考虑使用高防IP或调整内核参数。Cloudflare的DDoS防护文档指出，其系统能自动检测并缓解第3/4层和第7层攻击，但Nginx本身更侧重于第7层防护。
Nginx可用的CC防护模块有哪些？
Nginx本身不内置专门的CC防护模块，但可通过以下方式实现类似功能：
1. ngx_http_limit_req_module（官方限流模块）
这是Nginx官方提供的模块，基于漏桶算法限制请求速率。配置简单，适合基础防护。核心指令为limit_req_zone和limit_req。
limit_req_zone $binary_remote_addr zone=cc:10m rate=5r/s;
server {
location / {
limit_req zone=cc burst=10 nodelay;
proxy_pass http://backend;
}
}上述配置表示每个IP每秒最多5个请求，允许突发10个。但该模块无法区分正常用户和恶意爬虫，误杀率较高。
2. 第三方模块（如ngx_http_limit_conn_module、OpenResty的lua-resty-limit-traffic）
OpenResty基于Nginx，通过Lua脚本实现更灵活的限流，例如基于用户行为动态调整阈值。但需要额外安装和编写脚本，门槛较高。
3. 集成WAF（如ModSecurity）
ModSecurity是开源WAF，可部署在Nginx中，通过规则库识别恶意请求。但配置复杂，且对性能有一定影响。
选择哪种模块取决于你的技术栈和攻击强度。若仅需简单限流，官方模块足够；若需精细化防护，可考虑OpenResty或WAF。
配置步骤：从基础到进阶
第一步：启用官方限流模块
大多数Nginx发行版已包含ngx_http_limit_req_module，无需额外编译。只需在http块中定义共享内存区域和速率，然后在server或location中引用。
第二步：结合连接数限制
使用limit_conn_zone限制单个IP的并发连接数，防止慢速连接耗尽资源。
limit_conn_zone $binary_remote_addr zone=perip:10m;
server {
location / {
limit_conn perip 10;
proxy_pass http://backend;
}
}第三步：配置缓存以减轻后端压力
Cloudflare缓存文档强调，缓存频繁访问的内容可显著降低源站负载。Nginx同样支持缓存，通过proxy_cache_path和proxy_cache指令，将静态资源或动态页面缓存到本地，减少后端处理请求数。这不仅能提升性能，还能在攻击时吸收部分流量。
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
location / {
proxy_cache my_cache;
proxy_pass http://backend;
}
}第四步：动态调整策略（进阶）
若攻击频繁变化，可借助OpenResty的Lua脚本实现动态限流。例如，根据请求URL或User-Agent分类限流，或对异常IP进行临时封禁。但需注意，脚本本身可能成为新的性能瓶颈。
参数调优：如何设置合理阈值？
阈值设置过松则防护无效，过紧则误杀正常用户。建议基于历史流量分析：
- 速率：统计正常用户平均请求频率，设置为其3-5倍。例如，若正常为1r/s，可设为5r/s。
- 突发：允许一定的突发量，避免正常用户因短暂高峰被拦截。burst值可设为速率的2-3倍。
- 连接数：根据业务并发量，设置单IP连接数上限，通常为10-20。
配置后需持续监控，使用access_log记录被限制的请求，观察误杀情况。Cloudflare的DDoS防护文档提到，其系统会自动调整规则，但Nginx需要手动调整。
常见误区与失败条件
误区一：认为限流模块能完全抵御CC攻击
限流只能减缓攻击速度，无法彻底阻断。攻击者可通过分布式IP（肉鸡）绕过IP限制，此时需结合其他手段，如WAF或高防CDN。ZuCDN的文章《高防CDN+高防IP联合组网》中提到，高防CDN可过滤大部分应用层攻击。
误区二：忽略缓存配置
不配置缓存，后端服务器直接承受所有请求，即使限流，合法请求也可能拖垮服务。缓存是缓解攻击的重要一环，应优先配置。
误区三：阈值设置过于严格
若速率设为1r/s，正常用户可能被误杀，导致业务受损。务必先做流量分析，再设置阈值。
失败条件：
- 攻击者使用大量IP，限流模块失效。
- 配置错误，导致Nginx无法启动或功能异常。
- 未结合缓存，后端资源耗尽。
此外，Nginx模块无法识别应用层攻击的语义特征（如SQL注入），需配合WAF规则。Cloudflare的DDoS防护文档指出，其系统能自动检测并缓解第7层攻击，但Nginx需额外配置。
无法覆盖的场景：何时需要外部防护？
当攻击流量超过服务器带宽或Nginx性能极限时，仅靠模块配置难以奏效。此时应考虑：
- 使用CDN服务（如Cloudflare）分散流量。
- 部署高防IP或高防CDN，将攻击流量引流至清洗设备。
Cloudflare缓存文档提到，其全球网络可缓存内容并就近访问，同时DDoS防护系统自动缓解攻击。但迁移至Cloudflare需要调整DNS和配置，适合长期防护。
参考资料
延伸阅读