HSTS 是一份单向承诺：max-age 是倒计时，includeSubDomains 是范围，preload 是写进浏览器

直接答案

「给站点加个 HSTS 头吧，安全。」

这句话省略了三个参数：管多久、管不管子域、要不要进浏览器的预加载列表。三个都是单向的，而且失效方式各不相同。

你写的	浏览器记住什么	作用范围	怎么结束
max-age=N	从收到这个头起 N 秒内，只走 HTTPS	发头的这个主机	到期，或再收到 max-age=0
includeSubDomains	上面这条策略也管子域	该主机的所有子域，含不对外公开的	随主策略一起删除
preload	在用户第一次访问之前就知道这条策略	所有子域与嵌套子域	从列表移除，等浏览器发版，按月计

最容易混的一点先放在前面：HSTS 不是服务器跳转，是浏览器行为。 服务器收到明文 HTTP 请求时「应该」回一个 301（RFC 6797 §7.2 用的是 SHOULD），但那是另一件事；HSTS 的作用是浏览器在发出请求之前，就把 http:// 改写成 https://。

一、它改的是浏览器，不是服务器

RFC 6797 对 HSTS 策略的定义只有一句，但每个词都有后果：

An HSTS Policy directs UAs to communicate with a Known HSTS Host only over secure transport and specifies policy retention time duration.

紧接着的一句更关键：

HSTS Policy explicitly overrides the UA processing of URI references, user input (e.g., via the “location bar”), or other information that, in the absence of HSTS Policy, might otherwise cause UAs to communicate insecurely with the Known HSTS Host.

也就是说，用户在地址栏里手打 http://、点了一个明文链接、甚至书签里存的是旧地址，浏览器都会先把它改成 HTTPS 再发请求。具体做法在 §8.3：把 URI 的 scheme 换成 https，显式写 :80 的端口改成 443，没写端口的不补端口。

然后是最硬的一条，§8.4：

When connecting to a Known HSTS Host, the UA MUST terminate the connection … if there are any errors, whether “warning” or “fatal” or any other error level, with the underlying secure transport.

证书过期、域名不匹配、链不完整、OCSP 或 CRL 取不到——都算。浏览器不会给一个「继续访问（不安全）」的按钮。§12.1 把这设计叫 No User Recourse：

This means that the user should not be presented with a dialog giving her the option to proceed.

RFC 还解释了为什么：允许用户点过去，就是给中间人攻击留门（a recipe for a man-in-the-middle attack）。

由此有三条很常见的配置错误，值得单独列出来：

• 在 80 端口的响应里加 HSTS 头，无效。 §7.2 明确 An HSTS Host MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport；§8.1 则要求 UA 对非安全传输收到的头 MUST ignore。
• 用 <meta http-equiv="Strict-Transport-Security">，无效。 §8.5：UAs MUST NOT heed ... settings on <meta> elements。
• 同一个响应里出现两个 HSTS 头，只有第一个算。 §8.1：the UA MUST process only the first such header field。CDN 加一个、源站再加一个，第二个不会「合并」，只会被丢掉。

二、max-age 是倒计时，不是开关

max-age 是必需指令，单位是秒，语法就是 delta-seconds（§6.1.1）。它的含义是「从收到这个头开始，在这么多秒内把这个主机当作 Known HSTS Host」。

三个容易被忽略的细节：

1. 每次收到头都会重置倒计时。 §11.2 写得很直白：each receipt of this header by a UA will require the UA to update its notion of when it must delete its knowledge of this Known HSTS Host. 常驻的响应头相当于不断续期。
2. 没收到头不等于策略结束。 §8.6：只要还在 max-age 内，UA 会继续把该主机当作 Known HSTS Host，哪怕这些响应里根本没有 HSTS 头。
3. max-age=0 才是删除信号。 §6.1.1 与 §8.1 都写了：零表示 UA 不再把该主机当作 Known HSTS Host，并且一并删除 includeSubDomains。§6.2 还给了一个例子：max-age=0; includeSubDomains 与 max-age=0 效果相同，因为零时长下子域指令被忽略。

