Nginx无法直接获取客户端真实源端口，因HTTP协议未定义该字段且TCP层端口在应用层不可见；可通过可信客户端自定义X-Client-Port头并透传，或改用X-Request-ID、用户ID等更稳定标识，禁用伪方案如误读$server_port或信任伪造头。
Nginx 本身无法直接获取并透传客户端真实源端口（$remote_port 变量不存在），因为 HTTP 协议标准头中没有定义该字段，且 TCP 层的源端口在应用层不可见。但若后端确需依据客户端 IP+端口组合做策略（如灰度路由、连接指纹、会话绑定等），可通过以下安全、可控、可落地的方式实现。
明确区分：服务端端口 ≠ 客户端端口
别混淆 $server_port（Nginx 监听端口）或 $remote_addr（客户端 IP）——这些都不是你要的“客户端发起请求时用的源端口”。真实源端口只能由客户端主动提供，或在可信内网链路中通过辅助手段推断。
客户端可控场景：自定义 Header + Nginx 透传
适用于内部 SDK、APP、CLI 工具或测试脚本等可自主构造请求的场景。
- 客户端在发起请求时带上自定义头，例如：
X-Client-Port: 52183 - Nginx 配置中启用下划线支持，并透传该头：
underscores_in_headers on; proxy_set_header X-Client-Port $http_x_client_port;
- ⚠️ 注意：浏览器发起的普通 HTTP 请求无法设置该头（受 CORS 和安全策略限制），此方式仅限可信客户端。
多层代理链路中：不依赖端口，改用更稳定的标识
端口易变（NAT、连接复用、短连接重用），可靠性远低于 IP 或 Token。建议后端逐步迁移到更健壮的标识方式：
- 使用请求级唯一 ID（如
X-Request-ID）做会话追踪 - 用认证后的用户 ID（如
X-User-ID）替代 IP+端口组合鉴权 - 若需设备指纹，可结合 TLS 会话 ID、User-Agent 哈希、或客户端生成的 nonce
不推荐的“伪方案”及风险
- ❌ 试图用
$connection或$binary_remote_addr拼接端口 → Nginx 无对应变量，纯属误读 - ❌ 把
$server_port当作客户端端口 → 它只是 Nginx 自己监听的端口（如 443），与客户端无关 - ❌ 信任未经校验的
X-Forwarded-For中的端口字段 → HTTP 头可被任意伪造，无安全意义
后端读取时务必校验来源可信性，比如只接受来自内网 IP 的 X-Client-Port，或对值做范围限制（如 1024–65535），避免注入或整数溢出问题。
不复杂但容易忽略。
