CDN回源走HTTPS还是HTTP，源站压力到底差多少

CDN回源协议这个问题，实际排查时经常遇到。页面访问慢、源站CPU高、负载抖动，业务方第一反应有时会问：是不是CDN回源用了HTTPS，把源站压住了？

这个判断不能只看“HTTPS比HTTP多加密”这一句话。真正影响源站压力的，通常是连接模型、回源比例、TLS握手次数、源站CPU型号、Web Server配置、动态请求占比这些因素。HTTPS确实会增加源站开销，但在大多数配置正常的CDN场景里，它不一定是主要压力来源。

HTTPS回源多出来的压力主要在哪里

HTTP回源基本就是TCP连接建立后直接传输明文HTTP报文。HTTPS回源则多了一层TLS，源站需要处理证书协商、密钥交换、加解密、完整性校验等工作。

源站压力主要多在两个地方：

一是TLS握手。新建HTTPS连接时，源站要参与密钥协商和证书相关计算。如果是TLS 1.2完整握手，网络上还会多一些RTT；TLS 1.3已经改善很多，但CPU计算仍然存在。

二是数据加解密。请求体、响应体都要经过加密和解密。不过这里补充一点，现代CPU普遍支持AES-NI，Nginx/OpenSSL配置正常的情况下，AES-GCM这类对称加密的持续吞吐开销并没有很多人想象中那么夸张。真正容易放大的，反而是大量短连接导致的握手成本。

握手成本比传输加密更容易出问题

实际使用中发现，源站CPU因为HTTPS回源明显上涨，常见场景不是“响应内容太大所以加密很累”，而是“CDN到源站连接没有复用好”。

比如每个请求都新建连接，或者keepalive时间太短，或者源站前面还有一层SLB/WAF，连接在中间层被频繁断开。这种情况下，源站每秒要处理大量TLS握手，CPU曲线会很难看。

如果CDN节点到源站是长连接复用，TLS session resumption也正常，HTTPS回源的额外CPU通常会下降很多。大文件下载、图片、视频切片这类场景，只要连接稳定，HTTPS回源增加的CPU一般比动态业务逻辑、数据库查询、PHP/Java渲染这些小得多。

按场景看压力差异

从经验数据看，如果CDN到源站keepalive正常，TLS复用正常，HTTPS回源比HTTP回源多出来的CPU开销，很多业务会落在5%到15%这个区间。这个不是标准值，只是常见线上环境的体感范围。

如果是短连接、高QPS、小响应包，并且TLS 1.2完整握手比例很高，CPU上涨到20%甚至更高也见过。尤其是1核2G、2核4G这种小机器，本来业务进程就吃CPU，再叠加TLS握手，很容易从“还能跑”变成“偶发502”。

CDN回源不是用户到CDN，别把两段链路混在一起

这里经常有人混淆：用户访问CDN用HTTPS，和CDN回源用HTTPS，不是同一段连接。

完整链路一般是：

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

用户到CDN用HTTPS，TLS压力在CDN边缘节点上，源站不承担这部分握手。CDN回源如果也用HTTPS，源站才会承担CDN节点到源站这一段TLS压力。

所以一个站点即使全站HTTPS，对源站有没有TLS压力，要看CDN配置里的回源协议。如果配置成“协议跟随”，用户HTTPS访问时CDN也HTTPS回源；如果配置成“HTTP回源”，那源站收到的仍然是HTTP请求。

HTTP回源的性能优势和安全代价

HTTP回源的好处很直接：源站少做TLS，配置也简单。Nginx监听80端口，CDN拉取内容，链路少一层证书问题。证书过期、SNI不匹配、TLS版本不兼容这类问题也少很多。

但代价也很明确：CDN到源站这一段是明文。

如果源站和CDN之间走公网，HTTP回源意味着请求路径上的中间网络理论上可以看到URL、Header、Cookie、请求体、响应体。对于普通图片、公开JS/CSS，这个风险不一定高；但如果是后台接口、登录态、订单信息、用户资料，HTTP回源就不太合适。

多说一句，有些业务以为“用户到CDN已经HTTPS，所以全链路安全”，这其实只保护了用户到CDN这一段。CDN回源走HTTP时，源站这一段并没有加密。

HTTPS回源更适合哪些业务

涉及账号、支付、订单、会员、企业内部系统、API接口的业务，建议CDN回源直接走HTTPS。哪怕源站CPU多一点，也比明文传输敏感数据更稳妥。

还有一种场景是源站防盗链、鉴权、签名校验都依赖Header或Cookie。如果这些信息在公网明文传输，被中间设备记录或篡改，后续排查会很麻烦。HTTPS回源至少能把链路上的窃听和篡改风险压下去。

