VIP域名选择：源站正常而边缘节点异常时应保留哪些证据
📱 Mozilla/5.0 (compatible; QlyzeBot/1.0; +https://app.qlyze.io/bot)
🔗 /88e958612334.html
📄
VIP域名选择：源站正常而边缘节点异常时应保留哪些证据
当 VIP 域名选择涉及旧系统退出时，源站正常而边缘节点异常，首先要保留的是能证明“同一时刻、同一请求路径、两端表现不同”的对照证据。没有这组对照，后续无论是回滚、切换还是继续观察，都只能凭印象判断。假设某旧业务准备从原有 VIP 域名切换到新入口，源站日志显示请求正常返回，但部分用户仍看到异常页面，此时不要先改 DNS，而应先固定证据，再决定是保留旧解析、调整回源策略，还是把边缘层单独下线。
先分清两种解释：边缘缓存旧内容，还是边缘到源站链路异常
源站正常、边缘异常，最常见的矛盾不是“源站到底有没有问题”，而是异常发生在哪一层。第一种解释是边缘节点仍在使用旧缓存或旧配置，源站已经更新，但边缘没有及时取到新版本。第二种解释是边缘到源站的回源链路、证书校验、超时设置或节点本身出现异常，导致边缘拿不到源站响应，只能返回旧内容或错误页。
这两种解释对应的处理方向不同。前者重点是缓存刷新、配置核对和回源验证；后者重点是节点状态、链路日志和切换回源路径。若只看到“源站 200”就认定边缘一定只是缓存旧内容，可能把链路故障误判成刷新问题。
能区分两种解释的证据：同一请求在两端的时间与状态对照
证据要能回答三个问题：同一时刻，源站收到了什么请求；边缘返回了什么内容；边缘是否真的向源站发起了回源。可以按下面顺序保留：
- 源站访问日志中对应时间段的请求记录，包括请求路径、状态码、响应大小和上游地址。若源站根本没收到边缘的回源请求，更像边缘缓存或边缘内部处理；若收到了但响应异常，则要回看源站当时返回内容。
- 边缘侧返回给客户端的响应头，重点关注缓存命中状态、回源标记、内容长度和日期。它能说明这次响应来自缓存还是回源结果。
- 边缘节点自身的错误日志或回源日志，包括连接超时、TLS 握手失败、连接被拒绝等记录。若存在这类记录，就不能只按缓存问题处理。
- 同一 URL 在异常节点与正常节点上的返回内容摘要，至少保留响应头和正文特征，不要只截一张页面图。
- 变更记录：最近是否改过 DNS、证书、回源地址、缓存规则或旧系统配置。没有变更记录，后续无法判断异常从哪一步开始。
一个假设例子：旧 VIP 域名准备退出，源站仍正常服务，但某地区边缘节点持续返回旧页面。若边缘日志显示该节点从未向源站发起回源，且响应头带有缓存命中标记，那么优先按缓存旧内容处理；若边缘日志显示回源连接超时，而源站日志没有对应请求，则优先按链路异常处理。这个对照动作会直接决定下一步是刷新缓存还是切换节点。
旧内容退出时，哪些证据要保留到切换完成之后
VIP 域名选择往往牵涉旧合作关系、旧系统或旧入口退出，证据保留周期不能只到“页面看起来恢复”为止。建议至少保留到旧解析完全停用、新入口稳定运行一段时间之后。需要留存的包括：原 VIP 域名的解析记录变更前后版本、边缘配置版本、源站回源规则、证书到期与更换记录，以及异常时段的访问日志样本。
如果旧域名还要保留跳转或过渡页，应单独记录跳转规则和生效范围。不要用 robots.txt 的抓取限制来代替旧内容退出；抓取限制不等于可靠的索引移除，也不等于旧入口已经停止服务。站点地图提交同样不保证收录变化，它只能作为辅助信号，不能当作边缘异常已经解决的证据。
边缘异常未查清前，不要先做不可逆动作
在证据不足时，删除旧解析、清空全部缓存、替换证书或直接下线边缘节点，都会让后续判断失去参照。更稳妥的动作是：先冻结变更，保留异常节点与正常节点的对照样本，再按回源日志判断异常属于缓存层还是链路层。若确认是边缘缓存旧内容，可以针对具体路径刷新并观察边缘是否重新回源；若确认是链路异常，则应先恢复回源路径或切换节点，再决定旧 VIP 域名是否继续保留。
如果异常只出现在部分节点，不要用“源站正常”覆盖全部结论。源站正常只能说明源站当时可服务，不能单独证明边缘节点、回源链路或客户端到边缘这一段没有问题。把这两层证据分开保存，后续无论继续保留旧入口还是完成退出，都有可复查依据。