RFC 没有规定上限。 它只要求是 1*DIGIT。§6.2 的示例用 31536000 表示「大约一年」，但那是示例，不是门槛。把「一年」当成 RFC 要求，是下一节要说的 preload 规则串了台。

还有一个操作上的推论（属编辑判断，不是原文）：把 max-age 调小，不会追溯缩短已经发出去的承诺。 浏览器只会在下一次收到新头时，按新值重算到期时间；一个几个月不访问的用户，手里仍然是旧的长时限。所以「先写一年，出事再改小」不是即时回滚，只是对「还会再来」的用户逐步生效。

hstspreload.org 给的升级节奏更保守，值得照抄：

阶段	响应头	这一阶段要等多久
第 1 段	max-age=300; includeSubDomains	等满 300 秒
第 2 段	max-age=604800; includeSubDomains	等满 7 天
第 3 段	max-age=2592000; includeSubDomains	等满 30 天

原文的要求是每一段都 wait the full max-age of the stage before you move on，并且在每段里检查坏页、看流量与收入等指标。注意第 1 段就带了 includeSubDomains——这是在已经确认所有子域都能走 HTTPS 的前提下才成立的；如果还没盘清，先把 includeSubDomains 拿掉。

三、includeSubDomains：你忘记的子域也算

includeSubDomains 是一个没有值的指令（§6.1.2）。它一旦出现，策略就适用于「该主机以及它域名的所有子域」。§5.4 的执行模型是：UA 在连接某个主机时，会向上找它的父域，只要某个父域的策略带了 includeSubDomains，这条策略就落到当前主机上。

这条指令的麻烦不在语法，在清单。hstspreload.org 在部署建议里专门加了一句：

This also includes internal subdomains that are not publicly accessible.

也就是说，internal.example.com、jenkins.example.com、某个早已忘记的 old.example.com，都在这条策略的管辖范围内。它们之中只要有一个没有可用的 HTTPS 证书，用户就打不开——而错误页上没有「继续」。

RFC 自己给了两个很具体的反例：

• §11.4.1：CA 的 CRL 与 OCSP 服务常跑在明文 HTTP 上，有时还在子域。如果主域带了 includeSubDomains，那么访问过主域的用户，之后会无法取 CRL、无法做 OCSP 检查——不是因为证书坏了，而是因为浏览器拒绝走明文。
• §11.4.2：主域只做跳转，用户实际书签的是 www。 如果只有 example.com 发 HSTS 头，而用户从不访问裸域，那么 UA 根本收不到这条策略；includeSubDomains 也帮不上忙，因为它只在「父域策略已经被记住」之后才起作用。解法是让实际被访问的那个子域也发头，而不是只靠父域。

还有一条安全侧的提醒，§14.5：HSTS 本身可以被用来做拒绝服务。攻击者若能通过 HTTP 响应拆分、伪造跳转，或诱导用户手工配置，就可能给一个只支持 HTTP 的主机设上策略，让它对受影响的用户彻底不可用。这不是「别用 HSTS」的理由，而是「别在没盘清的主机上开」的理由。

顺带说一个常被忽略的场景：如果你用的是自签证书或内部 CA，而根证书没有装进用户的浏览器/系统信任库，§11.3 的结论是连接会失败——secure connections to that site will fail, per the HSTS design。HSTS 不会给内部证书开例外。

四、preload：把策略写进浏览器二进制

HSTS 有个天生的缺口：浏览器只有在访问过一次之后才知道这条策略。hstspreload.org 把它叫 first-load problem——第一次连接仍可能被中间人截住。preload 列表就是为了补这个缺口：Chrome 把一批「强 HSTS、只走 HTTPS」的域名编进浏览器；发往这些域名的请求只走 HTTPS，HTTP 请求会被升级，连不上就失败。