如果是纯静态资源站，比如公开图片、安装包、前端静态文件，HTTP回源在很多场景下也能接受，尤其是源站资源有限、访问量又很大的时候。不过现在云厂商CDN和源站的TLS优化都比较成熟，静态站点也没必要因为担心一点CPU就完全排斥HTTPS回源。

真正要看的指标不是协议名，而是回源连接状态

排查HTTPS回源压力，不能只看top里CPU高不高。需要把几个指标拉出来看，否则容易误判。

看CDN回源命中率

缓存命中率低，源站压力一定会上来。比如命中率从95%掉到70%，源站请求量可能直接翻几倍。这个时候就算回源走HTTP，源站也会被打得很难受。

动态接口、带随机参数的URL、Cache-Control设置不合理、Cookie导致缓存绕过，都会让CDN变成“转发代理”，而不是缓存层。

看源站TLS握手次数

Nginx可以通过stub_status、日志变量、OpenSSL统计、系统连接数等方式观察。更直接一点，看Nginx access log里的连接复用情况，或者从CDN侧看回源连接复用率。

如果HTTPS回源QPS只有几百，但每秒新建TLS连接也接近几百，说明连接复用不理想。正常情况下，CDN到源站应该尽量复用长连接，而不是请求一次握手一次。

看CPU消耗分布

如果CPU主要耗在业务进程，比如php-fpm、java、node、数据库驱动，那HTTPS回源不是主因。如果nginx worker或openssl相关消耗明显，才需要重点看TLS。

实际使用中发现，很多“HTTPS回源导致源站高负载”的案例，最后查出来是缓存规则没生效、接口全部回源、源站数据库慢查询，HTTPS只是背锅。

源站配置对HTTPS回源影响很大

Nginx、OpenResty、Apache、Envoy这类组件，配置差别会直接影响HTTPS回源成本。

keepalive要打开并调合理

CDN侧支持回源长连接时，源站也要配合。Nginx上游、SLB、WAF、源站监听层，任何一层把连接频繁断掉，都会让TLS握手变多。

如果源站前面还有负载均衡，注意负载均衡的idle timeout。CDN以为连接还能复用，但中间层已经断开，就会出现连接重试、回源慢、偶发502这类问题。

TLS版本建议用TLS 1.2和TLS 1.3

TLS 1.0、TLS 1.1不建议再留。TLS 1.3握手更少，安全性也更好。现代CDN和浏览器都支持得比较成熟，源站如果OpenSSL版本太老，建议升级。

证书算法上，ECDSA证书在握手性能上通常比RSA更友好，但兼容性要看业务环境。很多站点会同时配置RSA和ECDSA双证书，由客户端或CDN自动选择。

开启session resumption

TLS session cache、session ticket这些能力可以减少完整握手次数。CDN回源节点固定时，复用效果会比较明显。

不过session ticket密钥管理也要注意，不能长期不轮换。安全要求高的业务，需要在性能和密钥管理之间做平衡。

带宽、延迟和CPU要分开看

HTTPS回源对带宽影响不大。TLS记录头、握手包会带来一些额外字节，但对大部分Web业务来说，占比很低。真正明显的是CPU和新连接延迟。

延迟方面，如果CDN节点到源站是新建HTTPS连接，TLS握手会增加回源耗时。TLS 1.2完整握手通常要多1到2个RTT，TLS 1.3会少一些。如果CDN节点和源站跨境，比如海外CDN节点回中国大陆源站，RTT本来就高，握手延迟会被放大。

所以跨境业务要特别注意源站位置。比如用户在中国大陆，源站放欧美，再让CDN频繁跨境HTTPS回源，体验很容易抖。业务如果需要香港节点、优化回国线路、仅计费上行流量这类资源，可以看看129云的中国香港云服务器，配置从1核到4核、1G到8G内存，带宽30Mbps，流量200G到4TB，适合放轻量源站、API中转、海外业务回国入口。

什么时候HTTP回源更合适

HTTP回源适合源站和CDN之间风险可控、内容不敏感、性能压力比较紧的场景。

比如公开静态资源，源站只给CDN访问，源站安全组只放行CDN回源IP，没有用户直连源站入口。再配合鉴权URL、Referer校验、源站防盗链，HTTP回源可以减少一点CPU开销，也降低证书维护复杂度。

但这里要注意，安全组只放行CDN回源IP很关键。否则攻击者绕过CDN直接打源站，HTTP还是HTTPS都挡不住源站被扫、被压、被DDoS。

什么时候HTTPS回源更合适

HTTPS回源适合对数据安全、链路可信度、合规要求更敏感的业务。尤其是API、管理后台、登录注册、支付订单、企业系统，不建议为了省一点CPU改成HTTP回源。

如果源站CPU不够，优先优化连接复用、缓存命中率、TLS参数，再考虑升级机器。直接从HTTPS回源降到HTTP回源，有时只是把问题藏起来。

