可通过log_format定义含$request_uri、$uri等变量的日志格式，结合多级Nginx代理与curl模拟请求，清晰追踪location匹配、proxy_pass路径重写及真实IP透传全过程，尤其需注意proxy_pass末尾斜杠对转发路径的关键影响。
直接在 Nginx 配置中加日志记录原始请求路径和转发后 URI，再结合 curl 模拟多级代理链路，就能清晰看到 location 路由与 proxy_pass 如何协同完成路径透传。
用 log_format 记录关键路径信息
在 http 块里定义带变量的日志格式，重点捕获客户端请求 URI、匹配的 location、proxy_pass 实际拼接结果：
-
$request_uri：原始完整请求路径（含参数），比如
/api/v2/users?id=1 -
$uri：Nginx 内部规范化后的路径（已解码、无参数），比如
/api/v2/users -
$request_filename：若用于文件服务可辅助判断，但代理场景更关注
$proxy_host和$proxy_port的组合行为 - 配合
log_format debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$request_uri" "$uri" "$host"';
构造分层测试环境验证透传逻辑
模拟两级代理（LB1 → LB2 → Backend），每层都启用相同日志格式，逐层比对：
- LB1（首层）配置：
location /svc/ { proxy_pass http://lb2:80/; }，访问/svc/user→ LB1 日志中$request_uri为/svc/user，$uri也为/svc/user - LB2（次层）配置：
location / { proxy_pass http://backend:3000/; }，它收到的是/user（因 LB1 已截掉/svc/），所以 LB2 日志中$request_uri是/user，$uri也是/user - 用
curl -v http://lb1/svc/user查看响应头中的X-Original-URI（可自定义添加）或直接查 LB2 日志确认最终到达路径
用 curl 携带真实 Host 和 X-Forwarded-* 头模拟真实链路
绕过 DNS 和浏览器，手动构造多级代理常见头字段，验证是否被正确保留或改写：
curl -H "Host: app.example.com" -H "X-Forwarded-For: 203.0.113.5, 192.168.1.10" http://localhost/svc/order- 检查后端 access.log 中是否记录了
app.example.com和203.0.113.5（需 LB2 启用 realip 模块并配置set_real_ip_from） - 若后端返回 JSON，可在响应体中 echo
$_SERVER['HTTP_HOST']（PHP）或request.headers.get('host')（Node.js）做交叉验证
观察 proxy_pass 尾部斜杠引发的路径差异
这是最常出错的环节，必须对比两种写法的实际转发目标：
- 错误配置：
location /api/ { proxy_pass http://b:8080; }→ 请求/api/users转发为http://b:8080/api/users（后端收不到） - 正确配置：
location /api/ { proxy_pass http://b:8080/; }→ 同样请求转发为http://b:8080/users（路径干净） - 用
nginx -t && nginx -s reload后，立刻用curl -v看响应头Via或后端返回的调试信息确认实际接收路径
