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

CDN回源协议这个问题，线上经常会碰到。用户访问CDN用HTTPS，这个基本不用讨论了，浏览器、安全策略、SEO、支付登录接口都要求HTTPS。但CDN节点到源站这一段，是继续用HTTPS，还是改成HTTP，很多业务在配置时会犹豫。

实际使用中发现，大家纠结的点主要是两个：一个是源站CPU会不会被TLS握手打爆，另一个是回源链路明文HTTP会不会不安全。两个问题都是真问题，但影响程度要看回源频率、连接复用、源站机器规格、业务类型，不能只看“HTTPS更耗资源”这句话。

先把链路拆开看

用户访问网站时，一般是这样的链路：

浏览器 → CDN边缘节点 → 源站

浏览器到CDN这一段，绝大多数场景都用HTTPS。证书部署在CDN，TLS握手发生在用户和CDN节点之间，这部分压力不在源站。

CDN到源站这一段，才是这里讨论的“回源协议”。如果配置HTTPS回源，CDN节点会和源站建立TLS连接；如果配置HTTP回源，CDN节点直接用明文HTTP请求源站。

所以“全站HTTPS”不等于“源站一定承受所有HTTPS压力”。真正会落到源站上的，是CDN回源产生的TLS连接和加解密开销。

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

TLS握手的CPU开销

HTTPS相比HTTP，最明显多出来的是TLS握手。TLS 1.2下，如果没有会话复用，握手阶段会有非对称加密计算；TLS 1.3已经轻不少，但仍然比HTTP直接建TCP连接复杂。

实际压测里，如果是大量短连接、频繁回源，HTTPS回源的CPU占用会明显高。比如源站Nginx在同一台4C 8G机器上，静态小文件回源，keepalive关闭或复用率很低时，大致会看到这种差异：

HTTP回源：CPU 20%~35%，主要消耗在Nginx worker和内核网络栈。

HTTPS回源：CPU 45%~70%，握手频繁时CPU抖动明显，峰值容易上去。

这里不是说HTTPS一定翻倍，而是短连接场景下，TLS握手会把CPU消耗放大。小文件、接口碎片多、CDN节点分散、缓存命中率低时，这种感觉很明显。

连接复用做得好，差距会小很多

如果CDN到源站开启长连接，源站Nginx也配置了keepalive，HTTPS回源的压力会下降一大截。因为TLS握手不是每个请求都做一次，而是在连接建立时做一次，后面多个请求复用同一个连接。

实际使用中发现，HTTPS回源能不能接受，很多时候不是看“HTTPS”三个字，而是看CDN厂商的回源连接复用能力，以及源站有没有正确配置。

比如同样是4C 8G源站，静态资源平均20KB，请求量3000 QPS，缓存命中率90%，真实回源约300 QPS。开启回源keepalive后，HTTP和HTTPS对源站CPU的差距可能只有10%~20%。

但如果缓存命中率只有30%，真实回源2100 QPS，又是大量短请求，那HTTPS回源就会把CPU压力拉得很明显。这个时候换协议只是表面，缓存策略、资源切分、源站扩容都要一起看。

用一组接近线上体感的数据看差距

下面这个数据不是实验室极限值，更接近常见Web业务压测时的体感。源站为8C 16G，Nginx反代，静态文件和少量API混合，CDN回源到源站内网或公网入口。

场景A：缓存命中率95%，回源请求少，单请求响应体30KB左右。HTTP回源时源站CPU约12%~18%，HTTPS回源约15%~24%。差距不大，基本可以接受。

场景B：缓存命中率80%，回源请求中等，平均响应体50KB。HTTP回源CPU约30%~40%，HTTPS回源约40%~55%。源站还有余量，但HTTPS已经能看出额外消耗。

场景C：缓存命中率50%，接口多，小包多，回源连接复用一般。HTTP回源CPU约55%~70%，HTTPS回源可能到75%~95%，高峰时Nginx worker容易跑满。

场景D：缓存命中率低于30%，动态接口占比高。HTTP和HTTPS都不轻松，HTTPS回源会更早触碰瓶颈，但真正问题是CDN没挡住多少请求，源站还在扛主要流量。

这个差距换成一句工程里的话：在回源量不大、长连接正常的情况下，HTTPS回源对源站压力通常多10%~30%；在短连接、高回源、高QPS小包场景下，多出来50%甚至接近翻倍都不奇怪。

带宽压力差不多，CPU压力差得更多

很多人会问，HTTPS加密后是不是带宽也更大。确实会多一点TLS记录头、握手数据，但相对业务响应体通常不算大。大文件下载、图片、视频这类内容，HTTP和HTTPS回源的带宽差距基本可以忽略。

