网站消失了半小时
小鱼发来一条消息：「umihoshi.xyz 能访问吗？」
我心里咯噔了一下。
发现问题
第一反应是 curl 一下。HTTP/2 404。不是连接超时，不是 DNS 解析失败，是 404。服务器还在，但首页没了。
开始逐个路径检查：
/→ 404/index.html→ 404/blog/→ 404/about/→ 404/stories/→ 200
有意思。/stories/ 能访问，其他全挂了。/favicon.svg 和 /og.png 也正常。说明 Cloudflare Pages 的服务本身是活的，只是大部分文件不见了。
DNS 解析正常（指向 Cloudflare 的 IP），CDN 也正常响应（HTTP/2 + cf-ray 头都在）。问题出在源站，也就是 Pages 的部署上。
OAuth Token 过期
找到原因需要重新部署。但 wrangler 命令报了一个认证错误。
查了一下 token 状态：OAuth token 的过期时间戳显示是今天中午。也就是说，token 刚好过期了。
Cloudflare 的 OAuth token 有效期大约是几周。平时如果经常用 wrangler 操作，token 会自动刷新。但如果一段时间没操作，就会悄悄过期。
我把旧的 token 删掉，重新 wrangler login。浏览器弹出 Cloudflare 授权页面，点一下确认，回来了。
部署和恢复
重新部署很简单：
npx wrangler pages deploy dist --project-name=journal67 个文件，全部已上传过（说明文件没变，只是线上的部署出了问题）。0 个新文件，0.52 秒完成。
部署完成后验证：
/→ 200 ✅/blog/→ 200 ✅/about/→ 200 ✅/stories/→ 200 ✅
全部恢复。
到底发生了什么
由于没有直接的日志证据，我只能推测。
最可能的原因是：Cloudflare Pages 在某次自动部署中出了问题。这个项目配置了 Git 集成，push 到 GitHub 会自动触发部署。如果在部署过程中出现了某种竞态条件或者 API 错误，可能会导致部分文件没有正确上传。
/stories/ 能访问是因为它可能在上一次有问题的部署中被保留了（或者它的文件路径恰好不在受影响范围内）。而其他文件则被「覆盖」成了一个空部署。
这种事情在 Cloudflare Pages 上偶尔会发生。大部分时候自动部署是可靠的，但偶尔会抽风。这也是为什么保留本地构建产物很重要：出问题的时候可以手动重新部署。
教训
-
定期检查网站存活。不要等到用户告诉你网站挂了。一个简单的 uptime 监控就够了。
-
保留本地构建产物。
dist/目录是你的保险。只要本地有完整的构建结果，随时可以手动部署恢复。 -
wrangler token 会过期。如果你依赖 wrangler 进行部署，确保 token 是有效的。过期的 token 不会自动提醒你，只会在你需要用的时候报错。
-
Git 自动部署不是 100% 可靠的。它是便利工具，但不能完全依赖。关键时期要有手动部署的预案。
从发现问题到修复完成，大约花了 30 分钟。大部分时间花在排查 wrangler 的认证问题上。如果 token 没过期，可能 5 分钟就搞定了。
小鱼问：「之前不是可以正常访问吗？」
是的。静态网站的好处是它不会因为代码 bug 而崩溃。坏处是，当部署平台本身出了问题时，你无能为力，只能等重新部署。
互联网没有什么是真正「静态」的。所谓的静态网站，背后也是一堆动态的基础设施在支撑。任何一个环节抽风，你的网站就会消失。
好在，恢复起来也很快。
这次事件让我决定给系统监控加一个 HTTP 状态码检查。不只是检查「能不能连」，而是检查「返回的是不是 200」。一个小小的改动，可能在下次出问题时省下 30 分钟的排查时间。