CDN回源失败率高，先别急着换服务商

CDN回源失败率突然升高，很多团队第一反应是节点不行、服务商质量差、调度有问题。实际使用中发现，真正因为CDN厂商整体故障导致回源失败持续升高的情况并不算最多，更多是源站、链路、协议、限流、DNS、证书、连接数这些地方出了问题。

尤其是业务刚经历过发布、迁移、扩容、防火墙规则调整、WAF策略上线、源站机房切换之后，回源失败率高，先查自己这边，速度通常更快。换CDN服务商不是不能做，但它应该是排查后的动作，不应该是第一反应。因为源站问题没解决，换一家CDN，大概率还是失败，只是失败日志换了个后台看。

先把“回源失败”拆开看，不要只看一个百分比

CDN后台里看到的回源失败率，通常只是结果。要先看失败类型。是TCP连接失败，还是HTTP 5xx，还是回源超时，还是TLS握手失败，还是DNS解析异常。不同错误背后的排查方向完全不一样。

常见表现可以这样理解：

TCP connect timeout：CDN节点连不上源站IP，重点看源站安全组、防火墙、机房网络、源站端口监听、黑白名单。

TCP reset：连接被中途断开，重点看源站Nginx、LB、WAF、内核连接队列、上游应用主动断连。

HTTP 502/503/504：可能是CDN到源站失败，也可能是源站反向代理到后端失败，要继续看源站访问日志和错误日志。

TLS handshake failed：证书、SNI、协议版本、加密套件、回源Host配置都要查。

Origin DNS error：回源域名解析异常，重点看DNS权威、解析线路、TTL、是否有CNAME链路过长。

这里补充一点，不要只看CDN控制台的“回源失败率”。最好把失败URL、失败节点区域、源站IP、HTTP状态码、错误原因拉出来一起看。只看一个聚合百分比，很容易把局部问题误判成全局问题。

排查顺序从最近变更开始

真实线上问题里，很多事故都跟变更有关。CDN配置改了、源站安全组改了、Nginx发版了、证书换了、DNS切了、WAF规则加了、应用扩容了、机房线路调整了。先看最近24小时到72小时内有没有这些动作。

如果回源失败率从0.2%突然到8%，时间点又刚好卡在某次发布后，那就别先盯着CDN节点。先把变更记录拉出来对时间线。

常见场景是：源站新加了安全组，只放行了办公出口IP，忘记放CDN回源IP段；或者源站Nginx升级后，keepalive参数变了，短连接暴增；再或者业务把回源Host改成了新域名，但源站虚拟主机没配这个server_name，结果回源全进了默认站点。

看源站是否真的扛得住CDN回源

CDN缓存命中率下降时，源站压力会被放大。比如平时命中率95%，10000 QPS里只有500 QPS回源；某次缓存规则改错，命中率掉到70%，回源就变成3000 QPS，源站压力直接变成原来的6倍。

这个时候CDN看起来是在大量回源失败，其实它只是把源站扛不住的问题暴露出来。

建议直接看这几类源站指标：CPU、load、内存、磁盘IO、网卡带宽、TCP连接数、Nginx active connections、upstream response time、应用线程池、数据库连接池、Redis延迟。

一个很典型的数据：源站Nginx access.log里，正常时upstream_response_time在30ms到80ms，故障时大量请求飙到3s、5s、10s，然后CDN侧开始出现504。这种情况不是CDN“不愿意回源”，而是源站响应慢到超过了CDN回源超时配置。

源站带宽也要单独看

很多人只看CPU，没看带宽。源站如果是20Mbps小带宽机器，CDN回源高峰打满之后，会出现大量超时。尤其是图片、视频、安装包、游戏补丁这类大文件业务，带宽打满后不是所有请求都失败，而是延迟逐渐升高，最终表现为间歇性回源失败。

这里可以粗算一下：一个平均2MB的文件，源站20Mbps理论每秒只能稳定传1.25个左右文件，考虑TCP开销、并发、跨网质量，实际更低。如果缓存命中率掉了，回源马上就堵。

