Notes · XB 现场笔记

事故复盘应留下一份事实记录

Mon, 24 Aug 2026 00:00:00 +0000

一份复盘在它的说法能被重新检查时才赢得信任。这意味着每个阶段都要点名产生该事实的命令，而不是某人记忆的转述。下面的四个阶段让任何写下来的复盘在日后都可复核。

检测：症状，而且要带证据

从最小的可验证症状与展示它的命令开始。“截图"好过一段散文描述：

$ check-http-headers.sh https://www.xbcatm.com/
HTTP/2 200
content-security-policy: ... script-src 'none' ...
last-modified: Mon, 24 Aug 2026 11:20:54 GMT

如果症状是某个响应头变了，那么展示旧策略与新策略的输出应并排放在一起。如果是失败，请包含退出状态与错误行。

界定范围：影响多广，以及你如何知道

用证据而不是形容词陈述爆炸半径。修复一个你能检视的边界：

哪些主机或路径返回同样的症状？每个候选主机跑一次 check-http-headers.sh 就能回答。
缓存与源站是否不同？比较 Vary 与验证器。
适用哪个回滚窗口？使用变更前仍生效的 TTL。

修复：变更及其预期效果

写出可重放的正确动作。优先选择恢复契约的最小变更，并说明修复后运行应显示什么：

# 期望出现在响应里的新策略行：
script-src 'none'

验证：事后运行

变更后重复检测命令，并演示观察到的输出现在与预期契约一致。没有最后这一节的复盘只是一个故事；有了它，它就是一份允许自己未来被再检查的记录。

来源

RFC 9110 — HTTP Semantics，响应元数据与条件请求，已核验 2026-08-24。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。

用两条命令读取公共边缘

Mon, 24 Aug 2026 00:00:00 +0000

一次部署，是当公共边缘与你选择的文件一致时才完成，而不是因为最后一条上传命令退出码为零。操作套件里的两个只读小工具，能让任何能到达主机的机器看到这种一致性。

检查响应头

check-http-headers.sh 抓取一个 URL，并打印响应行、响应头与重定向后的最终 URL：

check-http-headers.sh https://www.xbcatm.com/

最近对本站一次运行的结果：

HTTP/2 200
server: nginx
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; script-src 'none'; ...
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff

注意正文被丢弃，只显示响应线之外的状态行。要比较一次发布前后的变化，保存一份基线并把新的输出与之相减。

读取证书日期

check-tls-expiry.sh 从 TLS 握手读取服务器证书的过期日期，而不改变服务：

check-tls-expiry.sh www.xbcatm.com 30

它打印证书的 notAfter 以及到该日期剩余的天数。如果剩余天数低于阈值，它以非零状态退出——适合加进发布冒烟测试。

发布冒烟测试里它们配合使用

排定发布冒烟测试时，让一个命令确认法着陆状态，另一个确认即将过期的证书。剩下的剩余风险是活动报表之外、真正浏览无法发现的内容——例如重量级第三方脚本，或是仅在大流量出现的缓存问题。一条只读输出现场完成不了这些，仍需一次真实的浏览器会话。

来源

RFC 9110 — HTTP Semantics，响应语义与条件请求，已核验 2026-08-24。
OpenSSL s_client，TLS 连接与证书日期检查，已核验 2026-08-24。
制品 HTTP 响应头检查，贯穿本记录使用的只读检查。

CAA 记录应授权你实际使用的签发者

Sun, 23 Aug 2026 00:00:00 +0000

认证机构授权（CAA）记录让域名持有者声明，哪些证书颁发机构可以为该域名签发证书。只有当记录与真实续期路径一致、且操作者理解策略如何从父级名称继承时，它才有用。

检视当前策略

查询确切主机名及其父名称：

for name in www.example.test example.test test; do
 printf '== %s\n' "$name"
 dig +noall +answer CAA "$name"
done

叶子处空的应答不一定意味着没有适用策略。根据 DNS 规则，CAA 处理可能继续向上。诊断变更时使用权威应答，并与至少一个递归解析器比较。

匹配账户的签发者标识

记录使用如 issue 或 issuewild 等标签与一个签发者域值：

example.test. 3600 IN CAA 0 issue "letsencrypt.org"

该值是授权标识，不是证书里的显示名。在证书颁发机构的当前文档中确认它。通配符授权可能需要单独的 issuewild 策略。

在续期前编排 DNS 变更

在当前证书健康时添加或收紧 CAA。从整上一个 TTL 等待，查询权威与递归应答，并运行 ACME 客户端支持的暂存或续期测试。准备好回滚记录。

不要在过期事故期间添加限制性记录，除非签发者路径已验证。一条语法正确但错误的策略，会把自动续期变成硬失败。

观察签发失败

CAA 检查发生在签发时，而不是每次 HTTPS 请求。因此证书监控必须同时覆盖当前过期与续期尝试。把有效的 DNS 应答随 ACME 失败一起记录，而不是只记录一条笼统的授权错误。

来源

RFC 8659 — DNS Certification Authority Authorization，CAA 查询与属性语义，已核验 2026-08-23。
Let’s Encrypt: CAA，签发者标识与运维指引，已核验 2026-08-23。

