CDN回源协议选HTTP还是HTTPS，源站证书到底要不要配

CDN配置里经常会看到两个协议相关的选项：客户端访问CDN用什么协议，CDN回源用什么协议。很多证书问题其实不是出在用户访问CDN这一段，而是出在CDN节点到源站这一段。

简单拆一下链路：用户浏览器 → CDN边缘节点 → 源站服务器。用户到CDN这一段如果开HTTPS，证书通常配置在CDN平台上；CDN到源站这一段如果也走HTTPS，源站就必须具备能被CDN节点正常校验的HTTPS能力。

所以问题不是“网站用了CDN还要不要源站证书”，而是看回源协议怎么选。

回源走HTTP时，源站证书不是必需项

如果CDN配置的是HTTP回源，CDN节点访问源站时用的是http://origin:80。这种情况下，CDN不会和源站建立TLS连接，也就不会校验证书。源站有没有SSL证书，对这条回源链路本身没有影响。

实际使用中发现，很多业务前端对外是HTTPS，但回源仍然走HTTP。用户看到的是HTTPS小锁，因为浏览器连接的是CDN，CDN上有证书；但CDN回源时走的是明文HTTP。

这种配置的好处是简单，源站不用处理TLS，证书续期压力小，排障也直观。尤其是一些内网源、对象存储源、只允许CDN节点访问的源站，HTTP回源很常见。

但这里有个前提：CDN节点到源站之间的链路是否可信。如果源站部署在公网云服务器上，CDN节点跨运营商、跨地域回源，中间链路不是业务方完全可控的。对登录态、支付回调、用户资料、API Token这类数据，HTTP回源会留下明文传输风险。

回源走HTTPS时，源站证书必须能被CDN接受

如果CDN配置HTTPS回源，CDN节点访问源站时会使用https://origin:443。这时源站必须提供SSL/TLS证书，并且证书配置要符合CDN的校验规则。

常见要求包括：证书未过期，证书链完整，证书由可信CA签发，证书中的CN或SAN能匹配回源域名，源站支持CDN节点使用的TLS版本和Cipher Suite。

这里最容易踩的是“证书域名不匹配”。比如CDN回源地址填的是origin.example.com，但源站证书只签了www.example.com。浏览器访问www没问题，CDN回源到origin时就可能报SSL握手失败、证书校验失败、502、525、526之类的错误。

不同CDN平台报错名字不一样，但本质差不多：CDN节点想和源站建立HTTPS连接，源站返回的证书不符合预期。

用IP回源时，HTTPS证书更容易出问题

HTTP回源填IP一般没什么问题，比如回源地址写1.2.3.4，Host头写www.example.com，源站Nginx按Host匹配站点。

HTTPS回源填IP就麻烦一些。TLS握手阶段会涉及SNI，CDN节点需要告诉源站“我要访问哪个域名”。如果CDN只按IP去连源站，没有正确传SNI，源站可能返回默认证书；如果默认证书不是业务域名，CDN校验就会失败。

实际排障里经常看到这种配置：源站IP是美国机器，Nginx上挂了多个站点，CDN回源地址填IP，回源Host写www.example.com，但SNI没有跟着Host走。结果源站返回了default_server的证书，CDN直接报错。

更稳的做法是用域名做HTTPS回源，比如origin.example.com解析到源站IP，源站证书覆盖origin.example.com，CDN回源Host按业务需要配置。部分CDN允许单独配置“回源SNI”，这时要确认SNI、回源Host、证书SAN之间的关系。

源站证书要不要和CDN上的证书一样

不一定。

CDN对外证书是给用户浏览器看的，源站证书是给CDN节点看的。两张证书可以一样，也可以不一样。只要各自覆盖对应的访问域名即可。

例如用户访问www.example.com，CDN上配置www.example.com证书。CDN回源访问origin.example.com，源站配置origin.example.com证书。这是很常见的隔离方式。

也可以CDN和源站都使用*.example.com泛域名证书，运维上简单一些。但泛域名证书权限更大，泄露后的影响面也更大，尤其是多团队共用证书时要谨慎。

自签名证书能不能用于HTTPS回源

要看CDN是否允许关闭源站证书校验，或者是否支持上传自定义CA。

有些CDN提供类似“严格校验”和“非严格校验”的开关。严格校验时，自签名证书一般过不了；非严格校验时，CDN可能只加密传输，不验证源站身份。这样确实能跑通，但安全意义打了折扣。

