要可靠透传用户标识，需结合可信 header（如 x-forwarded-for、x-auth-user-id）与 $proxy_add_x_forwarded_for 等变量透传真实 ip 和认证信息，并确保后端主动解析而非依赖默认 remote_addr；同时必须显式保留 host 等关键头，避免被重置。
在 Nginx 中，proxy_set_header 是将客户端请求头或自定义信息透传给后端服务的关键指令。要可靠传递用户标识（如登录态、用户ID、来源等），核心是选对 header 字段、确保值来源可信，并配合后端正确解析。
用 $remote_addr 或 $http_x_forwarded_for 获取真实客户端 IP
直接使用 $remote_addr 只能得到直连 Nginx 的 IP（可能是 CDN 或代理），不适用于多层代理场景。更稳妥的方式是信任上游可信代理设置的 X-Forwarded-For，并在 Nginx 中将其作为用户网络标识透传：
- 确认前端负载均衡或 CDN 已正确设置
X-Forwarded-For，且 Nginx 配置了set_real_ip_from和real_ip_header X-Forwarded-For - 在 proxy location 块中添加：
proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; - 后端应用应优先从
X-Forwarded-For最左非私有 IP 解析用户出口 IP
通过 Cookie 或 Authorization 透传认证凭证
若用户已登录，身份通常存在 Cookie 或 Bearer Token 中。Nginx 不解析鉴权逻辑，但可原样转发关键字段：
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
- 透传会话 Cookie：
proxy_set_header Cookie $http_cookie;（默认已继承，显式声明更清晰） - 透传 Token：
proxy_set_header Authorization $http_authorization; - 如需提取并重写（例如只传 user_id），需搭配
map指令预处理：map $http_cookie $user_id {<br> ~*user_id=(\w+) $1;<br> default "";<br>}
再用proxy_set_header X-User-ID $user_id;
注入可信的用户上下文（如内部系统 ID）
当 Nginx 位于认证网关之后（例如集成 OAuth2 Proxy 或 Keycloak Adapter），可在转发前注入已验证的用户信息：
- 假设认证中间件将用户 ID 写入
X-Auth-User-ID请求头，则直接透传：proxy_set_header X-User-ID $http_x_auth_user_id; - 若需拼接固定前缀或格式化，可用
concat方式：proxy_set_header X-Client-ID "svc-$remote_addr"; - 避免在 Nginx 中生成敏感标识（如 JWT），它不具备签名/验签能力，仅适合传递已校验过的上下文
注意事项与常见陷阱
header 透传看似简单，但容易因配置疏漏导致标识丢失或污染：
-
proxy_set_header会覆盖默认 header，未显式设置的原始 header（如 Host）将被重置为$proxy_host，需手动保留：proxy_set_header Host $host; - 不要用
$args或$query_string提取用户 ID 并设为 header——URL 参数易被篡改，缺乏可信度 - 所有自定义 header 名称建议统一加
X-前缀（如X-User-ID），避免与标准协议字段冲突 - 后端必须明确约定接收哪些 header，并做必要校验（如白名单 IP 校验、签名验证），Nginx 不提供安全边界
不复杂但容易忽略细节。关键是把 Nginx 当作“可信管道”，只传递上游已确认的信息，不自行生成或解析用户身份。
