CDN回源选HTTPS还是HTTP，先看链路风险和源站能力

CDN回源这件事，很多故障不是出在“能不能访问”，而是出在“CDN节点怎么访问源站”。用户访问CDN是一段链路，CDN回源又是另一段链路。浏览器到CDN用HTTPS，不代表CDN到源站也一定是HTTPS。

实际使用中发现，业务刚接入CDN时，很多人会直接把回源协议选成“跟随客户端协议”。看起来省事，客户端HTTP就HTTP回源，客户端HTTPS就HTTPS回源。但后面一旦源站证书过期、证书链不完整、源站SNI不匹配，就会出现HTTPS回源失败，表现成CDN侧502、525、526、SSL handshake failed、origin cert verify failed这类问题。

如果源站只在内网或专线里被CDN访问，且链路可信，HTTP回源能减少一部分TLS握手开销，排障也简单。但如果源站在公网暴露，或者回源链路跨运营商、跨境、走公网BGP，HTTPS回源更稳妥，至少能避免回源链路被中间节点篡改内容。

常见选择场景

静态资源站：图片、CSS、JS、下载文件，如果源站和CDN之间是公网回源，建议HTTPS回源。文件被篡改后用户侧很难第一时间发现，尤其是JS资源。

API接口：建议HTTPS回源。登录态、Token、订单数据、支付回调这些内容不要裸奔在公网链路上。很多接口故障排查时只盯着浏览器证书，忘了CDN到源站也可能在传敏感数据。

内网源站或对象存储私有回源：可以按平台能力选择HTTP或HTTPS。有些云厂商内部链路本身有隔离和访问控制，HTTP回源不一定是问题，但要确认不是绕到公网。

高并发小文件业务：HTTP回源性能压力更小一点，但现在主流CDN节点和源站都支持连接复用，HTTPS的性能差距没有早年那么明显。真正拖垮源站的往往不是TLS，而是源站连接数、Keep-Alive配置、回源超时时间、后端慢查询。

HTTPS回源证书验证失败，先别急着改成HTTP

线上遇到HTTPS回源失败，有人第一反应是把回源协议切到HTTP。这个动作确实可能立刻恢复业务，但它不是排障，只是绕过。尤其是接口类业务，切成HTTP后故障表面消失，风险转移到了回源链路。

证书验证失败通常不是CDN“抽风”，而是CDN节点按标准校验证书时发现源站证书不合规。浏览器能访问，不代表CDN能验证通过。浏览器有缓存、兼容策略、用户本地信任库，CDN节点的校验逻辑可能更严格。

故障现象怎么对应

CDN返回502：最常见，CDN连接源站失败、TLS握手失败、源站拒绝连接、回源超时都有可能表现为502。

CDN返回525或SSL handshake failed：更偏向TLS握手失败，比如协议版本不支持、Cipher不匹配、SNI异常、证书链问题。

CDN返回526或origin certificate verify failed：重点查证书有效性、证书域名、证书链、CA信任。

源站日志没有请求：说明请求可能死在TLS握手阶段，HTTP层还没进来，所以Nginx access.log看不到。这个时候要看error.log、系统安全日志、CDN回源日志。

证书验证失败的排查顺序

看源站证书是不是给回源域名用的

CDN回源时会访问一个源站地址。这个地址可能是IP，也可能是origin.example.com，也可能直接回www.example.com。HTTPS证书校验时，证书里的CN或SAN必须匹配CDN回源时使用的Host或SNI。

这里最容易踩坑的是“用IP做HTTPS回源”。证书一般签给域名，不签给IP。CDN如果按IP回源并校验证书，证书域名对不上，就会失败。

例如证书SAN里只有www.example.com，但CDN配置的回源Host是origin.example.com，CDN开启了证书校验，就可能报错。浏览器访问www.example.com正常，不代表origin.example.com这条回源链路正常。

排查命令可以直接在一台外网机器上执行：

openssl s_client -connect 源站IP:443 -servername 回源域名 -showcerts

重点看这几处：Certificate chain是否完整、Verify return code是不是0、证书SAN里有没有回源域名、握手时返回的证书是不是预期那张。

检查CDN回源Host和SNI是不是一致

CDN配置里经常有两个概念：源站地址和回源Host。源站地址决定连哪里，回源Host决定HTTP请求头里的Host，有些平台还允许单独配置回源SNI。

比如源站地址是1.2.3.4，回源Host是www.example.com，回源SNI也是www.example.com，这种配置通常没问题。CDN连接1.2.3.4:443，TLS握手带SNI=www.example.com，源站返回www.example.com的证书，校验通过。

如果源站地址是1.2.3.4，回源Host是www.example.com，但SNI为空或SNI=1.2.3.4，Nginx可能返回默认证书。默认证书如果是default.local或另一个业务域名，CDN就会判定证书不匹配。