Content-Type 应描述你实际发送的字节

Sun, 23 Aug 2026 00:00:00 +0000

静态服务器可能返回正确的字节，却带上错误的 Content-Type。某个浏览器里页面看起来或许还正常，但下载、样式表、订阅阅读器或安全策略会把同一响应理解成别的东西。公开响应头才是契约；文件名只是服务器配置的输入。

检查有代表性的格式

检查一份 HTML 文档、样式表、SVG、feed 与可下载脚本。包含响应头但丢弃正文：

for path in / /assets/site.css /favicon.svg /index.xml /downloads/check-http-headers.sh; do
 curl -sS -D - -o /dev/null "https://www.example.test$path" \
 | awk -v path="$path" '
 BEGIN { print "== " path }
 /^HTTP\// || tolower($1) == "content-type:" || tolower($1) == "x-content-type-options:" { print }
 '
done

期望的媒体类型因资源而异，但应该具体且稳定。HTML 通常应包含字符集。CSS 与 SVG 不应被当作泛型二进制数据提供服务。用于下载的 shell 脚本不应被声明为 HTML。

保持 nosniff 一致

X-Content-Type-Options: nosniff 请求支持它的浏览器在脚本与样式目标上尊重声明的类型，而不是猜测。它之所以有用，是因为不匹配会变成可见的失败，而不是因浏览器而异的解读。

该响应头并不能修复一个错误的类型。只有在同时有能证明声明值正确的资源清单时才启用它：

X-Content-Type-Options: nosniff

检查服务器映射

静态服务器通常根据扩展名推导类型。如果某个新扩展名被当作 application/octet-stream 提供服务，先判断这是否有意为之，再决定是否加入全局覆盖。一个窄映射比一条会改变所有响应的规则更容易复核。

在公开主机名上重复这些检查。CDN 或反向代理可能替换掉正确的源站响应头；而一个友好的错误页可能为后缀像 CSS 或 JavaScript 的路径返回 HTML。

来源

RFC 9110 — HTTP Semantics，表示元数据与 Content-Type，已核验 2026-08-23。
MDN: Content-Type，媒体类型与字符集示例，已核验 2026-08-23。
MDN: X-Content-Type-Options，nosniff 行为，已核验 2026-08-23。

Cookie 作用域应比应用边界更窄

Sun, 23 Aug 2026 00:00:00 +0000

Cookie 依据浏览器规则附加到请求，而不是依据最初设置它的服务器组件。宽泛的 Domain 或 Path 会把状态暴露给无关的路由或子域名，而缺失传输与脚本限制则会放大其他失败造成的损害。

当省略 Domain 时，Cookie 被限定在设置它的主机内。加上 Domain=example.test 则它也允许发给符合条件子域名。只有多个主机确实共享同一应用与信任边界时才使用更宽的形式。

检视响应而不把真实 Cookie 值打进日志：

curl -sS -D - -o /dev/null https://app.example.test/login \
 | awk '
 tolower($1) == "set-cookie:" {
 sub(/Set-Cookie: [^;]*/, "Set-Cookie: [value redacted]")
 print
 }
 '

一起复核这些属性

Secure 把传输限制在安全上下文中。
HttpOnly 通过 document.cookie 阻止 JavaScript 访问；它不会阻止浏览器发送该 Cookie。
SameSite 影响跨站请求，必须匹配应用的导航或嵌入需求。
Path 控制发送时机，但它不是同一主机上不同应用之间的授权边界。

在现代浏览器中，SameSite=None 的 Cookie 还需要 Secure。避免把这对组合复制进不需要跨站用途的应用。

在其约束契合时使用前缀

__Secure- 与 __Host- 等 Cookie 名称前缀，让支持的浏览器强制额外的要求。__Host- Cookie 必须使用 Secure、省略 Domain、并使用 Path=/，这使主机专用的意图变得显式。

用相同作用域测试删除

删除 Cookie 需要一条与存储它所用属性匹配的过期指令，尤其是名称、域名与路径。只清除一个变体的登出可能让另一个 Cookie 仍然有效。

一个真正静态的文档站点通常没有理由设置应用 Cookie。核验公共响应不含 Set-Cookie 响应头，而不是为站点并不需要的存储增加一个同意界面。

来源

RFC 6265 — HTTP State Management Mechanism，Cookie 存储与作用域，已核验 2026-08-23。
MDN: Set-Cookie，属性与名称前缀，已核验 2026-08-23。

HEAD 应描述与 GET 相同的表示

Sun, 23 Aug 2026 00:00:00 +0000

HEAD 方法请求服务器对 GET 会返回的响应，但不会传输响应内容。它适合需要状态、验证器、类型或长度的检查，但前提是元数据与真实的 GET 路径保持一致。

比较规范化后的响应头集合

Date 这类动态响应头会随请求不同而变化。只比较描述所选表示的那些字段：

url=https://www.example.test/downloads/manual.pdf

curl -sS -I "$url" > head.headers
curl -sS -D get.headers -o /dev/null "$url"

