如何利用 limit_req_zone 和 $request_uri 实现核心缓存资源流控防护的最佳实践？

本文共计788个文字，预计阅读时间需要4分钟。

直接使用 `$request_uri` 作为限制流键，容易绕过、内存消耗大，且无法区分带参数和不带参数的同一资源路径。真正安全稳定的做法是结合 `map` 指令进行语义化归一化，再配合 `limit_req_zone` 实现精确防护。

核心思路是：把“缓存友好型 URI”提取成统一标识，而不是原样用 $request_uri

比如 /api/v1/products/123?sort=price 和 /api/v1/products/123?sort=name 实质访问的是同一个产品缓存资源，但 $request_uri 会当成两个不同 key，导致限流失效或误伤。

---

✅ 正确做法：用 map 提取缓存资源主干

在 http 块中定义：

map $request_uri $cache_key { ~^/api/v1/products/(\d+) products_$1; ~^/api/v1/categories/(\d+) categories_$1; ~^/static/(.+\.js|.+\.css) static_assets; default $binary_remote_addr; }

这个 map 把高频缓存接口按业务维度抽象为稳定 key：

• 所有 /api/v1/products/{id} → 统一为 products_123
• 所有静态资源 .js/.css → 归为 static_assets
• 其他请求默认回落到 IP 级兜底

---

✅ 定义缓存资源专用限流区

limit_req_zone $cache_key zone=cache_limit:10m rate=5r/s;

• 10m 内存支持约 8 万个不同缓存资源键（如 10 万商品 ID）
• 5r/s 是单个缓存资源每秒最大处理速率，防穿透、防刷热 key

---

✅ 在 location 中启用并控制行为

location /api/ { limit_req zone=cache_limit burst=15 nodelay; proxy_pass http://backend; }

• burst=15：允许最多 15 个请求排队（不延迟），超了直接拒绝（503 或自定义 429）
• nodelay：避免因排队引入响应延迟，保障缓存服务低延时特性

---

✅ 补充建议：区分冷热资源，加一层 IP 限流兜底

limit_req_zone $binary_remote_addr zone=ip_fallback:10m rate=100r/m; location /api/ { limit_req zone=cache_limit burst=15 nodelay; limit_req zone=ip_fallback burst=50 nodelay; # 防止单 IP 刷多个缓存资源 proxy_pass http://backend; }

双层限制：既保单个热资源不被打穿，又防 IP 级横向扫描。

---

⚠️ 避免踩坑的几个关键点

• 不要在 if 块里写 limit_req —— Nginx 不支持，配置会加载失败
• zone 大小要预留余量：10MB ≈ 8 万 key，若商品 ID 达百万级，需调到 20m 或分片
• 开启日志记录限流状态，便于分析是否误杀或攻击特征：

  log_format limitlog '$remote_addr - $remote_user [$time_local] "$request" $status $limit_req_status'; access_log /var/log/nginx/cache_limit.log limitlog;

• 若后端已做缓存（如 Redis），可适当放宽 rate，重点防穿透而非防并发

这样配置下来，对 /api/v1/products/123 的高频请求会被收敛到同一个 key 上精确限流，而不会因为加了不同参数就逃逸，真正守住缓存层命脉。