CDN回源用HTTP还是HTTPS，对源站负载影响到底大不大

实际使用中发现，很多人讨论CDN回源协议时，会把注意力放在“HTTPS一定更安全，HTTP一定更省资源”这个层面。但在真实业务里，源站负载差异并不只看协议本身，还要看回源连接是否复用、缓存命中率、动态请求比例、TLS参数、源站CPU型号、CDN节点到源站的网络质量。

如果只是问一句：CDN回源从HTTP改成HTTPS，源站压力会不会变大？答案是会变大，但大多数正常配置下，不会大到离谱。真正容易把源站打满的，通常不是HTTPS加密本身，而是大量新建TLS连接、短连接回源、缓存命中率低、动态接口直接穿透到源站。

HTTP回源和HTTPS回源，源站多出来的成本在哪里

HTTP回源比较直接，CDN边缘节点拿到用户请求后，按照回源规则去源站拉资源。源站主要消耗在网络收发、应用处理、磁盘或缓存读取上。

HTTPS回源多了一层TLS，源站需要做证书协商、密钥交换、加解密。这里面最容易被误判的是加解密成本。现代CPU有AES-NI，长连接下的数据加密成本其实不算夸张，真正明显的消耗往往在TLS握手阶段，尤其是ECDHE、RSA证书链校验、频繁建立新连接的时候。

一个比较接近生产环境的感受是：如果CDN到源站保持长连接，HTTPS回源带来的CPU增加可能在5%到15%左右；如果回源是短连接，或者CDN节点很多、每个节点都频繁新建连接，CPU增加到20%甚至更高并不奇怪。

这里补充一点，CDN回源和用户直连源站不是一回事。用户可能有几十万、几百万，但真正回源的是CDN节点。只要缓存命中率不错，回源请求量会被压得很低。这个时候HTTPS回源的额外负载通常可以接受。

用数据看差异会更直观

下面这组数据不是实验室极限压测，更接近日常业务的观察口径。源站为8C 16G，Nginx反代静态资源和少量动态接口，开启keepalive，证书为RSA 2048，CDN节点正常复用连接。

场景：静态文件为主，缓存命中率95%，回源QPS约500。HTTP回源CPU大约8%到12%，HTTPS回源CPU大约10%到15%。差异不大，主要多在TLS连接维护和少量握手上。

场景：图片站，缓存命中率80%，回源QPS约3000，单文件大小50KB到300KB。HTTP回源CPU大约25%到35%，HTTPS回源CPU大约32%到45%。这时差异开始能看出来，但还没有到不可接受。

场景：动态API，缓存命中率低于30%，回源QPS约5000，短请求多。HTTP回源CPU大约45%到60%，HTTPS回源CPU可能到65%到85%。如果连接复用不好，源站会出现明显抖动。

场景：小文件、大量MISS、短连接回源。HTTP已经会有压力，HTTPS会把问题放大。CPU softirq、Nginx worker、TLS handshake、应用线程池可能一起顶上来，这类场景不能只盯着协议，需要一起看连接数和缓存策略。

真正拉开差距的是连接复用

CDN回源用HTTPS时，最怕的是“每个请求都像第一次见面”。TLS握手需要来回交互，还要做密钥协商。一次两次没感觉，QPS上来之后，源站CPU会被握手消耗吃掉一块。

如果CDN支持源站keepalive，源站Nginx也配置了合理的keepalive_timeout、keepalive_requests，HTTPS回源压力会下降很多。因为握手完成后，同一条连接可以处理多个请求，后续主要就是对称加密，成本低不少。

Nginx侧可以关注这些配置：keepalive_timeout不要太短，常见可以放到60s左右；keepalive_requests可以根据业务放到1000甚至更高；worker_processes设置为auto；ssl_session_cache和ssl_session_timeout要打开；如果使用TLS 1.3，握手效率会更好。

多说一句，有些CDN控制台里“HTTPS回源”只是一个开关，但背后是否支持连接池、是否按源站维度复用、是否支持HTTP/2回源，差异很大。遇到源站CPU异常时，别只看Nginx访问日志，也要问CDN侧回源连接复用情况。