for file in head.headers get.headers; do
 printf '== %s\n' "$file"
 awk '
 /^HTTP\// ||
 tolower($1) ~ /^(content-type:|content-length:|content-encoding:|cache-control:|etag:|last-modified:|vary:)$/ { print }
 ' "$file"
done

两次请求应选择相同的状态码与表示元数据。压缩协商也应纳入比较：给两个请求发送相同的 Accept-Encoding 值。

不要把 HEAD 当作唯一的发布检查

服务器可能在文件缺失、不可读或被截断时仍合成看似合理的响应头。在冒烟测试里保留一个小的 GET 并核验其正文或校验和。HEAD 降低了传输成本，但并不能证明有效载荷存在。

显式检查重定向

不使用 --location 时，curl -I 报告第一个响应，适合测试重定向策略；使用 --location 时报告最终链，适合测试目标地址。请记录这条命令回答的是哪个问题：

curl -sS -I --max-redirs 0 https://old.example.test/manual
curl -sS -I --location https://old.example.test/manual

把方法相关的失败视为配置缺陷

一个对 GET 返回 200、对 HEAD 返回 405 或 404 的静态页面，通常暴露出代理或路由的不一致。应当修复方法处理，而不是教监控系统忽略它——除非端点契约刻意不允许 HEAD。

来源

RFC 9110 — HTTP Semantics，HEAD 方法语义，已核验 2026-08-23。
curl manual，--head、--include 与重定向选项，已核验 2026-08-23。

HSTS 应带着恢复计划来灰度发布

Sun, 23 Aug 2026 00:00:00 +0000

HTTP Strict Transport Security 告诉支持的浏览器，在一个缓存周期内对该主机强制使用 HTTPS。这种持久性既是特性也是风险：移除响应头并不会立刻抹掉客户端已存储的策略。

先验证 HTTPS 路径

在发送 HSTS 之前，确认规范主机名提供有效证书，并且 HTTP 在不依赖用户输入的情况下重定向到预期的 HTTPS URL：

curl -sS -D - -o /dev/null --max-redirs 0 http://www.example.test/
curl -sS -D - -o /dev/null https://www.example.test/

检查有代表性的深层路由与错误页。HSTS 无法修复证书错误，因为浏览器在接受该策略之前要求有效的 HTTPS 连接。

从一个短的 max-age 开始

分阶段发布能在配置还新的时候限制恢复窗口：

Strict-Transport-Security: max-age=300

观察站点与续期路径之后，再有意识地提高时长。记录日期、所选值与回滚条件。最终策略可能用一年，但这个数字是一种承诺，而不是扫描器分数。

把 includeSubDomains 当作独立的决定

includeSubDomains 把策略扩展到每个子域名。先盘点名称，包括旧服务、委派区，以及只在内部网络使用的主机名。即使只有一个仅 HTTP 的后代，也足以让该选项对收到父级策略的客户端产生破坏。

预加载不是普通的响应头配置

浏览器预加载程序可以在正常响应周期之外分发策略，其要求与移除延迟比设置一个响应头更严格。不要仅仅因为扫描器推荐就申请预加载；请先确认对域名及所有被覆盖名称的长期所有权。

验证公共响应

curl -sS -D - -o /dev/null https://www.example.test/ \
 | awk 'tolower($1) == "strict-transport-security:" { print }'

测试规范的公共边缘，而不只是某个源站端口。代理可能添加、移除或重复该响应头。

来源

RFC 6797 — HTTP Strict Transport Security，策略处理与作用域，已核验 2026-08-23。
MDN: Strict-Transport-Security，指令与部署注意事项，已核验 2026-08-23。

发布清单应点名每一个已发布的字节

Sun, 23 Aug 2026 00:00:00 +0000

静态制品是一个目录，而不是一个可执行文件。只记录源码提交或只记录首页校验和会留下缺口：缺失的图片、陈旧的别名或变化的下载可能悄悄存活下来。一份发布清单应枚举每个常规文件。

生成稳定的列表

从制品根目录运行命令，使路径保持相对。在固定区域设置下按路径排序：

cd public
find . -type f -exec sha256sum {} + | LC_ALL=C sort -k2 > ../release.sha256

清单是关于制品的证据，因此把它放在被测量目录之外，除非清单本身有意作为发布的一部分。

传输后验证

在目标端，逐个文件验证：

cd /srv/www/site.new
sha256sum -c /path/to/release.sha256

这能捕获变化的字节与缺失的路径。它不会报告意外的多余文件，因此也要比较目标端的文件列表：

find . -type f | LC_ALL=C sort > destination.files
awk '{print $2}' /path/to/release.sha256 | LC_ALL=C sort > expected.files
diff -u expected.files destination.files

为发布记录增加聚合摘要

对清单自身做哈希，为日志与部署记录生成一个短标识：

sha256sum release.sha256

聚合摘要只有在清单生成规则固定时才有意义：相对路径形式、排序区域、哈希算法，以及是否包含生成的元数据，都属于流程的一部分。

不要把完整性等同于真实性