页面还写明：其他主流浏览器（Firefox、Safari、IE 11、Edge）的预加载列表基于 Chrome 的列表。所以这不是「Chrome 一家的事」，但也不能保证每家都同步、都按同样的时间表更新——原文在移除一节明确说 we cannot make guarantees about other browsers。

4.1 收录门槛

通过 hstspreload.org 提交，站点必须同时满足：

1. 提供有效证书；
2. 如果在 80 端口监听，同主机从 HTTP 跳到 HTTPS；
3. 所有子域都能走 HTTPS；如果 www 有 DNS 记录，必须支持 HTTPS；
4. 裸域的 HTTPS 响应带 HSTS 头，且 max-age 至少 31536000 秒（一年）、带 includeSubDomains、带 preload。

第 4 条还有一个补充：如果 HTTPS 站点还有额外跳转，那个跳转也必须带 HSTS 头（that redirect must still have the HSTS header），而不是只在最终页面上有。

另外两条时间线值得记住：

• 2017-10-11 及以后提交的域名适用上面的 31536000 门槛；
• 2016-02-29 至 2017-10-11 之间提交的旧域名，门槛是 10886400 秒。

所以「一年」是这个表单当下的收录门槛，不是 RFC 的通用要求，也不是历史上一直如此。

4.2 进去之后

提交成功不等于立刻生效。原文：新条目 hardcoded into the Chrome source code and can take several months before they reach the stable version。在这期间，不同版本、不同浏览器的用户看到的状态并不一致。

移除更难：

Be aware that inclusion in the preload list cannot easily be undone. Domains can be removed, but it takes months for a change to reach users with a Chrome update and we cannot make guarantees about other browsers.

页面也给了一条现实路径：如果你发现某个子域因为强技术或成本原因确实无法提供 HTTPS，we will generally honor requests to be removed。注意措辞是「通常会批准」，不是「一键撤销」。而且删掉响应头里的 preload 指令只是让站点 immediately eligible for the removal form——只是有资格申请；反过来，不满足持续要求也可能被自动移除。

4.3 它并不是默认推荐

这一节最该被单独引用。同一页的开头就写着：

The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS. While HSTS is recommended, HSTS preloading is not recommended.

以及对工具/模板维护者的要求：

If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default.

理由很实际：他们经常收到站点运营者的邮件，说只是「试了一下 HSTS」，结果发现自己在预加载列表里，而某些子域根本不能上 HTTPS；Removal tends to be slow and painful for those sites。

还有一条事实能解释「为什么收益有限」：不少浏览器（页面点名 Chrome、Safari）will automatically upgrade all HTTP navigations to HTTPS, regardless of the domain's HSTS policy。也就是说，preload 的额外价值主要体现在存在主动攻击者、且这些自动升级会失败的时候。

五、三层怎么选：一张判断表

你的处境	建议	依据
刚上 HTTPS，子域还没盘清	只用 max-age=300，先不加 includeSubDomains	分阶段 ramp；子域清单是前置条件
主域 + 所有子域（含内部）都能 HTTPS	可以加 includeSubDomains，仍从短时长起步	hstspreload 的内部子域提醒；RFC §11.4
子域里有 HTTP-only 的后台、监控、旧系统	不要加 includeSubDomains，更不要 preload	RFC §11.4.1 的 CRL/OCSP 反例；§14.5 的 DoS
用自签证书或内部 CA	先确认根证书已部署到所有用户，否则不要开	RFC §11.3：连接会按设计失败
证书自动续期 + 到期监控都已就位	才考虑把 max-age 拉到一年	长时限的前提是「不会坏」
想进 preload	先满足四条门槛，再连续观察数月	移除按月计，且不保证其他浏览器
只想要「别让用户走明文」	HSTS 就够了，不必 preload	来源自己写 preload 收益有限

一句话总结这张表：includeSubDomains 是范围承诺，preload 是长期承诺；范围没盘清就不要承诺范围，运维没底就不要承诺长期。

六、出事时：先修复，不是先降级

这是整篇最反直觉、也最需要在故障当天记住的一节。