如果业务本身依赖高质量源站线路，比如游戏资源、海外访问、回国访问，可以考虑把源站放在网络更稳的云服务器上。比如香港精品CN2-C型适合需要精品线路和中等带宽的业务，香港综合-D型适合需要CN2+CMI+CU回国线路的场景。如果你也在找这种源站承载环境，可以看看129云，他们有香港、美国、大带宽和高防服务器产品，客服热线400-9177118，适合在CDN源站、游戏业务、高防入口这类场景里做选型。

确认CDN回源IP有没有被源站拦掉

这是高频问题。源站为了安全做了IP白名单，但CDN回源IP段更新后没有同步；或者安全设备把CDN节点误判为异常扫描；再或者DDoS防护、WAF、云防火墙触发了限速策略。

排查时不要只在一台机器上curl源站。要从多个网络环境测，比如本地办公网、云服务器、海外机器、同运营商机器。如果本地curl正常，但CDN节点回源失败，就要重点看源站是否对CDN回源IP做了限制。

源站日志里如果完全看不到CDN回源请求，说明请求可能还没到应用层，问题在网络、防火墙、安全组、LB之前。Nginx access.log里没有，error.log也没有，别在应用代码里找半天。

白名单策略要避免写死得太死

有些团队把CDN回源IP写进iptables，半年不维护，后面服务商节点扩容、IP池调整，故障就来了。更稳的做法是定期同步CDN官方回源IP段，或者在边界层用安全策略加日志观察，不要只靠静态IP表硬拦。

多说一句，如果源站同时接多个CDN，白名单维护更容易乱。A CDN正常，B CDN失败，看起来像B CDN质量差，实际是B CDN回源段没放行。

检查回源Host、协议和端口

CDN回源配置里最容易被忽略的是Host。客户端访问的是www.example.com，CDN回源时可以带www.example.com，也可以带origin.example.com，还可以带源站IP对应的默认Host。源站Nginx如果靠server_name分流，Host错了，请求就会进错站点。

表现通常是：部分URL 404、部分502、证书不匹配、源站返回默认页、回源健康检查失败。

协议也一样。客户端到CDN是HTTPS，不代表CDN到源站也一定是HTTPS。有人在源站只开了443，但CDN配置成HTTP 80回源；也有人源站80会301跳HTTPS，CDN又配置了跟随跳转，来回折腾后出现异常。

端口也要看清楚。源站服务实际监听8080，前面LB监听80，CDN却直接回源到服务器IP:80，这种配置迁移时很常见。

TLS问题不要只看证书有没有过期

HTTPS回源失败，很多人只看证书有效期。证书没过期，不代表TLS就没问题。

要继续看这些内容：证书链是否完整，SNI是否匹配，源站是否支持CDN使用的TLS版本，是否禁用了TLS 1.2，是否只保留了很偏的加密套件，回源Host和证书CN/SAN是否一致。

比如CDN回源Host是origin.example.com，但源站证书只包含www.example.com，部分CDN会直接握手失败，部分CDN会放宽校验，这就导致换不同CDN时表现不一致。这个时候不能简单说某家CDN“不稳定”，而是配置容忍度不同。

可以用openssl直接测：

openssl s_client -connect origin.example.com:443 -servername origin.example.com

如果不带-servername正常，带了反而失败，或者反过来，就说明SNI配置要继续查。

看缓存命中率是不是异常下降

回源失败率升高，经常是缓存命中率先掉。命中率下降的原因很多：Cache-Control改了，CDN缓存规则顺序变了，URL加了随机参数，发布系统给静态资源加了时间戳，Cookie参与缓存判断，Range请求配置不对。

这里有个实际使用中发现的情况：某站点静态资源URL后面加了v=时间戳，本来是按版本号变更，后来发布系统把时间戳精确到秒，每次页面刷新资源URL都不同，CDN几乎无法命中，源站瞬间被打爆。

要看命中率，不能只看全站平均。要按目录、文件类型、状态码拆。比如/image/命中率95%，但/download/只有30%，那排查重点就不一样。大文件下载回源失败，通常比小图片更容易拖垮源站连接。

区分“所有地区失败”和“部分地区失败”

如果全国所有地区、所有运营商回源失败率同时升高，源站自身问题概率大。比如源站宕机、端口关闭、证书错误、配置发布错误。

如果只有某个区域、某个运营商失败率高，比如华南电信、华北联通、海外到香港，这时要看链路质量、BGP路由、跨境拥塞、运营商互联质量。

