要通过log_format结合$upstream_addr追踪多后端请求流向，核心是结构化记录$upstream_addr、$upstream_response_time、$upstream_status及可选$upstream_http_x_backend_name，并配合$remote_addr、$request、$request_id等变量形成端到端可追溯日志链路。
要通过 log_format 结合 $upstream_addr 追踪多后端环境下的请求流向，核心是让每条访问日志明确记录“这次请求到底发给了谁、有没有重试、重试了几次、分别耗时多少”。这不是单纯加个变量就能用，得结构化设计日志格式，并配合实际分析手段。
必须包含的关键 upstream 变量
仅记录 $upstream_addr 不够，需搭配以下变量才能还原完整流向：
-
$upstream_addr：真实转发目标（IP:Port），重试时按顺序逗号分隔，如10.0.1.10:8080,10.0.1.11:8080 -
$upstream_response_time：对应每次转发的响应时间，单位秒（毫秒精度），顺序与$upstream_addr严格对齐，如0.023,1.876 -
$upstream_status：每次转发返回的状态码，如200,502，可直接判断哪次成功、哪次失败 -
$upstream_http_x_backend_name（可选但推荐）：由后端在响应头中返回的逻辑标识（如user-service-v2），便于跨机器统一识别服务名
定义清晰可读的 upstream 日志格式
在 http 块中定义专用格式，避免和默认日志混用：
log_format upstream_trace '$remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent" ' '$upstream_addr $upstream_response_time $upstream_status ' '$upstream_http_x_backend_name $request_id';
注意：$request_id 加入后可用于关联后端日志，形成端到端追踪链路；$upstream_http_x_backend_name 需后端主动设置响应头 X-Backend-Name 才有值。
在 location 中启用并验证输出
在具体代理的 location 块中启用该格式：
location /api/ {
proxy_pass http://backend_cluster;
access_log /var/log/nginx/api_upstream.log upstream_trace;
}
触发一次请求后，检查日志是否出现类似内容：
192.168.3.5 - - [30/Apr/2026:06:40:22 +0800] "GET /api/user/123 HTTP/1.1" 200 342 "-" "curl/7.68.0" "10.0.1.10:8080,10.0.1.11:8080" "0.012,0.008" "200,200" "user-service-v2" e8a3f9b2c1d4e5f6a7b8c9d0e1f2a3b4;
若 $upstream_addr 出现多个地址且 $upstream_status 含非 2xx 值，说明发生了重试；若只有一组值且 $upstream_response_time 明显偏高，则问题大概率出在该节点本身。
用简单命令快速看流向分布
无需导入 ELK，用基础命令即可发现异常模式：
- 统计各后端被选中的次数：
awk '{print $12}' api_upstream.log | cut -d',' -f1 | sort | uniq -c | sort -nr（取首个地址，忽略重试） - 查某台后端是否集中返回 5xx：
awk '$14 ~ /5[0-9][0-9]/ && $12 ~ /10\.0\.1\.10/' api_upstream.log | head -5 - 定位慢请求源头：
awk '$13 > 2.0' api_upstream.log | awk '{print $12, $13, $14}' | head -10（找响应超 2 秒的记录）
这些操作直击请求流向本质，比翻 error.log 更快定位是配置、网络还是后端自身的问题。