如果 TLS 已经坏了，你就发不出「解除」的头。 浏览器要收到 max-age=0，必须先完成一次成功的 TLS 连接；证书错误时 §8.4 要求直接终止连接，响应头根本没机会被读到。所以 max-age=0 不是远程开关——它只能对「还能连上你」的用户生效。

这推出一个操作顺序（编辑判断，但直接来自上面的机制）：

1. 先修证书：续期、重签、把链补全，让 HTTPS 恢复可用；
2. 再决定要不要降级：如果只是某个子域坏了，而裸域还能正常服务，可以在裸域发 max-age=0 或去掉 includeSubDomains；但这会让所有子域一起失去保护，通常不如直接修那个子域的证书；
3. 最后才谈 preload：改响应头不会动预加载列表里的条目，那条路要单独走移除表单，按月计。

几个具体判断：

现象	能不能靠响应头救	该做什么
裸域证书过期，用户全面打不开	不能	立刻续期/换证书；max-age=0 送不到
某个子域证书过期，裸域正常	能，但有代价	优先修子域证书；其次才考虑在裸域降级
子域只有 HTTP 服务，被 includeSubDomains 挡住	能	给子域上 HTTPS，或在裸域去掉 includeSubDomains
已进 preload，想撤回	不能	走移除表单；等浏览器发版，数月
用户说「清一下缓存就好了」	不是协议路径	只有该主机自己能删；UA 的删除入口是实现建议，不可依赖

最后一条展开一点。§5.3 说策略按域名存储，Only the given HSTS Host can update or can cause deletion of its issued HSTS Policy。§12.5 确实建议 UA 提供「按主机删除」的功能，但同时说这功能要非常谨慎地设计，不能变成用户日常「点一下就过去」的动作。所以：浏览器可能有手工删除入口，也可能没有；即使有，也不该把它写进故障预案。 同理，不要教用户点「继续访问」——RFC §12.1 的设计就是不给这个选项。

七、十分钟自检：五条命令与一张判读表

以下命令为示例，example.com 请替换成你的域名（命令与判读顺序属编辑判断）。

第一组：看 HTTPS 响应到底发了什么

curl -sSI https://example.com | grep -i '^strict-transport-security'
curl -sSI https://example.com | grep -ci '^strict-transport-security'

第一条看值和指令，第二条数个数。按 §8.1，多个头只有第一个生效，所以计数应该是 1。

第二组：看 80 端口是不是「同主机」跳转

curl -sSI http://example.com | grep -iE '^(HTTP/|location:|strict-transport-security:)'

期望看到 301/308 且 Location 指向同一个主机名的 HTTPS 地址。这里如果出现 HSTS 头，按 §7.2/§8.1 是无效的——不要把它当成「已经配好了」。

第三组：把子域清单跑一遍

for h in example.com www.example.com api.example.com internal.example.com; do
  printf '%-28s ' "$h"
  curl -sSI --max-time 10 "https://$h" | head -1
done

这一步的目的不是看头，是看每个子域能不能完成 TLS。任何一个失败，includeSubDomains 就不该开。

第四组：确认证书覆盖了要用的名字

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -dates -subject -ext subjectAltName

看 notAfter 与 SAN 列表。证书里没有的名字，就是将来会失败的名字。

第五组：查 preload 状态

按 hstspreload.org 的说明，可以在 Chrome 里打开 chrome://net-internals/#hsts 查当前列表状态。其他浏览器的入口与更新节奏不同，来源明确说不对它们作保证。

判读表

你看到的现象	更可能的原因	下一步
只有 HTTP 响应带头，HTTPS 没有	头加错了 server 块	加到 HTTPS 的响应上
HTTPS 响应有头，但 max-age=0	策略被删除或从未生效	确认这是不是你想要的状态
同一个响应有两个 HSTS 头	CDN 与源站各加了一个	只保留一个；第二个不会生效
头只在最终页面有，跳转那跳没有	少了 preload 要求的那一条	让每个跳转响应也带头
某个子域 curl 直接 TLS 失败	证书没覆盖或链不全	修证书，或先去掉 includeSubDomains
max-age 小于 31536000 却带了 preload	不满足收录门槛	要么升到门槛，要么删掉 preload
chrome://net-internals/#hsts 显示已 preload	已在列表里	改头不会立刻移除，按移除流程走

