HTTP Flood攻击的本质是攻击者利用HTTP协议的无状态特性，向目标服务器发送大量看似正常的请求，以此耗尽服务器的连接数、线程池、CPU或数据库连接资源。与SYN Flood等网络层攻击不同，HTTP Flood不需要伪造IP地址，攻击流量通常来自真实的TCP连接和合法的HTTP报文，因此传统的防火墙和黑洞路由很难直接区分恶意请求与真实用户请求。一个中小规模站点即使只有几十Mbps的攻击流量，如果每个请求都触发复杂的后端查询或动态页面生成，也可能迅速不可用。
一、HTTP Flood的攻击特征与检测指标
要有效防护HTTP Flood，首先需要能识别它。HTTP Flood可以细分为GET Flood、POST Flood和慢速攻击等类型。GET Flood通常表现为某一个或某几个URL被高频请求，例如攻击者会对搜索接口、商品详情页或登录页反复发起GET请求；POST Flood则通过提交大量表单数据、JSON请求来消耗应用服务器的解析和业务处理能力；慢速攻击如Slowloris则利用较少的连接数，通过缓慢发送请求头或请求体长期占用连接资源。
检测HTTP Flood不能只看带宽，需要关注以下指标：单个IP或客户端IP段的请求速率、并发连接数、HTTP错误率、响应时间分位数、URL访问分布以及User-Agent头分布。正常用户的请求速率通常具有长尾特征，绝大多数IP在单位时间内只发起少量请求；而攻击脚本或僵尸网络往往会表现出突发性、集中性和规律性。例如某个IP每秒固定请求同一个URL超过20次，且响应码集中在500或404，就非常可疑。
在实际排查中，可以通过分析Nginx访问日志快速定位异常来源。下面这条命令统计访问日志中请求次数最多的前20个IP，帮助运维人员发现高频请求源：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20
除了IP维度，还可以按请求URI和状态码进行聚合统计。如果发现某个不常被访问的接口突然出现大量请求，或者同一IP对同一个带随机参数的URL反复请求，往往意味着应用层洪水攻击已经开始。
二、基础限流：连接与请求速率控制
在边缘或反向代理层做限流是抵御HTTP Flood的第一道屏障。Nginx提供了两个核心模块：ngx_http_limit_req_module用于限制请求速率，ngx_http_limit_conn_module用于限制并发连接数。通过在http块中定义共享内存区域，可以按客户端IP、请求路径或自定义变量进行计数。
下面是一段典型的Nginx限流配置，将每个IP的请求速率限制为每秒10次，并允许突发流量不超过20次：
http {
limit_req_zone $binary_remote_addr zone=req_per_ip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=conn_per_ip:10m;
server {
location / {
limit_req zone=req_per_ip burst=20 nodelay;
limit_conn conn_per_ip 10;
proxy_pass http://backend;
}
}
}
其中burst=20表示允许在速率限制之外额外排队20个请求，nodelay会立即处理突发请求而不是平均延迟。这种配置能在拦截明显异常流量的同时，避免正常用户在短时间内的集中访问被误伤。不过对于登录、支付等关键接口，应设置更严格的独立限流策略，并配合IP白名单来放行内部系统和合作伙伴的调用。
需要注意，基于IP的限流在面对攻击者使用代理池或真实僵尸网络时效果有限，因为攻击请求来自大量不同IP，单IP速率可能并不突出。此时需要结合下一节的应用层行为分析来识别攻击。
三、应用层识别：WAF规则与行为挑战
WAF（Web应用防火墙）可以在HTTP语义层面识别恶意请求。以ModSecurity为例，可以编写规则阻断携带明显恶意特征的请求，例如缺失User-Agent、使用已知攻击工具特征、请求频率过高等。下面这条规则会拒绝来自同一个IP在10秒内超过30次访问的请求：
SecRule IP:REQUEST_RATE "@gt 30" "id:100001,phase:1,deny,status:429,msg:'HTTP Flood detected'"
该示例依赖ModSecurity的请求速率计数器，实际部署时还需要配置SecAction初始化计数器。WAF的优势在于可以结合正则表达式匹配URL模式、Referer来源和Cookie完整性，将那些不符合正常浏览器行为的请求直接丢弃。例如攻击脚本通常不会携带完整的Cookie或不会执行JavaScript，通过检查这些特征可以有效过滤大量机器流量。
更进一步的防护是引入行为挑战机制。当请求被判定为可疑时，不直接返回错误，而是返回一个包含JavaScript挑战的页面，要求客户端计算并回传一个Cookie或Token。正常浏览器可以自动完成挑战并继续访问，而简单的攻击脚本无法执行JavaScript，就会被拦截。下面是一个Python Flask的简化实现：
from flask import Flask, request, make_response
app = Flask(__name__)
@app.before_request
def js_challenge():
if request.cookies.get('validated') != '1':
resp = make_response('<html><body><script>document.cookie="validated=1; path=/"; location.reload();</script></body></html>')
return resp
@app.route('/')
def index():
return 'Welcome'
这种验证码或JS挑战机制会增加攻击成本，但也会对用户体验造成一定影响。通常建议只对高风险路径或异常流量启用挑战，正常用户和搜索引擎爬虫应尽量绕过。对于无法执行JavaScript的合法客户端，可以提供降级方案，例如临时白名单或人工验证码。
四、架构防护：CDN边缘节点与源站隐藏
当攻击流量规模较大或来源分散时，仅靠源站自身的限流和WAF可能仍然不足。将网站接入CDN（内容分发网络）是抵御HTTP Flood的有效架构手段。CDN厂商在全球部署了大量边缘节点，攻击请求会在边缘节点被识别和丢弃，不会全部回源到真实服务器。同时CDN的缓存能力可以将静态资源直接返回，避免源站承受不必要的动态处理压力。
部署CDN后，需要在DNS层面将域名解析到CDN提供的CNAME地址，并确保源站IP不对外泄露。源站防火墙或安全组应配置为只允许CDN回源IP段访问80和443端口，其他来源一律拒绝。这样一来，即使攻击者通过历史DNS记录或子域名枚举找到源站IP，也无法直接建立连接。
配合CDN的还有Anycast技术和多节点负载均衡。Anycast使同一个IP在不同网络路径上路由到最近的边缘节点，攻击流量会在多个节点之间被分摊。CDN控制台通常还提供速率限制、WAF规则、Bot管理等功能，可以根据业务需要开启针对性的防护策略。需要注意的是，CDN并非万能，动态接口请求仍会回源，因此源站侧的应用层限流和缓存优化不能省略。
五、调优与监控：避免误伤和持续迭代
任何防护策略都可能误伤正常用户，因此监控和调优与防护本身同样重要。建议对请求速率、连接数、响应时间、5xx错误率和限流触发次数进行实时监控。可以在Nginx中开启stub_status模块，或通过Prometheus采集Nginx Exporter指标，设置告警阈值。当发现某个接口的限流拒绝次数异常升高时，需要结合业务日志判断是攻击还是正常促销活动带来的突发流量。
针对误伤问题，可以建立多级白名单机制，例如搜索引擎爬虫的User-Agent白名单、已知合作伙伴IP段白名单，以及通过Cookie或Header标识放行已通过身份验证的用户。对于登录、支付等核心接口，可以适当放宽整体限流阈值，但增加针对单账号、单设备指纹的细粒度限制。行为分析模型也可以定期更新，例如根据正常业务高峰期的流量模式调整基线，避免在早高峰或秒杀场景下大量拦截真实请求。
HTTP Flood防护没有一劳永逸的配置，攻击手法的变化要求安全团队持续观察访问日志和监控数据，结合业务特征不断调整限流参数、WAF规则和挑战策略。通过边缘限流、应用层识别、CDN协同和动态调优的组合，可以将绝大多数HTTP Flood攻击的影响控制在可接受范围内。
