精细速率调节需结合业务特征等多维度动态控制，按访问主体区分限流策略，合理配置burst与nodelay，分级location应用，并通过状态码、日志与监控实现可观测可回滚。
精细的速率调节不是简单设个“每秒10个请求”，而是结合业务特征、用户分层、路径差异和突发容忍度，做有区分、可观察、能回滚的动态控制。核心在于用对模块、配准参数、分层应用。
按访问主体区分限流策略
单一 IP 限流容易误伤 NAT 用户或 CDN 回源，应结合多维度标识：
- 用 $binary_remote_addr 做基础 IP 级限流（内存高效，推荐）
- 对登录用户，提取 $cookie_uid 或 $http_x_user_id，单独定义 zone，实现账号级速率控制
- 对 API 接口，可基于 $host + $request_uri 组合哈希，做到“/api/v1/order” 和 “/api/v1/user” 各自独立计数
- 避免直接用 $remote_addr —— 它是字符串格式，比 $binary_remote_addr 多占 7–15 倍内存
合理设置 burst 与 nodelay 的组合效果
burst 不是“允许突增”，而是缓冲队列容量；nodelay 决定是否跳过排队直接拒绝。两者配合决定用户体验和后端压力：
- burst=0 nodelay：严格硬限流，超速即 503，适合支付、风控等强一致性接口
- burst=10 nodelay：允许最多 10 个请求“瞬时冲入”，Nginx 立即处理（不排队），再按 rate 匀速放行后续请求
- burst=10（无 nodelay）：超出 rate 的请求进入队列，延迟处理；若队列满则返回 503；适合对响应延迟不敏感但需保量的场景（如日志上报）
分级 location 应用，避免全局一刀切
把限流嵌套在具体路径层级，让静态资源、健康检查、管理接口免于限制：
- 在 server 块中不设 limit_req，仅在关键路径启用
- 例如：location /api/ 下启用限流，而 location = /healthz 或 location ~* \.(js|css|png)$ 完全绕过
- 支持嵌套：外层按 IP 限流，内层 location 再叠加按 user_id 的二级限流 zone，实现“IP 总量 + 账号细粒度”双控
配合状态码与日志，让限流可追踪
默认被限流返回 503，但不利于监控归因。建议显式配置反馈行为：
- 添加 limit_req_status 429，统一返回 429 Too Many Requests，便于前端识别重试逻辑
- 开启 log_format 中的 $limit_req_status 变量，日志里标记是 “-”（未触发）、“p”（排队）、“r”（拒绝）
- 搭配 Prometheus + nginx-vts-exporter，实时看每个 zone 的 hit、miss、rejected 数，及时发现配置偏差
