技术随笔：折腾了两个月，fairy.tw 终于把 HSTS 挤进了 Chrome 正式版
最近给博客的底层安全配置做了一次久违的复盘。算起来，站点的这套防御架构里，大部分激进的策略其实早在一开始就开启了，唯独 “HSTS Preload” 这一项，是直到最近才总算尘埃落定。
借着这个契机，顺便写篇随笔，简单总结一下目前站点（fairy.tw）的这些硬核硬标准。
漫长的等待：HSTS 正式写入 Chrome 核心源码
用过 HSTS 的朋友都知道，普通的 HSTS 只是在服务器的响应头里加个参数，告诉浏览器下次自动走 HTTPS。但这种做法在用户“第一次访问”时依然存在被劫持的风险。
最激进、也最彻底的解决方案，是把域名申请提交到 HSTS 的预载列表（Preload List）里。只要审核通过，你的域名就会被直接硬编码进 Chrome、Firefox 等现代浏览器的核心源码中。
这批复的过程比我想象的要漫长得多。从我最初提交申请，到今天终于能在 Chrome 正式版里查到完全生效，整整耗费了两个月的时间。
现在，只要你在 Chrome 浏览器里打开 chrome://net-internals/#hsts，在底部的查询框里输入 “fairy.tw”，就能看到它已经死死地烙印在底层的静态列表中了。这意味着此后任何人访问本站，浏览器甚至连第一次跳转请求都不会发，无条件在本地强制以 HTTPS 握手，把中间人劫持的概率直接降到了零。
拒绝过时技术：全面收紧的传输与邮件防线
除了刚刚通关的 HSTS，解析、传输协议和邮件方面的其他配置，算是我很久以前就推行的“老基建”了。在基于 Cloudflare Pages 部署的架构下，我尽可能地将安全权重提到了最高：
- 最低 TLS 1.2 强制锁定： 在传输层协议上，我彻底废弃了对老旧设备的无底线兼容。目前在面板中已将最低 TLS 版本死死锁定在 1.2。这意味着任何试图使用过时的 TLS 1.0 或 TLS 1.1 协议的客户端，都会被本站的边缘节点直接拒绝连接。在确保主流访问的前提下，压榨出了最纯净的加密通道。
- DNSSEC： 域名系统安全扩展。通过在 DNS 节点引入加密数字签名，彻底杜绝了任何形式的 DNS 缓存污染和域名劫持，保证解析链路的绝对真实。
- SPF & DKIM： 邮件防伪的双重保险。SPF 限定了发信服务器的合法 IP 白名单，DKIM 则用加密私钥为每一封外发邮件盖上数字化印章。
- DMARC Reject 模式： 邮件安全体系的铁腕策略。我将 DMARC 策略配置为了最严厉的
p=reject。只要任何假冒本站域名的邮件没有同时通过 SPF 和 DKIM 验证，接收方服务器（如 Gmail 等）会将其直接在网关处无情拦截并销毁，连进垃圾箱的机会都不会给。
结语
技术折腾的乐趣，往往就在于把这些安全标准推到极限时的成就感。大网站为了照顾复杂的旧业务和多方兼容，往往不敢在 HSTS Preload 和 DMARC Reject 上走得太远；而小站或技术博客没有历史包袱，反而能把技术的纯粹性推向极致。
虽然为了一个 HSTS Preload 苦等了两个月，但当看到 chrome:// 页面里跳出生效记录，且 TLS 1.2 稳固守护着传输边界的那一刻，还是觉得挺值。未来如果有什么更激进、更好玩的运维技术，我还会继续在这个站点上折腾实验。