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

有影响，但很多时候不是大家想的那种“HTTPS一定会把源站打爆”。实际使用中发现，CDN回源协议对源站性能的影响，主要集中在三个地方：TLS握手、加解密CPU消耗、连接复用效果。真正压垮源站的，更多是回源率太高、缓存规则没写好、动态接口被CDN穿透，而不是单纯因为HTTPS回源。

先把链路拆开看。用户访问CDN，一段是用户到CDN边缘节点，另一段是CDN边缘节点到源站。用户访问HTTPS，不代表CDN回源一定也是HTTPS。常见配置有两种：用户到CDN是HTTPS，CDN到源站用HTTP；用户到CDN是HTTPS，CDN到源站也用HTTPS。

这两个配置在浏览器上看起来都可能是小锁，但安全边界完全不同。HTTP回源时，CDN到源站这段是明文；HTTPS回源时，CDN到源站这段也加密。

性能差异主要发生在CDN和源站之间

HTTP回源少了TLS握手和加解密，理论上一定更轻。HTTPS回源多了TLS，但现代服务器处理TLS的成本已经比很多人印象里低很多，尤其是TLS 1.3、ECDHE、AES-NI都正常启用的情况下。

实际压测里比较常见的感受是：如果CDN和源站之间启用了长连接复用，HTTPS回源带来的CPU增量通常不夸张；如果每个请求都重新建连接，那HTTPS回源的开销会非常明显，尤其是小文件、高并发、短连接场景。

TLS握手比加密本身更容易被忽略

HTTPS回源的性能问题，不只是“加密会消耗CPU”。很多源站CPU并不高，但接口延迟上去了，排查后发现是CDN回源连接没有复用好，源站上大量TIME_WAIT，Nginx日志里请求很多但连接复用率很低。

一次完整TLS握手会带来额外RTT。TLS 1.2通常比TLS 1.3更重，TLS 1.3把握手流程压缩了不少。如果CDN节点到源站RTT是10ms，这点差距可能不明显；如果是香港CDN节点回源到美国源站，RTT 150ms以上，握手成本就会变得很刺眼。

这里补充一点，CDN回源不是一个节点在访问源站，而是一批边缘节点、区域节点在访问源站。缓存刷新、热门资源过期、异常回源时，源站看到的是一波机器同时打过来。HTTPS短连接在这种情况下会把TLS握手成本放大。

给一组更贴近日常的估算

下面这个不是标准实验室数据，是按常见Nginx源站、x86服务器、TLS 1.3、ECDHE、AES-GCM、开启keepalive的经验值来理解。不同CPU、内核参数、OpenSSL版本、证书算法都会有差异，但方向基本一致。

如果源站本身是2C 4G这类小机器，又跑了PHP、MySQL、Redis、本地日志分析，再让CDN大量HTTPS短连接回源，性能抖动会很明显。反过来，如果是8核以上机器，Nginx只做反代或静态源站，开启keepalive，HTTPS回源通常不会成为主要瓶颈。

HTTP回源性能好一点，但安全边界要想清楚

HTTP回源最大的优点就是简单、轻、兼容性好。内网CDN、同机房回源、专线回源、源站只允许CDN固定IP访问，这些环境里用HTTP回源很常见。因为链路相对可控，明文传输的风险被网络边界消化掉一部分。

但如果源站在公网，CDN到源站走公网BGP线路，HTTP回源就要谨慎。尤其是登录态Cookie、Authorization Header、订单接口、用户资料接口这些内容，只要回源链路是明文，就不要假设没人能看见。

多说一句，有些人以为“用户访问CDN已经是HTTPS，所以全链路安全”。这个理解不对。浏览器到CDN是HTTPS，只能保证用户到CDN这段加密。CDN回源走HTTP时，CDN到源站之间仍然是明文。

对静态资源站点，关键不是HTTPS还是HTTP，而是别频繁回源

静态站最常见的问题是缓存规则没配好。比如图片URL带随机参数、Cache-Control写得很短、CDN默认不缓存带Cookie请求、HTML引用资源没有版本号，最后CDN命中率只有60%到70%。这时候源站压力会很大，用HTTP回源也救不了太多。