举个常见场景：源站在香港，用户在大陆，CDN节点回源也走跨境链路。晚高峰期间普通国际线路丢包升高，CDN回源超时增加。这个时候换CDN不一定能解决，因为瓶颈可能在源站线路。源站如果接的是CN2、CMI、CU这类更适合回国访问的线路，稳定性会明显好一些。

香港综合-D型这种CN2+CMI+CU线路组合，适合源站需要面向大陆回源、又不想完全依赖单一运营商链路的业务。香港精品CN2-C型则更偏精品线路和稳定回国访问，带宽75Mbps峰值，对中小型动态站、API源站、图片源站比较合适。

源站连接数和队列满了，表现会很像网络故障

CDN回源失败里有一类很隐蔽：源站端口是通的，curl也能通，但高并发时大量失败。这个时候要看连接队列。

Linux上可以看：

ss -s

ss -ant | awk '{print $1}' | sort | uniq -c

netstat -s | grep -i listen

如果看到大量SYN-RECV、TIME-WAIT，或者listen queue overflow，就要查somaxconn、tcp_max_syn_backlog、Nginx worker_connections、worker_processes、keepalive_timeout、upstream keepalive。

Nginx里还有一个常见坑：worker_connections设置太低，worker_rlimit_nofile没跟上，系统ulimit也没调。表面看CPU很低，内存也够，但连接接不进来，CDN侧就出现connect failed或timeout。

回源超时时间不是越大越好

有些人看到504，就把CDN回源超时从5秒改到60秒。短期看失败率可能下降，但用户等待时间变长，源站连接占用更久，故障时会拖得更严重。

更合理的做法是先看业务类型。API接口通常不应该让用户等几十秒；图片、文件下载可以适当放宽；大文件要配合Range、分片缓存、回源限速和源站带宽评估。

如果源站平均响应时间已经从100ms变成5s，把超时调大只是掩盖问题。要查应用慢、数据库慢、缓存穿透、源站带宽满，或者CDN缓存规则失效。

别忽略源站DNS解析

CDN回源可以填IP，也可以填域名。填域名的好处是源站切换方便，坏处是DNS出问题时CDN也会受影响。

需要检查权威DNS是否稳定，解析是否有多线路策略，TTL是否过短，是否存在CNAME套CNAME，是否某些地区解析到错误IP。还有一种情况是源站域名开启了智能解析，CDN节点所在地区被解析到了不适合的线路。

比如CDN某些海外节点回源origin.example.com，被DNS解析到大陆源站；大陆节点又被解析到香港源站。这种策略如果没设计清楚，会出现延迟高、跨境绕路、偶发失败。

WAF和DDoS防护策略要看日志，不要凭感觉关

源站前面如果有WAF、高防、LB，回源失败要看这些设备的拦截日志。不要一看到失败就直接关闭防护，也不要完全相信“没有拦截”的概览页。

要按CDN回源IP、URL、User-Agent、Host、状态码去查。很多WAF规则会对特定路径、特定参数、异常Header触发拦截。CDN回源时可能会带X-Forwarded-For、Via、X-Real-IP等Header，源站安全策略如果写得太死，也会误伤。

DDoS清洗场景里还会出现源站被限速。比如清洗设备认为某些CDN节点访问频率异常，把它们压低速率，表现就是部分节点回源慢、超时、失败率升高。

用源站日志反推CDN问题，比盯控制台更快

CDN控制台看到的是边缘视角，源站日志看到的是源站视角。两边对起来，问题会清楚很多。

可以把CDN请求ID、X-Forwarded-For、回源IP、Host、URI、状态码、request_time、upstream_response_time打进日志。没有这些字段，排查只能靠猜。

Nginx日志里建议至少保留：

$remote_addr $host $request $status $body_bytes_sent $request_time $upstream_response_time $http_x_forwarded_for $http_user_agent

如果CDN侧说回源504，但源站日志完全没有对应请求，问题在到达源站之前。源站有请求且request_time很长，要查源站处理。源站很快返回502，那就继续看Nginx到后端应用。源站返回200，但CDN记录失败，就要查连接中断、响应头异常、内容长度不匹配、分块传输问题。

换CDN服务商之前，至少做一次对照测试