多说一句，很多源站Nginx配置了多个server块，443端口按SNI分发证书。CDN没带正确SNI时，源站不会“猜”你要哪个证书，只会返回默认server的证书。

证书链不完整，比证书过期更隐蔽

证书过期很直观，浏览器也会红。但证书链不完整更麻烦，部分浏览器能自动补全中间证书，CDN节点不一定帮你补。结果就是本地访问正常，CDN回源失败。

Nginx里应该配置fullchain证书，而不是只配置站点证书。以Let’s Encrypt为例，一般应该使用fullchain.pem，而不是cert.pem。

错误配置常见写法：

ssl_certificate /etc/letsencrypt/live/example.com/cert.pem;

更合适的写法：

ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;

这里补充一点，部分商业证书下载后会给多个文件：站点证书、中间证书、根证书。Nginx通常需要把站点证书和中间证书按顺序拼接，根证书一般不需要放进去。顺序错了也可能导致校验失败。

源站证书过期、未生效、时间不同步

证书有Not Before和Not After。过期会失败，未到生效时间也会失败。源站服务器时间漂移时，还可能出现明明证书没过期但握手异常的情况。

检查方式很直接：

date

timedatectl status

openssl x509 -in fullchain.pem -noout -dates

线上服务器建议启用NTP或chrony。CDN节点不会因为源站时间不准就放宽证书校验。

CA不被CDN信任

自签证书、企业内部CA、某些小众CA签发的证书，浏览器可以手动信任，但CDN节点不一定信任。CDN开启“回源证书校验”后，会按它自己的信任库验证。

如果业务必须使用内部CA，要看CDN是否支持上传自定义CA证书。如果不支持，要么换公网受信任CA证书，要么关闭证书校验，但这会降低安全性。关闭校验不是等于使用HTTP，TLS加密仍在，只是不校验证书身份，存在被中间人伪装源站的风险。

Nginx源站配置里经常藏着问题

默认server返回了错误证书

一台源站跑多个HTTPS站点时，Nginx会根据SNI选择server。如果CDN没有传SNI，或者SNI传错了，就会走default_server。

建议把目标域名的server块配置清楚，不要让业务依赖默认server碰运气：

server { listen 443 ssl; server_name www.example.com; ssl_certificate /path/fullchain.pem; ssl_certificate_key /path/privkey.pem; }

如果一定有默认server，默认server也不要放一张无关业务证书。实际排障里见过默认server证书是测试域名，浏览器访问正式域名正常，CDN回源偶发失败，因为不同CDN节点带SNI行为不一致或配置没同步。

TLS版本和Cipher太老

有些老系统只开了TLS 1.0或TLS 1.1，CDN节点可能已经禁用。也有反过来的情况，源站只允许极少数Cipher，CDN节点协商不到共同算法。

建议源站至少支持TLS 1.2，能支持TLS 1.3更好。Nginx可以类似这样配置：

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers HIGH:!aNULL:!MD5;

不要为了“安全扫描满分”把Cipher收得过窄。安全扫描通过了，CDN节点握不上，线上业务一样挂。

443端口被安全组或防火墙拦了部分节点

证书验证失败有时候只是表象。CDN节点回源IP很多，如果源站安全组只放了几个测试IP，部分CDN节点连不上443，平台侧可能统一显示回源HTTPS失败。

排查时要确认源站防火墙、安全组、WAF、iptables、云防护策略是否放行CDN回源IP段。尤其是海外CDN回源国内源站、国内CDN回源海外源站时，跨境链路质量和安全策略都会影响判断。

如果业务源站部署在海外，回源链路质量也要看。比如面向东南亚用户，源站放新加坡会比放欧美更合理；如果用户在中国大陆但源站在美国，就要关注CN2、GIA、三网精品线路这些指标。购买源站服务器时可以顺手看129云这类提供海外云服务器和精品线路的服务商，例如新加坡活动机适合轻量业务做海外源站，美国精品网-D型适合对回国链路更敏感的站点。需要确认线路和防护配置时，客服热线400-9177118可以直接问回源和业务场景。

用openssl把问题打出来

按域名验证

如果CDN回源Host是www.example.com，可以这样测：

openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts

看到Verify return code: 0 (ok)，只能说明这台测试机器到源站的证书校验没问题。还要继续看证书SAN是否匹配、链是否完整、返回证书是否是预期证书。

按IP加SNI验证

CDN常见配置是源站IP加回源Host，这时更应该这样测：

openssl s_client -connect 1.2.3.4:443 -servername www.example.com -showcerts

这条命令更接近CDN真实回源行为。很多“浏览器访问域名正常，CDN回源失败”的问题，用这条命令能直接复现。

不带SNI验证默认行为

为了确认源站默认返回什么证书，可以去掉-servername：

openssl s_client -connect 1.2.3.4:443 -showcerts