源站本身还要考虑抗攻击能力。CDN能抗大部分边缘流量，但如果源站IP泄露，攻击流量可以绕过CDN直接打源站。游戏、企业站、高风险业务可以考虑高防源站。比如129云的十堰高防-D型，E5-2680v4双路、28核心56线程、64G DDR4 ECC、800G SSD、50Mbps峰值带宽，单机600Gbps防御，适合源站需要硬抗DDoS、CC压力比较大的场景。需要确认线路和防护策略，可以直接打客服热线400-9177118问清楚。

一个线上压测口径

压测CDN回源协议时，建议不要只压CDN域名。因为压CDN域名时，很多请求会被边缘缓存命中，看不到源站真实压力。

更接近真实情况的做法是准备两组回源配置：一组HTTP回源，一组HTTPS回源。缓存规则、源站机器、Nginx配置、业务代码保持一致，然后分别观察源站CPU、load、Nginx active connections、TLS握手数、回源延迟、5xx比例。

压测请求也要区分静态和动态。静态资源命中率高时，协议差异会被缓存掩盖；动态接口每次都回源，才更容易看出HTTPS回源的额外成本。

配置选择时可以按业务类型拆开

同一个站点不一定所有路径都用同一种回源策略。很多CDN支持按域名、路径、规则配置回源协议。

例如：

/static/、/img/、/download/ 这类公开静态资源，可以根据源站压力和安全要求选择HTTP或HTTPS回源。

/api/、/user/、/admin/、/pay/ 这类接口和后台路径，建议HTTPS回源。

大文件下载如果源站CPU紧张，可以重点确认CDN是否支持Range回源、分片缓存、回源长连接。单纯把HTTPS改HTTP，不一定能解决下载慢；很多时候瓶颈在源站磁盘、出口带宽、跨境线路。

常见误区

看到CPU高就怪HTTPS回源

HTTPS回源会吃CPU，但不代表CPU高就是它造成的。动态业务、日志写入、压缩、图片处理、数据库慢查询，都可能比TLS更重。

特别是开启gzip、brotli、图片实时裁剪、水印处理时，CPU上涨很明显。相比之下，TLS加解密可能只是小头。

以为CDN开了HTTPS源站就不用证书

如果CDN到源站也走HTTPS，源站必须有证书。可以是公网可信证书，也可以是CDN支持的自签证书模式，但要看厂商是否校验证书链、是否校验域名、是否支持SNI。

证书过期会直接导致回源失败，表现可能是CDN 502、526、回源SSL握手失败。线上证书监控要覆盖源站证书，不要只监控用户访问的CDN证书。

HTTPS回源一定比HTTP慢很多

连接复用正常时，不会每个请求都完整握手。CDN和源站之间通常是少量长连接承载大量请求，HTTPS的额外延迟会被摊薄。

如果每次请求都重新握手，那不是HTTPS天然慢很多，而是连接复用或中间链路配置有问题。

源站机器规格对选择也有影响

小规格源站，比如1核1G、1核2G，跑Nginx加一个轻量应用还可以，但如果动态接口QPS上来，再叠加HTTPS回源、日志、监控Agent，CPU余量会很薄。

如果是海外业务、小型电商、TikTok相关工具站、Amazon运营后台、轻量代理服务，源站压力不大但需要稳定网络，可以看129云德国双ISP-特惠，1核、1G DDR4 ECC、15GB SSD、100Mbps带宽、1个IPv4，GTT直连，适合轻量业务和测试环境。

如果是生产业务，建议源站CPU留出30%左右余量。HTTPS回源不是不能开，而是不要把机器长期跑在80%到90% CPU，再去纠结协议差异。那种状态下，任何流量波动、缓存失效、爬虫访问都会把服务打抖。

比较稳的配置习惯

CDN到源站能走HTTPS的业务，尽量走HTTPS，尤其是接口和敏感数据。源站压力通过keepalive、TLS 1.3、session resumption、缓存规则、机器规格去处理。

静态公开资源可以按成本和压力选择HTTP回源，但源站访问控制要做好，只允许CDN回源IP访问，不要把源站裸露在公网。

Nginx层面注意ssl_session_cache、ssl_session_timeout、keepalive_timeout、worker_processes、worker_connections这些配置。OpenSSL版本太老的机器，升级收益会比切换HTTP更干净。

CDN侧注意回源Host、SNI、证书校验、回源协议跟随、Range回源、回源长连接。很多线上问题不是协议选择错了，而是这些配置互相不匹配。

压测时把缓存命中和回源Miss分开看，把用户到CDN和CDN到源站分开看，把TLS握手和业务处理分开看。这样才能判断HTTPS回源到底多消耗了多少，而不是凭感觉改配置。