关键依据是$upstream_addr字段：非空即表示发生反向代理，值为后端ip:port或socket路径；为空或仅localhost则未转发。需结合proxy_pass配置与location匹配验证，排除fastcgi等伪代理场景。
要分析 Nginx 访问日志中的反向代理转发记录，关键在于识别哪些请求是经由 proxy_pass 转发出去的，并区分真实客户端、代理层与后端服务之间的交互关系。Nginx 本身不直接在日志中标记“这是反向代理请求”，需结合日志格式、请求头、上游配置和上下文综合判断。
确认日志中是否包含关键代理标识字段
Nginx 默认日志格式（log_format combined）通常不含代理相关字段，容易混淆源 IP 和转发行为。建议自定义日志格式，显式记录代理链信息：
-
$http_x_forwarded_for：记录原始客户端 IP 链（如
203.0.113.5, 192.168.10.2），首项一般为真实用户 IP -
$http_x_real_ip：若启用了
set_real_ip_from，该字段更可靠地反映客户端 IP -
$upstream_addr：核心字段！记录实际转发到的后端地址（如
10.0.3.12:8080或unix:/var/run/backend.sock），非空即表示发生了反向代理 -
$upstream_http_xxx：可记录后端返回的特定响应头（如
$upstream_http_x_backend_name），用于标识被调用的服务
示例增强日志格式：
log_format proxy_log '$remote_addr - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent" '
'upstream="$upstream_addr" '
'xfwd="$http_x_forwarded_for" '
'xreal="$http_x_real_ip" '
'rt=$request_time uct="$upstream_connect_time" uht="$upstream_header_time" urt="$upstream_response_time"';通过 upstream_addr 判断是否发生反向代理
$upstream_addr 是最直接的判断依据：
- 值为空（
-）或为localhost/127.0.0.1且非你主动配置的 upstream，则大概率是静态资源或本地处理，未走代理 - 值为明确的 IP:Port（如
172.16.5.20:3000）、域名（如api.internal:8000）或 Unix socket 路径，说明已执行proxy_pass - 若出现多个地址（如
10.0.1.10:8000, 10.0.1.11:8000），代表发生重试或负载均衡切换，需关注失败后是否 fallback 成功
结合 location 与 proxy_pass 配置交叉验证
仅看日志不够，必须对照 Nginx 配置理解转发逻辑：
- 检查
location块是否匹配该请求 URI，且内部含proxy_pass指令（注意末尾/的路径重写影响） - 确认是否有
proxy_set_header设置了X-Forwarded-For、X-Real-IP等，避免日志中这些字段被覆盖或丢失 - 若使用
upstream块，$upstream_addr会显示具体选中的节点；若直接proxy_pass http://10.0.2.5:8080，则固定显示该地址
例如，访问 /api/users 日志中 upstream="10.0.4.8:8000"，而配置中恰好有：
location /api/ {
proxy_pass http://10.0.4.8:8000/;
}即可确认该条日志属于反向代理转发记录。
排查常见误判场景
以下情况易被误认为“代理转发”，实则不是：
-
FastCGI 或 uWSGI 请求：
$upstream_addr可能显示127.0.0.1:9000，但这是 CGI 协议通信，不属于 HTTP 反向代理，应查fastcgi_pass或uwsgi_pass指令 -
rewrite + internal 重定向后代理：原始请求可能未直接匹配 proxy location，但经 rewrite 后触发，此时需结合
$request_uri与$uri对比分析路径变化 -
CDN 或前置 LB 透传 X-Forwarded-For：日志中
$http_x_forwarded_for非空，但$upstream_addr为空，说明 Nginx 本身未转发，只是接收了带代理头的请求
