Strict-Transport-Security 必须由服务器在有效HTTPS响应中通过HTTP头发送，不可用<meta>标签设置；因RFC 6797明确禁止，且<meta>在HTML解析阶段生效，已错过策略注册时机，而HTTPS响应头具备传输完整性与即时生效能力。
Strict-Transport-Security 不是 HTML 的 <meta> 标签，也不能通过 HTML 设置——它必须由服务器在 HTTPS 响应中返回 Strict-Transport-Security HTTP 响应头。任何试图用 <meta http-equiv="Strict-Transport-Security"> 的写法都无效，浏览器会直接忽略。
为什么不能用 <meta> 标签设置 HSTS
浏览器规范（RFC 6797）明确禁止通过 HTML <meta> 设置 HSTS：该策略只接受 HTTPS 响应中的 HTTP 头，且要求证书有效、未过期、域名匹配。HTTP 响应头可被中间人篡改，但 HTTPS 下的响应头具备传输完整性，而 <meta> 在 HTML 解析阶段才生效，早已错过连接建立和策略注册时机。
常见错误现象：
- 页面里写了
<meta http-equiv="Strict-Transport-Security" content="max-age=31536000">，但curl -I https://example.com查不到Strict-Transport-Security头 - 浏览器开发者工具的 Network 面板中，HTTPS 响应 Header 里没有该字段
- 访问
chrome://net-internals/#hsts查询域名，显示 “Not found”
Nginx / Apache / IIS 中正确添加响应头
只有服务端配置生效。关键点：必须在 HTTPS 响应中发送，且不能出现在 HTTP 响应里（否则被忽略）。
立即学习“前端免费学习笔记（深入）”；
Nginx 示例（需放在 server 块的 ssl 配置内）：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
Apache 示例（启用 mod_headers 后）：
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
IIS 示例（web.config）：
<customHeaders> <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains; preload" /> </customHeaders>
注意：
-
always参数在 Nginx 中必需，否则 304/4xx 响应不带该头 -
preload要求max-age≥ 31536000 且含includeSubDomains，否则无法提交到 HSTS Preload List - 首次部署建议先设
max-age=300（5 分钟），验证无误再逐步延长
HSTS 生效的前提和典型陷阱
HSTS 不是“一配就永久生效”，它依赖浏览器缓存策略，且有明确触发条件：
- 用户必须至少成功完成一次无警告的 HTTPS 访问（证书不能过期、不能域名不匹配、不能自签名）
- 若用户清空浏览器数据、换新设备或首次访问，HSTS 不起作用——这就是为什么仍需服务端保留 HTTP→HTTPS 301 重定向作为兜底
- 子域名策略（
includeSubDomains）一旦开启，所有子域都强制 HTTPS；若某个子域（如http://blog.example.com）尚未支持 HTTPS，会导致整个子域不可访问 - 前端调用后端 API 时若混用 HTTP 协议，且后端返回了 HSTS 头，浏览器会自动将 HTTP 请求升级为 HTTPS（307 Internal Redirect），从而改变
Origin，触发 CORS 错误 —— 这类问题常被误判为跨域配置失误
真正容易被忽略的一点：HSTS 是“单向信任增强”，它不解决证书本身的问题。如果证书链断裂、时间错乱或域名不一致，浏览器连 HSTS 策略都不会存——更不会执行后续的自动跳转。上线前务必用 curl -Iv https://yourdomain.com 验证握手过程和响应头同时达标。
