博客突发崩溃？我的紧急排查与解决全记录

type

status

date

slug

summary

一、崩溃确认：没有后台的尴尬与排查起点

静态博客的极简架构在此刻成了双刃剑：没有后台状态面板可供查看，只能通过外部访问结果判断故障程度。用公司网络、手机热点、4G/5G 流量反复测试，结果一致；拜托三位不同城市的朋友帮忙验证，均反馈 “无法连接”，我意识到这绝非偶然 —— 整个站点已经陷入全网瘫痪。

摊开笔记本画出简易架构图：Vercel 部署静态文件→阿里云域名解析→又拍云 CDN 加速。这三个环节构成了博客的全部访问链路，任何一环断裂都会导致全站失联。没有后台的情况下，排查只能从最外层的访问节点开始，像剥洋葱一样逐层定位。

二、排查链路：从 “逐一排除” 到 “共性突破”

1. 部署平台（Vercel）的排除法

首先想到的是部署平台故障。登录 Vercel 控制台，查看最近部署记录显示 “成功”，点击预览链接却能正常打开 —— 这说明静态文件本身和部署环境没有问题。为了进一步验证，甚至用 Vercel 提供的临时域名测试，访问流畅无阻。至此，Vercel 的嫌疑被彻底排除。

2. 域名解析（阿里云）的反复核验与 DNS 污染排查

打开阿里云域名控制台，逐条检查解析记录：A 记录指向正确，MX 记录未受影响，CNAME 记录清晰指向又拍云的 CDN 域名，TTL 设置为 10 分钟也符合快速生效原则。但考虑到可能存在 DNS 污染问题，我又进行了一系列排查。

先是修改本地 DNS 服务器，将其切换为公共 DNS，像 114.114.114.114 和 8.8.8.8，修改后重新访问博客，依旧无法打开，这在一定程度上降低了本地 DNS 被污染的可能性。接着使用 nslookup 和 dig 命令查询域名解析结果，返回值与阿里云控制台的配置完全匹配；切换不同 DNS 服务器多次测试，解析过程均无异常。反复刷新页面确认，域名解析这一环似乎也站得住脚，基本排除了 DNS 污染导致故障的可能。

3. CDN 故障：从 “毫无头绪” 到 “配置深挖”

排除前两项后，排查陷入短暂僵局。重新梳理链路时突然想起：我在又拍云还部署了另外两个小型站点。抱着试试看的心态输入它们的域名，结果令人心头一震 —— 这两个站点同样无法访问！

三个不同域名、不同内容的站点，唯一的共性就是使用了又拍云 CDN 服务。这个发现像一道光劈开迷雾：问题极有可能出在 CDN 环节。可登录又拍云控制台后，界面却让我愣了一下 —— 不知何时悄悄更新过，布局比之前看起来有点陌生，而且全程没有任何故障提示或警告信息，只能靠自己一点点排查。

我开始逐个检查配置项，从缓存设置到页面压缩，这些常规功能看起来都正常运行。直到点击进入安全配置区域，才发现 HTTPS 配置的入口位置和之前略有不同。点进去后，逐项核对配置参数，当目光扫过 SSL 证书设置时，突然发现最关键的 SSL 证书区域显示 “未配置”—— 要知道，这里本该有一个用了三年的自动续签证书！

瞬间恍然大悟：证书消失导致 HTTPS 握手失败，进而引发回源异常，这才是所有站点同时瘫痪的根源。从共性锁定 CDN，到在更新后的界面里逐个排查配置，最终在 HTTPS 设置中找到消失的证书，整个过程像在没有地图的迷宫里摸索，全凭对系统架构的熟悉度咬牙向前。