不要直接全量切。可以拿一个测试域名或灰度域名，接同一个源站，对比不同CDN的回源表现。注意测试时要保证回源Host、协议、端口、缓存规则、证书校验策略尽量一致，否则对比没有意义。

对照时看这些数据：命中率、回源状态码分布、平均回源耗时、P95/P99回源耗时、不同区域失败率、不同文件类型失败率。

如果A CDN失败率高，B CDN正常，再看失败集中在哪些区域和错误类型。是A的节点到源站链路差，还是A的回源IP被源站拦了，还是A默认开启了严格证书校验，还是A没有按预期传Host。原因不同，处理方式完全不同。

源站选型会直接影响CDN回源质量

CDN不是万能缓冲层。动态接口、低命中资源、首个请求、大文件冷资源、缓存刷新后的请求，都要回源。源站线路差、带宽小、防护弱、跨网绕路严重，CDN也救不了全部请求。

如果业务用户主要在大陆，源站放香港或海外，要重点看回国线路。普通国际BGP在晚高峰可能抖动，CN2、GIA、CMI、CU这类线路组合通常更适合对延迟和稳定性敏感的业务。美国精品大宽带-A型这种1Gbps峰值产品，更适合大文件分发、海外业务、下载站冷源承载，但要注意500GB流量包是否匹配业务峰值。

在购买源站机器时，不要只看CPU和内存。CDN回源场景更要看带宽峰值、流量包、线路类型、防御能力、机房位置、是否支持快速扩容。129云的产品线里有香港精品CN2-C型、香港综合-D型、美国精品大宽带-A型，也有G口大带宽服务器和高防服务器，适合按业务访问区域和防护要求来搭源站。

线上处理时的排查节奏

故障正在发生时，不建议一边改CDN、一边改源站、一边改DNS。动作太多，后面很难判断到底是哪一步起作用。

可以按这个节奏走：先确认失败类型和影响范围；再看最近变更；接着看源站健康、带宽、连接数；然后查安全组、防火墙、WAF、回源IP；再查Host、协议、端口、TLS；之后看缓存命中率和DNS；需要时做跨区域链路测试。

如果已经确认源站带宽打满，临时动作可以是提高缓存TTL、关闭不必要的刷新、对大文件开启Range缓存、临时扩源站带宽、增加源站节点、把动态和静态资源拆开。不要在源站已经满负载的时候继续全量刷新缓存，这相当于把所有冷请求一次性打回源站。

如果确认是某个CDN区域回源链路异常，可以临时调整回源线路、切换备用源站、开启多源站权重、对问题区域做调度规避。这个动作要有监控跟着看，不要凭感觉切完就放着。

最容易误判的场景

本地访问源站正常，所以源站没问题

本地访问正常只能说明你所在网络到源站正常，不代表CDN节点到源站正常。CDN回源路径、源站防火墙策略、运营商链路都可能不同。

源站CPU低，所以源站没问题

CPU低不代表连接数够，不代表带宽没满，不代表磁盘IO正常，也不代表后端数据库快。很多回源失败发生时，CPU确实不高。

换了CDN后好了，所以原CDN一定有问题

可能是新CDN的回源IP没有被拦，可能是新CDN默认回源超时更长，可能是新CDN没有严格校验证书，也可能是测试时流量还没完全切过去。要看数据，不要只看现象。

HTTPS能打开，所以证书没问题

浏览器能打开的是客户端到CDN，或者本地到源站，不代表CDN到源站的SNI和证书链没问题。HTTPS链路要分段看。

排查时保留证据，后面才好复盘配置

每次处理回源失败，建议保留当时的CDN错误日志、源站access.log、error.log、系统指标、带宽图、连接数、DNS解析结果、traceroute或mtr结果、WAF拦截日志。不是为了写报告好看，是为了下次同类问题能更快定位。

尤其是缓存命中率、回源耗时P95/P99、源站带宽峰值，这些数据平时就要有基线。没有基线，故障时看到80ms不知道高不高，看到5000连接不知道多不多，只能靠经验猜。

CDN回源失败率高，先把错误类型、源站承载、回源配置、安全策略、线路质量查清楚。需要换服务商或换源站线路时，再带着明确原因去换，避免把同一个问题搬到下一家继续发生。