静态托管

优选是社区行为，请注意 TOS

静态托管的优化关键在于分配到更好的 IP。对于 Vercel、Netlify、Cloudflare 等厂商，分配到的 IP 往往不尽人意。分配到更好的 IP，就可以极大缓解不稳定的情况，并且大幅度提速。

Vercel / Netlify

先使用官方 CNAME 获取到 SSL 证书，然后换成：

1 2	vercel.example.com. 1 IN CNAME vercel-cname.xingpingcn.top. ; cf_tags=cf-proxied:false netlify.example.com. 1 IN CNAME netlify.cname.bee-zh.cn. ; cf_tags=cf-proxied:false

由于 CNAME 的 IP 的质量并不能总是保持优质，需要隔三差五检查。

另有：

1
2
3

vercel.example.com.	1	IN	CNAME	vercel.cname.bee-zh.cn. ; cf_tags=cf-proxied:false
netlify.example.com.	1	IN	CNAME	netlify-cname.xingpingcn.top. ; cf_tags=cf-proxied:false
netlify.example.com.	1	IN	CNAME	sth.netlify.com. ; cf_tags=cf-proxied:false

Cloudflare Pages

使用任意支持地域化解析的 DNS 供应商（可惜 Cloudflare 免费版不支持，可以 NS 到支持的，比如阿里），国外解析到 sth.pages.dev，国内解析到 cf.877774.xyz

Cloudflare CDN

使用 Cloudflare SaaS（Software as a Service, 软件即服务）中的自定义主机名功能，具体可参考这个视频，皮皮虾老师讲的非常清楚，鄙人不多赘述。

单点服务器

自托管服务器的网站问题则更大了。

HSTS Preload

HSTS 配置错误可能会导致网站长期报废

由于 HTTP 不加密，首次访问可能会被劫持，没有机会建立 HTTPS 连接；若无 HSTS（HTTP Strict Transport Security，HTTP 严格传输安全），攻击者甚至还可以阻断 HTTPS 的连接。即使加上 HSTS 头，从一般用户角度来说，也往往需要首次的 HTTP。

那怎么办？加入 HSTS Preload（HSTS Preload List，HSTS 预加载列表）列表（这个列表随着每次浏览器的发布而更新）后，你的网站会自动启用 HSTS，首次访问即为 HTTPS。代价就是 SSL 证书爆炸的话无路可退，只能等下一次浏览器发布的时候退出列表。

进入 preload 列表必须 max-age ≥ 31536000 且 includeSubDomains 且 preload。为了避免这个问题，建议从较小的 max-age 起递增。

加上这个头：

1	Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Copy from Google：
max-age 指令用于指定用户浏览器必须仅使用 TLS 访问网站的时间量（以秒为单位）。一旦时间过去，如果网站未提供 HSTS 标头（或从 HTTP 到 HTTPS 的临时重定向），用户就可以再次通过纯 HTTP 访问该网站。
设置 includeSubDomains 指令会强制在最初发送标头的网页网址的任何子网域上使用该标头。例如，如果 google.com 发送的 HSTS 标头包含 includeSubDomains 指令，则会在 mail.google.com 上强制执行 HSTS 标头。
设置 preload 指令并将网域提交给 HSTS 预加载服务后，系统会将该网域编译到使用预加载 HSTS 列表的浏览器二进制文件中。不仅 Google Chrome 如此，

泛解析

某一个域名的所有子域名指向同一个网站，一定程度上起到镜像站的作用。有些时候 ISP（Internet Service Provider，互联网服务提供商，也就是运营商）不会下狠手，只会封禁一个子域名。

DNSSEC

DNS 污染是对于小网站成本较低、伤害较大的一个招式。当受到大范围的 DNS 投毒时，上游的权威 DNS 都会受到污染，DoT 和 DoH 也无力回天。

DNSSEC（Domain Name System Security Extensions，域名系统安全扩展）通过引入数字签名来确保 DNS 响应的真实性和完整性。哪怕攻击者劫持了 DNS，也难以伪造签名，这个错误的 DNS 解析结果会被拒绝。它确保了你的浏览器在发起 HTTP / HTTPS 请求时，连接的是正确、合法的服务器。