更好的方式是使用可信CA签发的证书。现在DV证书成本已经很低，Let’s Encrypt这类免费证书也可以满足大部分回源需求。关键是自动续期要做好，不要让CDN在凌晨突然开始大量502。

如果是企业内部高安全场景，可以使用私有CA，但要确认CDN支持导入CA根证书或支持源站证书白名单校验。不是所有公有CDN都支持这种玩法。

HTTP回源和HTTPS回源的差异放到场景里看

静态图片、CSS、JS这类资源，如果源站只允许CDN节点访问，并且源站与CDN之间在同一云厂商内网或专线环境里，HTTP回源通常够用。缓存命中率高时，回源请求本来就少，HTTPS带来的安全收益和运维复杂度需要权衡。

登录接口、订单接口、后台API、带Cookie的动态页面，建议HTTPS回源。哪怕用户到CDN已经是HTTPS，CDN到源站这段如果明文传输，敏感字段仍然会暴露在回源链路上。

海外源站更要关注这个问题。比如中国大陆用户访问香港、新加坡、美国源站，中间经由CDN加速后，用户到边缘节点很快，但边缘节点回源可能跨境。跨境链路上跑明文HTTP，不适合承载敏感业务。

从性能看，HTTPS回源会多TLS握手开销。TLS 1.2通常需要额外1到2个RTT，TLS 1.3一般是1个RTT，连接复用后影响会降低。假设CDN节点到美国源站RTT是150ms，冷连接HTTPS回源可能多出150ms以上的握手时间；但如果开启长连接、HTTP/2回源、连接池复用，实际影响会小很多。

缓存命中率也会改变感知。一个静态站点命中率95%，只有5%的请求回源，HTTPS回源的额外开销不明显。动态API命中率接近0，每次都回源，TLS握手、源站CPU、连接复用配置就会变得很重要。

源站证书配置里最常见的坑

证书链不完整是高频问题。浏览器可能因为本地缓存了中间证书，看起来访问正常；CDN节点环境更干净，缺少中间证书时就会校验失败。Nginx里应该配置fullchain.pem，而不是只放站点证书。

证书过期也很常见。源站如果平时不对用户开放，业务团队容易只盯CDN证书，忽略源站证书。等证书过期后，CDN回源HTTPS失败，前台直接502。

TLS版本过低也会出问题。有些老系统只支持TLS 1.0或TLS 1.1，部分CDN节点默认不再支持。反过来，源站只开了非常新的Cipher Suite，老一点的CDN回源集群也可能握手失败。生产环境建议至少支持TLS 1.2，能开TLS 1.3更好。

回源Host和证书SAN不一致也要重点看。CDN配置里经常有三个字段：回源地址、回源Host、回源协议。HTTPS场景下还要看SNI。不要只盯着DNS解析对不对，TLS阶段用的是另一个判断逻辑。

301跳转也会把回源协议搞乱

源站上常见配置是HTTP强制跳转HTTPS，比如访问http://origin会301到https://www.example.com。这在用户直连源站时没问题，但放到CDN回源里可能造成额外问题。

如果CDN配置HTTP回源，而源站强制跳HTTPS，CDN每次回源都会收到301。CDN如果跟随跳转，又可能回到CDN域名，形成绕路甚至循环。部分CDN不跟随跳转，用户就会直接拿到301，表现也不符合预期。

还有一种情况是CDN对外HTTPS，回源HTTP，源站应用通过X-Forwarded-Proto判断协议。如果这个头没传，应用以为用户是HTTP访问，于是生成HTTP链接或继续跳转HTTPS，页面里出现混合内容、跳转循环。

解决这类问题时，不要只改证书。要同时检查CDN是否传递X-Forwarded-Proto、源站应用是否信任代理头、Nginx是否根据CDN源IP段正确处理真实协议。

源站隐藏和证书校验不是一回事

很多业务上CDN后会把源站IP隐藏起来，只允许CDN回源IP访问。这个做法可以降低源站被直接打穿的风险，但它不能替代HTTPS回源。

访问控制解决的是“谁能访问源站”，HTTPS证书解决的是“访问的是不是预期源站，以及传输是不是加密”。两者不是同一个层面。

