HSTS只能通过HTTPS响应头配置，不能用HTML的meta标签实现；必须在Nginx的443 server块中用add_header ... always添加，并配合80端口301重定向和HTTPS可用性保障。
不能在 index.html 里配置 HSTS —— 所有试图用 <meta http-equiv="Strict-Transport-Security"> 的做法都无效。
为什么 <meta> 标签完全不起作用
HSTS 是 HTTP 协议层机制，不是 HTML 特性。浏览器只从 HTTPS 响应头中读取 Strict-Transport-Security，且必须满足：证书有效、连接可信、响应由服务器直接发出。
用户第一次访问 http://example.com 时，请求根本没走 HTTPS，HTML 文件都还没下载，<meta> 根本不存在，更不可能被解析或执行。
RFC 6797 明确禁止通过 HTML 标签传递 HSTS 策略，所有主流浏览器（Chrome、Firefox、Edge、Safari）均不支持。
立即学习“前端免费学习笔记（深入）”；
Nginx 中正确添加 HSTS 响应头的位置
HSTS 头必须加在 listen 443 ssl 的 server 块内，且需搭配 always 参数（防止被子 location 覆盖）：
server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
<pre class='brush:php;toolbar:false;'># ✅ 正确：加在 server 级，用 always
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
location / {
root /var/www/html;
index index.html;
}}
- 不要写在
location ~ \.php$或其他子块里——容易漏掉静态 HTML 响应 - 不要省略
always，否则 304 响应或某些缓存场景下头会被丢弃 - 如果用了 CDN（如 Cloudflare），确保它透传该 header，而非自行覆盖或删除
必须同步完成的两件事：HTTP 重定向 + HTTPS 可用性
HSTS 不是独立开关，它依赖两个前置条件稳定生效：
-
listen 80server 块中必须有 301 重定向：return 301 https://$host$request_uri;（注意带$request_uri，否则参数丢失） - HTTPS 服务本身必须全链路可用：证书未过期、私钥权限为
600、Nginx 用户可读证书目录、443 端口开放 - 若任意子域（如
api.example.com）不支持 HTTPS，又启用了includeSubDomains，会导致整个域名不可访问
preload 参数上线前务必验证并小范围灰度
preload 不是“多加个词就更安全”，它意味着你申请进入浏览器预加载列表（hstspreload.org），一旦收录，撤回需数月，期间任何 HTTP 回滚或证书故障都会造成大面积访问中断。
上线前检查：
- 用
curl -I https://example.com确认响应头含完整Strict-Transport-Security - 在 Chrome 开发者工具 > Application > Clear storage > Clear site data 后，首次访问测试是否自动跳转 HTTPS
- 先设
max-age=300（5 分钟）观察几天，确认无误再逐步拉长
真正起作用的永远是服务器响应头，不是 HTML 文件内容。把精力放在 Nginx/Apache 配置和证书运维上，比改 index.html 有用一百倍。
