用 proxy_pass 实现多级反向代理嵌套，本质是请求在多个 Nginx 实例间逐层转发；关键在于每层正确处理 URI 重写（如 location /v1/ { proxy_pass http://mid-nginx:8080/; }）、请求头透传（Host、X-Real-IP、X-Forwarded-For、X-Forwarded-Proto）及协议一致性（推荐外层 SSL 终止），并结合日志与 curl 分层调试。
用 proxy_pass 实现多级反向代理嵌套，本质是让请求在多个 Nginx 实例之间逐层转发，最终抵达真实服务。关键不在“嵌套”本身，而在于每层的 proxy_pass 配置是否正确处理 URI 重写、请求头传递和协议一致性。
第一层：入口 Nginx 要精准截断并重写路径
用户访问 https://api.example.com/v1/users，入口 Nginx 需把 /v1/ 前缀剥离，再转发给下一级（比如内网的中间层 Nginx）。否则后端会收到带多余前缀的路径，导致 404。
推荐写法：
- 用带尾部斜杠的
location匹配，例如location /v1/ { proxy_pass http://mid-nginx:8080/; }—— 注意proxy_pass后的/，它会自动替换掉匹配到的/v1/ - 避免写成
proxy_pass http://mid-nginx:8080;（无尾斜杠），这样整个原始 URI（包括/v1/users）会原样拼接过去，中间层收不到干净路径 - 若需保留前缀（如中间层也需识别
/v1/），则改用rewrite显式控制，但通常不推荐增加复杂度
第二层：中间层 Nginx 要透传关键请求头
中间层收到请求后，继续转发给最终服务（如 Node.js 或 Java 应用）。此时必须确保客户端真实信息不丢失：
- 加
proxy_set_header Host $host;，避免后端看到的是内部 IP 或端口 - 加
proxy_set_header X-Real-IP $remote_addr;和proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;，供后端识别真实客户端 IP - 若上游用了 HTTPS，还需加
proxy_set_header X-Forwarded-Proto $scheme;，让后端知道原始是 HTTP 还是 HTTPS - 默认情况下，Nginx 会清除
Connection、Keep-Alive等头，如需长连接透传，显式设置proxy_pass_request_headers on;并补全必要头
协议与 SSL 终止位置要提前约定
多级代理中，HTTPS 解密在哪一层做，直接影响配置逻辑：
- 推荐在最外层终止 SSL（即入口 Nginx 配置证书），后续层级走内网 HTTP —— 简单、高效、便于调试
- 若中间层也要 HTTPS（如跨机房），则
proxy_pass必须写https://协议，并配置proxy_ssl_*系列指令（如proxy_ssl_verify off;测试时可关，生产建议开） - 注意：SSL 终止层决定了
$scheme和$https变量的值，后端依赖这些变量生成跳转链接时，必须确保它们反映的是客户端原始协议
调试嵌套代理的核心技巧
请求层层转发后出问题，别盲目改配置，先确认每一跳的实际行为：
- 在每一层 Nginx 的
log_format中加入$upstream_addr和$upstream_http_content_type，看它到底连了谁、收到了什么响应 - 用
curl -v从上到下逐层测试：先直连中间层，再直连后端，最后走完整链路，定位失败点 - 临时在某层加
return 200 "forwarded to $upstream_addr\n";，快速验证流量是否到达该层 - 检查各层的
proxy_buffering和超时设置（proxy_connect_timeout等），避免某层卡住导致整条链路挂起
