多级反向代理中必须透传X-Forwarded-Proto和X-Forwarded-Port以还原原始访问协议与端口，一级代理注入、中间级继承、后端结合可信IP白名单校验并按规则映射默认端口，避免链接生成错误。
多级反向代理中，后端服务常因无法获知原始请求端口（如 443 或 80），导致生成的跳转链接、资源路径或 API 回调地址出错——例如返回 http://example.com:8080/api 而非用户实际访问的 https://example.com/api。这本质是协议与端口信息在逐级转发中丢失，仅靠 X-Forwarded-For 或 Host 不足以还原完整上下文。
必须透传的关键端口标识：X-Forwarded-Port 与 X-Forwarded-Proto
浏览器不直接发送“我用了什么端口”，但可通过 X-Forwarded-Proto（http/https）和 X-Forwarded-Port 共同推断真实访问端口。这两者需协同设置：
- 一级代理（公网入口）必须主动注入：
proxy_set_header X-Forwarded-Proto $scheme;proxy_set_header X-Forwarded-Port $server_port;
（$scheme取决于 server 块监听协议；$server_port是当前 nginx 实际监听端口，如 443） - 中间各级代理**不得覆盖**，而应继承并透传：
proxy_set_header X-Forwarded-Proto $http_x_forwarded_proto;proxy_set_header X-Forwarded-Port $http_x_forwarded_port; - 最下层代理（直连后端）若自身监听的是非标准端口（如 8080），但上游已传入
X-Forwarded-Port: 443，则必须以该值为准，不能用$server_port覆盖
后端如何安全使用这些头还原原始端口
后端应用不应无条件信任所有 X-Forwarded-* 头，而应结合可信代理链白名单校验：
- 只接受来自你控制的跳板机 IP 的
X-Forwarded-Port和X-Forwarded-Proto，拒绝其他来源的该头 - 优先采用
X-Forwarded-Proto判断协议，再映射默认端口：
若X-Forwarded-Proto: https→ 默认端口为 443
若X-Forwarded-Proto: http→ 默认端口为 80
若同时存在X-Forwarded-Port且非默认值（如 8443），才使用它 - 生成重定向 Location 或绝对 URL 时，显式拼接：
https://example.com:443/path→ 简化为https://example.com/path（省略默认端口）
常见错误配置及验证方法
以下配置会破坏端口透传链路：
- 在二级代理中写
proxy_set_header X-Forwarded-Port $server_port;—— 它把中间机的 8080 覆盖了原始的 443 - 漏配
X-Forwarded-Proto，导致后端误判为 HTTP，即使用户访问的是 HTTPS - 未限制可信代理，使攻击者伪造
X-Forwarded-Port: 22触发 SSRF 或路径污染
验证方式：
用 curl -v https://yourdomain.com/health 查看响应头中是否包含 X-Forwarded-Proto: https 和 X-Forwarded-Port: 443；再检查后端日志或调试输出，确认其读取到的端口值是否符合预期。
