500表示请求处理失败，但浏览器看到的状态可能由应用、反向代理或CDN错误处理逻辑生成。CDN也可能只是转发源站状态。排查第一步是固定同一次请求的证据，并沿边缘到源站的日志链寻找对应记录，避免凭错误页样式猜测责任方。
记录时间及时区、完整路径、Host、协议、状态码、响应头、边缘请求标识和少量错误正文。可用curl -i观察状态和头部。检查缓存状态、对象年龄、边缘错误分类和源站访问日志；必要时用相同Host与SNI做受控对照。不要公开包含Cookie、授权头或个人信息的诊断输出。
先确认请求是否命中缓存。若错误对象被缓存，源站当前已恢复也可能仍看到旧响应；反过来，改变查询参数可能触发另一缓存键，并不一定代表真实用户请求路径已恢复。
“源站日志没找到”不是充分证据，日志采样、延迟、入口差异或请求标识丢失都可能造成空档。应同时看边缘日志和源站负载，在同一时间窗口用请求ID、Host和路径对齐记录。
对照发布与配置变更时间，检查应用错误率、上游响应码、连接池等待、CPU/内存和依赖服务错误。比较首页、静态资源、健康检查及其他动态路由：若静态资源正常而首页500，问题更可能集中在动态渲染或首页依赖；若多个动态路由同时异常，则检查共享上游。观察错误率和延迟分位数的变化，不用单次探测代表全站状态。
使用相同Host、路径、协议和代表请求重复验证；确认边缘与源站日志能通过请求ID关联，源站返回预期状态及内容，边缘没有持续的回源错误。再检查相邻业务路由和错误率趋势，等待至少覆盖站点正常观测周期。错误页样式和500数字都不能单独证明故障归属；可复现的响应路径证据才是修复依据。✅