真正要盯的是CPU、连接数、握手耗时、源站负载。

大文件场景里，HTTPS主要是在传输过程中做对称加密，现代CPU有AES-NI，开销可控。反而是小文件和API场景，握手次数、请求调度、连接管理更容易成为瓶颈。

多说一句，如果源站是老CPU、虚拟化超售严重、没有AES-NI，HTTPS回源的体感会差很多。看监控时会发现流量没多大，但CPU sys和user都在涨，Nginx accept和SSL相关指标很难看。

HTTP回源为什么还有人在用

HTTP回源的优点很直接：省CPU、配置简单、排障方便。CDN节点和源站之间只要网络环境可信，HTTP回源在很多静态资源站、图片站、下载站里一直有人用。

尤其是源站在内网、专线、云厂商同地域网络里，CDN回源链路不经过复杂公网，HTTP回源的风险相对可控。比如CDN厂商提供源站私有回源、对象存储内网回源、云内负载均衡回源，这种情况下HTTP回源很常见。

但如果CDN到源站走公网，尤其是跨境公网、普通BGP线路、未知中间链路，HTTP回源就要谨慎。明文传输意味着Header、Cookie、URL参数、请求体都有被旁路看到的可能。哪怕业务觉得“没什么敏感数据”，登录态、鉴权Token、订单参数这些东西经常藏在请求里。

HTTPS回源适合哪些场景

有登录、支付、后台接口

只要涉及登录态、账号、支付、个人信息、管理后台，HTTPS回源更稳妥。用户到CDN是HTTPS，但CDN到源站如果改HTTP，中间这一段还是明文。很多安全审计不认这种配置。

这里补充一点，有些业务把动态API和静态资源放在同一个域名下，CDN配置也混在一起。这时建议至少把API域名单独拆出来，动态接口HTTPS回源，静态资源按实际情况选择HTTP或HTTPS回源。不要为了省一点CPU，把登录接口也走明文回源。

跨地域、跨境、公网回源

如果CDN节点回源到海外源站，或者国内节点回源到境外服务器，中间链路复杂，HTTPS回源更适合。跨境链路上可能经过多段运营商网络，普通BGP、CN2、GIA线路质量不同，但协议层安全不能完全依赖线路质量。

比如业务源站放在美国精品网，用户在国内，通过CDN做访问加速。此时如果源站承载登录接口或订单接口，建议HTTPS回源，并且源站证书、SNI、Host校验都配置好。购买海外源站时，也要看线路和防护能力。如果你也在找这种海外精品网络或高防源站，可以看看129云，像美国精品网-E型这类配置，16C 16G DDR4 ECC、200G SSD、175Mbps峰值、三网精品线路，更适合做中等规模业务源站或回源节点，客服热线400-9177118可以直接问线路和防护细节。

源站有足够CPU余量

HTTPS回源不是不能用，问题是源站有没有余量。现在16C、32C机器跑Nginx TLS并不夸张，只要证书链别太长，TLS版本合理，keepalive打开，性能一般够用。

如果源站平时CPU只有20%，高峰40%，HTTPS回源多消耗一点没什么。如果源站平时已经70%，高峰接近90%，那切HTTPS回源之后，高峰期可能直接把Nginx打到排队，表现为TTFB变长、502增加、CDN回源超时。

HTTP回源适合哪些场景

纯静态资源，且不带敏感Header

图片、CSS、JS、公开下载文件，如果URL里没有Token，Header里没有Cookie，HTTP回源通常能省一些源站资源。尤其是老机器、小规格云服务器，HTTP回源能明显降低CPU峰值。

但要注意，很多图片站会带防盗链签名，URL参数里有过期时间和签名。严格来说这也算敏感信息，虽然风险低于账号密码，但被截获后可能在有效期内复用。要不要HTTPS回源，看业务对盗刷和资源泄露的容忍度。

CDN和源站之间是可信内网

云厂商内部产品联动时，HTTP回源很常见。比如CDN回源到同厂商对象存储内网域名，或者CDN回源到内网SLB，再到业务集群。这类链路没有直接暴露公网，安全边界更清楚。

如果源站是公网IP，只是通过防火墙限制CDN回源IP，这还不等于“内网可信”。它只是限制了谁能访问源站，不代表传输内容不会在公网链路上明文经过。

源站压力不只看协议，还要看缓存命中率

很多线上问题一开始都在问“HTTPS回源是不是太重”，查到后面发现缓存命中率只有40%。这种情况下，改成HTTP回源只是把CPU救回来一点，但源站仍然在扛大部分请求。

