要让nginx在返回503时记录请求路径和排队耗时，需在触发503的前置环节埋点：通过启用upstream queue、定义含$upstream_queue_time的日志格式，并用map结合access_log if条件精准记录高风险请求。
要让 Nginx 在返回 503 时自动记录请求路径和排队耗时到独立日志，关键不是“捕获 503”，而是**在触发 503 的前置环节（如连接被限、后端不可达、超时前）埋点记录**。Nginx 本身不支持对已返回的响应状态码做条件日志（log_format 中无法直接判断 $status 是否为 503 并据此写入特定日志），但可通过以下方式精准实现目标效果。
启用带排队耗时的自定义日志格式
Nginx 原生提供 $request_time（总处理时间）和 $upstream_queue_time（上游排队时间，需开启 upstream 模块并配置 queue）。先确认你使用的是较新版本（1.21.4+），然后在 http 块中定义日志格式：
- 添加
log_format overload_log '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $request_time $upstream_queue_time'; - 确保后端
upstream块启用了队列支持，例如：upstream backend {<br> queue 100 timeout=30s;<br> server 127.0.0.1:8080;<br>} -
$upstream_queue_time仅在请求进入 upstream 队列且实际等待后才非空；若后端直接拒绝（如 connection refused），该值为破折号（-），但仍可结合状态码识别异常场景。
用 map 指令标记可能导向 503 的请求类型
真正实用的方式是：**提前识别高风险请求行为**，而非等 503 发生后再记录。利用 map 根据请求特征打标，再配合 access_log 的 if 条件写入隔离日志：
- 在
http块中定义：map $status $is_503_or_overload {<br> 503 1;<br> ~^[5] 1;<br> default 0;<br>}
（此例将所有 5xx 响应都纳入监控，更稳妥；纯 503 可写503 1单独匹配） - 同时可叠加判断：
map $upstream_response_length $is_upstream_timeout {<br> "" 1;<br> default 0;<br>}
（空响应体常意味着后端未响应，易转为 503） - 然后在 server 或 location 中启用条件日志：
access_log /var/log/nginx/overload.log overload_log if=$is_503_or_overload;
补充关键：让排队耗时真实可测
默认情况下 $upstream_queue_time 不生效。必须满足两个前提：
- 后端服务需支持 HTTP/1.1 keepalive，并正确响应
Connection: keep-alive；否则 Nginx 不会复用连接，也无队列概念。 - 在
upstream块中显式配置queue指令（如上所示），且后端服务需能承受排队压力（例如 Node.js 需启用 cluster 模式，PHP-FPM 需调高pm.max_children）。 - 若用 fastcgi_pass，需搭配
fastcgi_next_upstream_tries和fastcgi_next_upstream_timeout，并确保fastcgi_param中传递了必要头信息，否则排队逻辑不触发。
验证与精简输出
写入日志后，建议用如下命令快速验证是否命中：
tail -f /var/log/nginx/overload.log | grep "503\|queue"- 模拟压测：
ab -n 200 -c 50 http://your-domain/，观察日志中是否出现非零的$upstream_queue_time值及对应路径。 - 若只需记录路径和耗时，可简化 log_format：
log_format overload_log '$request_uri $request_time $upstream_queue_time';
