Nginx 无法直接透传客户端原始端口，因 HTTP 标准头无定义且 $remote_port 不可用；可行方案包括客户端自定义头（X-Client-Port）、上游负载均衡注入 X-Forwarded-Port，或后端改用 Token/Request-ID 等更健壮标识替代端口依赖。

Nginx 的 proxy_set_header 本身无法直接透传客户端原始端口，因为 HTTP 协议标准头中没有定义“客户端源端口”字段，且 $remote_port 变量在 Nginx 中不可用（仅 $remote_addr 存在）。但后端若需依据客户端端口做路由或策略判断（如 IP+端口组合鉴权、灰度分流），可通过以下可行方式间接实现。

---

一、用自定义 Header 携带客户端端口（需客户端配合）

最直接的方式是让客户端主动在请求头中带上自己的源端口，例如：

X-Client-Port: 54321

然后 Nginx 透传该头：

proxy_set_header X-Client-Port $http_x_client_port;

⚠️ 注意：

• 此法依赖客户端可控（如内部 SDK、APP 或测试脚本），公网浏览器无法设置该头（受 CORS 和安全策略限制）；
• 需开启 underscores_in_headers on;（若头名含下划线），否则 Nginx 默认丢弃。

---

二、通过日志或变量拼接 IP+端口后透传（仅限可信内网场景）

若 Nginx 与客户端直连（无中间代理/CDN），且网络环境可信，可借助 $binary_remote_addr + $connection 等变量间接推导——但Nginx 原生不提供 $remote_port，无法精确获取。

实际中，部分用户误以为可用 $server_port 或 $server_addr，这些是服务端信息，与客户端无关。

WebChat Voice Proxy

⚠️ 已弃用 — 该技能已拆分为两个独立技能，以提升模块化程度：**webchat-https-proxy**（HTTPS/WSS 反向代理）和 **webchat-voi...**

下载

✅ 可行替代方案：

• 后端改用 X-Real-IP + 请求时间戳 + 连接特征做会话绑定，规避端口依赖；
• 或由上游负载均衡器（如 SLB、ALB）注入 X-Forwarded-Port（阿里云/腾讯云等支持），Nginx 再透传：

proxy_set_header X-Forwarded-Port $http_x_forwarded_port;

---

三、用 realip 模块 + 自定义头还原端口（不推荐，技术上不可行）

ngx_http_realip_module 仅处理 IP 地址映射，不支持端口解析或重写。试图用 set_real_ip_from + real_ip_header 处理端口字段属于误用，Nginx 不识别端口类头为地址元数据。

---

四、后端适配建议：绕过端口依赖

多数真实业务场景中，强制依赖客户端端口存在隐患（如 NAT、复用连接、端口随机化）。更健壮的做法是：

• 使用 Token 或 Cookie 标识会话，替代端口路由；
• 在登录/握手阶段由后端分配唯一 session_id 并透传；
• 若必须区分连接，可由 Nginx 添加唯一请求 ID：

map $request_id $client_conn_id {
    default $request_id;
}
proxy_set_header X-Request-ID $client_conn_id;

后端据此做轻量路由或日志追踪，比端口更稳定。

---

不复杂但容易忽略