Cloudflare 提供免费的 DNSSEC，可以按照博客开启。

CAA

CAA（Certificate Authority Authorization，证书颁发机构授权）是规定那些有权为域名签发证书的 CA（Certificate Authority，证书颁发机构）的白名单。

1
2
3

example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issue "pki.goog"
example.com. CAA 0 issue "digicert.com"

这可以有效防止黑 CA 或者 ISP 通过颁发假证书的方法进行攻击。如果 CA 胆敢违反 CAA 颁发证书，那么可能会被吊销执照。

CT

但是，某些 ISP 掌握或者胁迫正规 CA 颁发证书，这个时候 CT（Certificate Transparency，证书透明度）就会出手。CT 会记录下每一张证书，方便进行审核。什么？你想不提交到 CT 来逃过审核？那这张证书会因为没有有效的 SCT（Signed Certificate Timestamp，证书签署时间戳）而被浏览器拒绝。

OCSP / CRL

证书已经出问题了，怎么办？

CRL（Certificate Revocation List，证书吊销列表）：CA 定期发布一个包含所有已吊销证书序列号的大列表，浏览器需要下载并检查。
OCSP（Online Certificate Status Protocol，在线证书状态协议）：浏览器向 CA 的 OCSP 服务器实时查询证书状况。
OCSP Stapling（OCSP Stapling，OCSP 装订）：网站服务器自己定期去查询 OCSP 状态，并将有效的 OCSP 响应与证书一起 “装订” 起来发给浏览器。这避免了浏览器自己去查询，减少了延迟和被 ISP 拦截的风险。但如果 ISP 是中间人，它也可以替换掉这个 “装订” 的响应。

似乎装订 + 短期证书（90d）更有效，靠撤销长期证书有点亡羊补牢？

# https://ssl-config.mozilla.org/#server=nginx&version=1.27.3&config=modern&openssl=3.4.0&hsts=false&guideline=5.7

# OCSP stapling
ssl_stapling on;
ssl_stapling_verify on;

# verify chain of trust of OCSP response using Root CA and Intermediate certs
ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

# replace with the IP address of your resolver;
# 这里我替换成了 1.1.1.1
# async 'resolver' is important for proper operation of OCSP stapling
resolver 1.1.1.1;

# If certificates are marked OCSP Must-Staple, consider managing the
# OCSP stapling cache with an external script, e.g. certbot-ocsp-fetcher

Let's Encrypt 的 CRL 域名在中国大陆遭到封禁，建议使用 Google Trust Services。其验证服务器在国内有 CDN。

通用

ECH

ECH（Encrypted ClientHello，加密客户端问候）理论上可以保护隐私、对抗封禁。

客户端

Firefox 119 已经默认启用 ECH，Chrome / Edge 据说是 105 开始默认启用，总之最新的浏览器没问题的。启用浏览器内置的安全 DNS（Cloudflare、Google 等主流均可），然后尝试访问 https://tls-ech.dev/，看到 You are using ECH. :) 就可以了。

服务器

Cloudflare CDN 免费版默认启用 ECH，Pages 似乎没有。

包括 OpenSSL、Curl、Nginx 等项目对于 ECH 的支持大多停留在实验阶段，故单点服务器难以上手。

你可以使用 Google Public DNS 查询网站的支持情况，HTTPS 记录中包含 ech= 即可。

Firefox 用户还可以安装 oh-my-ech 插件实时查看网站的 ECH 情况。

CSP 与 SRI

自己的网站百密无疏了，但是别忘了上游 CDN 投毒也是网络安全的重要话题。StaticFile、BootCDN、51LA 等都发生过投毒事件。

可以通过 CSP（Content Security Policy，内容安全策略）头限制资源加载：

1 2	<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' trusted.com">

通过 SRI（Subresource Integrity，子资源完整性）防止资源被篡改：

1
2
3

<script src="https://cdn.example.com/jquery.js"
        integrity="sha384-..."
        crossorigin="anonymous"></script>

网站可用性优化指北