1. 项目概述：为什么Nginx是防御CC攻击的首选
做Web服务运维的同行，大概都经历过服务器CPU或连接数突然飙升，网站响应变得奇慢无比甚至直接挂掉的时刻。很多时候，这不是流量暴涨带来的“甜蜜烦恼”，而是遭遇了CC攻击。CC攻击，全称Challenge Collapsar，你可以把它理解为一种针对应用层的“慢速”DDoS。攻击者并不追求瞬间打垮你的带宽，而是通过控制大量“肉鸡”或代理服务器，模拟真实用户行为，高频地请求你网站上那些消耗资源大的动态页面（比如登录、搜索、数据库查询），目的就是耗尽你的服务器CPU、内存或数据库连接池，让正常用户无法访问。
面对这种攻击，在服务器入口处部署一道高效的过滤网至关重要。而Nginx，凭借其高性能、高并发处理能力和灵活的模块化架构，天然就是这道屏障的最佳载体。它不像硬件防火墙那样成本高昂，也不像单纯依靠操作系统防火墙那样功能单薄。通过精细化的配置，Nginx可以在请求到达后端应用（如PHP、Java服务）之前，就识别并拦截掉大部分恶意流量。这不仅仅是加几条规则，而是构建一个从连接控制、请求频率限制到智能验证的多层次纵深防御体系。今天要聊的，就是如何把这套体系落地，让你手头的Nginx从单纯的Web服务器或反向代理，升级为守护业务高可用的第一道智能屏障。
2. 防御体系设计：从单点限制到智能联动
在动手改配置之前，得先想清楚防御策略。一个有效的CC防御体系不是一堆规则的堆砌，而是一个有层次、有关联的有机整体。核心思路是：快速识别、分层过滤、减少误杀。
2.1 核心防御层次解析
我的防御体系通常分为四层，像漏斗一样层层过滤：
- 网络连接层控制：这是最底层，基于IP和TCP协议。目标是在恶意请求消耗大量应用资源之前，就在网络层面进行限制。主要手段是限制单个IP的连接数和请求速率。这能有效应对那些使用较少“肉鸡”但每个“肉鸡”发起大量连接的攻击模式。
- 请求频率层限制：这一层关注的是HTTP请求的速率。即使连接数不多，攻击者也可能在单个连接内快速发送大量请求。我们需要在Nginx的HTTP处理阶段，对特定URL（尤其是登录、提交表单、API接口）的访问频率进行限制。
- 请求特征层过滤：很多CC攻击工具发出的请求带有明显特征，例如固定的User-Agent、缺失或异常的Referer、针对特定参数的重复攻击等。通过识别这些特征，可以直接拦截，精准性高。
- 动态挑战层：对于经过前三层仍未完全阻断的、疑似恶意的流量，可以引入轻量级的挑战，例如返回一个特殊的验证码（如简单的JavaScript计算题），或者将请求重定向到一个静态等待页。真实用户的浏览器会自动处理，而很多简单的攻击脚本则会在此“卡壳”。
2.2 关键模块选型与考量
Nginx实现这些功能，主要依赖其核心模块和第三方模块：
ngx_http_limit_conn_module和ngx_http_limit_req_module：这是Nginx官方内置的“王牌”模块，分别用于限制连接数和请求速率。它们稳定、高效，是防御体系的基石。必须启用。ngx_http_access_module：用于基于IP的访问控制。虽然对于分布式CC攻击直接封IP效果有限，但对于拦截已知攻击源、扫描器IP依然简单有效。ngx_http_map_module：这个模块非常强大，用于创建变量映射。我们可以用它来定义黑名单IP列表、可疑的User-Agent列表等，为后续的条件判断提供数据源。- 第三方模块考量：对于更复杂的需求，如集成JavaScript挑战，可以考虑像
ngx_http_js_challenge_module这样的第三方模块。但引入第三方模块需谨慎，需评估其稳定性、兼容性和维护状态。在大部分场景下，利用好官方模块的组合已经足够。
选择这些模块的核心逻辑是：优先使用成熟、内置的方案，在性能开销和防御效果间取得平衡。避免引入过多复杂逻辑拖慢正常请求的处理速度。
3. 核心配置实战：逐行拆解与参数调优
理论说完，我们进入实战环节。以下配置均需写入Nginx的配置文件（通常是nginx.conf或sites-available/下的独立配置文件），并重载Nginx生效 (nginx -s reload)。
3.1 连接数与请求速率限制
这是防御的“基本款”，必须配置好。
首先，在http{}块内定义共享内存区：
http { # 定义限制连接数的共享内存区，名为addr，大小10m，可以存储约16万个IP的状态 limit_conn_zone $binary_remote_addr zone=addr:10m; # 定义限制请求速率的共享内存区，名为one，大小10m，速率限制为每秒10个请求（10r/s） limit_req_zone $binary_remote_addr zone=one:10m rate=10r/s; # 可选：针对特定URL（如登录）设置更严格的限制区 limit_req_zone $binary_remote_addr $request_uri zone=login:10m rate=2r/s; ... }注意：这里使用
$binary_remote_addr而非$remote_addr，是因为前者用二进制格式存储IP，占用空间更小（约4字节），相同内存能存储更多状态。10m的内存大约能存储16万个独立IP的状态，可根据业务规模调整。
然后，在server{}或location{}块中应用限制：
server { listen 80; server_name yourdomain.com; # 全局应用请求速率限制：延迟处理模式，突发队列不超过5个请求 limit_req zone=one burst=5 nodelay; # 全局应用连接数限制：每个IP同时最多允许10个连接 limit_conn addr 10; location / { root /var/www/html; index index.html; } # 对登录接口应用更严格的限制 location /api/login { # 使用专门的login限制区，突发队列为3，无延迟（超过直接返回503） limit_req zone=login burst=3 nodelay; # 此接口连接数限制更严 limit_conn addr 3; # 代理到后端应用服务器 proxy_pass http://backend_server; } # 设置被拒绝请求的返回状态码和页面 limit_req_status 429; # Too Many Requests limit_conn_status 503; # Service Temporarily Unavailable error_page 429 /429.html; error_page 503 /503.html; location = /429.html { ... } location = /503.html { ... } }参数调优心得：
burst（突发队列）：这个参数很关键。设为0意味着超过速率的所有请求立即被拒（nodelay模式）或等待（无nodelay）。设置一个合理的burst（如5-10）可以容忍正常用户的短暂请求高峰，比如页面加载时瞬间请求多个资源。nodelay参数会让突发队列中的请求也立即处理，但不影响限制的平均速率。- 区分场景：像首页、静态资源可以放宽限制（如
rate=30r/s），而对登录、搜索、提交订单等动态接口必须严格限制（如rate=2r/s）。这需要对业务接口的访问模式有清晰了解。
3.2 基于请求特征的过滤规则
攻击脚本的请求往往有迹可循。我们可以利用map和if指令（谨慎使用）进行过滤。
定义黑名单和特征映射：
http { # 定义一个变量 $bad_ua，匹配常见的恶意爬虫或攻击工具UA map $http_user_agent $bad_ua { default 0; ~*(python|curl|wget|scan|nikto|sqlmap) 1; # 包含这些关键词的UA视为可疑 "~*^$" 1; # 空UA也视为可疑 } # 定义IP黑名单（可以结合外部动态更新） map $remote_addr $ip_blacklist { default 0; 1.2.3.4 1; # 示例恶意IP 5.6.7.8 1; } ... }在server{}块中应用过滤：
server { ... # 如果IP在黑名单中，直接返回403 if ($ip_blacklist) { return 403; } # 如果User-Agent被识别为恶意，可以记录日志并返回错误，或引入挑战 location / { if ($bad_ua) { # 记录到特殊日志文件便于分析 access_log /var/log/nginx/bad_ua.log main; # 直接返回444（Nginx特有，关闭连接不发送响应头，消耗最小） return 444; # 或者返回一个简单的JS挑战页 # return 200 "<html><script>document.cookie='challenge_passed=1'; location.reload();</script></html>"; # 注意：需要配合cookie检查使用，此处仅为示例。 } ... } # 针对特定攻击模式：防止对某个参数的高频攻击（例如：?id=xxx） location ~* \.php$ { # 限制对带有id参数的请求频率（需结合limit_req_dynamic等，此处为逻辑示例） # 更佳实践是通过 $request_uri 在 limit_req_zone 中定义特定区域。 ... } }重要提示：Nginx官方文档建议谨慎使用
if指令，因为它在某些上下文中不符合预期行为。上述在server和location层级的if用于简单的返回是相对安全的。但对于复杂的重写或代理逻辑，应尽量使用map生成变量，再在location中根据变量值进行判断。
3.3 动态挑战与验证码集成
对于高级别的防护，或者当频率限制可能误伤时，动态挑战是很好的补充。一个简单的实现思路是使用auth_request模块或lua模块（如 OpenResty）。
这里给出一个利用error_page和子请求模拟挑战的简化思路：
- 设计一个挑战接口：在后端或一个简单的Nginx location中，实现一个生成并验证令牌（如一个简单的数学问题答案）的接口。
- 在Nginx中拦截疑似请求：
# 定义一个映射，通过某些条件（如请求速率超过阈值但未触发limit_req）设置一个标记变量 map $slow_request $need_challenge { default 0; 1 1; } server { ... location / { # 当需要挑战时，内部重定向到挑战页面 if ($need_challenge) { # 设置一个cookie记录原始请求URL add_header Set-Cookie "original_uri=$request_uri; Path=/"; # 重定向到挑战页面 return 302 /challenge.html; } proxy_pass http://backend; } location = /challenge.html { # 返回一个包含简单JS计算题的HTML页面，提交答案到 /verify_challenge alias /path/to/challenge_page.html; } location = /verify_challenge { # 验证客户端提交的答案 # 如果正确，重定向回 original_uri 并设置一个通过验证的cookie（有过期时间） # 如果错误，返回错误信息或增加错误计数 # 此处需要一些简单的后端逻辑，可以用Nginx的 $arg_ 变量获取参数，用 if 进行基本判断，复杂情况建议用少量Lua或代理到微型后端。 ... } # 在真正处理业务的位置，检查挑战通过的cookie location ~ \.php$ { if ($cookie_challenge_passed != "1") { # 可再次判断是否需要挑战，避免无限循环 set $need_challenge 1; } proxy_pass http://backend; } }这个方案相对复杂，但它展示了一种思路：将可疑流量引入一个交互式环节，利用浏览器自动化与脚本自动化的差异进行过滤。
4. 高级策略与运维实践
配置不是一劳永逸的，防御需要持续的观察和调整。
4.1 日志分析与攻击识别
Nginx的访问日志是金矿。你需要配置详细的日志格式，并定期分析。
http { log_format main '$remote_addr - $remote_user [$time_local] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for" ' 'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"'; access_log /var/log/nginx/access.log main buffer=32k flush=5s; }分析时，重点关注：
- 高频IP：
awk '{print $1}' access.log | sort | uniq -c | sort -nr | head -20 - 高频请求URL：
awk -F\" '{print $2}' access.log | awk '{print $2}' | sort | uniq -c | sort -nr | head -20 - 响应时间异常：结合
$request_time和$status，找出响应慢且返回状态码可能是404、502的请求，这可能是攻击者在扫描或攻击不存在的端点。 - 特定User-Agent或Referer：快速定位可疑的流量模式。
可以将这些分析做成定时任务（如每分钟的crontab），当某个IP的请求频率在短时间内超过阈值，自动将其IP加入一个临时黑名单文件，然后通过include指令让Nginx加载。这实现了简单的动态封禁。
4.2 与操作系统及上游的联动
Nginx不是孤岛。
- 操作系统层面：在Nginx之前，可以使用
iptables(Linux) 或firewalld设置更底层的连接数限制（如iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j REJECT），作为第一道粗粒度防线。但注意，这可能会影响正常用户的并发连接。 - 上游应用层面：与后端应用（如PHP-FPM、Java应用服务器）的配置联动。例如，确保PHP-FPM的
pm.max_children、pm.max_requests设置合理，避免单个进程被攻击请求拖垮。Nginx的proxy_next_upstream指令可以配置当后端返回特定错误码（如502、503）时，尝试转发到其他上游服务器，这对于负载均衡集群的高可用很有帮助。 - Docker/K8s环境：在容器化部署时，Nginx配置通常通过ConfigMap挂载。要确保配置的热更新能力。在K8s中，可以考虑将Nginx作为Ingress Controller（如使用Nginx Ingress Controller），其配置方式有所不同，但防御原理相通，可以通过Annotations来配置限速等规则。
4.3 配置管理与平滑重载
防御规则需要经常更新。务必使用nginx -t测试配置语法正确后再重载。平滑重载 (nginx -s reload) 是生产环境的标准操作，它不会中断正在处理的连接。
建议将防御配置模块化，例如：
limit.conf：存放所有limit_conn_zone,limit_req_zone定义。blacklist.conf：存放通过map定义的IP或UA黑名单。server_security.conf：存放应用到具体server或location的limit_req,limit_conn,if判断等规则。
在主配置文件中用include指令引入。这样管理起来清晰，也便于版本控制。
5. 常见问题排查与性能调优
在实际部署中，你会遇到各种问题。这里记录几个典型的坑和解决方案。
5.1 配置不生效或日志报错
- 问题：配置了
limit_req但似乎没效果。- 排查：首先检查Nginx错误日志 (
error.log)。查看limit_req_zone定义的内存区名称和大小是否在limit_req指令中正确引用。确保指令放在正确的上下文中（http,server,location）。 - 注意：
limit_req和limit_conn对通过proxy_pass向上游转发的请求同样有效，但对Nginx直接服务的静态文件请求也有效。
- 排查：首先检查Nginx错误日志 (
- 问题：
unknown directive "limit_req_zone"。- 排查：说明Nginx编译时没有包含
--with-http_limit_req_module。使用nginx -V查看编译参数。如果是包管理器安装的，通常已包含。如需自定义编译，务必加上此参数。
- 排查：说明Nginx编译时没有包含
- 问题：重载配置后，部分用户被误拦截。
- 排查：检查
burst和rate参数是否设置过严。特别是对于首页、CSS/JS资源等，正常访问也可能在短时间内产生较多请求。考虑为静态资源设置独立的、更宽松的location块，或者使用limit_req的delay参数（不加nodelay）让超出的请求排队等待而不是直接拒绝。
- 排查：检查
5.2 性能影响与优化
防御配置必然带来一定的性能开销，目标是将其降到最低。
- 共享内存区大小 (
10m)：设置太小，在高并发下可能导致状态存储溢出，限制失效。设置太大浪费内存。监控nginx -s info（如果支持）或通过awk分析日志，估算独立IP数。一个经验公式：10m内存大约可以存储 16万（160000）个不同的$binary_remote_addr状态。根据业务峰值调整。 - 大量使用
map和if：复杂的map映射和if判断会增加每个请求的处理时间。尽量将判断前置，例如在map中匹配简单的字符串，避免使用复杂的正则表达式，尤其是嵌套的if。 - 日志记录：对疑似攻击的请求记录到独立日志文件是好习惯，但确保磁盘I/O不会成为瓶颈。使用
buffer和flush参数进行缓冲写入。 - 压力测试：在调整完防御规则后，务必进行压力测试（可以使用
wrk,ab,jmeter等工具），观察在正常流量和模拟攻击流量下，服务器的资源消耗（CPU、内存、Nginx工作进程状态）和正常请求的响应时间是否在可接受范围内。
5.3 误封与用户体验平衡
这是防御中最难的部分。完全不让一个正常用户受影响几乎不可能，但可以尽量减少。
- 设置白名单：对于已知的合作伙伴IP、搜索引擎爬虫（需验证其真实IP段）、公司内部网络等，务必设置白名单，绕过所有频率限制。可以通过
geo模块或map模块实现。geo $whitelist { default 0; 192.168.1.0/24 1; # 内网 203.0.113.1 1; # 某个合作伙伴IP } location / { if ($whitelist) { break; # 跳过后续的限制规则 } limit_req zone=one burst=5 nodelay; ... } - 使用Cookie或Token作为限制维度：对于已登录用户，可以使用其用户ID（存储在Cookie或Token中）作为
limit_req_zone的键，而不是IP地址。这可以避免同一局域网（如公司、学校）出口IP相同导致的所有用户被连带限制的问题。但需要注意用户ID的伪造风险。 - 提供友好的错误页面：当用户被限制时（返回429或503），返回一个友好的静态页面，解释原因（如“访问过于频繁”），并可能提供一个“重试”按钮或联系渠道。这比冰冷的错误代码体验好得多。
- 分层放行：对于触发了严格限制（如登录接口每秒2次）但可能是真实用户的请求，可以将其导向一个带有图形验证码或短信验证码的二次验证页面，而不是直接拒绝。
防御CC攻击是一场持久战，没有银弹。核心在于通过Nginx构建一个可观察、可调整、多层次的过滤体系，并基于对自身业务流量模式的深刻理解来持续优化规则。这套配置不是终点，而是你守护Web服务稳定性的起点。随着攻击手段的演变，你的防御策略也需要不断地迭代和进化。
