在 nginx 中，`proxy_set_header` 默认不会透传客户端的真实端口，因为 http/1.1 规范中的 `host` 头部通常只包含域名或 ip，不包含端口。要获取并透传客户端连接 nginx 时的真实源端口，需要利用 nginx 内置变量 `$remote_port`，并通过自定义 header（如 `x-real-port`）将其传递给后端服务。
如何配置 Nginx 以传递源端口
要实现这一功能，只需在 `location` 或 `server` 块中添加一行配置：`proxy_set_header X-Real-Port $remote_port;`。这样，Nginx 会将客户端发起请求时使用的 TCP 源端口号作为值，放入名为 `X-Real-Port` 的 HTTP 头中，并随请求一起转发给上游服务器。后端应用只需解析该 Header 即可获取原始端口信息。
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend_server;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Real-Port $remote_port;
}
}
上述配置中，`$remote_port` 是 Nginx 提供的标准变量，代表客户端连接到 Nginx 时的源端口。当客户端通过非标准端口（如 8080）访问时，`X-Real-Port` 将包含该端口号。后端服务收到请求后，可从请求头中提取 `X-Real-Port` 的值。例如，在 Node.js 中可通过 `req.headers['x-real-port']` 获取，在 Python Flask 中可通过 `request.headers.get('X-Real-Port')` 获取。注意，如果客户端使用标准端口（80 或 443），某些代理或浏览器可能会省略端口部分，但 `$remote_port` 始终返回实际连接的 TCP 端口，因此即使为 80 也会正确传递。
为什么不能直接修改 Host 头部来携带端口
虽然 `Host` 头部理论上可以包含端口（如 `Host: example.com:8080`），但大多数后端框架和负载均衡器会自动标准化 `Host` 头部，忽略非标准端口或导致路由错误。此外，HTTP 规范要求 `Host` 头部必须存在且格式正确，手动拼接可能导致合规性问题。相比之下，使用自定义 Header（如 `X-Real-Port`）更安全、更清晰，且不会影响现有路由逻辑。Nginx 的 `$remote_port` 变量精确反映客户端连接端口，不受 URL 路径或查询参数影响，是透传源端口的最佳实践。
// Node.js 示例：读取 X-Real-Port
app.get('/test', (req, res) => {
const realPort = req.headers['x-real-port'];
res.json({ port: realPort });
});
此代码片段展示了后端如何接收并响应源端口信息。当请求到达时，`req.headers['x-real-port']` 将包含 Nginx 透传的客户端源端口。若未配置 `proxy_set_header X-Real-Port $remote_port;`，则该值为 `undefined`。建议在后端对可能缺失的情况做容错处理，例如提供默认值或记录日志。同时，确保后端服务信任 Nginx 传来的 Header，避免被恶意客户端伪造。
特定场景下源端口为空或异常的原因
在某些网络架构中，如使用云负载均衡器（AWS ALB、GCP LB）或反向代理链，`$remote_port` 可能无法正确反映最终客户端的源端口。这是因为中间代理会建立新的 TCP 连接，其源端口由代理自身分配，而非原始客户端。此时，若需获取真实客户端端口，需依赖其他机制，如 `X-Forwarded-For` 配合端口扩展（非标准）、或通过应用层协议传递。此外，若客户端使用 NAT 或防火墙转换，源端口可能被重写，导致 `$remote_port` 指向 NAT 设备的端口而非用户设备。验证方法：在本地直连测试可确认 `$remote_port` 准确性；在生产环境中，检查中间代理是否支持端口透传，或联系云服务商确认其行为。对于高安全要求场景，建议结合证书绑定或多因素认证，而非仅依赖源端口识别。
