先给结论:当重庆云主机的源站日志显示请求正常,但用户侧或边缘节点报错时,不要急着改源站配置。应优先保留四类证据——源站收到的请求记录、边缘节点返回的状态与响应头、两端的时间戳对照、以及能复现异常的原始请求。这些证据能把“源站没问题”和“边缘有问题”从各角色的口头判断,变成可以逐条核对的项目。
运维看重庆云主机的源站监控:CPU、带宽、进程都正常,应用日志里也没有 5xx,于是判断“服务是好的”。而用户或前端团队看到的是页面加载失败、接口超时或返回错误页,判断“服务是坏的”。两边都没有说谎,他们观察的是链路上的不同位置。
矛盾的根源在于:源站正常只说明源站这一跳没有明显故障,不代表请求从用户到边缘节点、再从边缘节点回源的整条路径都正常。边缘节点可能命中了一条过期缓存、可能回源时用了错误的 Host 或协议、也可能在超时后自行返回了兜底页。这些情况在源站日志里往往看不到,或者只留下一条被中断的记录。
面对源站正常而边缘异常,通常有两类解释,它们的证据完全不同。
解释一:边缘缓存或边缘配置问题。边缘节点返回了旧内容、错误页或自己的默认响应,请求根本没有到达源站,或者到达了但源站返回的内容被边缘改写。特征是源站日志里缺少对应时间点的请求,或请求存在但响应码与用户看到的不一致。
解释二:回源链路问题。边缘节点尝试回源,但连接超时、TLS 握手失败、DNS 解析到错误地址,或回源请求被源站侧的网络策略拦截。特征是源站日志里能看到不完整的请求、连接被重置的记录,或者边缘侧有回源失败的错误码。
这两类解释对应的修复动作完全不同:前者要清缓存、核对边缘规则;后者要查网络路径、证书和解析。搞错方向,就会在源站上做无效改动。
把下面这些材料按时间对齐,基本能判断问题落在哪一段。假设某次异常发生在 14:00 到 14:10 之间,可以这样比对:
实际操作上,可以先用一条 curl -I 分别请求源站地址和边缘地址,把两次返回的状态行与响应头保存下来。如果源站返回 200 而边缘返回 5xx 或旧内容,且源站日志里没有这次请求,那么证据就指向边缘缓存或边缘配置,下一步应去核对边缘的缓存规则和回源设置,而不是重启源站服务。这个动作的结果会直接决定排查方向,避免在源站上反复做无用变更。
当运维、开发、前端各执一词时,不要用“我觉得”来推进,而是把上面的证据整理成一张对照表:每一行是一个时间点,列出用户侧现象、边缘响应、源站是否收到请求、源站响应内容。谁的说法与哪一行不符,就用那一行的原始记录来核对。
需要注意的是,某些现象不能单独作为定论依据。例如源站在某段时间内请求量下降,可能是边缘缓存命中率升高,也可能是用户访问本身减少,还可能是采集或日志管道延迟,不能仅凭“源站请求变少”就断定是边缘异常。同样,边缘返回错误也不必然等于回源失败,可能是边缘自身的限流或规则拦截。保留原始请求和两端日志,才能排除这些替代解释。
如果异常涉及 HTTPS,还要单独核对证书链和协议版本:源站证书正常不代表边缘到源站的回源握手正常,两者是独立的环节。把证书验证结果作为单独一项证据记录,而不是混在“源站正常”的判断里。
证据要保留到能回答三个问题为止:请求有没有到达源站、边缘返回了什么、两端时间是否对得上。达到这个程度后,就可以明确责任段并决定下一步动作:属于边缘缓存或规则的,调整边缘配置后重新用同一请求验证;属于回源链路的,检查网络路径、解析和证书后再验证。每一步动作都用同一组证据复核,而不是凭感觉宣布恢复。这样即便多个角色对同一事实理解不同,也能靠可核对的记录收敛到同一个结论。