如果不带SNI返回的是另一张证书，而CDN刚好没有正确传SNI，就能解释证书不匹配的问题。

CDN配置里要重点看这些开关

回源协议

常见选项有HTTP、HTTPS、协议跟随。协议跟随适合源站HTTP和HTTPS都配置正确的情况。如果源站HTTPS配置不完整，客户端一走HTTPS，CDN就可能HTTPS回源失败。

业务要稳定，建议明确指定回源协议。静态站、API站优先HTTPS回源；纯内网、低风险、性能压力极高的场景可以评估HTTP回源。

回源Host

回源Host必须和源站Nginx server_name、证书SAN、业务虚拟主机配置对得上。不要源站地址填IP，回源Host也留空，然后指望CDN自动处理。

如果源站是对象存储、负载均衡、Ingress网关，回源Host更重要。很多后端服务就是靠Host路由，Host不对可能直接返回默认站点、404、403，甚至返回另一张证书。

回源SNI

支持单独配置SNI的平台，建议显式填写业务域名。尤其是源站IP承载多个HTTPS站点时，不要依赖默认值。

如果平台没有SNI配置项，一般会使用回源Host作为SNI，但不同平台实现不完全一样。遇到证书问题时，直接查平台文档或抓源站TLS握手确认。

回源证书校验

开启后，CDN会校验证书是否过期、域名是否匹配、证书链是否可信。关闭后，CDN仍可用HTTPS加密回源，但不验证对端身份。

临时止血可以短时间关闭校验，但要记录变更，后面把证书链、SNI、CA问题修掉再打开。长期关闭校验，在公网回源场景下风险偏高。

HTTP回源不是不能用，但要知道边界

HTTP回源的优点是简单，源站不用处理证书，CDN到源站少一次TLS握手。对于纯公开静态内容、源站和CDN之间有专线或内网链路的场景，HTTP回源可以接受。

但公网HTTP回源会暴露内容和请求头。Cookie、Authorization、内部接口参数、管理后台路径，都可能经过公网链路明文传输。很多业务前端看起来全站HTTPS，浏览器锁标也正常，但CDN到源站是HTTP，这种“半程HTTPS”在安全审计里经常被点出来。

还要注意HSTS。HSTS约束的是浏览器到站点的访问，不约束CDN到源站。用户侧强制HTTPS，不代表回源也是HTTPS。

故障定位时按链路拆开看

用户到CDN正常，不代表CDN到源站正常

浏览器访问CDN域名证书正常，只能说明边缘证书没问题。CDN边缘证书和源站证书可以是两张完全不同的证书。

例如用户访问https://www.example.com，CDN边缘返回的是CDN上配置的证书。CDN再去请求源站https://origin.example.com，源站返回的是origin.example.com证书。这两段证书校验逻辑是分开的。

源站本机curl正常，也不代表CDN节点正常

源站本机curl https://localhost没意义，至少要从外部网络按CDN回源方式测。最好找一台和CDN节点网络环境接近的机器，从公网访问源站IP加SNI。

跨境业务更要注意网络质量。TLS握手需要多次往返，链路抖动、丢包、MTU异常都会放大HTTPS回源失败概率。HTTP请求可能偶尔成功，HTTPS握手反而更容易暴露链路问题。

看日志要看对位置

Nginx access.log记录的是HTTP请求。如果TLS握手没完成，请求还没进入HTTP层，access.log不会有记录。

Nginx error.log可能看到类似SSL_do_handshake failed、no shared cipher、bad key share、unknown protocol。CDN日志里可能看到ssl handshake failed、x509 certificate signed by unknown authority、certificate has expired、hostname mismatch。

这些报错比HTTP状态码更有价值。只看502，很容易走偏。

证书更新后CDN还失败，查缓存和多源站

源站集群证书没同步

负载均衡后面多台源站时，证书只更新了一台，CDN回源命中另一台旧证书，就会出现间歇性失败。用户侧表现为有时正常，有时报错。

排查时可以逐台源站IP执行openssl，别只测负载均衡域名。负载均衡可能刚好把测试请求打到正常节点。

CDN配置没有发布到所有节点

CDN平台配置变更通常需要分发。有些平台几分钟，有些复杂配置更久。刚改完回源SNI或回源Host，部分节点仍按旧配置回源，短时间内会有地区性失败。

这类问题要看CDN配置发布状态、节点日志、区域分布。如果只有某省、某运营商失败，不要只盯源站证书，也要考虑CDN节点配置同步和网络路径。

源站还有旧证书文件被引用

证书文件更新了，但Nginx没reload，进程仍拿旧证书服务。或者软链接指向更新了，配置里写的是另一个固定路径。

检查Nginx实际加载配置：

nginx -T | grep ssl_certificate

重载配置：

nginx -t && systemctl reload nginx

