hsts不参与灰度发布，仅强制https访问；灰度环境须禁用hsts，生产环境才启用并严格限定作用域，避免因配置不当导致灰度链路中断。
HSTS（HTTP Strict Transport Security）本身不参与灰度发布逻辑，它只是强制浏览器只通过 HTTPS 访问站点的安全策略。在灰度环境中，HSTS 不能、也不应被用来控制流量分发或版本路由——它和灰度发布是两个正交的机制：一个管“是否加密”，一个管“去哪个后端”。
但 HSTS 配置不当，确实会在灰度发布中引发实际问题，比如：
- 灰度域名（如
gray.example.com）误配了includeSubDomains或过长max-age，导致测试域名被浏览器永久锁定为 HTTPS，而测试环境又没配好证书，结果整个灰度链路无法访问； - 正式域名（如
example.com）开启 HSTS 后，灰度路径（如/api/v2/）仍走 HTTP 内部跳转，被浏览器拦截； - 灰度服务部署在临时子域或 IP 地址上，却继承了主站 HSTS 响应头，造成调试困难。
所以优化重点不是“用 HSTS 做灰度”，而是让 HSTS 不干扰灰度流程。
HSTS 配置必须按环境隔离
HSTS 头应只在正式生产环境启用，且严格限定作用域：
- ✅ 正式域名（
prod.example.com或example.com）可启用：add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
- ❌ 灰度域名（
gray.example.com、test.example.com、192.168.x.x）禁止设置 HSTS：# 在灰度 server 块中显式清除（即使 upstream 继承了 header） add_header Strict-Transport-Security "" always;
- ⚠️ 若灰度与正式共用同一 Nginx 实例，务必用
if或map按server_name或$host条件控制：map $host $hsts_value { default ""; ~^example\.com$ "max-age=31536000; includeSubDomains"; ~^www\.example\.com$ "max-age=31536000; includeSubDomains"; } server { listen 443 ssl; server_name example.com www.example.com gray.example.com; add_header Strict-Transport-Security $hsts_value always; }
灰度阶段禁用 preload 和 includeSubDomains
-
preload会将域名提交至浏览器预加载列表，一旦上线就无法撤回。灰度域名绝不可加。 -
includeSubDomains会让所有子域（包括api.gray.example.com、static.gray.example.com）强制 HTTPS。灰度环境常有未配证书的内部服务，启用后会导致大量 307 Internal Redirect 或连接失败。
开发/测试环境彻底关闭 HSTS
本地联调、CI 环境、预发环境建议：
- 不返回 HSTS 头；
- 或设极短
max-age=0（等效于清除）：add_header Strict-Transport-Security "max-age=0" always;
- 浏览器已缓存 HSTS 的，可通过 Chrome 访问
chrome://net-internals/#hsts手动删除（开发机需告知测试同学）。
配合灰度发布的安全兜底建议
- 所有灰度接口路径（如
/gray/,/v2/）应在 Nginx 层做ssl_redirect on显式跳转，避免 HTTP 回退； - 若灰度服务暂无有效证书，使用自签名证书 + 前端信任（仅限内网），不要妥协用 HTTP；
- 在灰度 Header（如
X-Env: gray）或 Cookie 中标记环境，后端日志和服务治理层据此过滤、告警，而非依赖 HSTS 判断环境。
HSTS 是安全护栏，不是流量开关。灰度发布靠的是请求特征识别与动态路由，HSTS 只负责确保那段流量走的是安全通道。两者各司其职，配错边界，反而会卡住灰度验证的关键环节。
