HSTS预加载列表（HSTS Preload List）是一种浏览器内置的安全机制名单，将你的域名提交到这个列表后，即使用户第一次访问你的网站，浏览器也会强制使用HTTPS连接，从根本上杜绝HTTP降级攻击和SSL剥离攻击。提交的核心步骤其实就三步：确保网站完全符合HSTS预加载要求、在官方提交页面填写域名信息、等待审核通过并被各大浏览器收录。但这三步背后有大量细节和坑，稍有不慎就会导致提交失败甚至影响网站正常访问。

什么是HSTS预加载列表以及为什么要提交

HSTS全称HTTP Strict Transport Security，是一种Web安全策略机制。服务器通过响应头告诉浏览器："以后访问我这个域名，必须用HTTPS，不许用HTTP。"普通的HSTS策略有一个致命弱点——用户第一次访问时，浏览器还没有收到这个头信息，攻击者可以在这个窗口期发起中间人攻击。预加载列表就是为了解决这个"首次访问"问题而存在的。你的域名一旦进入预加载列表，就会被硬编码到浏览器的源代码中，用户无论何时何地第一次访问，都会自动走HTTPS。

提交HSTS预加载前必须满足的硬性条件

在你动提交的念头之前，必须逐一核对以下所有条件，缺一不可：

1、网站必须有有效的HTTPS证书，且证书链完整、未过期、未被吊销。自签名证书不行，必须是受信任CA签发的证书。

2、HSTS响应头的max-age值必须至少为31536000秒（即一年）。建议设置为两年或更长，常见做法是63072000秒（两年）。

3、必须包含includeSubDomains指令，确保所有子域名都强制HTTPS。

4、必须包含preload指令，这是告诉浏览器"我要进预加载列表"的关键标识。

5、如果你的网站有HTTP到HTTPS的重定向，那么这个重定向响应本身也必须返回HSTS头，而不仅仅是最终的HTTPS页面返回。

6、网站的所有子域名都必须支持HTTPS，不能有任何子域名只提供HTTP服务。

7、如果你使用了HTTP Strict Transport Security的redirect响应（状态码301/302），该重定向页面本身也要携带HSTS头。

一个标准的HSTS响应头应该长这样：

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

如何检查你的网站是否已经满足预加载条件

不要凭感觉判断，要用工具验证。推荐使用以下方法逐一排查：

第一步，用curl命令检查主域名的HSTS头：

curl -I https://www.yourdomain.com

确认返回头中包含Strict-Transport-Security且带有preload指令。

第二步，检查HTTP访问是否自动跳转到HTTPS并携带HSTS头：

curl -I http://www.yourdomain.com

如果返回301/302，再跟进检查跳转后的响应头是否也有HSTS。

第三步，逐一检查所有子域名，特别是cdn、mail、api、admin等常见子域名，每个都要支持HTTPS并返回正确的HSTS头。

第四步，使用在线检测工具如hstspreload.org的检测功能，输入域名进行自动化扫描，它会告诉你哪些条件不满足。

HSTS预加载列表的具体提交流程

满足所有条件后，就可以正式提交了。提交入口在Chromium项目的官方预加载列表页面（hstspreload.org）。具体操作如下：

1、打开hstspreload.org网站，页面底部有一个"Submit"区域。

2、在输入框中填写你的域名，注意只填域名本身，不要加https://前缀，也不要加斜杠路径。比如填写yourdomain.com即可。

3、勾选"includeSubDomains"选项，这一步基本是必选的。

4、提交后，系统会进行自动化验证。如果全部通过，你的域名会进入审核队列。如果有问题，页面会明确告诉你哪项不达标。

5、审核通过后，你的域名会被合并到Chromium的源代码中。这个过程通常需要几周到几个月，取决于浏览器的发布周期。Chrome、Edge、Firefox、Safari等主流浏览器都会同步更新这个列表。

提交后的注意事项和常见坑点

提交成功不代表万事大吉，以下这些问题必须高度重视：

第一，提交后无法轻易撤销。HSTS预加载一旦生效，浏览器会强制HTTPS。如果你以后想退回HTTP，在预加载列表更新之前，所有用户都无法通过HTTP访问你的网站。如果你的证书过期了、服务器配置出错了，网站会直接变得不可访问。所以提交前一定要确保你有完善的证书续期机制和运维能力。