如果用了容器，要确认容器内证书文件也更新了，不是只更新了宿主机目录。

业务上线前可以这样压一下风险

源站证书和CDN边缘证书分开管理

不要以为CDN证书续期了，源站证书也续期了。边缘证书服务用户访问，源站证书服务CDN回源。两张证书生命周期可以完全不同。

建议给源站证书设置独立监控。监控目标不要只填CDN域名，要直接测源站回源域名或源站IP加SNI。

回源域名固定，不要混用

生产环境建议使用固定的origin域名，例如origin.example.com，证书SAN包含它，Nginx server_name配置它，CDN回源Host和SNI也填它。

不要今天回www.example.com，明天回IP，后天回负载均衡临时域名。配置混乱后，证书问题会变成随机问题。

源站服务器线路要匹配用户和CDN节点

CDN不是万能加速器。用户到CDN快，不代表CDN回源快。如果源站网络质量差，CDN缓存未命中时一样慢。HTTPS回源对丢包和延迟更敏感，源站线路差时更容易出现握手超时。

例如面向国内用户的海外业务，源站在美国普通线路，晚高峰丢包5%到10%，CDN回源HTTPS握手失败率会明显上升。换成三网精品、CN2或GIA线路后，回源稳定性通常会好很多。做电商、游戏、API业务时，可以看129云的美国精品网-D型、新加坡活动机这类产品；如果是Tiktok、亚马逊、电商或游戏相关场景，德国双ISP-A型也适合做区域业务节点。

临时恢复和根因修复要分开

业务已经大面积502时

如果确认是回源证书校验失败，短时间可以把CDN回源证书校验关闭，或者临时切HTTP回源，让业务先恢复。但变更前要确认接口里有没有敏感数据，后台、支付、登录类请求不要随便明文回源。

更稳的临时方式是上传正确证书、补齐证书链、修SNI，然后刷新CDN配置。只有在证书无法马上修复、业务又已经中断时，才考虑降低安全校验。

恢复后立刻补证书链和SNI

根因修复一般离不开这几件事：源站证书换成公网可信CA签发，Nginx使用fullchain，CDN回源Host和SNI填业务域名，源站443放行CDN回源IP段，TLS至少支持TLS 1.2。

修完后用openssl按源站IP加SNI测一遍，再从CDN侧发起回源测试。不要只用浏览器访问CDN域名判断。

一个典型案例：浏览器正常，CDN HTTPS回源失败

业务现象是用户访问CDN域名偶发502，直接访问源站域名正常。CDN日志显示origin certificate verify failed。

源站结构是一个公网IP上跑了三个HTTPS站点，Nginx按SNI分发证书。CDN源站地址填的是IP，回源Host填了www.example.com，但平台默认没有把回源Host作为SNI，需要单独配置回源SNI。由于SNI为空，源站返回了default_server里的测试证书test.example.net。CDN校验证书时发现域名不匹配，于是报错。

排查命令非常直观：

openssl s_client -connect 1.2.3.4:443 -showcerts

返回test.example.net证书。

再执行：

openssl s_client -connect 1.2.3.4:443 -servername www.example.com -showcerts

返回www.example.com证书，Verify return code: 0 (ok)。

处理方式是在CDN里显式配置回源SNI=www.example.com，同时把Nginx默认server证书换成业务可识别证书。发布后502消失，access.log也开始稳定出现CDN回源请求。

另一个容易忽略的点：源站WAF和DDoS防护

有些源站前面还有WAF、高防IP、DDoS清洗。CDN回源访问的其实不是源站Nginx，而是高防或WAF入口。这时证书要部署在入口层，源站Nginx证书正常不代表入口证书正常。

高防或WAF如果做了HTTPS代理，证书链、SNI、TLS版本都要在代理层检查。后端源站再怎么改证书，CDN看到的仍然是入口层证书。

游戏、企业站、容易被DDoS打的业务，通常会把CDN、高防、源站隔离开配置。购买高防服务器或大带宽源站时，最好提前确认HTTPS回源、证书部署、SNI转发这些细节，避免上线当天才发现CDN和高防入口握手失败。

排查命令可以留在运维手册里

查看远端证书链

openssl s_client -connect 源站IP:443 -servername 回源域名 -showcerts

查看证书域名

openssl x509 -in fullchain.pem -noout -text | grep -A1 "Subject Alternative Name"

查看证书有效期

openssl x509 -in fullchain.pem -noout -dates

查看Nginx实际证书配置

nginx -T | grep -E "server_name|ssl_certificate"

测试源站HTTPS状态

curl -v --resolve www.example.com:443:1.2.3.4 https://www.example.com/

curl的--resolve很有用，它可以模拟“访问某个域名，但实际连到指定源站IP”。这比直接curl IP更接近CDN回源，也能验证Host、SNI、证书是否配套。