nginx在https中安全传递认证用户信息的核心是可信提取与可靠转发，而非替代后端鉴权；需通过mtls提取证书字段、透传jwt或basic auth身份、确保内网可信转发，并由后端主动校验x-auth-*类头。
在 Nginx 的 HTTPS 环境中，安全传递认证后的用户信息，关键不是让 Nginx 自己做权限判断，而是确保身份信息真实、完整、不可篡改地抵达后端应用。Nginx 作为网关，只负责“可信地提取”和“可靠地转发”，不替代后端做鉴权决策。
启用并验证客户端证书（mTLS 场景）
当使用双向 TLS（mTLS）完成强身份认证后，Nginx 已确认客户端持有合法 CA 签发的证书。此时可直接提取证书字段作为用户标识：
- 通过 ssl_verify_client on 强制校验，确保每个请求都附带有效证书
- 用 ssl_client_certificate 指定信任的 CA 根证书，防止伪造
- Nginx 自动解析证书内容，并注入标准请求头：$ssl_client_s_dn（完整 Distinguished Name）、$ssl_client_i_dn（签发者 DN）、$ssl_client_serial（序列号）等
- 在 location 块中用 proxy_set_header 将这些变量透传给后端，例如：
proxy_set_header X-Client-DN $ssl_client_s_dn;
proxy_set_header X-Client-Serial $ssl_client_serial;
透传其他认证方式的可信身份（如 JWT 或 Basic Auth）
若前端已用其他方式完成认证（如 API 网关签发 JWT），Nginx 可承担“信任链中继”角色：
- 保持原始认证头（如 Authorization: Bearer xxx）不被修改或丢弃，直接透传：
proxy_pass_request_headers on;（默认开启，但需确认未被覆盖） - 如需标准化或增强可信度，可在 Nginx 层校验 JWT 签名（需安装 nginx-jwt 模块），验证通过后再提取 sub、iss 等字段，写入自定义头：
proxy_set_header X-Auth-User $jwt_claim_sub; - 对 Basic Auth，可解码后提取用户名（注意：仅限 HTTPS 下，且后端必须忽略原始 Authorization 头，只信任 Nginx 注入的 X-Auth-User）
确保传输过程不被污染或伪造
即使信息已提取，若转发链路不可信，仍可能被中间节点篡改：
- 所有向后端的 proxy 请求，必须走内网可信通道（如 127.0.0.1 或私有网段），避免暴露在公网
- 后端服务应只接受来自 Nginx 出口 IP 的请求，并校验关键头是否来自预期来源（例如检查 X-Forwarded-For 是否与 Nginx 实际 IP 匹配）
- 禁用后端对原始请求头的直接信任，强制其只读取 Nginx 显式设置的 X-Auth-* 类头，且不处理未声明的同名头
- 若后端也是 Nginx，建议启用 http_realip_module 并配置 set_real_ip_from，防止伪造 X-Real-IP 影响身份上下文关联
后端应用必须主动消费并校验这些信息
Nginx 不会自动把头信息变成用户对象，后端需明确对接：
- Java Spring Boot：配置 server.forward-headers-strategy=framework，并在 Controller 中读取 request.getHeader("X-Client-DN")
- Python FastAPI：用 Depends 提取 header，结合证书序列号查用户库，拒绝空值或格式异常值
- Node.js Express：用 req.headers['x-client-dn'] 获取，配合中间件做白名单校验（如只允许特定 OU 或 CN）
- 所有场景下，后端应视这些头为“可信输入”，但仍需做最小必要校验（如非空、长度合理、不含控制字符），不盲目信任
