要验证delay是否生效，需结合日志（启用limit_req_log_level warn并记录$limit、$limit_rate）、状态码（delay=N时前N超限请求返回200，溢出才503）、压测行为（如wrk模拟确认排队与延迟分布）及后端响应时间比对（$request_time与$upstream_response_time差值突增提示delay积压）。
要识别 delay 状态是否生效、判断流量整形是否正在影响用户，不能只看配置，得让 Nginx 主动“说话”——通过日志、状态码和可验证行为三方面联动观测。
开启 delay 相关的详细日志
默认情况下，Nginx 不会记录请求因排队或延迟调度产生的细节。需显式启用警告级日志：
-
在 http 块中添加：
limit_req_log_level warn; - 当某个请求因 burst 队列已满、无法再进入 delay 免等待通道时，Nginx 会记一条 warn 日志，例如：
limiting requests, excess: 5, by zone "api" - 配合
log_format在日志中加入$limit和$limit_rate变量（需较新版本支持），可进一步区分是被 delay 调度还是被直接拒绝
用 HTTP 状态码区分处理路径
delay 本身不改变返回码，但它的存在会影响哪些请求最终触发 503：
- 配置
nodelay时：超限请求立即返回 503 Service Unavailable - 配置
delay=N（N > 0）时：前 N 个超限请求仍走正常流程（返回 200），其余排队；只有队列溢出才返回 503 - 不写 delay 也不写 nodelay 时：所有超限请求严格排队，极少返回 503，但响应延迟明显上升
- 建议在 access_log 中固定记录
$status，用日志分析工具（如 Grafana + Loki）统计 503 出现时段与 burst 峰值是否同步
构造可验证的压测行为
真实业务流量难复现边界情况，可用 ab 或 wrk 模拟确定性场景来确认 delay 是否按预期工作：
- 设配置为：
rate=5r/s; burst=10; delay=3 - 用
wrk -t1 -c10 -d5s http://host/search发起 10 并发、5 秒持续请求（约 50 请求） - 观察结果：
– 前 5 个请求应几乎同时返回（基础 rate）
– 接下来 3 个应快速跟进（delay=3 的免等待名额）
– 后续 2 个大概率排队，响应时间拉长到 200ms～400ms 区间（按令牌桶节奏释放）
– 若第 11 个之后开始出现 503，则说明 burst 已耗尽
关联后端响应时间做横向比对
delay 的本质是把压力“摊薄”，不是消除。若发现 Nginx 日志里 delay 队列频繁使用，但后端平均耗时反而升高，可能说明：
- burst 设置过大，导致大量请求积压在 Nginx 队列中，实际并未缓解后端压力
- delay 值偏高，使本该被拒绝的请求滞留过久，拖慢整体 P95 延迟
- 建议在 upstream 日志中同步记录
$request_time和$upstream_response_time，对比二者差值突增是否与 delay 触发时段重合