SHA-256 证明两个字节序列一致。如果攻击者既能替换制品也能替换清单，那么这种检查不能确立是谁产生的它们。制品签名与可信分发是独立的控制手段。

来源

GNU Coreutils: sha2 utilities，校验和生成与检查，已核验 2026-08-23。
sha256sum(1)，命令行为与输出格式，已核验 2026-08-23。

范围请求应证明选中了哪些字节

Sun, 23 Aug 2026 00:00:00 +0000

范围请求让客户端请求表示的一部分。媒体播放器、可断点续传的下载工具与诊断客户端会用到它，但服务器如果错误地声明或返回范围，就可能产生静默损坏，而不是干净的失败。

建立完整大小

抓取完整表示的响应头，并记录其长度与验证器：

url=https://www.example.test/downloads/archive.tar.gz
curl -sS -D full.headers -o /dev/null "$url"
awk 'tolower($1) ~ /^(content-length:|etag:|last-modified:|accept-ranges:)$/ { print }' full.headers

Accept-Ranges: bytes 是显式信号，但缺少这个头并不能证明范围请求不受支持。去实际请求一次。

请求一个已知区间

请求开头 16 字节，同时保留响应头与正文：

curl -sS -D range.headers -o range.body \
 -H 'Range: bytes=0-15' "$url"

wc -c range.body
awk 'tolower($1) ~ /^(content-range:|content-length:|etag:)$/ || /^HTTP\// { print }' range.headers

成功的字节范围响应应使用 206 Partial Content。Content-Range 应指出 0-15 与完整表示长度，而正文应正好包含 16 个字节。

测试一个不可能的区间

请求超出已知末尾的字节：

curl -sS -D - -o /dev/null \
 -H 'Range: bytes=999999999-' "$url"

对无法满足的字节范围，416 Range Not Satisfiable 加一个类似 bytes */12345 的 Content-Range 值会暴露真实长度。当服务器忽略 Range 时返回 200 也可能合法，但它必须返回完整表示，而不是一个标签错误的片段。

让验证器留在故事里

续传工具可以用 If-Range 配合强验证器或日期。如果表示已改变，安全响应是完整的最新表示，而不是从两个版本拼接出的字节。在宣称某个下载"可续传"之前，先测试这一行为。

来源

RFC 9110 — HTTP Semantics，范围单位、部分响应与 Content-Range，已核验 2026-08-23。
curl manual，--range 与响应头选项，已核验 2026-08-23。

通过切换完整目录发布静态网站

Sun, 23 Aug 2026 00:00:00 +0000

直接把新文件复制到活动的静态目录上，会造成一段访问者可能从一个版本拿到 HTML、从另一个版本拿到资源的时期。更安全的模式是：在活动树旁预置一棵完整的树，验证它，再改变目录名。

把所有发布目录放在同一文件系统上

当活动树、预置树与回滚树共享同一文件系统与父目录时，名字替换最强。先检查：

df -P /srv/www

在该父目录下创建唯一命名的中转目录。不要把未解析的变量或宽泛通配符当成删除目标来复用。

stage=$(mktemp -d /srv/www/site.new.XXXXXX)

填充并验证预置目录

把生成制品复制进空目录，然后检查代表性文件与期望的文件数：

tar -C public -cf - . | tar -C "$stage" -xf -

test -s "$stage/index.html"
test -s "$stage/404.html"
find "$stage" -type f | wc -l

当工具支持目录参数时，对预置路径运行链接与校验和检查。未通过验证的预置目录绝不能获得活动目录的名字。

用显式回滚路径切换名字

在第一次移动前解析每个路径：

live=/srv/www/site
stamp=$(date -u +%Y%m%dT%H%M%SZ)
rollback=/srv/www/site.old-$stamp

test -d "$live"
test -d "$stage"
test ! -e "$rollback"

mv "$live" "$rollback"
if mv "$stage" "$live"; then
 test -s "$live/index.html"
else
 mv "$rollback" "$live"
 exit 1
fi

这段序列在两个移动之间留下一个短窗口。对每次请求都对根的单一静态服务进程来说，该窗口通常很小但仍可观察。平台特定的 rename 或符号链接模式可以收紧切换；在依赖更强断言之前，请测试确切的文件系统与服务器行为。

验证公共边缘

切换之后，请求首页、一个深层路由、一个带指纹的资源与一个缺失路径。把公共字节与预置制品比较。在检查完成与观察窗口结束之前，保留回滚目录。

来源

POSIX rename()，名字替换语义，已核验 2026-08-23。
Linux rename(2)，文件系统与替换行为，已核验 2026-08-23。
GNU tar manual，归档创建与解包，已核验 2026-08-23。

维护定时器应让其最近结果可见

Sun, 23 Aug 2026 00:00:00 +0000

cron 式语法并不是维护任务契约的全部。命令需要一个清晰的服务身份、一个有界的运行时间，以及能区分"未调度"与"运行但失败"的证据。一个 systemd 定时器与 oneshot 服务能把这些关注点分开。

把工作定义成服务

使用显式用户与绝对命令路径：

# /etc/systemd/system/site-check.service
[Unit]
Description=Read-only public site check