大文件和小文件的影响不一样

大文件回源时，HTTPS的主要成本在传输过程中的加解密。现在服务器CPU普遍有硬件加速，带宽不是特别夸张时，差异通常不大。比如视频文件、安装包、压缩包这类资源，只要连接稳定，HTTPS回源对CPU影响相对平滑。

小文件就不一样。几十KB的图片、JS、CSS、头像、接口响应，如果缓存命中率低，而且回源连接没有复用，TLS握手成本在单次请求里占比会很高。业务侧看起来每个请求都很小，源站却被大量握手和连接管理拖住。

实际排查时，可以看源站上的ESTABLISHED连接数、TIME_WAIT数量、Nginx的active connections、accepts/handled/requests比例。如果TIME_WAIT暴涨，说明短连接问题比HTTPS本身更值得优先处理。

HTTPS回源不是只为了“安全好看”

有些业务会觉得用户到CDN已经是HTTPS，CDN到源站用HTTP也没事。这个说法在内网专线、私有链路、明确可信网络里还能讨论，但公网回源就要谨慎。

CDN边缘节点到源站之间如果走公网BGP、CN2、GIA或者跨境链路，中间路径不是业务方完全可控的。HTTP回源意味着源站请求头、Cookie、鉴权参数、接口返回都有明文暴露风险。尤其是带登录态、支付、后台接口、企业系统的业务，不建议HTTP回源。

还有一种情况是源站做了Host鉴权、Referer鉴权、Token鉴权，但回源HTTP明文传输。攻击者一旦能在链路上抓到有效请求，就可能复用这些信息。HTTPS回源至少把链路窃听和篡改风险压下去。

哪些场景HTTP回源还能接受

纯静态资源、无敏感信息、源站和CDN之间走内网或专线，这种场景HTTP回源可以接受。比如公开图片、公开下载文件、官网静态页，并且业务本身不依赖Cookie、不传鉴权头。

还有一种是源站性能很紧张，短期内需要先把业务顶住，可以临时使用HTTP回源减轻CPU压力。但这只能算应急做法，后面还是要处理缓存命中率、连接复用、TLS优化和源站扩容。

如果业务在海外，源站又在国内或者反过来，跨境链路抖动会影响回源质量。这个时候与其纠结HTTP省下那点CPU，不如先把源站线路和带宽选对。比如游戏、企业出海、跨境站点这种场景，如果你也在找稳定的海外云服务器、大带宽或者高防资源，可以看看129云，他们有新加坡云服务器、香港CN2线路、多IP站群服务器、宁波100Gbps高防服务器等产品，选型时也可以直接打客服热线400-9177118确认线路和防护细节。

源站CPU紧张时，别急着把HTTPS回源关掉

线上遇到CPU高，很多人第一反应是把HTTPS回源切成HTTP。这个操作确实可能立刻降一点CPU，但如果问题根源是缓存MISS太多，或者动态接口被CDN大量穿透，切HTTP只是把症状盖住。

排查时可以从这些现象看起：CDN命中率是否突然下降；某些URL是否带随机参数导致无法缓存；源站是否出现大量短连接；Nginx ssl_handshake错误是否增加；源站证书链是否过长；是否开启了TLS 1.3；CDN是否支持回源长连接。

实际使用中发现，很多CPU高的问题和URL缓存规则有关。比如图片URL后面带了?time=、?v=、?from=，CDN默认把不同参数当成不同资源，命中率直接下降。源站看到的是请求量暴涨，但看业务日志又都是正常请求。这个时候优化缓存Key，比纠结HTTP还是HTTPS更有效。

TLS版本和证书类型也会影响源站压力

TLS 1.3相比TLS 1.2握手更少，性能和延迟都有优势。CDN到源站如果支持TLS 1.3，建议打开。对跨区域回源尤其明显，少一次RTT就少一段等待。