如果业务容易遭遇DDoS，源站本身也需要有防护能力。CDN抗住HTTP Flood是一部分，源站IP一旦暴露，L3/L4流量还是可能打到机器上。选择源站服务器时，建议把防御、线路、带宽峰值一起看。如果你也在找高防源站或海外精品线路，可以看看129云，像十堰高防-A型提供600Gbps单机防御，适合源站需要强抗打的企业业务；美国精品网-E型适合海外业务回源和三网访问优化，客服热线400-9177118可以直接问线路和防护细节。

不同配置下源站证书要求对照

客户端HTTPS，CDN回源HTTP：源站不要求HTTPS证书。证书配置在CDN上，源站可以只监听80端口。但敏感业务不建议这么跑。

客户端HTTPS，CDN回源HTTPS：源站必须有可用证书。证书要匹配回源域名或SNI，证书链完整，TLS配置正常。

客户端HTTP，CDN回源HTTPS：源站也需要证书。虽然用户侧不是HTTPS，但CDN到源站走了TLS，源站仍然要完成证书握手。

客户端HTTP，CDN回源HTTP：源站不需要证书。这是最简单的链路，但安全性最低，适合非敏感、临时、内网隔离比较强的资源。

IP回源加HTTPS：源站证书通常不能只签业务域名后就完事，要确认CDN是否支持SNI配置。更建议使用origin域名回源。

自签名证书加HTTPS回源：能不能用取决于CDN策略。严格校验下大概率失败，关闭校验后只能保证加密，不能可靠验证源站身份。

排查HTTPS回源失败时的顺序

先在一台外部机器上用curl验证源站证书，例如curl -v https://origin.example.com，看证书链、过期时间、返回码是否正常。再用openssl s_client -connect origin.example.com:443 -servername origin.example.com 查看SNI下返回的证书是否正确。

如果CDN回源地址是IP，要特别测试SNI：openssl s_client -connect 1.2.3.4:443 -servername origin.example.com。很多问题在这里能直接暴露出来，返回的证书如果不是origin.example.com或*.example.com，就要改Nginx的server配置或CDN的SNI配置。

再看CDN回源Host。源站Nginx可能按Host分站点，如果CDN回源Host传错，会命中默认站点。默认站点证书不匹配，HTTPS握手失败；默认站点证书虽然匹配，但应用返回404，也会被误判成证书问题。

还要看源站防火墙和安全组。HTTPS回源需要CDN节点访问443端口，如果只放行了80端口，CDN侧可能显示连接超时，而不是明确的证书错误。高防场景下还要确认清洗设备没有拦截CDN回源IP。

证书续期要覆盖源站，不只覆盖CDN

不少团队会把CDN证书托管给平台自动续期，但源站证书还是手工签发。这样表面上看用户访问证书一直正常，实际上源站证书悄悄过期，HTTPS回源开始失败。

源站证书建议接入自动续期，并加监控。监控不要只监CDN域名，也要监origin域名。过期时间低于15天告警比较稳，低于7天再告警一次。证书链变化后，最好用CDN真实回源链路做一次探测，而不是只在源站本机curl。

如果源站不想暴露origin域名给公网，可以通过安全组只允许监控节点和CDN回源IP访问。证书校验仍然按域名做，访问控制按IP做，两个配置不要混在一起理解。

实际选择时的判断方式

纯静态资源、无敏感数据、源站和CDN之间链路相对可控，可以用HTTP回源，运维简单，问题少。

涉及账号、Cookie、订单、后台、API、跨境链路，直接用HTTPS回源。源站证书用可信CA签发，回源域名独立出来，SNI和Host配置清楚。

源站是多站点Nginx时，不建议HTTPS回源直接填IP。给源站单独准备origin.example.com，证书SAN覆盖它，DNS解析到源站IP，CDN回源地址填这个域名，后面迁移源站也方便。

源站需要高防时，证书只是HTTPS链路的一部分。服务器线路、防御峰值、带宽、CDN回源质量都要一起看。比如游戏、企业官网、活动页这类业务，源站被打挂后CDN缓存也撑不了动态请求，可以结合129云的高防服务器或美国精品线路做源站承载，再在CDN侧配置HTTPS回源和源IP访问控制。

配置完成后，用真实CDN域名访问一次动态接口，再看源站日志里的Host、X-Forwarded-Proto、SNI对应证书、状态码和回源IP。证书没问题但业务异常时，日志比控制台报错更快定位。