CDN回源用HTTP还是HTTPS？证书、SNI和端口怎么选

网站接入CDN后，用户访问的是CDN边缘节点，但边缘节点仍然可能需要向源站获取页面、接口或未缓存的文件。这个过程就是“回源”。

不少网站在接入阶段会遇到这种情况：用户访问已经启用HTTPS，源站也安装了证书，可CDN一回源就出现502、TLS握手失败、证书域名不匹配，或者页面陷入反复跳转。问题通常不是“有没有证书”这么简单，而是回源协议、端口、SNI、HTTP Host和证书域名没有对齐。

对于正常运行的生产网站，优先建议使用：

CDN到源站采用HTTPS回源，使用443或厂商支持的HTTPS端口，开启严格证书校验，并确保回源SNI对应的域名包含在源站证书的SAN中。

HTTP回源并非完全不能使用，但如果CDN与源站之间经过公网，HTTP会让这段链路失去传输加密和源站身份验证。登录信息、Cookie、接口数据以及回源鉴权头都可能暴露在未加密链路上。

用户访问HTTPS，不代表CDN回源也是HTTPS

一次经过CDN的HTTPS访问，实际上可能包含两条独立连接：

用户浏览器
    │
    │ HTTPS：验证CDN边缘证书
    ▼
CDN边缘节点
    │
    │ HTTP或HTTPS：由CDN回源配置决定
    ▼
源站服务器

第一条连接是用户与CDN之间的“边缘连接”，使用的是CDN为加速域名配置的边缘证书。

第二条连接是CDN与源站之间的“回源连接”，使用的是源站证书。即使浏览器地址栏显示安全锁，也不能据此判断回源链路是否加密。

因此，下列配置在技术上都可能存在：

如果希望配置简单、结果稳定，通常应在边缘将HTTP访问重定向到HTTPS，同时让CDN固定使用HTTPS回源，而不是让回源协议随着访客协议变化。

CDN回源应该选HTTP还是HTTPS

生产网站优先使用HTTPS回源

以下业务不应仅依赖HTTP回源：

• 登录、注册和用户中心；

• 电商订单与支付相关页面；

• API接口及带有Token的请求；

• 使用Cookie维持会话的网站；

• 管理后台、企业内部系统；

• 涉及个人信息或业务敏感数据的页面；

• 源站与CDN节点之间经过公共网络的业务。

HTTPS回源除了加密数据，还能通过证书验证源站身份。如果CDN严格检查证书，就能降低流量被转发到错误服务器或中间节点的风险。

什么情况下可能使用HTTP回源

HTTP回源通常只适合以下有限场景：

• 源站确实不支持TLS，暂时处于迁移阶段；

• CDN与源站之间使用受控专线、私有网络或加密隧道；

• 纯公开静态内容，且已经评估过回源链路风险；

• 内部测试环境，不承载真实用户数据。

即使源站位于私有网络，也应确认链路是否真正隔离，不能仅因为使用了内网IP就认定传输一定安全。HTTP回源更适合作为暂时兼容方案，而不是生产环境的默认选择。

先分清源站地址、回源Host和SNI

配置HTTPS回源时，最容易混淆的是下面三个值：

这三个值可以相同，也可以不同，具体取决于源站架构和CDN厂商提供的配置能力。

源站地址决定连接目标

源站地址可以是IP，也可以是专门的源站域名。例如：

源站地址：203.0.113.10
回源端口：443

或者：

源站地址：origin.example.net
回源端口：443

源站地址解决的是“CDN应该连接到哪里”。如果使用源站域名，应避免该域名再次解析回当前CDN，否则可能形成回源循环。

如需进一步区分边缘节点和真实源站，可以参考CDNChart的CDN节点IP和源站IP区别说明。

SNI决定源站返回哪张证书

同一个IP和443端口上可以部署多个HTTPS网站。TLS握手发生时，HTTP请求还没有发送，服务器无法根据HTTP Host选择站点，因此客户端会在握手阶段通过SNI告诉服务器准备访问哪个主机名。

RFC 6066对SNI的定义说明了客户端如何在TLS ClientHello中携带服务器名称，使同一地址上的多个虚拟主机能够选择相应证书。

例如源站同时托管多个网站：

203.0.113.10
├── www.example.com
├── api.example.com
└── static.example.com

如果CDN回源时没有发送SNI，或者发送了错误的SNI，服务器可能返回默认站点的证书。此时端口虽然能够连接，TLS握手仍可能因为证书域名不匹配而失败。

回源Host决定请求进入哪个网站

TLS握手完成后，CDN才发送HTTP请求。请求中的Host决定Nginx、Apache、负载均衡器或应用网关把请求交给哪个虚拟主机。

因此可能出现：

源站地址：203.0.113.10
SNI：origin.example.net
Host：www.example.com

这表示：

1. CDN连接203.0.113.10:443；

2. TLS握手使用origin.example.net作为SNI；

3. 源站返回覆盖origin.example.net的证书；

4. TLS成功后，HTTP请求使用Host: www.example.com；

5. Web服务器把请求交给www.example.com对应的站点。