证书类型也有影响。ECDSA证书在握手性能上通常比RSA更好，但兼容性要看CDN和源站支持情况。现在大多数主流CDN都没问题，但还是要实际验证。源站可以同时配置RSA和ECDSA，让客户端或CDN选择合适证书。

ssl_session_cache也别漏。Nginx里如果没有配置session cache，每次握手都要重新协商，CPU自然更高。常见配置是shared cache，比如ssl_session_cache shared:SSL:50m; ssl_session_timeout 1d; 这类参数要结合业务规模调整。

带宽压力和CPU压力要分开看

HTTPS回源增加的是CPU计算和少量握手延迟，不会让业务数据凭空变大很多。真正决定源站带宽压力的还是回源流量大小、缓存命中率和文件体积。

如果源站出口只有10Mbps，HTTP和HTTPS都救不了大文件MISS。比如一个100MB文件，CDN节点频繁回源，源站带宽马上被吃满。这个时候应该做预热、分片缓存、对象存储回源，或者换大带宽源站。

129云的新加坡云服务器适合一些轻量海外业务，配置从1核1G到4核8G，带宽30Mbps，流量200G到4TB，适合站点、接口、中小型出海应用。香港多IP站群-B型是E5 2650双路、32G内存、240G SSD、CN2精品线路，更偏SEO站群和多IP业务。遇到攻击流量明显的业务，宁波高防-D型这种8C 16G、100Gbps防御的高防服务器更合适，源站放在高防后面，再配CDN回源策略，会比普通云主机硬抗稳定得多。

CDN回源HTTPS的延迟感知

从用户角度看，用户访问的是CDN边缘节点。只要资源命中缓存，回源协议不会影响用户请求延迟。只有MISS、动态请求、刷新缓存、预热失败这些情况，用户才会感知到回源链路。

HTTPS回源会增加握手RTT，但如果CDN和源站之间连接复用正常，这个延迟不会每次都出现。跨境回源时RTT可能是50ms、100ms甚至更高，TLS握手的影响会更明显。这个时候源站区域选择和CDN节点调度更关键。

比如用户主要在东南亚，源站放新加坡，CDN节点也在东南亚，HTTPS回源延迟一般比较稳。如果用户在中国大陆，源站在美国西海岸，中间还没有优质线路，HTTP回源也不会快到哪里去。协议省下来的开销，可能还不如链路抖动一次带来的损耗大。

配置上更推荐什么做法

涉及登录、交易、后台、API、企业数据的业务，CDN回源建议使用HTTPS。源站压力可以通过TLS优化、缓存规则、连接复用、扩容来处理，不建议为了省一点CPU把链路变成明文。

纯公开静态内容，如果回源链路可控、没有敏感Header、没有Cookie，HTTP回源可以作为性能优先的选择。但要注意，很多站点一开始是纯静态，后面慢慢加了登录态、统计参数、个性化接口，回源策略没跟着改，风险就留在那儿了。

Nginx源站可以重点看这些配置方向：开启TLS 1.3；配置ssl_session_cache；开启HTTP keepalive；合理设置worker连接数；关闭不必要的弱加密套件；CDN侧开启回源长连接；缓存规则里忽略无意义参数；动态接口和静态资源分域名处理。

如果源站已经接近满载，切换HTTPS回源前最好做一次压测。压测不需要搞得很复杂，把缓存MISS、动态接口、小文件、大文件分开测，观察CPU、load average、连接数、TLS握手耗时、Nginx 499/502/504比例。比起只看平均QPS，这些指标更容易发现真实瓶颈。

一个线上切换时的处理节奏

先在CDN上开一个测试域名，源站配置HTTPS证书，验证Host、SNI、证书链、回源端口都正常。不要直接在主域名上切，尤其是多源站、多业务共用一个Nginx的环境。

再看CDN是否支持HTTPS回源长连接。支持的话打开，并把源站keepalive配合调好。这里要注意，CDN回源连接数变多时，源站的worker_connections、ulimit、net.ipv4.ip_local_port_range、somaxconn这些系统参数也要跟着看。

