CDN回源用HTTP还是HTTPS有什么区别

CDN访问链路可以拆成两段：用户到CDN节点，CDN节点到源站。平时大家更关注用户侧是不是HTTPS，证书有没有配对，浏览器有没有小锁。但实际排障时，经常出问题的是第二段，也就是CDN回源。

CDN回源用HTTP还是HTTPS，本质区别不只是“加不加密”。它会影响源站安全、回源耗时、证书校验、Host配置、302跳转、缓存命中、WAF识别，甚至会影响一次故障到底是CDN的问题，还是源站的问题。

先把链路说清楚

假设用户访问 https://www.example.com/a.jpg，链路通常是这样：

用户浏览器 → CDN边缘节点 → 源站服务器

用户到CDN这一段如果是HTTPS，浏览器看到的是CDN上配置的证书。CDN到源站这一段，如果选择HTTP，那就是明文回源；如果选择HTTPS，那CDN会和源站再建立一次TLS连接。

所以会出现一种常见配置：用户访问HTTPS，但CDN回源是HTTP。浏览器仍然显示HTTPS，因为浏览器只跟CDN节点建立了HTTPS连接。源站这段是不是HTTPS，用户侧看不到。

HTTP回源的特点

性能和配置更简单

HTTP回源最大的特点是简单。源站只要监听80端口，CDN按Host回源即可，不需要源站证书，不涉及证书链，也不涉及SNI。很多静态资源站、图片站、下载站早期都是这么配的。

从性能上看，HTTP少了TLS握手。一次新连接少了大约1到2个RTT的协商过程。实际使用中发现，如果CDN节点和源站在同一个区域，比如华东CDN节点回上海源站，RTT可能只有5ms到15ms，这点差异不明显；如果海外CDN节点回国内源站，RTT到150ms以上，TLS握手成本就会被放大。

当然，现代CDN一般会做回源长连接复用，HTTP/1.1 keep-alive或者HTTP/2回源都能减少重复建连。不是每个请求都重新握手，所以不能简单说HTTPS回源一定慢很多。

安全边界更依赖网络环境

HTTP回源是明文。请求URL、Header、Cookie、Authorization这类内容，在CDN到源站链路上没有加密保护。如果源站和CDN之间走公网，这个风险要认真看。

有些业务觉得“源站IP只有CDN知道”，所以HTTP回源也没问题。这个判断在纯静态资源上还能接受，但如果回源请求里带用户态Cookie、Token、订单接口参数，就不建议这样做。

这里补充一点，CDN回源通常不是一条固定专线。很多情况下是CDN节点通过公网访问源站公网IP。中间经过运营商网络、BGP路由、跨境线路时，链路不可控程度比内网访问高。只要业务里有登录态、支付态、后台接口，HTTPS回源会稳妥很多。

源站压力小一点，但差距别想太大

HTTP回源少了TLS解密，源站CPU压力会低一些。以前RSA握手占用比较明显，现在大部分都用ECDHE、AES-GCM、TLS 1.3，差距已经不像老环境那么夸张。

实际压测里，Nginx开HTTPS后CPU上升是能看到的，但是否构成瓶颈取决于并发连接数、证书算法、会话复用、是否有硬件AES-NI、是否大量短连接。静态小文件高QPS场景更敏感，大文件下载反而主要吃带宽和磁盘。

HTTPS回源的特点

CDN到源站链路加密

HTTPS回源的核心价值就是CDN节点到源站之间也加密。用户到CDN是HTTPS，CDN到源站也是HTTPS，这才是完整的端到端加密链路，虽然中间CDN仍然会解密并处理请求。

对业务来说，HTTPS回源更适合这些场景：

登录、注册、会员中心、订单、支付、API接口、后台管理、带Cookie的动态页面、带Authorization Header的接口、医疗金融类业务、对合规要求比较严格的企业站。

这些场景里，回源链路如果用HTTP，风险点不是理论上的，而是出了问题很难解释。尤其是第三方审计或者等保检查时，经常会问“源站通信是否加密”。

会多出证书和校验问题

HTTPS回源不只是源站开443端口。证书域名、证书链、中间证书、SNI、回源Host都要配对。

实际使用中发现，HTTPS回源故障里，证书问题占比很高。比如源站证书绑定的是 origin.example.com，但CDN回源Host用的是 www.example.com，CDN开启严格证书校验后就会失败。还有一种是源站证书没带完整中间证书链，浏览器访问可能正常，但CDN节点校验失败。

