无法传递客户端MAC地址，因其属数据链路层标识，经三层设备后即丢失；但可透传客户端源端口，使用$remote_port变量配合proxy_set_header X-Real-Port。
无法通过 proxy_set_header 传递客户端真实的 MAC 地址和端口。
MAC 地址在 HTTP 代理中不可获取
MAC 地址是数据链路层（OSI 第二层）标识，仅在局域网内有效，经过路由器、NAT 设备或任意三层网络设备后就会被替换。当请求到达 Nginx（通常部署在公网或服务端网络）时，原始客户端的 MAC 地址早已丢失，Nginx 所在操作系统根本无法看到它。即使在同个局域网，Nginx 若非直接与客户端二层互通（如无交换机/网关介入），也通常只能看到上游网关的 MAC。
因此：
- proxy_set_header X-Real-Mac $xxx 没有对应的标准变量；
- Nginx 不提供读取 TCP 数据帧源 MAC 的机制；
- 任何试图“伪造”或“猜测”MAC 的做法都不可靠且无实际意义。
客户端源端口可通过 $remote_port 获取并透传
Nginx 支持使用内置变量 $remote_port 获取与 Nginx 建立 TCP 连接的客户端源端口（注意：这是连接 Nginx 的端口，不是原始请求最终目标端口）。该值可在 proxy_set_header 中使用：
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
示例配置：
location / {
proxy_pass http://backend;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-Port $remote_port; # ✅ 可用
}⚠️ 注意：
- 若 Nginx 前还有 L4 负载均衡器（如 AWS ALB、F5、HAProxy 启用 PROXY protocol），则 $remote_addr 和 $remote_port 可能是负载均衡器地址和端口，需启用 real_ip_header 或 proxy_protocol 并配合 set_real_ip_from 才能还原真实客户端信息；
- 客户端端口是临时随机端口（ephemeral port），仅对单次连接有意义，业务系统一般不依赖它做识别或策略控制。
替代方案：需要唯一客户端标识怎么办？
若目标是识别或追踪真实终端用户，应放弃 MAC 和端口，改用更可靠、应用层可控的方式：
- 前端生成并携带 UUID 或设备指纹（如通过 JS 计算浏览器特征 + 时间戳 + 随机数），通过请求头（如
X-Device-ID）发送； - 后端登录态绑定设备 token，由认证服务统一发放和校验；
- 结合 TLS 客户端证书（mTLS）实现强身份认证；
- 日志中记录
$remote_addr、$http_x_forwarded_for、$request_time等字段，用于风控或审计分析。
不复杂但容易忽略：网络分层决定了什么信息能传、什么不能传。与其强行透传 MAC，不如在应用层设计合理的标识机制。