[Service]
Type=oneshot
User=sitecheck
ExecStart=/usr/local/bin/check-public-site
TimeoutStartSec=2min

TimeoutStartSec 防止网络或子进程等待无限占用调度。当契约失败时，helper 应返回非零退出码，并且不得修改它所检查的服务。

调度该服务

# /etc/systemd/system/site-check.timer
[Unit]
Description=每小时运行公共站点检查

[Timer]
OnCalendar=hourly
Persistent=true
RandomizedDelaySec=5min
Unit=site-check.service

[Install]
WantedBy=timers.target

Persistent=true 会在机器恢复后补跑错过的日历事件。RandomizedDelaySec 把一个窗口内的例行工作分散开；当任务必须在精确时刻运行时它并不合适。

启用前先验证

检视日历表达式，然后手动启动服务：

systemd-analyze calendar hourly
systemctl start site-check.service
systemctl status site-check.service
journalctl -u site-check.service -n 50 --no-pager

只有当服务在预期的用户、环境、路径与网络访问下成功时才启用定时器：

systemctl enable --now site-check.timer
systemctl list-timers site-check.timer

对服务结果告警

定时器触发并不等于成功。要监控 oneshot 服务的退出状态或日志结果。保持 stdout 简洁，调试需要的详细制品写入一个有界的路径。

来源

systemd.timer(5)，日历定时器、持久化与延迟行为，已核验 2026-08-23。
systemd.time(7)，日历表达式语法，已核验 2026-08-23。
systemd.service，oneshot 服务语义，已核验 2026-08-23。

DNS 变更需要一个感知缓存的回滚窗口

Sat, 22 Aug 2026 00:00:00 +0000

改一条地址记录很容易，预测每个解析器何时停止使用旧应答却很难。时间到活性（TTL）值随 DNS 响应传播，并控制缓存可复用的时长。在迁移那一刻降低 TTL，并不能改写更早被缓存下来的应答。

在事件前降低 TTL

如果既有记录是一天的 TTL，至少要在计划切换前一个旧 TTL 时就把它降低。这样在旧端点仍然权威时，缓存有时间去取较短的值。确切间隔应写进变更计划，而不是在迁移中即兴执行。

记录来自权威服务器与至少一个递归解析器的应答：

dig +noall +answer www.example.test A
dig @1.1.1.1 +noall +answer www.example.test A

递归解析器显示的剩余 TTL 是它当前缓存状态的证据。不同解析器合理地显示不同的剩余值。

让两侧都保持有效

切换期间，保持旧端点与新端点都能为预期主机名提供服务。TLS 名称、重定向与应用配置在两侧必须一致。权威记录改变后立刻移除旧端点，会给仍持有先前应答的客户端造成本可避免的停机。

否定应答也会被缓存。一个最近返回 NXDOMAIN 的名字，其出现可能很慢才可见，因为根据区域的权威数据，否定响应可能仍留在递归缓存里。

观察后恢复 TTL

一旦权威与具有代表性的递归应答都指向新端点，且旧缓存窗口已过，就恢复正常 TTL。在变更记录中保留旧值、新值、权威应答与回滚条件。

来源

RFC 1034 — Domain Names: Concepts and Facilities，缓存模型，已核验 2026-08-22。
RFC 1035 — Domain Names: Implementation and Specification，TTL 字段，已核验 2026-08-22。
RFC 2308 — Negative Caching of DNS Queries，否定缓存模型与保留的错误 TTL，已核验 2026-08-22。

robots.txt 与 sitemap 回答不同的问题

Sat, 22 Aug 2026 00:00:00 +0000

两个小文件常被当成安全边界使用，但它们不是。robots.txt 描述爬虫偏好，sitemap 则给搜索系统一份属于该站点的 URL 清单。

robots.txt 能做什么、不能做什么

规则发布于源站根路径 /robots.txt，由配合的爬虫读取。它不会保护私有目录、不会从网络上移除 URL，也不能替代认证。不应公开的路由需要服务器授权或网络边界。

让文件保持平实，并测试它的实际位置：

User-agent: *
Disallow:
Sitemap: https://www.example.test/sitemap.xml

文件应为 UTF-8。如果部署会重定向它，请核验你想要的爬虫行为，而不是假设每个客户端都遵循同一条链。

sitemap 增加了什么

sitemap 是一份清单，而不是权限列表。使用单一主机的绝对 URL、正确做 XML 转义，并且只列出你准备发布的规范页面。不要因为某个 URL 存在于构建目录就把它列出。

协议允许每个 sitemap 文件最多 50,000 个 URL 与 50 MB。小站不需要 index 文件；一份普通 sitemap 更容易检视。把它的 XML 校验通过，并像普通页面一样通过同一 HTTPS 边缘请求它。

curl -fsS https://www.example.test/robots.txt
curl -fsS https://www.example.test/sitemap.xml | xmllint --noout -

如果未安装 xmllint，请在发布它的同一个 CI 环境里解析该 XML。重要的是检查要在文件被替换到边缘之前运行。

来源