还有些源站用了自签证书。如果CDN支持“忽略证书校验”，可以临时跑起来，但这相当于只加密不验证身份。中间人风险没有完全解决，生产环境不建议长期这么用。

回源排障会多一层TLS诊断

HTTP回源排障通常看状态码、Host、源站端口、防火墙、源站日志。HTTPS回源还要加上TLS版本、Cipher Suite、证书过期、SNI、ALPN、OCSP、证书链。

比如CDN报502，源站日志没有请求。HTTP回源时多半是端口、防火墙、路由、源站进程问题。HTTPS回源时，还可能是TLS握手失败，连接在进入HTTP层之前就断了，源站access log当然看不到。

这类问题可以在源站上用 openssl s_client -connect 源站IP:443 -servername 回源域名 来测。看证书返回的是不是预期域名，证书链是否完整，TLS版本是否被CDN支持。

用户侧HTTPS不等于回源HTTPS

很多人以为网站已经开了HTTPS，CDN回源自然也是HTTPS。这个不一定。CDN控制台里通常会有独立配置，常见选项包括：

跟随协议：用户用HTTP访问，CDN用HTTP回源；用户用HTTPS访问，CDN用HTTPS回源。

固定HTTP回源：无论用户怎么访问，CDN都用HTTP访问源站。

固定HTTPS回源：无论用户怎么访问，CDN都用HTTPS访问源站。

强制跳转：用户HTTP访问时，CDN直接301/302到HTTPS。

这里比较容易踩坑的是“跟随协议”。如果站点同时允许HTTP和HTTPS访问，用户用HTTP进来，CDN就可能HTTP回源。对于需要全站加密的业务，通常会在CDN边缘做HTTP到HTTPS跳转，并固定HTTPS回源。

回源协议和缓存命中有什么关系

正常情况下，缓存命中主要看URL、Query String、Header、Cookie、缓存规则、源站Cache-Control。回源协议本身不是决定缓存命中的核心因素。

但实际配置里，HTTP和HTTPS经常会间接影响缓存。

比如源站对HTTP请求返回301跳转到HTTPS，CDN却配置HTTP回源。结果CDN每次回源都拿到301，缓存规则没配好时，用户访问静态资源也可能拿到跳转，或者出现循环跳转。

再比如源站根据 X-Forwarded-Proto 判断当前请求协议。如果CDN回源HTTP，但没有传正确的 X-Forwarded-Proto: https，源站应用会以为用户是HTTP访问，于是生成HTTP链接、跳转HTTP页面，混合内容问题就来了。

还有一种比较隐蔽：同一个URL，源站对HTTP和HTTPS返回不同内容。CDN如果缓存Key里没有区分协议，就可能出现内容串扰。规范做法是源站不要对同一资源按协议返回不同内容，或者在CDN缓存Key里明确区分。

HTTP回源和HTTPS回源的差异对比

从工程排障角度看，可以按下面这些维度判断：

安全性：HTTP回源是明文，HTTPS回源是加密。只要涉及用户敏感数据，HTTPS回源优先。

配置复杂度：HTTP简单，开80端口即可；HTTPS需要证书、SNI、证书链、TLS策略都正确。

性能开销：HTTP开销低；HTTPS会多TLS握手和加解密，但长连接、TLS 1.3、会话复用后影响可控。

排障难度：HTTP主要查网络和应用；HTTPS还要查TLS握手、证书校验、协议兼容。

兼容性：HTTP对老源站友好；HTTPS要求源站Web Server配置规范，老系统可能需要升级OpenSSL或Nginx。

合规性：HTTP回源在安全审计里容易被问到；HTTPS回源更容易通过企业安全要求。

性能差多少，别只看理论

HTTPS回源的性能差异主要来自两块：TLS握手和数据加解密。

如果是短连接，每个请求都新建TCP和TLS，HTTPS回源会明显慢。跨区域回源时，1个RTT是几十到几百毫秒，TLS握手多出来的时间很容易被用户感知。

但CDN和源站之间通常会复用连接。源站 keepalive 配得合理时，HTTPS回源只在连接建立时多一次成本，后续请求复用同一个连接，差距会缩小很多。

一个常见经验值：同城或同省回源，HTTP和HTTPS的平均回源耗时可能只差几毫秒；跨境回源，如果没有长连接复用，HTTPS新建连接可能多出100ms到300ms；如果长连接稳定，差异会降到比较低。