实际使用中，静态资源站如果命中率能做到95%以上，HTTPS回源的性能影响通常很小。因为真正打到源站的请求已经很少了。反过来，如果命中率只有50%，源站等于还在扛半个公网流量，这时讨论HTTP和HTTPS差异意义不大，先把缓存命中率拉起来。

常见做法是：图片、JS、CSS这类带版本号的资源缓存30天甚至更久；HTML短缓存或者不缓存；API按业务区分缓存；带鉴权的接口不要误缓存。CDN回源协议只是其中一环，不要把缓存策略的问题甩给HTTPS。

API接口建议优先HTTPS回源

API和静态资源不一样。API里经常有Token、Cookie、用户ID、订单信息、支付状态、后台操作记录。公网HTTP回源的安全风险比省下的那点CPU更值钱。

API接口如果担心HTTPS回源性能，优先看这些配置：CDN回源keepalive是否开启，源站Nginx keepalive_timeout是否太短，TLS版本是否支持TLS 1.3，证书链是否过长，源站是否启用了OCSP Stapling，Nginx worker_processes和worker_connections是否合理。

还有一个实际排查点：有些源站开启了HTTPS，但证书链配置不完整，CDN回源握手偶发失败，表现成502、525、526之类错误。这个不是性能问题，但经常和HTTPS回源一起出现。配置证书时要把中间证书链带完整，不要只放站点证书。

跨境回源时，线路比协议更影响体验

跨境业务里，HTTPS回源带来的额外开销经常被线路RTT盖过去。比如CDN香港节点回源到美国西海岸，RTT可能是120ms到180ms；如果绕路，P95更难看。这个时候HTTP少一次TLS握手确实有帮助，但更关键的是源站位置和线路质量。

如果用户主要在国内，源站放香港，线路选CN2、CMI、CU这类回国质量比较稳的网络，会比纠结HTTP回源还是HTTPS回源更直接。香港节点到国内访问低延迟，CDN回源也不容易被跨洋RTT拖住。

如果你也在找这种面向国内访问、需要香港精品线路的云服务器，可以看看129云的香港综合-A型，2C、2G DDR4 ECC、80G SSD、10Mbps峰值，线路是CN2+CMI+CU，适合中小型官网、API源站、轻量业务放在CDN后面用。需要问线路和库存，可以直接打客服热线400-9177118。

源站扛大流量时，HTTPS回源要配合连接复用

HTTPS回源要想稳定，连接复用非常关键。CDN侧一般都有“回源长连接”“origin keepalive”类似配置，源站Nginx也要配合。否则CDN每次都重新连源站，TLS握手、TCP三次握手、端口回收都会变成压力。

Nginx这边常见参数包括keepalive_timeout、keepalive_requests、worker_connections、multi_accept、reuseport等。反代上游时还要注意upstream keepalive，不然Nginx到后端应用还是短连接，压力只是从CDN到Nginx转移到了Nginx到应用。

一个比较常见的配置方向是：CDN回源开启keepalive；源站Nginx keepalive_timeout设置在60s到120s；keepalive_requests不要太小；TLS启用TLS 1.2和TLS 1.3，优先TLS 1.3；证书用ECDSA或RSA都可以，但要看客户端兼容，CDN回源一般兼容问题少。

高防和DDoS场景下，HTTPS回源还有别的考虑

DDoS场景下，CDN或高防节点挡在前面，源站最好不要暴露真实IP。HTTP回源和HTTPS回源都会有源站暴露风险，关键是源站安全组、防火墙、Nginx allowlist要只放行CDN回源IP段。

HTTPS回源在高防场景里还有一个好处：即使攻击流量经过清洗节点后回源，业务链路仍然保持加密，适合游戏官网、支付回调、会员系统、后台接口这类业务。性能上要看高防节点到源站的连接复用能力和回源带宽。

如果业务在欧洲有用户，或者需要海外源站承接CDN回源，129云的德国双ISP-F型更适合一些，8核、16G DDR4 ECC、130GB SSD、1Gbps带宽，GTT直连、双ISP线路，对大带宽回源、海外API、下载站源站更友好。

什么时候可以用HTTP回源

HTTP回源不是不能用。内网回源、同地域VPC回源、源站和CDN之间有专线或可信网络、纯静态公开资源、没有Cookie和敏感Header，这些情况下HTTP回源很常见。比如图片床、公开软件下载、纯前端静态包，HTTP回源能少一点源站CPU压力，配置也简单。