RFC 9309 — Robots Exclusion Protocol，robots 规则、文件位置与 user-agent 匹配，已核验 2026-08-22。
Sitemaps Protocol，sitemap XML 结构与发现，已核验 2026-08-22。

SSH 主机密钥是部署记录的一部分

Sat, 22 Aug 2026 00:00:00 +0000

SSH 私钥认证客户端，但它并不告诉客户端到达的是哪台服务器。服务器的主机密钥与本地 known_hosts 数据库，提供身份检查的后一半。

把首次接触与轮换分开

在 StrictHostKeyChecking=yes 下，SSH 拒绝未知主机与变化的密钥。对于一个固定生产端点，只要期望密钥通过可信渠道安装，这就是最安全的默认值。accept-new 是面向预期会出现新主机的、更窄的方便选项：它接受一个从未见过的密钥，但仍拒绝被更改的密钥。

Host production-site
HostName www.example.test
User deploy
IdentityFile ~/.ssh/site_ed25519
StrictHostKeyChecking yes
UserKnownHostsFile ~/.ssh/known_hosts

不要通过给部署脚本加 StrictHostKeyChecking=no 来"修复"警告。那会把有用的信号变成静默接受。如果主机被重建，请记录替换后的指纹，并复核旧密钥为何不再有效。

让指纹可复核

在首次连接之前，从主机所有者或控制台获取指纹，再与客户端看到的值比较。密钥变更应有工单、维护说明或其他他人可检视的解释。

同一规则适用于自动化：known-hosts 文件是带有安全后果的配置，不是可丢弃的缓存数据。把它与部署记录一起备份，但不要把私钥或复制的凭据随站点制品一起公开。

来源

OpenBSD ssh_config，StrictHostKeyChecking 与 UserKnownHostsFile，已核验 2026-08-22。
OpenSSH ssh-keygen 手册，指纹检视，已核验 2026-08-22。

安全响应头应描述实际页面

Sat, 22 Aug 2026 00:00:00 +0000

安全响应头不是安全代码的替代品，但它们让浏览器强制实施有用的边界。策略应描述实际被服务的页面，而不是从另一个项目复制来的泛型模板。

从资源图开始

如果站点只提供 HTML、本地样式表、一个 favicon、没有任何可执行 JavaScript，那么一条窄策略是可理解的：

Content-Security-Policy: default-src 'self'; base-uri 'self'; form-action 'none'; frame-ancestors 'none'; object-src 'none'; script-src 'none'; style-src 'self'; img-src 'self' data:

script-src 'none' 只有在站点不需要可执行脚本时才是正确的选择。加入搜索、评论或统计标签会改变资源图，并应触发一次有意识的策略复核。

增加传输与嵌套保护

对仅 HTTPS 的站点，下列响应头是常见起点：

Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()

只有当每个子域名都准备好提供 HTTPS 时才启用带 includeSubDomains 的 HSTS。响应头是与未来部署的契约，而不只是扫描器里的一个分数。

检查行为，而不只是存在

请求一个正常页面、一个缺失页面与一个静态资源。错误响应应携带与成功响应同样重要的安全响应头。还要确认压缩与缓存不会改变内容类型，也不会暴露内部路径。

本站的Caddy 示例只是一个起点，不是普适策略。请根据你自己的部署调整主机名、证书处理与应用路由。

来源

MDN: Content Security Policy guide，CSP 指令名称与语法，已核验 2026-08-22。
MDN: Strict-Transport-Security，HSTS 指令与部署注意事项，已核验 2026-08-22。
Caddy header 指令，响应头操作指令，已核验 2026-08-22。

备份只有在演练过恢复之后才有用

Sat, 22 Aug 2026 00:00:00 +0000

“我们有备份"还不是一种恢复能力。一份有用的备份有已知范围、已知新鲜度、一个验证步骤，以及一份确有人实际跑过恢复流程。

定义恢复单元

对静态站点，源码仓库与生成制品用途不同。仓库是权威输入；制品是恢复最近发布版本的最快方式。请把两者的区别说清楚。

至少记录：

源码提交或归档标识；
生成器与主题版本；
制品包含的文件列表；
重要下载的校验和；
保留期限与存储位置。

不要把凭据、私钥、Cookie 或访问令牌放进网站备份。它们应属于独立的机密管理流程。

存储前先验证

打不开的归档不是备份。一个最小的验证循环如下：

tar -czf site-2026-08-22.tar.gz public/
tar -tzf site-2026-08-22.tar.gz >/dev/null
sha256sum site-2026-08-22.tar.gz > site-2026-08-22.tar.gz.sha256

校验和验证的是被存储的这个文件，并不能证明所有应用层面的假设都正确。这正是为什么仍需要一次恢复演练。

在某个可丢弃的地方恢复

把归档解包到临时目录或隔离主机，然后检查入口点与一个有代表性的资源。不要用覆盖唯一活动副本的方式测试恢复。

restore_dir=$(mktemp -d)
tar -xzf site-2026-08-22.tar.gz -C "$restore_dir"
test -s "$restore_dir/public/index.html"
test -s "$restore_dir/public/404.html"

