Nginx无法直接传递客户端真实端口号，因HTTP标准头无定义且无内置变量支持；可通过X-Client-Port自定义头（需客户端可控并启用underscores_in_headers）、X-Forwarded-Port传Nginx监听端口，或改用Token/Request-ID等更可靠标识替代端口依赖。
Nginx 本身无法直接传递客户端真实端口号，因为 HTTP 协议标准头中没有定义该字段，且 Nginx 内置变量中不提供 $remote_port（仅支持 $remote_addr）。后端若需依赖客户端 IP + 端口组合做策略判断（如灰度路由、连接级限流），必须通过间接方式实现。
用 X-Client-Port 自定义头（客户端可控时首选）
让客户端在发起请求时主动带上源端口，例如：
X-Client-Port: 52103
Nginx 配置透传即可：
- 启用下划线支持：
underscores_in_headers on;（否则含下划线的头会被丢弃） - 透传该头：
proxy_set_header X-Client-Port $http_x_client_port;
⚠️ 注意：此法仅适用于内部 SDK、测试脚本或可控终端；浏览器受 CORS 和安全策略限制，无法手动设置该头。
用 X-Forwarded-Port 传服务端监听端口（不等于客户端端口）
如果后端真正需要的是“客户端连接到 Nginx 所用的端口”（比如区分 80/443 入口做协议适配），可用：
proxy_set_header X-Forwarded-Port $server_port;
⚠️ 注意：$server_port 是 Nginx 监听的端口（如 80 或 443），不是客户端源端口。它反映的是入口协议层信息，适用于多端口对外暴露场景，但不能替代真实客户端端口。
改用更健壮的标识替代端口依赖
端口本身不稳定（NAT、连接复用、短连接等会导致变化），生产环境建议避免强依赖客户端端口。可考虑：
- 由客户端生成唯一 Token 或 Request-ID，透传
X-Request-ID给后端做链路追踪与策略绑定 - 后端基于
X-Real-IP+ 用户身份（如 JWT 中 sub 字段）做会话级识别 - 在负载均衡层（如 SLB/WAF）注入可信端口信息，并只允许来自内网 Nginx 的请求携带该头
本质上，客户端端口不是可靠的身份标识，优先从架构层面降低对它的依赖。
