Nginx访问日志字段需按数据来源层级理解：$remote_addr是直连IP（非真实用户IP），$status是Nginx返回码（非应用状态），$upstream_status和$upstream_response_time仅在proxy_pass等配置下有效，反映Nginx与上游交互而非应用内部耗时。
Linux 下 Nginx 访问日志的核心参数，不是简单罗列变量，而是要理解每个字段在真实请求链路中代表什么、谁生成的、在哪一环生效。很多排查失效，恰恰是因为把 $upstream_response_time 当成应用耗时，或把 $remote_addr 当作真实用户 IP——这些都不是“错”，而是没看清数据来源层级。
关键字段谁在记录？分清 Nginx 本体与上游边界
Nginx 的 access_log 不记录后端应用逻辑，只记录它自己“看到”和“处理过”的信息：
-
$remote_addr：Nginx 接收到连接的直接对端 IP。若前端有 CDN 或负载均衡，这里通常是代理 IP，不是用户真实 IP；要获取真实 IP，需依赖
$http_x_forwarded_for（且前提是上游代理正确设置了该头） - $status：Nginx 返回给客户端的状态码。200 表示 Nginx 成功响应，但不保证后端应用没报错；502/504 才说明 Nginx 与 upstream 通信失败
- $upstream_status 和 $upstream_response_time：这两个字段只在配置了 proxy_pass 或 fastcgi_pass 时才有值，反映的是 Nginx 与后端服务之间的交互结果，不是应用内部处理时间
-
$request_time：从 Nginx 接收第一个字节到发送完最后一个响应字节的总耗时，含网络延迟、排队、upstream 等全部环节；而
$upstream_response_time仅是 Nginx 等待 upstream 响应的时间段
日志格式配置常见失配点
log_format 定义和 access_log 调用必须匹配，否则字段为空或报错：
- 定义了
log_format main_detail ... $request_time ...;，但access_log /path/access.log main;中写的是main（默认格式），则$request_time不会输出 - 在 server 块中启用
access_log /var/log/nginx/app.log main_detail;，但log_format main_detail只定义在另一个 server 块里——Nginx 不跨块继承 format，必须定义在 http 块或同级作用域 - 使用
$http_x_forwarded_for却未确认前端是否透传该头，或 Nginx 未开启underscores_in_headers on;（当头名含下划线时需此配置）
排查时容易忽略的路径与继承逻辑
日志文件写入位置不是全局固定的，而是按配置块逐级覆盖：
- http 块中配置
access_log /var/log/nginx/global.log;，表示所有未显式覆盖的 server 都走这个路径 - 某个 server 块里写了
access_log /var/log/nginx/api.access.log;，那该站点所有请求都写入新路径，不会同时写进 global.log - location 块也可单独指定 access_log，比如只对
/healthz关闭日志：access_log off;，或写入独立文件用于监控采集 - 检查日志是否生成，不能只看 /var/log/nginx/access.log 是否存在，得确认当前请求实际命中的是哪个 server/location 块，再查对应配置的 access_log 路径
状态码与响应体大小背后的线索
单看 $status 和 $body_bytes_sent 组合，能快速识别异常模式：
-
400+0字节：可能是恶意构造请求（如超长 header）、协议违规，Nginx 拒绝解析，尚未转发给 upstream -
502+ 小响应体（如 172 字节）：典型 upstream 连接拒绝或无响应，配合 error_log 查 “Connection refused” 或 “no live upstreams” -
200+ 异常大$body_bytes_sent（如 >10MB）：可能遭遇资源盗链、未限速的大文件下载，或后端返回了错误内容 -
304+0：资源未修改，Nginx 直接返回空响应体，属正常行为，不应误判为失败
