CDN回源失败怎么办？分层排查方法

CDN 回源失败，是指边缘节点需要向源站获取内容时，没有拿到可用响应。用户看到的可能是 502、504、连接超时、证书错误、403 或错误站点，也可能只有未缓存页面失败。排查时不要一开始就反复改 DNS，而要先判断问题发生在“用户到 CDN”还是“CDN 到源站”。

不同 CDN 厂商对内部状态码和回源能力的定义并不完全相同，控制台字段也会变化。下面给出的是通用分层方法，操作时应同时查看当前服务商的错误分析、请求标识和最新文档。

先用现象确定排查层级

现象	优先检查
缓存命中正常，动态页面或首次访问失败	源站可用性、回源协议、超时、应用和数据库
全部 URL 同时 502 或 504	源站进程、端口、防火墙、负载和网络连通性
返回默认页或其他站点内容	回源 Host、源站虚拟主机和 HTTPS SNI
HTTP 正常，HTTPS 回源失败	443 端口、证书域名、证书链、SNI 和 TLS 兼容性
只有部分节点或地区间歇失败	多源站健康、区域网络、IP 白名单、单机容量和节点日志
回源出现 403	源站 WAF、防火墙、鉴权、防盗链和 CDN 回源地址放行
回源出现 404	Host、路径重写、源站目录和应用路由

状态码只是入口，不是结论。以 502、504 为例，错误既可能由源站返回，也可能是 CDN 无法联系源站。记录完整 URL、发生时间与时区、错误页面特征、请求标识和命中状态，才能在边缘日志与源站日志之间对齐。

第一步：绕过 CDN 验证源站

不要只在浏览器里直接访问源站 IP。一个 IP 上可能部署多个站点，直接访问会命中默认虚拟主机，不能证明目标站点异常。HTTP 测试要带正确 Host，HTTPS 测试还要让域名、SNI 和证书校验保持一致。

curl -I -H 'Host: www.example.com' http://ORIGIN_IP/
curl -I --resolve 'www.example.com:443:ORIGIN_IP' https://www.example.com/
openssl s_client -connect ORIGIN_IP:443 -servername www.example.com

请把示例域名和 ORIGIN_IP 换成自己的值。测试结果要同时看连接是否建立、TLS 是否通过、返回状态、响应头和正文是否属于目标站点。如果源站域名本身也接入同一 CDN，可能形成回源环路，应使用不会再次指向当前加速域名的源站地址。

第二步：核对源站地址与回源 Host

“源站地址”和“回源 Host”解决两个不同问题：前者告诉 CDN 连接哪台服务器，后者告诉这台服务器请求哪个站点。Nginx 等 Web 服务器会根据监听地址、端口和 Host 选择虚拟主机；Host 不匹配时，可能返回默认页、404、403 或另一套证书。

源站填写 IP 时，确认该 IP 当前仍属于目标服务器，迁移后没有遗留旧地址。
源站填写域名时，确认其权威解析不会再回到同一个 CDN，避免循环回源。
一个源站 IP 承载多个域名时，回源 Host 应匹配源站的 server_name 或应用绑定域名。
对象存储作为源站时，按服务商要求使用存储桶访问域名和私有回源鉴权。
有多个源站时逐个测试，不要因为其中一台正常就忽略间歇故障节点。

域名解析记录与CDN源站关系说明配图 — DNS 决定名称指向哪里，回源 Host 决定源站上的哪个虚拟主机处理请求，协议和端口则属于后续连接配置。

A、CNAME 等记录本身不能携带端口，相关分层可以先阅读域名解析、端口与反向代理的区别。修改源站或加速域名解析前，还应记下原值和 TTL，准备可回滚方案。

第三步：确认协议与端口成对

回源配置	源站必须满足	典型错误
HTTP 回源	指定端口监听明文 HTTP	把 HTTP 请求发到只接受 TLS 的 443 端口
HTTPS 回源	指定端口支持 TLS，证书与 SNI 配置正确	源站只开 80，或 443 被安全组拦截
协议跟随	HTTP 与 HTTPS 对应链路都可用	只验证了一种协议，另一种用户请求回源失败
自定义端口	CDN 产品支持该端口，源站与防火墙同时放行	应用已迁移端口但控制台、Nginx 或安全组未同步

各产品支持的回源端口范围不同，不能把某家 CDN 的端口能力直接套到另一家。变更后应从服务商实际节点验证，不要只在服务器本机执行 curl localhost，因为本机测试绕过了公网防火墙、安全组和跨网链路。