第二，证书管理必须自动化。强烈建议使用Let's Encrypt等免费证书配合自动续期工具（如certbot），设置cron定时任务，确保证书永远不会过期。证书一旦过期，在预加载生效期间，你的网站对所有用户来说就是"死站"。

第三，所有子域名必须长期维护HTTPS。提交时你检查了所有子域名，但以后新增的子域名呢？如果你后来加了一个新的子域名只提供HTTP，虽然不会直接导致预加载被移除，但会造成该子域名无法正常访问，用户体验极差。建议在DNS层面做通配符证书或者建立子域名HTTPS自动化部署流程。

第四，不要在测试环境提交。有些开发者喜欢先在测试域名上试一试流程，这没问题。但一定要确保测试域名不会被误提交到正式列表。提交前反复确认域名拼写正确，别把test.yourdomain.com当成正式域名提交了。

第五，关注预加载列表的更新周期。浏览器不是实时更新预加载列表的。Chrome大约每隔几周发布一次大版本，预加载列表随版本更新。提交后你需要耐心等待，不要以为提交了马上就生效。你可以在hstspreload.org上查询你的域名状态，看到"pending"就是还在审核，"ready"就是已经生效。

第六，HTTP重定向的陷阱。很多网站用301重定向把HTTP流量引到HTTPS，但重定向页面本身没有返回HSTS头。这在普通场景下没问题，但在预加载审核时会被判定为不合格。必须确保从HTTP发出的第一个响应就携带完整的HSTS头。

HSTS预加载与其他安全策略的配合

HSTS预加载不是孤立的安全措施，它应该和其他安全头配合使用，形成完整的防护体系：

Content-Security-Policy（CSP）：防止XSS攻击，限制页面可以加载的资源来源。

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline';

X-Content-Type-Options: nosniff：防止MIME类型嗅探攻击。

X-Content-Type-Options: nosniff

X-Frame-Options: DENY 或 SAMEORIGIN：防止点击劫持。

X-Frame-Options: DENY

Referrer-Policy：控制引用来源信息的泄露。

Referrer-Policy: strict-origin-when-cross-origin

这些安全头和HSTS预加载组合在一起，才能构建一个真正健壮的网站安全基础。单独依赖HSTS预加载是不够的，它只解决了传输层强制加密的问题，应用层的安全漏洞依然需要其他策略来防护。

哪些网站适合提交HSTS预加载

并不是所有网站都适合提交预加载。以下几类网站强烈建议提交：

电商平台、金融服务、在线支付系统：这些网站涉及用户敏感数据，安全等级要求最高。

企业官网和SaaS服务：品牌信誉和用户信任至关重要，HTTPS是基本要求。

API服务接口：如果你的API只提供HTTPS访问，预加载可以防止调用方误用HTTP。

以下情况建议谨慎考虑：

内部管理系统如果只在内网使用，且没有公网访问需求，预加载意义不大。

证书管理能力弱的小型网站，如果无法保证证书长期有效，提交预加载反而是给自己埋雷。

还在频繁更换域名或架构调整的网站，预加载会增加迁移成本。

提交失败的常见原因和解决办法

如果你提交后被拒绝，通常是以下原因：

max-age不够31536000秒——修改服务器配置，调大数值后重新提交。

缺少includeSubDomains——加上这个指令，确保所有子域名都覆盖。

缺少preload指令——这是最容易忘的，一定要加上。

HTTP重定向页面没有HSTS头——在重定向的服务器配置中添加HSTS响应头。

有子域名不支持HTTPS——要么给所有子域名配上HTTPS，要么从预加载申请中排除这些子域名（但这会削弱保护效果）。

证书链不完整——检查中间证书是否正确配置，用SSL Labs等工具检测证书链。

总结

HSTS预加载列表是网站安全的高级防护手段，它把HTTPS强制策略从"服务器告诉浏览器"升级为"浏览器天生就知道"。提交的门槛不高，但维护的要求很高。核心就一句话：提交之前确保万无一失，提交之后确保长期运维。把证书续期自动化、子域名HTTPS全覆盖、安全头策略配套这三件事做好，HSTS预加载才能真正成为你网站安全的加分项，而不是定时炸弹。