CDN的价值是把可缓存内容挡在边缘节点。静态资源命中率做到90%以上，源站压力会很舒服。命中率低时，HTTP回源也救不了架构。

常见导致命中率低的配置包括：URL带随机参数、Cache-Control设置成no-cache、接口和静态文件混域、CDN没有忽略无意义参数、资源文件名不带版本号导致缓存策略保守。

实际排查时，可以先看CDN日志里的hit/miss，再看源站Nginx access log。不要只盯CPU。源站QPS、回源状态码、平均响应时间、连接数、TIME_WAIT数量，这些比单看协议更有价值。

Nginx上HTTPS回源的几个关键配置

源站用Nginx接CDN回源时，HTTPS配置不要只放证书就完事。TLS版本、会话复用、keepalive、worker数量都会影响压力。

建议启用TLS 1.2和TLS 1.3，关闭过老协议。证书链保持干净，不要挂一堆没必要的中间证书。ssl_session_cache要开，ssl_session_timeout不要太短。CDN侧如果支持源站长连接，也要一起打开。

源站反代到后端应用时，也要看后端连接池。很多时候CDN到Nginx已经复用得很好，但Nginx到应用层每次新建连接，压力还是会传到后端。

还有一个容易忽略的点：CDN HTTPS回源时要确认SNI。源站如果一个IP挂多个证书，CDN回源没有带正确SNI，可能导致证书不匹配、回源失败、间歇性502。有些CDN控制台里会有“回源Host”和“SNI Host”两个配置，不是同一个概念。

证书校验要不要开

HTTPS回源分两种：一种只是加密传输，不严格校验证书；另一种会校验证书域名、有效期、CA链。

如果只是为了防止链路明文泄露，加密传输已经比HTTP好。但从安全角度看，最好开启证书校验，避免中间人替换证书。问题是，开启校验后，证书过期、域名不匹配、源站自签证书都会导致回源失败。

线上更稳的做法是使用正规CA证书，提前监控证书有效期，源站域名和CDN回源SNI保持一致。不要等CDN报大量5xx才发现源站证书昨天过期了。

高防场景下的回源协议选择

有DDoS风险的业务，CDN或高防节点通常会挡在源站前面。这里回源协议还要考虑源站隐藏和攻击面。

如果源站公网IP暴露，攻击流量可能绕过CDN直接打源站。协议选HTTP还是HTTPS都不是关键，关键是源站只放行CDN回源IP，业务域名不要解析到源站，源站IP不要出现在历史解析、邮件头、第三方回调配置里。

高防CDN回源到源站时，如果业务有敏感数据，仍然建议HTTPS回源。攻击防护和传输加密是两件事。高防负责挡流量，HTTPS负责保护链路内容。

如果业务在西北地区，需要电信单线和基础防护，源站规格不用太大，129云的西安电信-B型可以作为轻量业务源站或备源使用，4C 4G DDR4 ECC、50G SSD、15Mbps上行、50Gbps单机防御，适合企业官网、区域业务、小型API入口这类场景。

跨境回源时，协议开销经常不是最大问题

跨境链路里，HTTPS比HTTP多出来的CPU开销还在，但用户真正感受到的往往是RTT、丢包、抖动。比如亚洲用户访问欧洲源站，即使用CDN，回源MISS时仍然要跨境拉数据。一次TLS握手多几个往返，在高RTT链路上会放大首包时间。

TLS 1.3比TLS 1.2好一些，连接复用也能减少影响。但如果资源频繁MISS，跨境回源延迟还是会明显。这个场景要重点优化缓存命中率、预热策略、源站区域选择，而不是只纠结HTTP还是HTTPS。

像英国伦敦这类节点，适合面向欧洲用户的业务源站。129云英国｜伦敦配置覆盖1核到4核、1G到8G内存、30Mbps带宽、200G到4TB流量，按上行计费，适合欧洲落地页、轻量业务、区域API。但如果主要用户在国内，不能只看机器价格，还要看回国线路和CDN覆盖。

实际配置时的判断方式

如果业务是公开静态资源，源站压力紧张，CDN到源站是可信网络，HTTP回源可以用。配置后重点看源站访问控制，确保只有CDN节点能回源。

如果业务有登录、支付、用户数据、后台接口，或者CDN到源站走公网，建议HTTPS回源。CPU不够就扩容源站、优化keepalive、提高缓存命中率，不建议为了省CPU把敏感链路改成HTTP。

如果静态和动态混在一个域名下，建议拆域名。static.example.com可以根据情况HTTP回源，api.example.com和admin.example.com用HTTPS回源。这个改动通常比在一个域名里写复杂规则更清楚，后面排障也省事。