多说一句，真正拖慢回源的，经常不是HTTPS本身，而是源站距离太远、跨境线路抖动、源站带宽打满、磁盘IO慢、后端应用响应慢。HTTPS只是被排障时看起来更显眼。

源站证书怎么配更稳

HTTPS回源建议源站使用可信CA签发的证书，域名和回源Host保持一致。比如CDN回源Host是 origin.example.com，源站证书就要包含 origin.example.com。

如果CDN回源到IP，但Host仍然是业务域名，那么证书看的是Host，不是IP。除非证书里包含IP SAN，但实际很少这么做。

证书链要完整。Nginx里不要只配置站点证书，要配置 fullchain.pem。很多CDN节点不像浏览器那样会自动补齐中间证书，链不完整就可能握手失败。

TLS版本也要注意。建议至少支持TLS 1.2，能支持TLS 1.3更好。TLS 1.0和TLS 1.1现在很多平台已经默认禁用。Cipher Suite不要配得太偏，过度追求“高安全”反而可能导致CDN节点无法握手。

回源Host和SNI经常被混在一起

回源Host是HTTP层的Host Header，SNI是TLS握手阶段告诉源站“我要访问哪个域名”。它们可以相同，也可以不同，但生产环境里建议保持一致，减少不必要的问题。

一个典型场景：源站Nginx有多个HTTPS站点，共用同一个443端口。CDN发起HTTPS回源时，如果SNI没带对，Nginx会返回默认证书。CDN严格校验时发现证书域名不匹配，于是回源失败。

有些CDN控制台会单独配置“回源Host”和“回源SNI”。如果只改了Host，没改SNI，问题就会很难看出来。源站access log里可能没有记录，因为TLS阶段已经失败了。

哪些场景可以用HTTP回源

HTTP回源不是不能用。纯静态资源、公开图片、公开JS/CSS、下载文件、没有Cookie和Token的内容，如果源站和CDN之间链路风险可接受，HTTP回源可以降低配置复杂度。

例如一个图片站，用户上传后的图片已经做了公开化处理，URL里不带敏感参数，CDN主要缓存图片，源站只是对象存储或者静态Nginx。这种场景HTTP回源问题不大。

还有些内网回源或专线回源场景，CDN节点和源站之间不是公网链路，而是云厂商内部网络或专线互联。此时HTTP回源的风险会小一些。不过安全审计严格的业务，仍然会要求HTTPS。

哪些场景建议固定HTTPS回源

动态站点建议直接HTTPS回源。尤其是登录态、管理后台、用户中心、接口服务、订单系统、支付回调、SaaS控制台，这些都不要纠结HTTP省下的那点开销。

如果业务有WAF、Bot防护、API Gateway，HTTPS回源也更容易保持协议一致性。源站应用通过 X-Forwarded-Proto、X-Forwarded-For、X-Real-IP 做判断时，链路更清晰。

企业站虽然看起来只是展示页面，但如果有表单提交、在线咨询、简历上传、询盘系统，也建议HTTPS回源。实际使用中发现，很多企业站被扫到的入口不是首页，而是这些表单接口。

CDN回源到海外服务器时要特别看链路

如果源站在美国、新加坡、香港等海外机房，国内CDN回源会经过跨境网络。此时HTTP和HTTPS的差异会被线路质量放大。

跨境RTT常见在120ms到250ms之间，普通线路高峰期抖动更明显。HTTPS新建连接的握手时间更容易暴露出来。如果业务必须海外源站，建议关注BGP质量、CN2、GIA、回国优化线路，以及源站带宽是否够用。

如果你也在找这种海外源站、G口大带宽或者高防服务器，可以看看129云。比如美国精品大宽带-C型有1Gbps峰值带宽、三网精品线路、基础防御，适合做海外业务源站、下载分发源站、跨境访问入口。需要西北地区电信线路和防御能力的业务，也可以看西安电信-C型，单机100Gbps防御更适合容易被DDoS打的站点。方案沟通可以直接打400-9177118。

回源协议配置容易踩的坑

源站强制HTTPS，但CDN配置HTTP回源

源站Nginx里写了80端口301到https://$host$request_uri，CDN却用HTTP回源。结果CDN拿到301后再返回给用户，用户可能还能访问，但多一次跳转，动态接口还可能出问题。

更麻烦的是，某些应用会根据协议拼接绝对地址。CDN HTTP回源时，应用以为当前请求是HTTP，返回Location: http://www.example.com/login。用户侧本来是HTTPS，结果被带回HTTP，再被CDN跳HTTPS，形成来回跳。