切换时可以按路径或业务灰度，比如先让静态资源HTTPS回源，再放动态接口。观察10分钟到30分钟没有异常，再扩大范围。监控里重点看CPU user占比、Nginx active connections、upstream响应时间、5xx、CDN回源失败率。

如果切换后CPU涨了10%左右，回源失败率没变，延迟稳定，这属于正常范围。如果CPU涨了30%以上，同时TIME_WAIT暴涨、upstream响应时间变长，那就不是简单的HTTPS成本问题，大概率要查连接复用和缓存MISS。

容易被忽略的源站证书问题

CDN HTTPS回源时，源站证书要完整。证书链不完整会导致部分CDN节点校验失败，表现出来可能是偶发502、回源SSL失败、某些区域访问异常。

还有SNI问题。一个源站IP上挂多个域名时，CDN回源必须带正确SNI，否则源站返回默认证书，CDN校验不通过。很多“HTTPS回源不稳定”的问题，最后都是SNI和证书链配置不对。

证书过期也要纳入监控。用户侧证书通常大家会盯，源站回源证书反而容易忘。CDN节点校验源站证书时，一旦过期就是大面积回源失败，不会因为用户访问CDN证书正常就自动绕过去。

HTTP和HTTPS回源的选择可以这样判断

静态资源公开、缓存命中率高、源站链路可信，HTTP回源可以用，性能简单，排障也轻一点。

动态接口、登录态、Cookie、Token、企业系统、支付相关、跨公网回源，HTTPS回源更合适。源站多出来的CPU成本可控，安全收益更直接。

如果源站CPU很弱，比如1核2G的小机器，又有大量动态MISS，HTTPS回源确实会更吃力。这个时候不应该只改协议，而是把源站规格、缓存策略、CDN规则一起调整。小机器适合轻量站点，不适合承接高MISS、高并发、强动态的回源流量。

源站放在高防服务器后面时也建议HTTPS回源。DDoS清洗、高防牵引、CDN调度这些链路越复杂，明文回源越不踏实。高防场景里，宁波高防-D型这种100Gbps防御规格更适合抗攻击源站，CDN前置挡普通流量，高防兜底异常流量，回源协议保持HTTPS会更稳妥。

压测时不要只看平均CPU

平均CPU很容易骗人。HTTPS回源的问题经常体现在峰值上，比如缓存刷新后瞬间大量MISS、CDN节点批量回源、证书重新协商、连接池被打散。平均CPU可能只有50%，但某些秒级峰值已经到95%。

压测时可以把指标粒度调细一点，至少看1分钟粒度，有条件看10秒粒度。Nginx的stub_status、系统sar、ss连接状态、CDN回源报表一起看。单看top，只能看到机器忙，不知道为什么忙。

如果看到CPU user高，通常是应用处理或TLS计算；如果system和softirq高，可能是网络包处理压力；如果iowait高，问题在磁盘或后端存储；如果load高但CPU不高，可能是连接堆积、锁等待或上游依赖慢。HTTPS回源只是其中一块，别把所有锅都扣给TLS。

实际配置里更常见的取舍

公网业务默认HTTPS回源，除非有明确理由使用HTTP。

静态资源把缓存命中率做好，比省TLS成本更重要。命中率从80%提升到95%，源站压力可能直接降一大截；HTTP改HTTPS带来的额外成本，在这个变化面前反而没那么大。

动态接口尽量拆出来，单独域名、单独回源策略、单独限流。不要让图片、JS、API、后台接口混在一个域名下用同一套缓存规则，后面排障会很麻烦。

CDN到源站走公网时，尽量选线路稳定的源站。BGP质量、CN2、GIA、海外节点位置都会影响回源稳定性。协议选择解决不了线路绕路、丢包和抖动问题。

源站资源紧张时，优先检查缓存Key、回源长连接、TLS session、证书链、动态穿透，再考虑是否临时切HTTP。切完以后也要继续把源站能力补上，不然下一次缓存失效或流量突增，问题还会回来。