八、开启前的十二项清单

1. 列出所有子域，包括不对外公开的内部子域、监控、CI、旧系统。
2. 对每个子域跑一遍第三组命令，确认 TLS 能完成，而不只是「DNS 能解析」。
3. 确认 80 端口是同主机跳转；如果有额外跳转，每一跳都要带 HSTS 头。
4. 确认裸域的 HTTPS 响应带三条指令：max-age、includeSubDomains、preload（如果你要提交）。
5. 确认只有一个 HSTS 头，且它不是加在 80 端口响应上的。
6. 从 max-age=300 起步，等满整个时长，再进入下一段。
7. 在每一段观察真实指标：坏页、流量、收入、错误率，而不是只看「站点能打开」。
8. 证书续期与到期监控先于长 max-age：没有自动续期与告警，就不要写一年。
9. 确认内部 CA / 自签证书的根已部署，否则不要开 HSTS。
10. 写下「谁能发 max-age=0」：哪个仓库、哪个配置、谁能上线。故障当天再找就晚了。
11. 把 preload 当成独立决策，默认不开；要开，先满足四条门槛并连续观察数月。
12. 把决定与日期记进仓库：为什么开、当时子域清单是什么、谁批准的（这一条属编辑判断）。

九、七种误读，与本周能做的五件事

误读一：「HSTS 能防住首次访问。」 不能。首次访问仍可能被中间人截住（§14.6 的 Bootstrap MITM）。preload 才是为这个缺口设计的，而且只对列表内的域名有效。

误读二：「HSTS 会做 301 跳转。」 不会。是浏览器在发请求前把 URI 升级成 HTTPS（§8.3）。服务器回 301 是 §7.2 对明文请求的独立建议，两者不是一回事。

误读三：「一年是 RFC 要求。」 RFC 只要求 max-age 是 delta-seconds，没有上限也没有下限。31536000 是 hstspreload.org 当前的收录门槛，旧条目还用过 10886400。

误读四：「preload 可以一键撤销。」 原文是 cannot easily be undone、takes months，且对其他浏览器 cannot make guarantees。删掉 preload 指令只是「有资格申请移除」。

误读五：「清缓存就能解除。」 协议层只有该主机自己发 max-age=0 才会删（§5.3、§8.1）。UA 可能提供手工删除入口，但那是实现建议（§12.5），不能当预案。

误读六：「preload 更安全，应该默认开。」 来源自己写 HSTS preloading is not recommended、收益 minimal compared to HSTS，并要求工具与模板不得默认带 preload。

误读七：「max-age 调小就立刻生效。」 只对下一次还能收到新头的用户生效；长期不访问的用户仍按旧时限执行。真正需要立刻解除时，靠的是「还能连上」这个前提——而证书坏了就没有这个前提。

本周能做的五件事：

1. 把子域清单拉出来：DNS 记录、证书 SAN、反代配置三处对照，标出任何一个只能走 HTTP 的名字。
2. 给每个子域跑一次 curl -sSI https://...，把失败的名字单独列一张表。
3. 如果已经在用 HSTS，确认 max-age 与指令是有意选的，不是模板默认带上的。
4. 把 max-age=0 的发布路径写下来：哪个仓库、哪个环境、谁有权上线。
5. 对 preload 做一次明确表态：开或不开，理由写进仓库；不要「别人都开我也开」。

如果只能记住一件事：HSTS 的代价不在开启那天，而在出事那天——那一刻你已经没有「让用户点继续」的选项，也不一定还能把「解除」送到用户手里。

---

