HSTS preload 移除是怎么回事
HSTS 的 preload 名单被编译进浏览器发行版：一旦域名进入名单，即使响应头不再下发 HSTS，客户端仍会强制使用 HTTPS，直到浏览器版本更新。移除的渠道是官方提交页，先在该页申请移除，同时把响应头里的 preload 参数去掉并把 max-age 降到 0（或按计划下调），然后等待各浏览器的新版本发布生效。整个过程以月计，不能指望改完头立刻恢复。
基本信息
| 提交入口 | hstspreload.org（提交与移除申请同一入口） |
|---|---|
| 同步操作 | 响应头去掉 preload 参数，下调 max-age |
| 生效周期 | 随各浏览器发行版更新，通常以月计 |
| 影响范围 | 主域与所有子域一并受 preload 约束 |
| 不可逆性 | 已进入名单的域名在客户端侧不服从响应头变化 |
| 适用场景 | 域名停用、迁到纯 HTTP 或交给不再支持 HTTPS 的服务 |
典型使用场景
- 域名退役：旧域名不再提供 HTTPS，需要从名单中移除。
- 业务迁移：接管方无法维持证书自动续期，继续留在名单会导致全面不可访问。
- 子域影响评估：preload 覆盖子域，需要先清点所有使用该域的资产。
- 事故恢复：证书续期失败导致长时间中断时，评估是否先从名单退出。
- 接入新域名前的自查：确认是否历史上已被提交过 preload。
检查与状态确认
检查与状态确认
# 看站点当前的 HSTS 响应头（是否仍带 preload）
curl -sI https://example.com | grep -i strict-transport-security
# 确认 HTTPS 是否强制：早期仍可 HTTP 访问说明影响有限
curl -sI http://example.com | head -3
# 提交移除后按不同浏览器实测，并记录浏览器版本与验证日期移除动作与生效链路
| 环节 | 动作 | 注意 |
|---|---|---|
| 提交申请 | 在官方页面提交移除请求 | 说明理由，等待审核 |
| 响应头 | 去掉 preload，max-age 降为 0 | 改完不会立刻在客户端生效 |
| 客户端缓存 | 等待已有 HSTS 记录过期 | max-age 越长，等待越久 |
| 浏览器版本 | 随发行版更新逐步摘除 | 不同厂商节奏不同，要分别验证 |
| 验证 | 多浏览器、多网络实测 | 记录版本与时间，形成处置证据 |
preload 影响的是客户端行为，服务端配置改完不等于生效。评估影响面时要按「最坏情况下全部客户端仍强制 HTTPS」来规划恢复窗口。