AWS ELB架构下Nginx反向代理Node.js时启用HSTS为何不生效

链路协议匹配问题 #

当前整体请求流转路径为：

• 客户端浏览器 经HTTPS加密连接 访问AWS ELB，由ELB承担SSL证书解密、HTTP请求到HTTPS的全量重定向逻辑
• ELB 将解密后的请求以明文HTTP协议转发给后端EC2上仅监听80端口的Nginx
• Nginx 反向代理转发请求给本地8080端口运行的Node.js服务

HSTS策略的浏览器生效规则有硬性要求：HSTS响应头必须出现在HTTPS加密通道返回的响应中，才会被浏览器识别并强制启用。当前你将HSTS头配置在Nginx的80端口监听块中，虽然理论上ELB会将Nginx返回的响应通过HTTPS通道透传给客户端，但存在多个导致配置失效的常见坑点：

• Nginx配置的server块仅匹配server_name localhost，所有来自ELB的请求携带的是公网域名Host头，一旦被其他默认server块规则匹配，你定义的HSTS头根本不会被生成
• Nginx的add_header指令默认仅在200、201、204、206、301、302、303、304或307状态码的响应中生效，遇到后端返回4xx、5xx错误状态码时，自定义响应头会被自动跳过
• 若ELB配置了响应头过滤规则，会直接移除后端返回的HSTS头，导致Nginx的配置无法传到客户端
• 无条件在80端口的响应中添加HSTS头，当请求以HTTP明文形式经过Nginx时，生成的HSTS头会被浏览器直接忽略，无法触发策略生效

1. 调整Nginx配置逻辑
   利用ELB默认携带的X-Forwarded-Proto请求头（标识客户端最初访问的原始协议），仅在收到原始访问为HTTPS的请求时添加HSTS头，同时给所有自定义响应头加上always参数，确保所有状态码的响应都会带上安全头：

   server {
     listen       80;
     server_name  localhost;
     # 匹配所有ELB转发的请求，避免Host头不匹配导致规则失效
     server_name  你的公网域名;
   
     location / {
       proxy_pass http://localhost:8080;
       proxy_http_version 1.1;
       # 仅当ELB标识原始协议为HTTPS时，添加HSTS头
       if ($http_x_forwarded_proto = "https") {
         add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
       }
       # 其余安全头配置加上always参数，覆盖所有响应状态码
       add_header X-Frame-Options DENY always;
       add_header X-Content-Type-Options nosniff always;
       add_header Content-Security-Policy "default-src 'self' www.google-analytics.com ajax.googleapis.com www.google.com google.com gstatic.com www.gstatic.com connect.facebook.net facebook.com" always;
       add_header X-XSS-Protection "1; mode=block" always;
       add_header Referrer-Policy "origin" always;
       # 原有代理转发配置保持不变
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection 'upgrade';
       proxy_set_header Host $host;
       proxy_cache_bypass $http_upgrade;
     }
   }
   

2. 本地验证Nginx配置
   修改完成后先执行nginx -t校验语法正确性，重载Nginx服务后，在EC2本地模拟ELB转发的请求校验响应头：

   curl -I -H "Host: 你的公网域名" -H "X-Forwarded-Proto: https" http://localhost
   

   若返回结果中可看到完整的Strict-Transport-Security头，说明Nginx侧配置已生效。
3. 验证ELB透传规则
   通过公网HTTPS地址访问服务，查看响应头中是否存在HSTS字段。若仍缺失，检查ELB监听器的响应头配置，确认没有开启后端响应头过滤逻辑，也没有在ELB层面直接覆盖安全响应头的规则。

内容的提问来源于stack exchange，提问作者Babu Rao