核心问题是代理头传了错误值、漏传关键头或后端未正确读取；需用curl -v和Nginx error_log确认实际发出的头（如X-Forwarded-Proto必须为https），并验证后端是否主动解析这些头（如Spring Boot需server.forward-headers-strategy=framework）。
透传代理头导致后端解析异常，核心问题不是头没传过去，而是传了错误的值、漏传关键头、或后端未正确读取——排查要聚焦“传了什么”和“后端用了什么”之间的落差。
确认 Nginx 实际发出的请求头
用 curl -v 直接请求 Nginx 代理地址，观察完整请求头和响应头；更可靠的是在 Nginx 的 error_log 中临时记录上游请求头：
- 在对应 location 块中添加：
log_format upstream_debug '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" "$http_x_forwarded_proto" "$http_x_forwarded_host"'; - 再配
access_log /var/log/nginx/upstream_debug.log upstream_debug; - 发起一次请求后，立刻查看日志，确认
X-Forwarded-Proto、X-Forwarded-Host、Host等是否符合预期（比如 HTTPS 请求下X-Forwarded-Proto是https而非http）
验证后端是否真正收到并使用这些头
后端应用必须主动读取 X-Forwarded-* 头才能修正 URL 构造逻辑。常见误区是以为只要 Nginx 传了，后端就自动适配——实际需检查：
- Spring Boot 项目：确认是否启用
server.forward-headers-strategy=framework（而非none），且反向代理配置（如server.tomcat.remoteip.remote-ip-header）与 Nginx 传的头名一致 - Node.js（Express）：是否使用
app.set('trust proxy', true)，并确保 Nginx 的X-Forwarded-For格式被正确解析（注意多级代理时 IP 链） - PHP（Laravel）：检查
TrustedProxy中配置的proxies和headers是否匹配 Nginx 传入的头
比对浏览器请求路径与后端生成路径的差异
静态资源加载失败（如 404 /static/app.js）往往是最终表现，根源是后端生成的 HTML 中链接路径错误。快速定位方法：
- 打开浏览器开发者工具 → Network → 刷新页面 → 找到主 HTML 响应 → 查看
Response内容，搜索href="/static/或src="/js/ - 对比该 HTML 中的路径，与你期望的访问前缀（如
/admin/static/）是否一致 - 若不一致，说明后端未识别
X-Forwarded-Prefix（如有）或X-Forwarded-Host+X-Forwarded-Proto组合，仍按裸服务模式生成根路径
排除头被覆盖或污染的干扰
某些中间层（如 CDN、WAF、前置 LB）可能覆盖或篡改 Nginx 设置的头，导致后端看到的是“二手值”：
- 检查 Nginx 日志中记录的
$host和$scheme变量是否与客户端原始请求一致（例如用户访问https://a.com:8443，但日志里$scheme是http，说明前置有降级） - 临时在 Nginx 中加一个自定义头用于标记，如
proxy_set_header X-Nginx-Proxy "true";，然后在后端打印所有请求头，确认该头是否存在且未被覆盖 - 若发现关键头缺失或值异常，需向上游（CDN/WAF）确认其头处理策略，必要时调整其透传规则
