strict-transport-security 实测：27 个首页 25 个发了，最短的只记五分钟
strict-transport-security 在 27 个首页里有 25 个发了，max-age 从五分钟到三年半都有。27 个站全部在第一跳把 http 跳到 https，其中一个用的是 302，而 18 个申请预置的头里有 3 个不满足公布的要求。
实测 · 2026-08-30 · 27 个首页 · 各发一次 http 请求和一次 https 请求 · Strict-Transport-Security
样本 / 口径：2026-08-15 起沿用的同一批 30 个站。2026-08-30 每个首页发两次请求 —— 一次打 http:// 且关掉跳转跟随，只看第一跳；一次打 https://，读安全响应头。三个站掉出去了：stackoverflow.com 与 medium.com 返回 403，reddit.com 只有 8,393 字节，没过 10,000 字节下限。剩 27 个。
27 个首页里 25 个发了 strict-transport-security。27 个全部在第一跳就把 http:// 跳到 https://，其中一个用的是 302。18 个在头里写了 preload，要求被预置进浏览器，而这 18 个里有 3 个今天发的头并不满足预置名单自己公布的提交要求。
怎么测的
每个站两次请求。http:// 那次用的是一个不跟随跳转的处理器，直接返回第一个响应，所以下面的状态码和 Location 是源站自己的第一句回答，不是一条链的终点。https:// 那次直接从交付的响应里读 Strict-Transport-Security。
两条限制放在这里说，不放文末。我们只看第一跳，所以跳两次的站在这里和跳一次的站长得一样。另外读的只是今天这个头，没有去查真正的预置名单 —— 今天头不达标的站，完全可能早年提交过、至今仍在名单里。
27 个站都跳 https，但用了三种码
跳转本身没有缺口可报。27 个站全部在第一个响应里就把 http:// 跳到同一主机的 https 地址，没有例外。
| 第一跳状态码 | 站数 | 例子 |
|---|---|---|
| 301 永久移动 | 22 | developer.mozilla.org |
| 308 永久移动 | 4 | vercel.com |
| 302 临时 | 1 | www.bbc.com |
那个 302 值得多看一眼。Google 的重定向文档把跳转分成永久和临时两类，对临时那一类写的是索引流程「doesn't use the redirect as a signal that the redirect target should be canonical」。把整个站从 http 迁到 https，大概是重定向里最不可能撤销的一种，所以这里的码和意图是拧着的。该发哪个码，在 301 和 302 重定向怎么选；同一批面板的跳数那一半在 重定向要跳几次。
还有三个站把端口写进了目标地址 —— slack.com、webflow.com、arstechnica.com 发的都是 Location: https://主机名:443/。能用。也是一个本来不需要写出来的端口号。
25 个 strict-transport-security，最短的只记五分钟
RFC 6797 把 max-age 定义成「收到这个头之后的多少秒内，浏览器把这台主机当成已知的 HSTS 主机」。这个值因此是一段记忆的长度，而 25 个站的分布比这个头的名声要散得多。
| max-age | 多长 | 站数 |
|---|---|---|
| 31536000 | 1 年 | 15 |
| 63072000 | 2 年 | 4 |
| 106384710 | 约 3.4 年 | 1 |
| 31556952 / 31556900 | 大致一个回归年 | 2 |
| 15552000 | 180 天 | 1 |
| 2592000 | 30 天 | 1 |
| 300 | 5 分钟 | 1 |
五分钟那个是 techcrunch.com。访客最后一次看页面之后五分钟，浏览器又会先去试 http://，而这正是这个头存在的主要目的。另有两个站一个头都不发：railway.com 和 www.wired.com。
25 个里有 19 个带了 includeSubDomains，RFC 6797 说这个指令把策略扩展到该主机名下的所有子域名。github.com 写的是小写 d 的 includeSubdomains；同一份 RFC 写着指令名不区分大小写，所以这个拼法没问题，只是看着像错的。
max-age 不是强度旋钮，是浏览器记多久。五分钟等于没记。
三个站要 preload，但没满足要求
18 个头里带了 preload，那是在申请被直接烧进浏览器，而不是等第一次访问时才学到。预置名单自己公布的提交要求写得很死：证书有效、如果在 80 端口监听就要从 HTTP 跳到同主机的 HTTPS、所有子域名都走 HTTPS，以及一个 max-age 至少 31536000 且同时带 includeSubDomains 和 preload 的头。
| 站点 | 今天发的头 | 缺了哪一条 |
|---|---|---|
| www.shopify.com | max-age=15552000; includeSubDomains; preload | max-age 不足 31536000 |
| www.theverge.com | max-age=31556952; preload | 没有 includeSubDomains |
| www.bbc.com | max-age=31536000; preload | 没有 includeSubDomains |
这不等于说这三个站不在名单里。早年提交的条目会一直留着，被收录之后头再漂移，表面上什么都不会坏。它说明的只有一件事：这 18 个站里，光看响应头证明不了任何一个真的在预置名单上。
独立站要做的三件事
三步，按这个顺序来，前两步各是一条命令。
- 先确认自己的第一跳是永久码。
curl -sI http://你的域名/不跟随任何跳转，直接给出状态码和Location。如果是 302，那就是拿临时码在干永久的活。 - 再读自己的
max-age。curl -sI https://你的域名/ | grep -i strict-transport。低于一年，就是比这批 25 个站里的 19 个给访客更短的记忆。 - 头的其余部分满足公布的要求，再写
preload。否则写了不花钱也证明不了什么 —— 这批里正好有三个站处在这个状态。
这一整件事都不是排名杠杆，这篇也不打算假装它是。它影响的是每次访问的第一个请求，包括爬虫发的第一个请求；而一个引擎取不干净的页面，就是一个它引用不了的页面 —— 那是 QueryWin 怎么运转 在管的事。
这次没测出来的几件事
这 18 个站到底在不在预置名单里，不知道。我们没有去查，所以上面那三行描述的是一个响应头，不是名单成员资格。第一跳之后的链条也没跟，任何一个子域名都没测，证书没验，所以预置要求里的其余几条在这里根本没有被测量。一次请求、一个出口、一个时刻：一个会按地域切换这个头的服务器，在这里只会呈现为一个固定事实。
常见问题
你们是怎么测的？
2026-08-30 对每个首页发两次请求 —— 一次 http:// 关掉跳转跟随，一次 https:// —— 从这两个响应里读第一跳状态码和 Strict-Transport-Security。
这个头到底管什么？
它告诉浏览器：接下来的 max-age 秒内，访问这台主机一律直接用 HTTPS，不要先试 http://。RFC 6797 把这个值定义为从收到头那一刻起算的秒数。
它对 SEO 有帮助吗？
这次测的东西证明不了。这批面板上每个站本来就把 http 跳到了 https，所以这个头省下的是首次访问时的一个请求，改变不了什么内容被收录。
max-age 该设多长？
25 个站里 15 个选的正好是一年，也正好是预置名单要求的下限。低于一年就是主动选了更短的记忆，而 300 秒基本等于没有。
includeSubDomains 有风险吗？
它把策略套到每一个子域名上，所以任何一个还在走明文 HTTP 的子域名，对见过这个头的访客来说会直接变得访问不了。这批 25 个里有 6 个没写它。