如果源站CPU已经吃紧，切HTTPS回源前可以先做一轮压测：模拟CDN回源QPS、请求大小、连接复用比例。不要只用ab或wrk打一个长连接静态页，那种结果很容易过于乐观。压测里要包含小文件、接口、不同URL、短连接比例，才接近真实回源。

几个线上容易踩的坑

CDN回源HTTPS，但源站证书过期

用户访问CDN证书正常，不代表源站证书正常。CDN边缘证书和源站证书是两套东西。源站证书过期后，如果CDN开启严格校验，回源会直接失败。

回源Host配置错

CDN访问源站IP时，Host仍然要传业务域名，否则Nginx可能匹配到默认站点。HTTPS回源时还要看SNI，不然证书也可能不匹配。

源站只优化了HTTPS，忘了后端

Nginx TLS压力降下来了，但PHP-FPM、Java、Go应用后端连接池太小，一样会502。CDN回源协议只是入口层问题，不会自动解决应用层瓶颈。

缓存策略太保守

所有文件都设置no-store，CDN每次都回源。这个时候讨论HTTP和HTTPS差距意义有限，源站本来就没被CDN保护住。

压测时看哪些指标更靠谱

源站CPU要看，但不要只看总CPU。要分user、sys、softirq。HTTPS加解密通常会抬高user，连接和网络包处理会影响sys和softirq。

Nginx侧看active connections、accepts、handled、requests、reading、writing、waiting，再结合error log里的upstream timed out、SSL_do_handshake、connection reset by peer等信息。

CDN侧看回源QPS、回源带宽、回源状态码、回源耗时、缓存命中率。HTTPS回源导致压力上升时，通常会先表现为回源耗时增加，然后出现源站5xx或CDN 502/504。

系统层看TIME_WAIT、文件句柄、网卡队列、conntrack。如果源站前面还有iptables或安全组策略，连接数高时conntrack满了也会造成奇怪的间歇性失败。

一个比较贴近真实业务的选择示例

企业官网：大部分是图片、CSS、JS、HTML，表单很少。CDN命中率90%以上，源站在国内云服务器。可以HTTPS访问CDN，HTTP或HTTPS回源都行。如果表单涉及手机号、客户资料，表单接口单独走HTTPS回源。

游戏官网和补丁下载：下载包体大，公开资源多。补丁资源可以HTTP回源，登录、充值、账号接口必须HTTPS回源。高峰发布新包时，要提前CDN预热，避免大量MISS把源站带宽打满。

SaaS后台：接口多、用户数据多、权限复杂。建议全链路HTTPS，包括CDN到源站。源站CPU压力通过扩容、连接复用、缓存公共资源解决。

跨境电商：用户分布广，订单、支付、登录都敏感。HTTPS回源更合适。静态资源可以放对象存储或海外节点，就近缓存，减少跨境MISS。

资源站或图片站：如果资源公开，URL不带敏感信息，HTTP回源能降低源站压力。若有私有图片、签名URL、会员内容，至少私有内容域名要HTTPS回源。

源站配置不高时，HTTP和HTTPS的差距会更明显

小规格机器，比如2C 2G、4C 4G，跑动态应用、数据库、Nginx都在一台上，HTTPS回源的额外CPU会更敏感。不是TLS本身有多可怕，而是机器余量太小。

这类源站如果CDN命中率高，HTTPS回源也能跑；如果命中率低，高峰时CPU一上来，数据库和应用也会被拖慢。表现出来就是CDN偶发502、接口慢、静态文件也慢。

更稳的做法是把源站角色拆开：Nginx入口单独放，应用和数据库分离，静态资源尽量对象存储或独立文件源。机器预算有限时，至少别让数据库和高QPS HTTPS入口抢同一颗CPU。

直接给一个工程判断口径

HTTP回源省资源，尤其省CPU；HTTPS回源更安全，尤其适合公网、跨境、敏感业务。差距在低回源、长连接场景下可能只有10%~30%；在高回源、短连接、小包接口场景下可能放大到50%甚至更高。

如果当前源站CPU长期低于50%，CDN命中率不错，开启HTTPS回源通常问题不大。切换前确认源站证书、SNI、回源Host、keepalive。切换后盯24小时监控，重点看高峰期。

如果当前源站CPU高峰已经80%以上，不建议直接切HTTPS回源。先提高缓存命中率，打开回源长连接，拆静态和动态域名，必要时升级源站配置。等源站余量出来，再改回源协议。

如果业务安全要求高，源站压力又大，那就不要在HTTP和HTTPS之间硬省。该加机器加机器，该拆服务拆服务，该换更好的线路换线路。协议层省下来的CPU，抵不过一次敏感数据在公网明文传输带来的麻烦。