边界说明：本文关于 HSTS 的规则陈述来自 RFC 6797 与 hstspreload.org，两份来源均于 2026-10-31 访问并验证为 HTTP 200（字节数见「来源」）。不写「HSTS 能防住首次访问」——§14.6 明确说首次仍可能被截；不写「HSTS 会做 301」——升级发生在 UA 内部，服务器 301 是另一条独立建议；不写「一年是 RFC 要求」——31536000 是表单门槛，旧条目为 10886400；不写「preload 可一键撤销」——原文是 cannot easily be undone、takes months；不写「清缓存就能解除」——协议层只有该主机自己能删；不把 preload 写成默认推荐——来源自己写 not recommended；不写具体浏览器版本、份额与「几个月」的确切天数（原文只说 several months / months）。文中标注为编辑判断的有：第二节「调小 max-age 不会追溯缩短承诺」的推论、第五节的判断表、第六节的处理顺序与判断表、第八节第 12 项、第九节的五件事。示例域名沿用 RFC 的保留示例域，不对应真实站点。本文不重复证书生命周期、ARI 与监控信号（见《续期从不报错》一篇），也不重复 DNS 切换与 TTL 取证（见《改一条 A 记录不是发布》一篇）。

来源

以下页面均于 2026-10-31 逐条访问并验证为 HTTP 200；字节数为当日抓取的实际大小。

1. RFC 6797: HTTP Strict Transport Security (HSTS)核查于 2026/10/31（200，133 951 B）：§5.2 的 HSTS Policy 定义与 explicitly overrides the UA processing of URI references, user input ...；§5.3 按域名存储与 Only the given HSTS Host can update or can cause deletion of its issued HSTS Policy、零时长删除；§6.1.1 的 max-age 为 delta-seconds、零表示停止；§6.1.2 的 includeSubDomains 无值指令；§6.2 的示例（31536000 为一年示例、max-age=0; includeSubDomains 等价于 max-age=0）；§7.2 的 SHOULD 301 与 MUST NOT include the STS header field in HTTP responses conveyed over non-secure transport；§8.1 的非安全传输忽略、只处理第一个头、零时长删除（含 includeSubDomains）；§8.3 的 scheme 替换与 80→443 端口映射；§8.4 的任何证书/传输错误即终止；§8.5 不认 <meta http-equiv>；§8.6 缺头仍持续到 max-age 到期；§11.2 每次收到头都更新到期时间、建议配置默认零；§11.3 自签/内部 CA 导致连接失败；§11.4.1 CRL/OCSP 子域反例；§11.4.2 www 子域未收到策略的反例；§12.1 No User Recourse 与 a recipe for a man-in-the-middle attack；§12.3 pre-loaded list 类似根证书 at the factory 预置；§12.5 按主机删除只是实现建议；§14.5 HSTS 可被用于 DoS；§14.6 Bootstrap MITM。
2. HSTS Preload List Submission核查于 2026/10/31（200，15 809 B）：HSTS 的作用与 upgrade all http:// URLs for that domain to HTTPS；includeSubDomains 对子域同样升级；部署建议的三段 max-age=300 / 604800 / 2592000 与 wait the full max-age of the stage before you move on；This also includes internal subdomains that are not publicly accessible；首次加载问题与 Chrome 内置列表、其他浏览器基于 Chrome 列表；Chrome/Safari 会 automatically upgrade all HTTP navigations to HTTPS, regardless of the domain's HSTS policy；The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS. While HSTS is recommended, HSTS preloading is not recommended.；四条收录要求（有效证书、80 端口同主机跳转、所有子域 HTTPS 含 www、裸域头需 max-age ≥ 31536000 + includeSubDomains + preload）；额外跳转 that redirect must still have the HSTS header；新条目 hardcoded into the Chrome source code and can take several months；删掉 preload 只是 immediately eligible for the removal form、可能被自动移除；inclusion in the preload list cannot easily be undone、takes months、we cannot make guarantees about other browsers；we will generally honor requests to be removed；Preloading Should Be Opt-In 与 do not include the preload directive by default、Removal tends to be slow and painful；2017-10-11 与 2016-02-29 两条时间线与旧门槛 10886400。