并非所有CDN都允许SNI和回源Host分别设置。有些厂商默认让两者保持一致，有些会在修改Host时同步修改SNI，还有些需要单独创建回源规则。配置前必须查看当前厂商文档，不能假设所有CDN行为一致。

源站证书应该包含哪个域名

源站证书需要匹配CDN实际用于证书校验的名称，通常就是回源SNI或厂商定义的源站主机名。

例如：

回源SNI：origin.example.net

那么源站证书的Subject Alternative Name，也就是SAN，至少应包含：

DNS:origin.example.net

RFC 9525的服务身份验证规范明确强调，应通过证书的subjectAltName验证DNS名称，而不是只依赖证书Common Name。

检查时不要只看证书是否过期，还要核对：

• 证书是否在有效期内；

• SAN是否包含回源校验域名；

• 中间证书链是否完整；

• 签发机构是否被CDN信任；

• 源站是否在目标端口返回了正确证书；

• 多源站环境中的每台服务器配置是否一致。

通配符证书也有边界。*.example.com通常可以覆盖origin.example.com，但不能覆盖根域名example.com，也不能覆盖a.origin.example.com这样的多级子域名。

公共CA证书还是CDN源站证书

源站通常可以使用以下证书：

例如，Cloudflare的Full (strict)模式说明要求源站证书有效、域名匹配，并由受信任的公共CA或其Origin CA签发。 这属于Cloudflare的具体行为，其他CDN是否接受厂商源站证书、自签名证书或私有CA，需要分别确认。

如果未来可能切换CDN或使用多CDN，公共CA证书通常更容易迁移。厂商专用源站证书则适合源站只允许该厂商访问的架构，但不能把它当作所有客户端都能验证的普通公网证书。

回源端口应该选80、443还是8443

协议和端口是两个独立配置项，但常见对应关系如下：

把端口改成8443并不会自动提高安全性。安全性来自TLS、证书验证、访问控制和正确的源站认证，而不是端口数字是否少见。

还要区分两个概念：

• 用户访问CDN使用的边缘端口；

• CDN连接源站使用的目标端口。

用户通过443访问CDN，不代表CDN必须连接源站443；但如果把HTTPS回源配置成80，而源站80只接受普通HTTP，CDN发送TLS握手时就会失败。反过来，将HTTP协议发往只监听TLS的443端口，也会出现连接被重置、无有效响应或协议错误。

自定义端口上线前至少确认：

CDN支持该回源端口
源站服务正在该端口监听
监听协议与回源协议一致
防火墙允许CDN回源网络访问
证书在该端口正确加载
健康检查使用相同或兼容的协议

一套更稳妥的生产配置

对于常规网站，可以从下面这套配置开始：

用户访问协议：HTTP自动跳转HTTPS
CDN回源协议：HTTPS Only
回源端口：443
源站地址：专用源站域名或源站负载均衡地址
回源SNI：源站证书覆盖的域名
回源Host：应用实际识别的业务域名
证书校验：严格验证
源站访问控制：限制CDN回源来源或启用回源认证

如果源站证书覆盖www.example.com，Web服务器也以www.example.com作为虚拟主机，可以让SNI和Host都使用该域名。

如果源站使用独立域名，则可以采用：

源站地址：origin.example.net
回源SNI：origin.example.net
回源Host：www.example.com

前提是CDN支持分别设置SNI和Host，并且源站证书覆盖origin.example.net。

不要把“忽略证书错误”作为长期配置。它虽然可能暂时让回源恢复，但会失去源站身份验证，使HTTPS只剩下加密而缺少可靠认证。

用curl直接验证HTTPS源站

测试源站时，不建议直接访问：

curl https://203.0.113.10/

这种方式可能没有发送正确SNI，还会按照IP校验证书，无法真实模拟CDN的域名回源。

如果SNI和Host都应该是www.example.com，可以使用：

curl -sS -D - -o /dev/null \
  --resolve www.example.com:443:203.0.113.10 \
  https://www.example.com/

--resolve只在本次请求中将www.example.com:443连接到指定IP，URL中的域名仍用于TLS SNI、证书校验和HTTP Host。curl官方手册对--resolve的定义也是为指定的主机名与端口临时设置连接地址。

重点观察：

• 是否成功完成TLS握手；

• 返回的HTTP状态码；

• 证书校验是否通过；

• 响应是否来自正确站点；

• 源站日志能否看到这次请求。

如果回源SNI和Host不同，可以分别模拟：

curl -sS -D - -o /dev/null \
  --resolve origin.example.net:443:203.0.113.10 \
  https://origin.example.net/ \
  -H 'Host: www.example.com'

这个命令使用origin.example.net建立TLS连接并校验证书，然后在HTTP请求中发送Host: www.example.com。

测试只应针对自己管理或已经获授权的源站。不要在公开文章、工单截图或聊天记录中暴露真实源站IP、内部域名、Cookie和认证Token。

用OpenSSL检查SNI和证书链

需要查看源站实际返回的证书时，可以执行：

