真正起作用的流量清洗墙需多维协同过滤：第一层用$binary_remote_addr保底限流，第二层按关键URI建zone限频，第三层结合User-Agent异常识别；burst值建议设为后端单实例QPS×1.5，慎用nodelay；map预处理key实现业务感知限流，须定义在http顶层；可主动设陷阱诱导爬虫暴露身份。
直接用 limit_req 按 IP 限流，防不住代理、CDN、IP 轮换或带合法 Cookie 的爬虫。真正起作用的流量清洗墙，得从多个维度识别异常请求，并让规则之间形成协同过滤。
组合 IP + URI + User-Agent 做分层限流
单一维度容易被绕过，必须叠加识别信号：
- 第一层：基于
$binary_remote_addr的保底限流，应对无伪装的暴力扫量 - 第二层：用
map提取关键接口路径（如/api/v1/login、/search），单独建 zone 限频 - 第三层：对高频访问但 User-Agent 明显异常的请求（如
python-requests/2.28却带Accept: text/html），可额外加一道limit_req或直接return 403
避免 burst + nodelay 透传洪峰
burst 不是缓冲池，而是允许突发的“通行证数量”。设得过大，等于把压力转嫁给后端：
- burst 值建议按后端单实例 QPS × 1.5 设定，比如后端能扛 60 QPS，burst 就别超 90
- 慎用
nodelay：它会让超出速率的请求立刻失败，适合强防护场景；若要平滑排队，去掉该参数，Nginx 会按漏桶延迟处理 - 两个
limit_req指令在同个 location 中会叠加生效，任一触发即返回 503
用 map 预处理 key 实现业务感知限流
不能在 limit_req_zone 里写正则，但可以用 map 把复杂逻辑提前归类：
- 把登录、下单、搜索等高风险路径映射为固定 key，比如
api_login - 把静态资源（
.js、.css）统一映射到static，给宽松配额 - 未匹配的请求 fallback 到
$binary_remote_addr，保留兜底控制力
注意：map 必须定义在 http 块顶层，不能放在 server 或 location 内。
主动诱导脚本暴露身份
与其等攻击发生再拦截，不如设计轻量陷阱让自动化工具自曝：
- 在页面隐藏一个带特定参数的 JS 请求（如
/trap?_t=abc），正常浏览器不会执行，但多数爬虫会顺手抓 - 对携带已知扫描器特征头（如
X-Scan: Acunetix）的请求，不拦截，而是记录并打上标记，后续请求提升限流等级 - 对连续访问
/robots.txt→/sitemap.xml→/admin的 IP，自动加入临时黑名单 10 分钟
