nginx无法获取客户端源端口，仅能通过$server_port透传自身监听端口；应使用x-forwarded-port头传递该值，后端据此识别原始访问端口，而非尝试获取不存在的$remote_port。
Nginx 本身无法获取客户端连接时使用的源端口（即 $remote_port），这是由 HTTP 协议设计和 Nginx 实现共同决定的：HTTP 标准头中没有定义“客户端源端口”字段，且 Nginx 内置变量中不存在 $remote_port（仅提供 $remote_addr、$server_port 等）。
你真正能拿到并透传的，是 Nginx 自己监听并接收请求的那个端口——也就是用户实际访问的端口（如 80、443 或 8080），它对应变量 $server_port。这个值对后端识别原始访问上下文（比如生成重定向 URL、判断 HTTPS 环境）非常关键，但请注意：它不是客户端的本地端口，而是服务端的监听端口。
✅ 正确做法：用 $server_port 透传用户访问的服务端口
这是最常用、最可靠的方式，适用于绝大多数反向代理场景：
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port; # ← 关键：透传 Nginx 监听端口
}
-
$server_port：当前server { ... }块监听的端口（如listen 443 ssl;→ 值为443） - 后端应读取
X-Forwarded-Port和X-Forwarded-Proto，而非直接调用request.getServerPort()，避免暴露内部端口（如8080）
❌ 不可行方案：试图获取客户端源端口
-
$remote_port不存在，Nginx 不提供该变量 -
$connection、$binary_remote_addr等变量无法推导出客户端源端口 - 浏览器或公网客户端无法主动设置自定义头（如
X-Client-Port），受 CORS 和安全策略限制 - 即使客户端可控（如内部 SDK），也需额外约定 + 后端解析，且不适用于标准 Web 请求
⚠️ 多级代理时注意信任链
若请求经过 CDN、WAF 或多层 Nginx：
- 每一级都应透传
X-Forwarded-Port和X-Forwarded-Proto - 后端需配置为只信任来自可信代理的这些头部（例如 Spring Cloud Gateway、Express 中间件、或 Django 的
SECURE_PROXY_SSL_HEADER） - 避免被恶意伪造（如攻击者手动加
X-Forwarded-Port: 65535）
? 补充：需要唯一请求标识？用 $request_id
如果目标是链路追踪而非端口信息，推荐搭配使用：
proxy_set_header X-Request-ID $request_id;
-
$request_id是 Nginx 1.11.0+ 内置变量，自动产生 UUID - 可与日志、APM 工具联动，比端口更稳定、更通用
不复杂但容易忽略：端口透传的核心不是“客户端连了哪个端口”，而是“用户最初敲下回车时访问的是哪个端口”。抓住 $server_port 这个点，就踩准了关键。