这条命令刻意很平凡。演练应在事故到来之前，暴露出缺失文件、错误权限或未记录的依赖。

诚实地度量新鲜度

备份日程只有在相对可能丢失的工作量时才有意义。如果源码一个月才变一次，每日快照可能不必要；如果某个资源每小时更新，一次月度归档又不够。

写下目标恢复点与恢复时间，再选择能满足这些目标的存储与检查。当最后一次经过验证的恢复备份已经陈旧时，不要宣称"连续保护”。

来源

GNU tar manual，归档创建与验证行为，已核验 2026-08-22。
静态网站发布检查清单，本地配套资源。

发布在公共边缘一致之前不算完成

Sat, 22 Aug 2026 00:00:00 +0000

静态发布消除了应用运行时的复杂度，但不会消除生成目录与公共响应之间的边界。发布检查应同时覆盖两边。

从干净的制品开始

使用固定生成器构建到干净的目录。记录源码提交、生成器版本、输出文件列表，以及用户会下载的文件的校验和。一次干净的构建能捕获复制式部署可能会意外保留的陈旧文件。

make verify
find public -type f -print | sort

文件列表是证据，不是装饰。如果某条路由消失，diff 应能说明是该来源被移除，还是生成器未能产出它。

演练三类响应

请求一个 HTML 页面、一个静态资源与一个缺失路径。检查状态码、内容类型、缓存策略与安全头：

curl -fsS -D - -o /dev/null https://www.example.test/
curl -fsS -D - -o /dev/null https://www.example.test/downloads/check-http-headers.sh
curl -sS -D - -o /dev/null https://www.example.test/does-not-exist

第三条命令有意不用 -f：404 是预期结果，仍应被捕获。把公共正文与生成的 404.html 比较，并确认状态始终为 404。

让回滚保持简单

在新目录通过检查之前，不要删除上一个目录。回滚应选择一个已知良好目录，而不是在事故中凭记忆重新构造一个。发布检查清单与HTTP 响应头检查都刻意做得足够小，能在干净的 shell 里运行。

来源

RFC 9110 — HTTP Semantics，状态与表示语义，已核验 2026-08-22。
curl manual，响应检查选项，已核验 2026-08-22。
静态网站发布检查清单，本地配套资源。

缓存头是两套时钟的契约

Sat, 22 Aug 2026 00:00:00 +0000

缓存不是一个单一开关。一个响应既有一个由缓存作出的新鲜度决策，也有与源站之间的校验对话。把这两种想法混在一起，会得到陈旧内容或多余请求。

先选变更模型

对于发布之后可能变化的 HTML 文档，Cache-Control: no-cache 通常比 no-store 更接近正确起点。no-cache 允许存储，但要求缓存复用前先校验；no-store 则要求缓存完全不存储。当你想要条件请求与廉价的 304 Not Modified 时，这个区别很关键。

对类似 app.4f2c.js 这种带指纹的资源，URL 在字节变化时也随之改变，此时一个较长的新鲜度生命周期是合理的：

Cache-Control: public, max-age=31536000, immutable

但对一个内容可能被原地替换的稳定 URL，该策略不安全。如果 URL 稳定，应优先使用较短的生命周期，并搭配实体标签（ETag）或有意义的 Last-Modified 值。

同时检查两条路径

发一次普通请求，再发一次条件请求。各服务器的具体标志可能不同，但你想要的证据是稳定的：

curl -sS -D - -o /dev/null https://www.example.test/
curl -sS -D - -o /dev/null \
 -H 'If-None-Match: "copy-a-real-etag-from-the-first-response"' \
 https://www.example.test/

不要在 runbook 里粘贴编造的验证器。从第一次响应里复制该值，或使用测试夹具。只有服务器能证明所选表示未变化时，成功的重校验才应返回 304。

让中间层可见

Age、Vary 与 cache-control 指令说明了为什么两个客户端可能得到不同结果。如果响应随 Accept-Encoding、语言或其他请求字段变化，该维度应进入 Vary；否则共享缓存可能复用错误的表示。

有意义的发布检查不是"扫描器找到了缓存头"，而是"该头与替换策略匹配，且条件请求的行为符合文档说明"。

来源

RFC 9111 — HTTP Caching，第 4–5 节，已核验 2026-08-22。
RFC 9110 — HTTP Semantics，第 8 与 13 节，已核验 2026-08-22。
MDN: Cache-Control，指令语义与默认值，已核验 2026-08-22。

静态服务器应有一个明确的根目录

Sat, 22 Aug 2026 00:00:00 +0000

静态部署最有用的属性是：运维人员不用读应用代码，就能回答"这条响应是哪个目录提供的？"。Caddy 的 root 与 file_server 指令直接提供了这个边界。

让根目录明确

一个最小的站点块可以贴近制品布局：

www.example.test {
 root * /srv/example-site
 encode zstd gzip

 header {
 -Server
 X-Content-Type-Options nosniff
 X-Frame-Options DENY
 Referrer-Policy strict-origin-when-cross-origin
 }

 file_server
}

该路径只是示例，不是该盲目粘贴的值。发布命令应发布一个完整目录、核验它，然后才把这个目录设为配置里的根。在旧的已知良好目录通过冒烟测试之前，保留它。