openssl s_client \
  -connect 203.0.113.10:443 \
  -servername origin.example.net \
  -verify_hostname origin.example.net \
  -verify_return_error \
  -showcerts </dev/null

检查以下输出：

subject=
issuer=
X509v3 Subject Alternative Name
Verify return code

正常情况下，SAN应包含origin.example.net，证书仍在有效期内，证书链完整，并且验证结果为成功。

如果不加-servername，共享IP上的服务器可能返回默认证书。这恰好可以帮助确认“CDN没有发送正确SNI时会发生什么”，但不能用这种结果直接判断源站证书配置错误。

不要依赖curl -k或openssl忽略验证错误来证明配置已经恢复。跳过校验只能用于定位“问题是否确实来自证书验证”，不能作为生产环境的修复方案。

不同测试结果分别说明什么

不同CDN使用的错误码并不完全一致。例如，有些厂商会把源站TLS失败统一显示为502，有些会提供单独的握手或证书错误码。因此，不能只根据前台错误页下结论，还要查看CDN控制台中的回源错误原因。

为什么开启HTTPS回源后出现重定向循环

常见错误配置是：

1. 用户通过HTTPS访问CDN；

2. CDN使用HTTP连接源站；

3. 源站发现请求是HTTP，于是跳转到HTTPS；

4. CDN仍然以HTTP回源；

5. 源站再次跳转。

还有一种情况是CDN已经使用HTTPS回源，但源站应用没有正确识别反向代理传递的协议，仍把请求判断成HTTP。

排查时可以查看：

curl -sS -I https://www.example.com/

观察Location是否反复指向同一URL，并检查源站应用是否正确、可信地处理X-Forwarded-Proto或厂商提供的等效请求头。

只有来自受信任CDN或反向代理的转发头才能用于协议判断。不要允许任意公网客户端伪造转发头影响安全跳转或应用逻辑。

修改后怎样确认回源真正恢复

不要只测试一次首页。建议按下面的范围复查：

• 首页、静态资源和动态接口是否正常；

• 首次访问或缓存MISS时是否能够成功回源；

• 清理测试对象缓存后是否仍能重新获取；

• 不同源站、负载均衡后端是否返回同一套证书；

• HTTP是否正确跳转到HTTPS；

• API的Cookie、认证头和请求体是否正常传递；

• CDN控制台是否仍记录TLS或连接错误；

• 源站日志中的Host、协议判断和状态码是否符合预期。

可以使用CDNChart的网站测速工具从公开用户路径观察不同地区的状态码和访问表现，但公开测速不能直接看到CDN内部使用的回源SNI和证书校验结果，这部分仍要结合CDN控制台、源站日志及定向命令判断。

如果尚未确认请求是否真正经过CDN，可以先通过CDN检测工具辅助查看域名解析、节点和厂商线索。证书链与公开端点的检查边界，则可以参考CDN安全评分中的TLS说明。

常见问题

用户访问已经是HTTPS，回源使用HTTP会影响浏览器安全锁吗？

浏览器可能仍然显示安全锁，因为浏览器验证的是用户到CDN边缘节点的连接。但是CDN到源站这一段仍然是明文，浏览器不会直接感知这段链路。因此，有安全锁不等于端到端两段链路都已加密。

源站使用IP作为回源地址，证书需要包含这个IP吗？

不一定。CDN可以连接源站IP，同时使用域名作为SNI和证书校验名称。只要厂商支持这种配置，证书覆盖SNI域名即可。如果CDN确实按照IP校验证书，则证书必须包含相应的IP地址标识，但公网证书和不同CDN对此支持有限，通常更适合配置明确的源站域名。

SNI和回源Host必须一样吗？

不必须。SNI在TLS握手阶段用于证书选择和身份校验，Host在TLS完成后的HTTP请求中用于站点路由。两者可以不同，但CDN和源站必须同时支持这种配置。若厂商会自动同步两者，就不能按照完全独立的字段来设计。

源站安装了证书，为什么CDN仍然返回502？

“安装了证书”只能说明源站具备TLS配置，不能证明证书有效。证书过期、SAN不匹配、中间链缺失、SNI错误、CA不被CDN信任、端口未监听以及TLS版本不兼容，都可能导致回源失败。部分CDN会把这些错误统一呈现为502。

HTTPS回源一定要使用443端口吗？

不一定，但443兼容性最好。使用8443或其他端口前，需要确认CDN允许该回源端口、源站实际以TLS监听、防火墙已经放行，并且健康检查与业务请求使用兼容的协议。更换端口本身不会提升加密强度。

能不能用自签名证书做HTTPS回源？

只有在CDN明确支持自签名证书、私有CA或证书固定，并且已经配置相应信任关系时才可以。否则严格校验会失败。不要通过长期关闭证书验证来兼容自签名证书。

HTTPS回源配置正确后，还需要限制源站访问吗？

需要。HTTPS负责加密和验证连接，不等于源站已经禁止绕过CDN访问。可以结合CDN回源地址限制、源站鉴权、厂商提供的认证回源或mTLS能力保护源站。配置访问控制时应保留管理和应急通道，避免因厂商地址范围变化导致整个源站不可达。