CDN回源用HTTPS还是HTTP，对服务器性能影响到底大不大

CDN回源协议这件事，实际项目里经常被问：用户到CDN已经是HTTPS了，那CDN到源站还要不要HTTPS？如果改成HTTP，源站性能是不是能省很多？

这个问题不能只看“HTTPS比HTTP多加密”这一句话。真实环境里，影响源站压力的不是单次请求有没有TLS，而是回源连接能不能复用、回源频率有多高、源站CPU是否紧张、CDN节点到源站的网络质量怎么样。

先把链路拆开看

访问一个接了CDN的网站，链路通常是这样：

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

用户到CDN这一段，大多数业务都会用HTTPS。证书部署在CDN上，浏览器看到的是CDN返回的证书，TLS握手也主要发生在用户和CDN之间。

CDN到源站这一段，就是“回源”。这里可以配置HTTP回源，也可以配置HTTPS回源。

HTTP回源：CDN用明文HTTP请求源站。

HTTPS回源：CDN和源站之间也建立TLS连接，源站需要部署证书，CDN校验证书或按配置跳过校验。

从安全上看，HTTPS回源肯定更稳，特别是源站在公网、跨区域、跨运营商、海外线路时，中间链路不可控。HTTP回源能省一些加密开销，但省出来多少，要看业务形态。

HTTPS回源的性能开销主要在哪里

TLS握手不是每个请求都来一次

很多人担心HTTPS回源，是把它理解成“每个请求都要重新握手、重新加密”。实际CDN回源一般会保持长连接，也就是Keep-Alive。只要源站、CDN配置没问题，一个TCP连接可以承载很多次HTTP请求。

如果是HTTP/1.1回源，CDN通常会复用连接，减少TCP握手和TLS握手次数。如果是HTTP/2回源，单连接多路复用，连接复用效果更明显。

真正耗CPU的是新建TLS连接时的非对称加密握手，尤其是RSA握手。现在常见的是ECDHE，配合TLS 1.3和Session Resumption，握手成本已经比早年低很多。

实际使用中发现，源站CPU被HTTPS回源打满的场景，往往不是“HTTPS本身太重”，而是连接复用没做好，比如：

CDN回源Keep-Alive关闭，导致每个请求都新建连接。

源站Nginx的keepalive_timeout太短，连接很快断开。

CDN节点很多，但每个节点和源站都频繁建立短连接。

源站有四层代理、七层代理、多级Nginx，链路中某一层没有复用连接。

加解密会占CPU，但现代CPU扛得住大多数业务

HTTPS回源的持续开销主要是对数据做对称加密和解密，比如AES-GCM、ChaCha20-Poly1305。现代CPU普遍有AES-NI指令集，HTTPS带来的CPU增加通常没想象中大。

拿常见Web业务做个参考，不是实验室极限值，是比较接近线上观察的量级：

静态小文件，命中CDN较高，回源QPS在几百以内：HTTPS回源对源站CPU影响通常不明显，可能只多几个百分点。

动态接口，回源QPS 1000～3000，响应体1KB～20KB：HTTPS回源可能让Nginx或应用网关CPU增加5%～15%，具体看TLS版本、连接复用、证书算法。

大文件回源，单机出站几百Mbps到1Gbps：加密吞吐会更容易体现出来，CPU可能增加10%～30%。如果机器CPU比较老，或者没有AES-NI，差距会更明显。

短连接高并发，连接复用差，回源QPS上万：HTTPS回源可能成为明显压力点，CPU、连接数、TIME_WAIT都会一起上来。这类场景要先查连接复用，不要一上来就把锅甩给HTTPS。

HTTP回源能省多少资源

HTTP回源确实更轻。没有TLS握手，没有加解密，Nginx处理纯HTTP请求的成本更低。对低配源站、超高回源量、内网专线回源场景，HTTP回源有现实意义。

比如源站和CDN在同一家云厂商内网，或者CDN厂商提供专线回源、私有网络回源，中间链路不经过公网，这时用HTTP回源可以减少一点CPU开销，运维上也少处理源站证书。

但如果源站暴露在公网，CDN节点从公网回源，HTTP回源会带来明文传输问题。请求头、Cookie、Token、后台接口参数，都可能经过不可控链路。很多业务前端已经全站HTTPS，但回源还是HTTP，这种配置在安全审计里经常被指出。