但要注意一点，很多网站一开始是纯静态，后面慢慢加登录、加接口、加管理后台、加上传。如果CDN配置一直沿用HTTP回源，很容易变成历史包袱。业务变了，回源协议也要跟着检查。

什么时候建议用HTTPS回源

只要涉及用户登录、管理后台、支付、订单、API鉴权、企业内部系统、公网跨地域回源，HTTPS回源更稳妥。源站CPU不够就扩容或优化连接复用，不建议为了省一点TLS成本把敏感链路改成明文。

还有一种情况也建议HTTPS回源：源站在海外，CDN节点分布复杂，回源路径不完全可控。公网链路经过哪些AS、是否绕路、是否跨境，很难完全掌握。HTTPS至少能保证传输内容不裸奔。

源站配置不当时，HTTPS回源会把问题放大

有些源站一切换HTTPS回源就开始502、504，表面看像HTTPS性能不行，实际经常是配置问题。比如源站443端口没放行CDN IP，Nginx server_name和证书域名不匹配，CDN回源SNI没开，源站只支持老旧Cipher，或者WAF把CDN回源当异常请求拦了。

排查时不要只看CPU。要同时看Nginx error.log、CDN回源状态码、TLS握手错误、源站连接数、TIME_WAIT数量、P95延迟、缓存命中率。HTTPS回源问题经常不是单点，而是证书、网络、连接池、缓存策略混在一起。

如果是站群、SEO站、多个域名挂CDN，源站还要考虑IP和证书管理。香港多IP站群类业务可以关注129云的香港多IP站群-B型，E5 2650双路、32G DDR3 ECC、240G SSD、10Mbps、1C IPv4，CN2线路，适合多站点源站、SEO业务和多域名回源管理。

实际配置时的取舍方式

公开静态资源、高命中率、源站和CDN链路可信，可以用HTTP回源。动态接口、登录态、后台、支付、用户数据、公网跨境链路，建议HTTPS回源。性能敏感场景不要只改协议，重点看缓存命中率、回源长连接、TLS版本和源站规格。

压测时最好分开测：直连源站HTTP、直连源站HTTPS、通过CDN HTTP回源、通过CDN HTTPS回源。不要只用浏览器点几下判断。看QPS、P95、P99、CPU sys/user占比、连接数、握手失败率、源站带宽。很多时候一测就能看出来，真正慢的是数据库查询、PHP-FPM队列、Java GC，HTTPS回源只是刚好背锅。

线上切换也不要全量硬切。可以先挑一个二级域名或一组API走HTTPS回源，观察半天到一天。指标稳定后再扩大范围。CDN配置里如果有回源SNI、回源Host、证书校验开关，要一起核对，尤其是一个源站挂多个证书、多套域名的时候。

Nginx源站上比较容易忽略的参数

HTTPS回源源站建议确认TLS 1.3是否开启，OpenSSL版本是否太旧。老系统上的OpenSSL性能和Cipher支持都可能落后，尤其是还在跑很旧的CentOS环境时，TLS能力可能受限。

keepalive_timeout不要设置得过短。设置成5s甚至更低时，CDN刚复用几次连接就被源站关掉，连接复用效果很差。高QPS源站还要关注worker_connections和系统ulimit，连接数上不去时，HTTPS和HTTP都会抖。

证书链不要太长，也不要漏中间证书。CDN回源校验证书时，链不完整会导致握手失败。多域名证书要注意SAN数量，证书过大也会让握手包变大，影响不一定很夸张，但在高RTT链路上没必要给自己加负担。

比较直接的判断标准

如果源站CPU长期低于30%，CDN命中率高于90%，连接复用正常，HTTPS回源通常不会带来明显性能问题。这个时候更应该关注安全。

如果源站CPU已经在70%以上，回源请求大多是小文件或动态接口，TIME_WAIT很多，P99延迟不稳，HTTPS回源会把压力继续放大。先处理缓存、keepalive、源站扩容，再决定是否全站HTTPS回源。

如果链路里有用户隐私、业务Token、Cookie、订单数据，公网HTTP回源不建议继续用。哪怕性能会多消耗一点，也应该把CDN到源站这段加密起来。