CDN固定HTTPS回源，但源站443没放行

这个很常见。源站安全组只开了80，或者防火墙只允许部分IP访问443。CDN切到HTTPS回源后直接502。看源站access log没有请求，容易误判成CDN缓存问题。

排查时要从CDN节点IP段、源站安全组、iptables、Nginx监听端口一起看。不能只在服务器本机 curl https://127.0.0.1 成功就认为没问题。

证书过期后，用户侧证书正常，回源却失败

用户侧证书配置在CDN上，源站证书配置在源站上。两套证书可能不是同一张。CDN证书没过期，不代表源站证书没过期。

HTTPS回源开启严格校验时，源站证书过期会直接导致回源失败。这个故障很典型：浏览器看CDN证书是正常的，但CDN日志里出现SSL handshake failed、certificate expired、upstream SSL error。

源站只支持老TLS版本

一些老系统还在用很旧的OpenSSL，只支持TLS 1.0或者一些弱Cipher。CDN节点安全策略升级后，突然不再支持这些算法，HTTPS回源就失败。

这种问题不是改CDN缓存能解决的，要升级源站OpenSSL、Nginx、Apache，或者调整TLS配置。生产环境不要长期依赖老协议。

源站真实IP保护和回源协议不是一回事

有些人把“HTTPS回源”和“隐藏源站IP”混在一起。HTTPS回源负责加密链路，不负责隐藏源站。源站IP是否暴露，要看DNS历史记录、证书透明日志、应用泄露、邮件头、接口返回、扫描记录。

如果源站IP已经暴露，攻击者可以绕过CDN直接打源站。此时HTTPS回源也挡不住DDoS或CC直接打源站IP。源站侧要做安全组白名单，只允许CDN回源IP访问80/443，管理端口放到VPN或堡垒机后面。

高防场景里，还要考虑源站本身的防御能力。比如游戏、活动页、API入口被打时，CDN能挡一部分HTTP层攻击，但源站IP暴露后仍然需要高防服务器或高防IP承接。

实际配置时可以这样判断

静态公开资源，源站离CDN很近，链路可控，源站证书维护成本比较高，可以考虑HTTP回源。但要确认不会返回敏感Header，不会带用户Cookie，不会被源站强制跳转影响缓存。

动态业务、登录态业务、API接口、后台系统、表单提交，直接配置HTTPS回源。证书用可信CA，回源Host和SNI统一，CDN开启证书校验，不要长期忽略证书错误。

跨境源站要额外关注长连接和线路质量。CDN到源站如果频繁新建连接，HTTPS握手成本会很明显。源站Nginx可以适当调高 keepalive、worker_connections、ssl_session_cache，并确认CDN侧支持回源连接复用。

如果源站承载大文件下载，HTTPS加解密不是唯一压力点。更关键的是上行带宽、磁盘吞吐、TCP拥塞、跨网质量。大文件源站建议直接上大带宽机器，1Gbps峰值比100Mbps在高峰期差异非常明显。

排障时看哪些日志

CDN侧看回源状态码、回源耗时、回源IP、回源协议、SSL错误、命中状态。源站侧看access log、error log、Nginx SSL日志、防火墙日志、安全组命中情况。

HTTP回源失败，重点看CDN能不能连到源站80端口，Host是否正确，源站是否返回了301/403/404/5xx。

HTTPS回源失败，除了上面这些，还要看TLS握手。可以从一台外部机器模拟CDN回源：

curl -v --resolve www.example.com:443:源站IP https://www.example.com/

这条命令能同时测试源站IP、HTTPS、Host、证书匹配。再用 openssl s_client 看证书链和SNI。如果这里都不通，CDN侧大概率也不会通。

关于回源协议的一个常见选择

全站HTTPS访问，CDN边缘强制HTTP跳HTTPS，CDN固定HTTPS回源，源站80只做跳转或直接不开放公网访问，443只允许CDN回源IP访问。这种配置在企业站、API站、会员系统里比较稳。

静态资源域名可以单独拆出来，比如 static.example.com，按资源属性决定HTTP或HTTPS回源。主站 www.example.com 和 api.example.com 不建议为了省事走HTTP回源。

源站如果用了多个域名，证书用SAN或通配符都可以，但不要让CDN回源Host、源站server_name、证书SAN三者对不上。这个问题一旦遇到，表现经常是部分节点正常、部分节点502，因为不同CDN节点的TLS策略和缓存连接状态不完全一致。