第四步：HTTPS 同时检查 SNI 与证书链

HTTPS 回源除了端口可达，还要完成 TLS 握手。源站共用一个 IP 承载多个证书时，CDN 需要发送正确 SNI；证书要覆盖回源校验使用的域名，并处于有效期内。若服务器只发送站点证书而缺少中间证书，一些回源客户端也会验证失败。

用 openssl s_client 查看实际返回的证书主题、有效期、链和验证结果。
比较 CDN 控制台的回源 Host、回源 SNI 与源站证书域名，不要默认三者一定相同。
确认源站支持 CDN 当前采用的 TLS 版本和密码套件。
证书续期后检查所有源站节点，避免负载均衡后仍有旧证书。

证书链的具体检查与 fullchain 部署方法可查看SSL 证书链不完整排查指南。

第五步：检查防火墙、WAF 与回源鉴权

源站如果只允许固定地址访问，应从 CDN 官方渠道获取当前回源 IP 段，并建立更新流程。节点地址可能调整，手工复制一次后长期不维护，会形成间歇性 403 或连接超时。也要检查安全组、主机防火墙、Nginx 访问控制、WAF、对象存储鉴权和防盗链是否重复限制。

对比失败请求是否进入源站访问日志：完全没有记录时，优先查网络和访问控制。
有访问日志但返回 403 时，核对命中的安全规则、Host、Referer、鉴权参数和时间同步。
不要为了恢复服务永久放开全部管理端口；只调整回源所需端口和来源。
临时放行用于定位后，应立即恢复最小范围策略并记录变更。

第六步：处理超时、过载与应用错误

当 CDN 能连接源站但迟迟收不到响应，要继续向应用内部追踪。查看 CPU、内存、连接数、磁盘、带宽、PHP 或 Java 进程池、数据库慢查询和下游接口。只有动态请求失败时，还要确认缓存规则是否让静态页面掩盖了源站故障。

按 URL、状态码、响应时间和源站节点聚合，找出是全站故障还是单一路径。
比较 CDN 回源超时与源站应用超时，避免上游先断开而后台仍继续占用资源。
检查请求体大小、响应压缩、连接复用和大文件下载是否只在特定场景触发。
多源站配置要核对健康检查、权重和故障切换，避免故障节点持续分流。
修复后主动请求原故障 URL，并观察缓存未命中时是否也能稳定返回。

恢复后可以把 DNS、HTTPS、状态码和页面内容纳入持续检查，方法见域名状态监测清单。监测需要包含一条强制回源或短缓存测试路径，否则长期命中缓存可能延迟发现源站失效。

一套不容易走偏的排查顺序

记录错误 URL、时间、状态码、请求标识和缓存命中情况。
带正确 Host 和 SNI 绕过 CDN 测试源站。
核对源站地址，排除旧 IP、回源环路和故障节点。
核对回源 Host、虚拟主机、路径重写和应用路由。
核对 HTTP/HTTPS、端口、SNI、证书域名和完整证书链。
检查 CDN 回源 IP 放行、WAF、安全组、防火墙和鉴权。
关联源站访问日志、错误日志、系统资源和数据库性能。
修复后从不同网络和未缓存路径复测，并保留回滚记录。

常见问题

直接访问源站 IP 正常，为什么 CDN 仍回源失败？

直接访问 IP 可能命中默认站点，也可能使用了不同 Host、协议、端口或网络来源。应使用与 CDN 回源一致的域名、Host、SNI 和端口测试，并确认源站允许 CDN 节点地址访问。

清理 CDN 缓存能解决回源失败吗？

通常不能修复源站连接、Host、TLS 或负载问题，反而会让更多请求同时回源，扩大故障。只有确认缓存内容错误或配置已修复且需要刷新旧对象时，才按范围清理并观察源站容量。

改成 HTTP 回源可以临时恢复吗？

它可能绕过某些 TLS 配置问题，但会改变 CDN 到源站之间的传输保护，不应在未评估数据敏感性和网络边界时作为长期方案。更稳妥的是修复源站 HTTPS、证书链和 SNI，并在变更前准备回滚。

总结

CDN 回源失败要按链路分层：先确认边缘与源站分界，再依次核对源站地址、回源 Host、协议端口、SNI 与证书、防火墙鉴权以及源站性能。每一步都用同一条 URL、明确时间和日志证据验证，才能避免在 DNS、缓存和服务器之间来回猜测。

官方参考

文章版权归作者所有，未经允许请勿转载。

THE END

CDN回源失败怎么办？从源站、Host、端口到HTTPS的排查方法