关键是透传并标准化关键请求头：Host、X-Real-IP、X-Forwarded-For、X-Forwarded-Proto、X-Request-ID，按需选择性透传Authorization、X-Tenant-ID等业务头，禁用敏感头，确保proxy_set_header在proxy_pass前配置，并通过add_header和access_log验证生效。
构建面向微服务架构的标准请求头转发网关，关键是让后端服务能准确获取客户端真实信息和上下文，避免因代理跳转丢失关键元数据。Nginx 本身不修改请求体，但必须在 proxy_pass 前主动注入、透传或重写关键头部。
必须设置的标准化请求头
以下 header 是微服务间协同的基础，缺一不可：
-
Host：设为
$host，确保后端生成正确跳转链接或签名计算不因 Host 变更而失效 -
X-Real-IP：设为
$remote_addr，提供原始客户端 IP（非 Nginx 本机地址） -
X-Forwarded-For：用
$proxy_add_x_forwarded_for追加，兼容多层代理场景 -
X-Forwarded-Proto：设为
$scheme，让后端知道是 HTTP 还是 HTTPS，影响重定向逻辑 -
X-Request-ID：建议用
$request_id（需启用http_random_index_module或 OpenResty 的ngx_http_core_module），用于全链路追踪
按微服务需求定制透传头
不同服务可能依赖特定 header，网关应有选择地透传而非全量放行：
- 若后端使用 JWT 鉴权，确保
Authorization头不被 Nginx 拦截或覆盖（默认透传） - 租户隔离场景下，可透传
X-Tenant-ID或X-Cluster，并配合map指令做路由决策 - 灰度发布时，前端携带
X-Release: canary，网关可用map $http_x_release $upstream_name { "canary" user-svc-canary; default user-svc; }动态选择 upstream - 禁止透传敏感头如
X-Internal-Token或Cookie中的 session secret，应在 location 级用proxy_hide_header或proxy_set_header显式清除
防止 header 被意外覆盖或污染
常见配置陷阱会导致 header 错误，需特别注意：
- 不要在
server块顶层直接写proxy_set_header，应放在每个location内，避免跨路径污染 - 若上游是 gRPC 服务，需额外添加
grpc_set_header并启用http_v2_module，且禁用proxy_buffering - 当启用
auth_request做前置鉴权时，鉴权服务返回的 header 默认不会透传给主后端，需用auth_request_set显式提取并赋值给新变量再 set - 所有
proxy_set_header必须写在proxy_pass之前，否则无效
验证与可观测性保障
仅配置不够，还需确认 header 真实到达后端：
- 在测试 location 中临时加入
add_header X-Debug-Headers "$http_x_real_ip, $http_x_forwarded_for, $http_authorization";，用 curl 查看响应头 - 开启 access_log 自定义格式，包含
$http_x_real_ip和$http_authorization（注意脱敏，避免记录 token） - 对关键服务，在 upstream 中配置
proxy_next_upstream error timeout http_502;，避免因 header 异常导致 502 却无日志线索
