在微服务架构中，Nginx 作为反向代理与 Gateway（如 Spring Cloud Gateway）配合是常见组合，常需通过自定义请求头（如灰度标识 `color_sign`）实现灰度发布、权限校验等功能。但实际配置中易出现请求头丢失、跨域报错、移动端适配异常等问题。本文结合实操场景，完整拆解问题根源及全场景解决方案，助力开发者避坑。
一、核心问题场景回顾
本次实操核心需求：通过自定义请求头 `gray_sign: gray` 实现灰度发布标识传递，架构为「客户端 → Nginx → Spring Cloud Gateway → 后端服务」。过程中遇到三大问题：
Nginx 转发后，Gateway 读取不到 `color_sign` 请求头，日志显示为 `null`；
配置 `proxy_set_header Host $host;` 后，浏览器出现跨域报错，此前配置正常；
疑问：手机端（H5/原生APP）请求不携带 Host 头是否有影响？
下文逐一拆解问题根源，提供可直接落地的解决方案。
二、问题1：Nginx转发后自定义请求头丢失
2.1 问题根源
默认情况下，Nginx 不会主动拦截自定义请求头，但存在两个关键“卡点”导致请求头丢失：
下划线请求头默认被忽略：Nginx 默认配置 `underscores_in_headers off;`，会直接忽略名称包含下划线（如 `gray_sign`）的请求头，既不读取也不转发给后端；
自定义请求头未显式转发：Nginx 仅默认转发标准请求头（如 Host、User-Agent），自定义请求头需通过 `proxy_set_header` 显式声明转发，否则部分版本可能不传递。
2.2 解决方案：Nginx 配置优化
修改 Nginx 配置，开启下划线请求头支持并显式转发自定义请求头：
server { listen 80; server_name your-domain.com; # 你的域名/IP # 关键1：开启下划线请求头支持（必加，解决color_sign丢失核心问题） underscores_in_headers on; location / { proxy_pass http://your-gateway-ip:7762; # Gateway地址和端口 # 关键2：显式转发自定义请求头color_sign proxy_set_header color_sign $http_color_sign; # 保留客户端真实Host（后续跨域问题的关联配置） proxy_set_header Host $host; # 保留客户端真实IP（可选，便于日志排查） proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # 确保请求头转发开关开启（默认on，显式声明更稳妥） proxy_pass_request_headers on; } }配置后重启 Nginx，通过 `curl -H "gray_sign: gray" http://your-domain.com/test` 测试，Gateway 日志应能正常读取到 `gray_sign: gray`。
2.3 兜底检查：Gateway 代码校验
若配置后仍读取不到，需检查 Gateway 代码中请求头名称一致性：
// 确保常量名称与请求头完全一致（大小写、下划线无偏差） public class CoreConstants { public static final String CURRENT_COLORSIGN = "color_sign"; // 正确 // 错误示例：color-sign（连字符）、Color_Sign（大小写） }可在 Gateway 过滤器中添加调试日志，打印所有请求头确认是否接收：
HttpHeaders headers = request.getHeaders(); log.info("接收到的所有请求头：{}", headers); log.info("color_sign值：{}", headers.getFirst("color_sign"));三、问题2：配置Host转发后浏览器跨域报错
3.1 问题根源
跨域报错的核心并非 Nginx 配置本身，而是 CORS（跨域资源共享）规范冲突，`proxy_set_header Host $host;` 仅为触发条件：
配置前“看似正常”的原因：未配置 `Host $host;` 时，Nginx 转发给 Gateway 的 Host 是内网地址（如 `127.0.0.1:7762`），浏览器对“内网地址 + 通配符源”校验不严格，即使 Gateway 配置 `allowed-origins: "*"` 也未报错；
配置后报错的核心冲突：配置 `Host $host;` 后，Nginx 转发真实客户端 Host（如 `your-domain.com`），浏览器严格执行 CORS 规范——当 `allow-credentials: true`（允许携带 Cookie/Token）时，`allowed-origins` 不能设为 `*`（通配符），否则强制拦截。
3.2 分场景解决方案
根据前端是否需要携带凭证（Cookie/Token），分两种场景优化 Gateway 跨域配置（优先级高于 Nginx 跨域头）。
场景1：前端需要携带凭证（主流场景）
必须放弃 `*`，指定具体允许的前端域名，同时显式包含自定义请求头：
spring: cloud: gateway: globalcors: cors-configurations: '[/**]': # 替换为实际前端域名（多个用逗号分隔，开发/生产环境区分） allowed-origins: "https://h5.your-domain.com,http://localhost:8080" allowed-methods: "*" # 允许所有请求方法 # 显式包含自定义请求头gray_sign，避免遗漏 allowed-headers: "gray_sign,token,Content-Type,Authorization" allow-credentials: true # 允许携带凭证 max-age: 3600 # 预检请求缓存时间，减少OPTIONS请求场景2：前端无需携带凭证
关闭 `allow-credentials`，可保留 `allowed-origins: "*"`：
spring: cloud: gateway: globalcors: cors-configurations: '[/**]': allowed-origins: "*" allowed-methods: "*" allowed-headers: "*" allow-credentials: false # 关闭凭证允许 max-age: 3600补充：Nginx 层跨域兜底配置
可在 Nginx 中添加跨域响应头兜底（优先级低于 Gateway 配置），处理预检请求：
# 跨域头兜底（仅H5场景需要） add_header Access-Control-Allow-Origin "https://h5.your-domain.com" always; add_header Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS" always; add_header Access-Control-Allow-Headers "gray_sign,token,Content-Type" always; add_header Access-Control-Allow-Credentials "true" always; # 处理OPTIONS预检请求，直接返回204 if ($request_method = OPTIONS) { return 204; }四、问题3：手机端不携带Host头是否有影响？
4.1 核心结论
手机端请求一定会携带 Host 头，且受 Nginx/Gateway 配置影响。Host 是 HTTP/1.1 必选请求头，无论移动端 H5、原生 APP，还是 Postman、curl 等工具，标准 HTTP 请求均会包含 Host 头，其作用是告知服务器目标访问域名/主机，Nginx 多站点配置也依赖 Host 头匹配站点。
4.2 手机端不同场景的影响分析
移动端场景 | 配置冲突的影响 | 正常配置的表现 |
|---|---|---|
移动端 H5（手机浏览器/APP内嵌WebView） | 与PC浏览器一致，触发跨域报错（如 `*` + `allow-credentials: true` 冲突），请求被拦截 | 正常请求，`gray_sign` 头可被 Gateway 读取，跨域校验通过 |
原生 APP（iOS/Android） | 无跨域报错（APP无浏览器同源策略），但 Gateway 若依赖 Host 头做业务逻辑（如域名白名单、灰度判断），可能出现逻辑异常 | 正常请求，`gray_sign` 头传递正常，Host 相关业务逻辑（如灰度）生效 |
4.3 移动端适配优化建议
兼顾 H5 + 原生 APP：采用「场景1」的 Gateway 跨域配置（指定具体前端域名），保留 Nginx 的 `proxy_set_header Host $host;`，确保 H5 跨域正常，原生 APP 业务逻辑不受影响；
仅原生 APP（无 H5）：可关闭 Gateway 全局 CORS 配置（APP 无同源策略，无需跨域校验），简化配置：
spring: cloud: gateway: globalcors: add-to-simple-url-handler-mapping: false
五、最终可用配置汇总
5.1 Nginx 最终配置
server { listen 80; server_name your-domain.com; underscores_in_headers on; # 开启下划线请求头支持 # 跨域头兜底 add_header Access-Control-Allow-Origin "https://h5.your-domain.com" always; add_header Access-Control-Allow-Methods "GET,POST,PUT,DELETE,OPTIONS" always; add_header Access-Control-Allow-Headers "color_sign,token,Content-Type" always; add_header Access-Control-Allow-Credentials "true" always; # 处理OPTIONS预检请求 if ($request_method = OPTIONS) { return 204; } location / { proxy_pass http://your-gateway-ip:7762; proxy_set_header Host $host; # 转发真实Host proxy_set_header color_sign $http_color_sign; # 转发自定义请求头 proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_pass_request_headers on; } }5.2 Gateway 最终配置（兼顾 H5 + 原生 APP）
spring: cloud: gateway: globalcors: cors-configurations: '[/**]': allowed-origins: "https://h5.your-domain.com,http://localhost:8080" allowed-methods: "*" allowed-headers: "color_sign,token,Content-Type,Authorization" allow-credentials: true max-age: 3600六、避坑总结
自定义请求头含下划线时，Nginx 必须开启 `underscores_in_headers on;`，并显式转发；
CORS 规范中，`allowed-origins: "*"` 与 `allow-credentials: true` 互斥，前端需携带凭证时必须指定具体域名；
手机端必带 Host 头，H5 需适配跨域配置，原生 APP 需关注 Host 相关业务逻辑；
调试时可通过打印请求头日志、curl 模拟请求等方式，快速定位请求头丢失、跨域等问题。
以上配置已在生产环境验证，可根据实际业务场景（如是否有 H5、是否需要携带凭证）微调，助力大家高效解决 Nginx 与 Gateway 配合中的请求头、跨域问题。
