如何配置Nginx过滤特定URL垃圾请求 抵御分布式洪泛攻击

你遇到的是典型的肉鸡池分布式HTTP洪泛攻击，核心特征是海量分散IP每个仅发起1-2次请求，精准命中固定高消耗接口，完全绕过基于单IP请求频率的限流规则，最终打满服务器CPU、内存资源导致服务不可用。
以下方案按止血优先级排序，可逐步落地：

第一层：Nginx侧快速止血（5分钟可配置生效） #

核心思路是把所有恶意请求挡在后端应用之外，绝不透传流量消耗业务服务资源。

• 针对被攻击的固定接口配置全局限流兜底，不要用IP维度限流，直接按接口总QPS卡阈值，阈值设为业务正常峰值的1.2倍即可，超限请求直接断开连接不返回内容，最大程度节省资源，配置示例：

# 分配100M内存存储接口访问统计，针对m3u8播放接口设置总QPS上限为200（按你实际业务峰值调整）
limit_req_zone $uri zone=hls_api_protect:100m rate=200r/s;

location ~* ^/playlist/.*/m3u_plus {
    # 限流突发队列设为0，不排队等待，超限直接返回444状态码（主动断连，资源消耗远低于返回403/502）
    limit_req zone=hls_api_protect burst=0 nodelay;
    limit_req_status 444;

    # 基础请求头合法性校验，拦截脚本构造的残缺请求
    # 空Referer、非本站域名Referer直接拦截
    valid_referers none blocked your-domain.com *.your-domain.com;
    if ($invalid_referer) {
        return 444;
    }
    # 缺失浏览器必带头的请求直接拦截，大部分攻击脚本不会携带完整的Accept、Accept-Language头
    if ($http_accept = "") { return 444; }
    if ($http_accept_language = "") { return 444; }

    # 优先返回Nginx缓存的静态内容，缓存未命中再转发给后端
    proxy_cache hls_cache;
    proxy_cache_valid 200 30s;
    proxy_pass http://your_backend_service;
}

• 调优Nginx连接参数，减少无效连接占用资源：

sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 10; # 长连接超时从默认65秒调短到10秒
client_body_timeout 10;
client_header_timeout 10;

• 配合iptables做TCP连接数限制，单个IP最多同时持有2个80/443端口连接，超出直接丢弃：

iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 2 -j DROP
iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 2 -j DROP

第二层：流量前置拦截（彻底降低源站压力） #

• 给被攻击的m3u8播放接口配置CDN缓存，设置10-30秒的缓存时间，相同参数的请求直接由CDN节点返回缓存内容，不回源到你的服务器，攻击流量会全部被CDN节点承接，根本接触不到源站。
• 如果攻击流量规模超过常规CDN免费防护阈值，可在源站前接入开源流量清洗组件，自动识别拉黑短时间内请求特征高度一致的恶意IP段。

第三层：业务层校验（从根源拦截非法请求） #

• 给播放地址加时效动态签名：所有合法播放链接由服务端生成，携带过期时间和签名校验参数，Nginx/CDN层直接校验签名合法性，签名错误、过期的请求直接拦截，攻击方拿不到合法签名的情况下，构造的请求全部会在边缘节点被丢弃，无法消耗后端资源。
• 对首次访问的用户增加轻量JS挑战：请求第一次到达时返回一段极简JS计算逻辑，正常浏览器会自动执行JS生成校验Cookie后重新发起请求，绝大多数肉鸡攻击脚本不会执行JS，会被直接拦截，校验通过的用户1小时内无需重复校验，对正常用户体验几乎无影响，该逻辑可通过Nginx Lua模块实现，无需改动现有业务代码。

注：你之前配置的limit_req_zone规则不生效的核心原因是限流key用了单IP维度$binary_remote_addr，这种分布式攻击每个IP仅发起1-2次请求，单IP频率永远达不到限流阈值，总请求量叠加后依然会打满服务，必须先加接口维度的全局限流做兜底，先保证服务不挂，再逐步清理恶意流量。

内容的提问来源于stack exchange，提问作者Delavor