X-Forwarded-Port应仅由最外层可信代理（如CDN或接入层Nginx）设置为$server_port，内层代理禁止覆盖；需配合X-Forwarded-Proto判断端口语义，避免误判。
当请求经过多层代理（如 CDN → Nginx → 应用服务器）时，X-Forwarded-Port 可能被中间代理反复覆盖或设为错误值（例如固定写成 80/443），导致后端应用误判客户端访问端口，影响重定向、URL 生成或安全策略。关键在于：**只由最外层可信代理设置该头，内层代理应清空或跳过继承**。
明确信任边界，仅由首层代理设置 X-Forwarded-Port
CDN 或边缘 Nginx 是用户直连入口，它知道真实客户端端口（如 443）。后续 Nginx（如反向代理到 Node.js/Python）不应再改写该头，否则会覆盖真实值。
- 在首层 Nginx（如接入层）中显式设置：
proxy_set_header X-Forwarded-Port $server_port;（若监听 443，则传 443；若用非标 HTTPS 端口，需确保 $server_port 正确） - 在内层 Nginx（如应用网关层）中禁止设置该头，更不要用
$remote_port或硬编码值覆盖 - 若必须透传，可用
proxy_pass_request_headers on;（默认开启），但不额外proxy_set_header
主动清除不可信的 X-Forwarded-Port（防御性配置）
当无法控制上游代理（如第三方 CDN 不按规范设头），可在本层 Nginx 入口处先清空再重设，避免污染：
FastAPI Flask Proxy
下载
FastAPI + Flask 混合部署最佳实践，解决路由定义、API 代理等常见问题，适用于同时运行 FastAPI API 与 Flask 前端的场景。
- 用
proxy_set_header X-Forwarded-Port "";清除上游传来的旧值（注意：空字符串会发送，部分后端可能视为空头） - 紧接着用
proxy_set_header X-Forwarded-Port $server_port;写入可信值 - 或更稳妥地：用
map判断来源 IP 是否可信，仅对可信源保留/重设该头
配合 X-Forwarded-Proto 判断实际端口语义
X-Forwarded-Port 单独使用易出错。应结合 X-Forwarded-Proto 推断语义端口：
- 若
X-Forwarded-Proto: https，即使X-Forwarded-Port: 80也应视为 443（因 HTTPS 默认端口是 443） - 后端应用应优先检查
X-Forwarded-Proto，再决定是否使用X-Forwarded-Port；若两者矛盾，以协议为准 - Nginx 中可统一设：
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
验证与调试技巧
快速确认头是否按预期传递：
- 在目标应用中打印所有
X-Forwarded-*头，观察X-Forwarded-Port的最终值 - 用
curl -v模拟请求，加-H "X-Forwarded-Port: 9999"测试是否被覆盖 - 在 Nginx 日志中添加
$http_x_forwarded_port字段，记录每层处理前后的值 - 检查是否有其他模块（如 realip、geoip）意外修改了请求头