这里补充一点：用户看到浏览器小锁，并不代表全链路都是加密。浏览器到CDN加密，只能说明前半段加密；CDN到源站如果是HTTP，中间仍然是明文。

性能差异在不同业务里差很多

CDN命中率高的网站

如果是图片、CSS、JS、安装包这类静态资源，CDN命中率能做到90%以上，源站只承担少量回源。这个时候HTTPS回源对源站性能影响通常很小。

例如每天1000万PV，CDN命中率95%，真正打到源站的请求只有5%。哪怕HTTPS回源比HTTP多消耗10%的网关CPU，折算到整站压力里也不明显。

这种业务更应该关注缓存策略：Cache-Control、ETag、Last-Modified、CDN缓存时间、URL版本号。如果缓存没做好，HTTP回源也救不了源站。

动态接口占比高的网站

API业务就不一样了。登录、下单、查询、支付回调、用户中心，这些请求很多不能缓存，CDN只是做加速、WAF、DDoS清洗，回源比例接近100%。

这种场景下，HTTPS回源带来的CPU开销会更直接地压到源站入口层。尤其是Nginx、OpenResty、Envoy这一层，如果还做WAF规则、Lua逻辑、鉴权、限流，CPU会叠加上去。

不过实际瓶颈不一定在TLS。很多动态业务最后卡在数据库、Redis、应用线程池、连接池、上游RPC。源站入口层CPU如果还很空，HTTPS回源影响就不是主矛盾。

大文件和视频类回源

大文件回源要看带宽和CPU。比如CDN节点回源拉取500MB文件，HTTPS加密的数据量很大，源站出站带宽越高，CPU加密开销越明显。

如果源站是1Gbps以上持续出流，建议重点看CPU型号、AES-NI、Nginx worker CPU占用、软中断、网卡队列。单纯说HTTP还是HTTPS不够，要一起看吞吐。

海外大带宽源站比较常见这种情况。如果业务面向海外用户、下载量大，对大陆访问不敏感，可以考虑新加坡大宽带这类机器，1-2Gbps峰值带宽更适合做源站或分发节点。如果在选机器，可以看看129云的新加坡大宽带产品，适合普通线路、海外大流量场景，但要注意它不保证大陆网络访问质量。

源站配置对差异影响很大

Nginx Keep-Alive要打开

CDN回源用HTTPS时，Keep-Alive非常关键。源站Nginx可以关注这些参数：

keepalive_timeout：不要太短，常见设置30s到75s。

keepalive_requests：不要太小，可以根据业务设置到1000或更高。

worker_processes：通常设置auto。

worker_connections：结合连接数调整，别让Nginx先到瓶颈。

ssl_session_cache：开启Session缓存，减少重复握手成本。

ssl_session_timeout：可以设置到10m或更长，按安全要求调整。

如果源站前面还有SLB、反向代理、Ingress，也要看这些组件是否复用回源连接。有些问题出在中间代理，CDN到代理是长连接，代理到后端却是短连接，后端压力照样很大。

证书算法也会影响握手成本

现在更推荐ECDSA证书或RSA+ECDSA双证书。ECDSA在握手性能上通常更好，证书体积也小。不过兼容性要看客户端和CDN支持情况。CDN到源站这段由CDN发起请求，只要CDN支持，问题通常不大。

TLS 1.3也值得打开。相比TLS 1.2，TLS 1.3握手更快，协议更简洁。配合Session Resumption，回源连接偶尔重建时压力会低一些。

什么时候可以放心用HTTPS回源

源站走公网回源，建议直接用HTTPS回源。特别是接口里有Cookie、Authorization、JWT、用户手机号、订单号、后台管理路径，不要为了省一点CPU把链路变成明文。

业务有合规要求，比如金融、医疗、企业内部系统、跨境业务，HTTPS回源基本是标配。很多安全扫描也会检查“CDN到源站是否加密”。

源站CPU余量充足，CDN命中率较高，QPS不是极端短连接模式，用HTTPS回源不会带来很大性能问题。实际压测里，只要连接复用正常，差距经常小于预期。

什么时候HTTP回源更合适

源站和CDN之间是内网链路、专线链路，安全边界明确，HTTP回源可以接受。

源站机器配置很低，CPU已经比较紧张，业务又是大流量静态回源，HTTP回源能省一部分资源。

回源内容本身不敏感，比如公开图片、公开下载文件，并且访问链路处在可控网络里，可以考虑HTTP回源。