源站机器配置也会影响HTTPS回源体验

HTTPS回源打开后，源站CPU和连接数会比HTTP更敏感。小规格云服务器在低并发时看不出来，高峰一上来，TLS握手、Nginx worker、内核连接队列都会被放大。

如果是图片站、下载站、海外业务源站，CPU不一定要特别高，但带宽和线路要稳。如果是动态API，CPU、内存、数据库连接池、后端响应时间都要一起看。CDN只能减少命中缓存的请求，缓存不了的动态请求还是会打到源站。

选择源站时，不要只看价格。带宽是共享还是独享，是否只计上行流量，是否有基础防御，线路是普通BGP还是CN2/GIA优化，都会影响回源表现。像129云这类提供海外云服务器、G口大带宽服务器和高防服务器的服务商，比较适合在源站侧按业务拆分：静态下载走大带宽，易被攻击的入口走高防，普通企业站走稳定云服务器。

不要忽略源站访问控制

不管HTTP还是HTTPS回源，源站都应该限制只允许CDN回源IP访问。否则攻击者绕过CDN直接访问源站，CDN上的HTTPS、WAF、限速、防盗链都失效。

源站Nginx可以根据CDN提供的IP段做allow/deny，云服务器安全组也可以限制80和443来源。管理端口不要暴露公网，SSH改端口不是安全策略，最多只是减少扫描噪音。

如果CDN厂商的回源IP段会变化，要定期同步。否则某天CDN扩容节点，新节点回源被源站安全组拦掉，就会出现区域性访问失败。

缓存静态资源时的协议细节

静态资源建议源站返回明确的Cache-Control，比如 public, max-age=31536000, immutable。文件名带hash时可以长缓存，不带hash的HTML不要长缓存。

HTTP回源时，要留意源站是否对HTTP请求返回不同Header。比如HTTPS访问返回Cache-Control: public，HTTP访问返回no-cache，这会导致CDN缓存策略和预期不一致。

HTTPS回源时，源站证书更新不要只在主站测试，也要测试静态域名。很多站点主域名证书自动续签正常，static、img、api这些子域名被遗漏，CDN回源故障通常就发生在这些域名上。

一个比较贴近现场的配置样例

www.example.com：用户侧HTTPS，CDN强制HTTP跳HTTPS，CDN固定HTTPS回源，源站443监听，证书包含www.example.com，开启HSTS前先确认全站资源都支持HTTPS。

api.example.com：用户侧HTTPS，CDN固定HTTPS回源，不缓存动态接口，保留真实客户端IP Header，源站校验X-Forwarded-For时只信任CDN IP段。

static.example.com：用户侧HTTPS，CDN可以HTTPS回源，也可以在确认无敏感内容后HTTP回源。缓存时间按文件hash策略设置，避免源站频繁被打穿。

download.example.com：大文件下载建议重点看源站带宽。CDN命中率高时压力不大，缓存预热不足或文件更新频繁时，回源流量会很猛。源站如果只有30Mbps上行，高峰期很容易拖慢CDN回源。

什么时候切换回源协议

从HTTP切HTTPS前，先确认源站443端口可公网访问或可被CDN访问，证书域名匹配，证书链完整，源站不会因为HTTPS请求返回异常内容。

切换时不要直接全量改核心业务。可以先在测试域名或灰度域名上验证，再切一部分路径或业务域名。观察CDN回源5xx、回源耗时、源站CPU、Nginx error log。

如果切换后502增多，优先查SSL handshake failed、certificate verify failed、no shared cipher、SNI mismatch。不要一上来就怀疑源站应用代码。

从HTTPS切HTTP通常是为了临时止血，比如源站证书过期、TLS配置出错。但这只能作为短时间应急。涉及用户数据的业务，修复证书后应该切回HTTPS回源。

最后说一个容易被忽略的现象

CDN回源HTTPS后，源站日志里看到的协议仍然可能显示HTTP，因为很多应用框架读取的是本地反向代理传递的变量。比如CDN到Nginx是HTTPS，但Nginx再转发给后端应用是HTTP，应用如果不读取 X-Forwarded-Proto，就会误判。

Nginx反代后端时可以显式传递：

proxy_set_header X-Forwarded-Proto $scheme;

如果CDN已经传了 X-Forwarded-Proto，也要确认中间Nginx没有覆盖错。多层代理时，协议、真实IP、Host都要在每一层传清楚，不然后端生成链接、鉴权回调、OAuth跳转都会出怪问题。