使用CDN后出现502或504，应先保存错误时间和请求标识，并区分边缘节点与源站响应。502通常涉及网关收到无效上游响应，504涉及等待上游超时，但单靠状态码不能确定是哪台服务器出了问题。
记录可以关联的证据
保存完整网址、时间及其时区、错误页面中的请求ID，并说明是否所有页面都失败。不要公开包含登录令牌或私人查询参数的URL。
对比静态文件、普通文章和动态接口。如果图片正常但结账超时，排查方向可能更靠近动态处理；若所有资源失败，优先检查源站连接和服务状态。
源站检查要保留域名条件
由管理员核对源站Web服务、PHP进程、资源和日志。测试源站时应保留正确Host与TLS主机名；直接用IP打开共享主机，可能落到其他虚拟主机，不能作为可靠对照。
源站只允许CDN访问的情况下，随意直连失败是预期行为。不要为了测试长期开放所有来源。
对照同一分钟的日志
查看源站是否收到该请求，是否返回错误、处理中断或等待外部接口。结合PHP慢日志、数据库连接及工作进程队列，判断资源不足还是具体请求卡住。
如果源站没有相应请求，应继续查网络、防火墙、端口和CDN到源站的连接。如果只有部分节点异常，再向CDN支持提供请求标识和时间。
修复与验收
服务崩溃需要查崩溃原因；超长任务可以改为后台处理或分批；外部接口需要合理超时及失败处理。单纯重启可能恢复服务，但应保留重启前日志，避免证据丢失。
修复后重复原始URL与操作，观察一段时间内的错误率和资源。不要只测试首页一次，也不要用清空所有缓存来替代动态请求验证。
关闭CDN就正常，是否证明CDN有故障？ 只能说明访问路径变化影响结果。TLS、访问规则、源站允许列表和超时策略也可能不同，仍需逐项对照。
参考资料
相关问题
本文为通用排查指南，依据所列官方资料整理；菜单名称和行为可能随版本及主机环境变化。配图为AI生成的概念示意，不是实际故障截图。
