Nginx通过auth_request_set提取认证服务返回的响应头（如X-User-ID），再用proxy_set_header透传给上游服务，实现鉴权后身份信息透传；需确保/auth返回200且含对应头，指令顺序为auth_request→auth_request_set→proxy_pass。

Nginx 本身不解析认证服务的响应体，但能可靠提取响应头，并通过 auth_request_set 把值存为变量，再注入到后续代理请求中——这是实现“鉴权后透传身份信息”最常用、也最稳妥的方式。

关键前提：认证服务必须在返回 200 时带上自定义响应头
比如你的 /auth 接口校验通过后，响应里要有类似这样的头：

X-User-ID: 10086
X-User-Role: admin
X-Auth-Scope: read:profile write:orders

没有这些头，Nginx 就无从提取。

---

✅ 正确配置 auth_request_set 提取响应头

在启用 auth_request 的 location 块中（例如 /api/），添加 auth_request_set 指令，格式为：

auth_request_set $user_id $upstream_http_x_user_id;
auth_request_set $role    $upstream_http_x_user_role;
auth_request_set $scope   $upstream_http_x_auth_scope;

注意三点：

Nginx Config Linter

对 Nginx 配置文件进行语法检查、验证和安全、性能审计。

下载

• 变量名（如 $user_id）可自定义，建议语义清晰
• $upstream_http_ 是固定前缀，后面接响应头名，全部小写、中划线转下划线（X-User-ID → x_user_id）
• 这些指令必须写在 auth_request /auth; 之后、proxy_pass 之前，否则变量未赋值

---

✅ 将提取的变量透传给上游服务

用 proxy_set_header 把变量作为新请求头转发：

proxy_set_header X-User-ID $user_id;
proxy_set_header X-User-Role $role;
proxy_set_header X-Auth-Scope $scope;

后端服务就能直接读取这些 header，用于日志记录、权限二次校验、个性化路由等，无需重复解析 token 或查数据库。

---

⚠️ 常见问题与避坑提示

• 响应头没生效？
  检查认证服务是否真返回了对应 header（用 curl -v http://auth-service/auth 验证）；确认 header 名拼写和大小写转换是否正确。

• 变量为空？
  auth_request_set 只在子请求返回 200 时执行。如果 /auth 返回 401，变量不会被赋值，$user_id 就是空字符串——后端收到的 X-User-ID: 会是一个空头，需做好容错。

• 需要默认值？
  Nginx 原生不支持 fallback，但可用 map 预设兜底：

  map $user_id $safe_user_id {
      "" "anonymous";
      default $user_id;
  }
  proxy_set_header X-User-ID $safe_user_id;

• 透传敏感信息要谨慎
  避免把原始 token、密钥、密码哈希等塞进响应头。只传必要字段，且确保传输链路（Nginx 到 auth 服务、auth 服务到 backend）全程走内网或 TLS。

不复杂但容易忽略。