但有一种配置要慎重：用户访问HTTPS，CDN回源HTTP，同时源站还开放公网80端口，没有鉴权、没有源站保护。这种情况下，别人绕过CDN直连源站，不仅能看到真实IP，还可能绕过CDN上的WAF、防刷、DDoS防护策略。

源站防护别只盯着协议

CDN回源协议只是源站架构里的一个环节。实际线上事故里，源站被打穿更多是这些原因：

源站IP泄露，被直接DDoS。

源站安全组没限制CDN回源IP段。

回源鉴权没做，攻击者构造请求绕过CDN。

缓存规则配置错误，动态接口被大量回源。

大文件缓存时间太短，CDN频繁回源拉取。

如果业务有攻击压力，尤其是游戏、活动页、API接口、海外站点，源站机器本身要带防护。比如国内西北企业站点、业务主要走电信线路，可以看129云西安电信-B型，4C4G、50G SSD、15Mbps上行，带50Gbps单机防御，适合预算敏感但需要基础防护的场景。

如果是海外业务，攻击量更大，源站需要更高防御，可以看美国高防-E型，16C16G、80Mbps峰值、三网精品、300G防御，适合游戏、接口服务、海外站点抗DDoS。选型时可以直接联系129云，客服热线400-9177118，把业务地区、带宽峰值、攻击类型、是否接CDN说清楚，方便匹配线路和防护规格。

压测时要这样看HTTPS回源影响

不要只用ab或wrk在源站本地打HTTP和HTTPS，然后得出“HTTPS慢很多”的结论。CDN回源的真实特征和本地压测不一样，尤其是连接复用、节点数量、回源并发、缓存命中率。

更接近生产的测试方式是：通过CDN域名发起请求，分别配置HTTP回源和HTTPS回源，对比源站入口层指标。

重点看Nginx CPU、系统load、连接数、TLS握手次数、5xx比例、P95/P99延迟、源站出入带宽、应用层响应时间。

如果切到HTTPS回源后，CPU只从20%涨到25%，P99延迟没明显变化，那性能影响可以接受。

如果CPU从50%涨到90%，同时连接数飙升，先查Keep-Alive和Session复用。很多时候调完连接复用，CPU会明显回落。

如果CPU没涨，延迟却增加，问题可能在网络链路、DNS解析、源站证书校验、CDN节点回源路由，不一定是TLS加密成本。

一些线上容易忽略的细节

源站证书过期会直接影响回源

HTTPS回源需要源站证书正常。证书过期、证书链不完整、域名不匹配，都可能导致CDN回源失败。部分CDN可以关闭证书校验，但这会削弱HTTPS回源的安全意义。

证书续期最好自动化，续完要reload Nginx。多台源站要确保所有机器证书一致，不要一台新证书、一台旧证书，排查起来很烦。

回源Host要配置对

CDN回源HTTPS时，SNI和Host很关键。源站Nginx如果根据server_name匹配证书和站点，CDN回源Host配置错了，就可能拿到默认证书或默认站点。

表现出来可能是502、525、526，或者回源到了错误业务。排查时直接在源站用curl指定Host和SNI测试，比盯着CDN控制台猜要快。

不要让源站同时裸奔

接了CDN以后，源站安全组最好只放行CDN回源IP段，或者做回源鉴权。否则攻击者拿到源站IP后，可以直接绕过CDN访问源站。

HTTPS回源也挡不住绕过CDN的直接攻击。协议加密解决的是传输安全，不是访问控制。

实际选择时的判断方式

用户到CDN这段，基本不用纠结，直接HTTPS。

CDN到源站如果走公网，业务包含登录、接口、后台、订单、用户数据，优先HTTPS回源。

CDN到源站如果是内网、专线、同云厂商私网，内容不敏感，HTTP回源可以用，省一点资源，也减少证书维护。

如果源站CPU紧张，不要只在HTTP和HTTPS之间二选一。先看缓存命中率、连接复用、TLS版本、证书算法、Nginx参数、源站机器规格。很多站点把缓存命中率从70%调到90%，收益比把HTTPS回源改成HTTP大得多。

HTTPS回源真正需要重点优化的，是高QPS动态业务、大文件高吞吐业务、短连接异常多的业务。普通企业站、内容站、官网、图片站，只要CDN缓存配置正常，HTTPS回源的性能影响通常不会成为主要瓶颈。