limit_req通过延迟排队而非封禁防爬虫，核心是按URI路径设key、rate 2–5r/s、burst 5–10、禁用nodelay，并在location中精准匹配静态资源启用，配合429状态码与日志验证。
用 limit_req 配合延迟处理防爬虫刷静态资源，核心不是单纯封禁，而是让异常请求“排队等、慢响应”，既拦住自动化高频行为，又不误伤真实用户加载。关键在合理选 key、控速率、设 burst，并慎用 nodelay。
选对限流维度：优先按 URI 路径，而非只靠 IP
只限 IP 容易被代理池绕过；只限全局速率又太粗放。推荐组合使用：
-
对高频静态路径单独建 zone：比如
/static/cover.jpg、/favicon.ico这类常被刷的资源，用$request_uri精准识别（含参数），避免漏控 -
必要时叠加 IP 维度：如攻击表现为“多个 IP 同时刷同一张图”，可定义
"$binary_remote_addr$request_uri"为 key，实现更细粒度隔离 -
避开 $uri 直接匹配带参路径：例如
/file?id=123若用$uri会归为同一 key，失去防护意义；此时应先用map提取固定路径段
设置合理速率与突发容量
静态资源正常访问有“页面首次加载并发多、后续缓存命中高”的特点，限流值要贴合这个节奏：
- rate 设为 2–5r/s 较稳妥：单个 URI 每秒 2–5 次请求，已远超单用户浏览器行为（通常首屏最多触发 1–2 次 favicon 或 logo 请求）
- burst 值建议 5–10：允许短时集中请求（如页面加载多个图片），但不宜过大——burst=20 就可能把洪峰直接透传到后端或 CDN 回源链路
- 去掉 nodelay，启用排队延迟：默认行为是请求超限后进入队列，按 rate 匀速释放；这对爬虫很有效——它发 100 个请求，前 10 个秒回，后面 90 个要等十几秒才陆续响应，极大拉低其效率
在 location 中精准启用并配合日志验证
限流必须落在具体资源匹配块里，不能只写在 server 根部：
-
用正则或精确匹配锁定静态路径：例如
location = /favicon.ico { ... }或location ~* \.(jpg|png|js|css)$ { ... } -
加
limit_req_status 429并配错误页：让爬虫明确收到 429 Too Many Requests，部分规范爬虫会主动退避；同时便于你在 access_log 中通过$limit变量确认哪条规则生效 -
上线后快速验证：用
ab -n 50 -c 10 http://yoursite.com/logo.png模拟并发，观察响应时间分布和返回状态码是否符合预期
进阶技巧：让可疑请求“主动暴露”
纯限流是被动防御，可搭配轻量策略提升识别率：
-
对无 Referer 或非浏览器 UA 的请求额外收紧：用
map标记风险等级，再映射到不同 rate 的 zone -
对反复触发限流的 IP，临时升级为连接数限制（limit_conn）：比如连续 3 分钟内被限 10 次，就将其纳入
conn_limit区域，限制最大并发连接为 1 -
在响应头中添加调试标识：如
add_header X-Rate-Limited "true" always;，方便前端或监控系统做二次判断
