精准审计反向代理链路需分离记录Nginx入口耗时与回源耗时，分别定义proxy_entry_log和upstream_debug_log两种日志格式，按location绑定，并通过统一Trace ID、固化后端服务名、分层状态码补全上下文，支撑精准归因。
要精准审计反向代理链路中“请求进入 Nginx”到“响应返回客户端”的全过程，关键不是只记一个时间，而是把反代层耗时（Nginx 接收请求到发出 upstream 请求）和回源耗时（upstream 处理 + 网络往返）拆开记录，并绑定同一请求上下文。两者分离后，才能判断毛刺发生在 Nginx 自身（如 rewrite、header 处理）、连接建立阶段，还是真实后端响应慢。
定义两个独立的 log_format，明确区分角色
避免混用变量造成归因混乱。在 http 块中分别定义：
-
proxy_entry_log：聚焦 Nginx 入口处理阶段，使用
$request_time（完整生命周期，含读请求头、发响应）和$msec（毫秒级时间戳，用于对齐） -
upstream_debug_log：专注回源行为，必须包含
$upstream_response_time，并搭配$upstream_connect_time和$upstream_header_time拆解耗时构成
示例：
log_format proxy_entry_log '$time_iso8601|$request_id|$status|$request_time|$bytes_sent';log_format upstream_debug_log '$time_iso8601|$request_id|$http_x_trace_id|$upstream_addr|$upstream_response_time|$upstream_connect_time|$upstream_header_time|$upstream_status';
为不同 location 绑定对应日志格式
每个反代路径应有专属 location 块，并显式启用匹配的日志格式：
- 静态资源或直通类请求（无 upstream）用
proxy_entry_log - 走
proxy_pass的业务接口，必须在该 location 内启用upstream_debug_log，且确保proxy_set_header X-Trace-ID $request_id;已配置，让上下游 ID 对齐 - 若一个 location 内存在多个 proxy_pass 分支（如通过 if 或 map 动态路由），需用
access_log off;关闭默认日志，改用access_log ... upstream_debug_log if=$is_auth_route;等条件日志方式分流
补全上下文字段，支撑横向比对
单靠耗时数字无法定位问题，必须带强标识字段：
-
统一 Trace ID：优先由上游注入
X-Trace-ID，Nginx 用$http_x_trace_id捕获；未提供时 fallback 到$request_id -
后端身份固化：禁用易变的
$upstream_addr（含端口、IP 变化大），改用proxy_set_header X-Service-Name "user-service";，再写入$http_x_service_name -
状态分层标记：同时记录
$status（Nginx 返回码）和$upstream_status（后端返回码），可快速过滤掉 502/504 等连接类失败导致的“假高耗时”
验证与日常使用建议
上线后需做两件事：
- 用 curl 发起一次请求，检查两条日志是否共享同一个
$request_id或$http_x_trace_id，且时间戳顺序合理（proxy_entry_log 时间 ≤ upstream_debug_log 时间） - 定期采样高
$upstream_response_time请求，查其$upstream_connect_time是否显著偏高——若占比超 30%，说明连接池复用异常或源站建连不稳定，而非业务逻辑慢 - 日志采集端（如 SLS、ELK）按
request_id聚合两条日志，计算差值request_time − upstream_response_time，即为 Nginx 本层开销，持续 >50ms 需检视 rewrite、set、geoip 等指令性能