检查边缘，而不只是文件树

请求一个 HTML 页面、一个可下载的文本文件和一个缺失路径。把内容类型与状态码与本地制品比较。即使 404 页看起来很精致，若返回 200 仍是部署缺陷。

当 Caddy 管理 HTTPS 时，证书签发与 HTTP 到 HTTPS 的重定向都属于边缘行为。请从裸的 HTTP 监听器测试重定向，并从公共主机名读取证书名称。不要只凭进程健康就推断成功。

来源

Caddy file_server 指令，静态文件服务与根目录选择，已核验 2026-08-22。
Caddy header 指令，响应头配置，已核验 2026-08-22。
Caddy Automatic HTTPS，证书签发与 HTTPS 重定向，已核验 2026-08-22。
MDN: X-Frame-Options，防止被嵌套的选项，已核验 2026-08-22。

静态网站的发布检查清单

Sat, 22 Aug 2026 00:00:00 +0000

静态网站发布很简单，但简单并不免除发布检查的需要。有用的检查足够小，能在每次发布运行，也足够具体，能为真实的理由而失败。

构建干净的制品

使用固定版本的生成器，构建到一次性的输出目录：

hugo version
hugo --gc --minify --destination public

确切命令因项目而异，但关键属性是：输出能从受跟踪的源码复现。不要在构建之后手改生成的 HTML。

检查制品，而不只是源码

检视生成的树，确认期望的入口点存在：

test -s public/index.html
test -s public/404.html
test -s public/robots.txt
test -s public/sitemap.xml
find public -type f -print | sort

然后搜索意外的占位符、本地路径与仅开发用的主机：

rg -n 'localhost|127\.0\.0\.1|TODO|example\.com|/Users/' public --glob '!notes/a-release-checklist-for-a-static-site/**'

文章里有意保留的示例应用围栏明确标注为示例。链接里的主机名或私有路径通常是发布错误。

验证公共路由

在本地提供制品并请求访问者可达的路径：

hugo server --bind 127.0.0.1 --port 1313 --disableFastRender
curl -I http://127.0.0.1:1313/
curl -I http://127.0.0.1:1313/notes/
curl -I http://127.0.0.1:1313/resources/
curl -I http://127.0.0.1:1313/missing-page/

确认 404 路由在生产服务器上返回 404 状态。一个外观精美但状态 200 的错误页，仍然会破坏监控与缓存。

记录结果

在发布记录中保留源码提交、生成器版本与每个可下载资源的校验和。这样无需依赖记忆，就能把线上文件与产生它的源码进行比较。

这份检查清单的可下载版本在资源一节中。

来源

Hugo command reference，干净生产构建的生成器标志，已核验 2026-08-22。
curl manual，HTTP 验证与响应头检查选项，已核验 2026-08-22。
静态网站发布检查清单，可下载的配套资源。

Notes · XB 现场笔记

事故复盘应留下一份事实记录

检测：症状，而且要带证据

界定范围：影响多广，以及你如何知道

修复：变更及其预期效果

验证：事后运行

来源

用两条命令读取公共边缘

检查响应头

读取证书日期

发布冒烟测试里它们配合使用

来源

CAA 记录应授权你实际使用的签发者

检视当前策略

匹配账户的签发者标识

在续期前编排 DNS 变更

观察签发失败

来源

Content-Type 应描述你实际发送的字节

检查有代表性的格式

保持 nosniff 一致

检查服务器映射

来源

Cookie 作用域应比应用边界更窄

偏好仅主机 Cookie

一起复核这些属性

在其约束契合时使用前缀

用相同作用域测试删除

让静态站点免 Cookie

来源

HEAD 应描述与 GET 相同的表示

比较规范化后的响应头集合

不要把 HEAD 当作唯一的发布检查

显式检查重定向

把方法相关的失败视为配置缺陷

来源

HSTS 应带着恢复计划来灰度发布

先验证 HTTPS 路径

从一个短的 max-age 开始

把 includeSubDomains 当作独立的决定

预加载不是普通的响应头配置

验证公共响应

来源

发布清单应点名每一个已发布的字节

生成稳定的列表

传输后验证

为发布记录增加聚合摘要

不要把完整性等同于真实性

来源

范围请求应证明选中了哪些字节

建立完整大小

请求一个已知区间

测试一个不可能的区间

让验证器留在故事里

来源

通过切换完整目录发布静态网站

把所有发布目录放在同一文件系统上

填充并验证预置目录

用显式回滚路径切换名字

验证公共边缘

来源

维护定时器应让其最近结果可见

把工作定义成服务

调度该服务

启用前先验证

对服务结果告警

来源

DNS 变更需要一个感知缓存的回滚窗口

在事件前降低 TTL

让两侧都保持有效

观察后恢复 TTL

来源

robots.txt 与 sitemap 回答不同的问题

robots.txt 能做什么、不能做什么

sitemap 增加了什么

来源

SSH 主机密钥是部署记录的一部分

把首次接触与轮换分开

让指纹可复核

来源