Cloudflare 多层子域名报 ERR_SSL_VERSION_OR_CIPHER_MISMATCH：检查边缘证书覆盖

https://www.example.com 能打开，换成 https://www.api.example.com 却报 ERR_SSL_VERSION_OR_CIPHER_MISMATCH。源站 Caddy 已为后一个域名生成证书，反复调整 Caddy 密码套件仍无效。若该名称开启了 Cloudflare 代理，先检查浏览器实际连接的边缘证书是否覆盖这个完整名称。

在以 example.com 为区域、使用常规完整 DNS 接入的情况下，默认 Universal SSL 覆盖根域和一层子域，如 api.example.com，不会自动覆盖 www.api.example.com。后者多了一层。源站证书存在，不能替代 Cloudflare 在浏览器连接上提供的证书。

相同浏览器错误也可能出现在边缘证书未激活、已过期或其他 TLS 配置故障中，不能只数域名中的点就认定根因。

对照访问名称、代理状态和边缘证书

先记录地址栏最后使用的完整主机名，包含重定向后的名称。检查该记录实际是否走 Cloudflare 代理，再到该区域的 SSL/TLS → Edge Certificates 查看相关证书的状态及覆盖名称。

对于这个示例中的区域，名称关系如下：

主机名	默认 Universal SSL 覆盖
example.com	覆盖根域
api.example.com	覆盖一层子域
www.api.example.com	不默认覆盖这个多层名称

表格不代表你的当前证书清单。已有额外证书、不同接入方式，或者 Cloudflare 实际管理的是另一个区域时，都要按实际配置判断。证书状态 Active 也不等于其中含有每个业务域名，应同时检查名称范围。

若握手能够完成，可在浏览器查看服务实际提供的证书。握手已经失败、没有提供适用证书时，不能因为浏览器里看不到证书详情，就跳过后台的覆盖检查。

给公开入口配置能够覆盖它的证书

确认多层名称不在现有边缘证书范围后，可以按账户当前可用的能力，为该名称配置 Advanced Certificate，使用 Total TLS 为未被 Universal 覆盖的代理主机名签发证书，或上传符合要求的 Custom Certificate。具体权限和产品条件应以账户为准，不能把“配置了源站证书”当成这些边缘方案的替代。

变更前保存原来的 DNS、边缘证书与应用域名配置。新证书需要覆盖完整主机名并处于有效状态；申请或上传动作完成，不保证边缘已能立即提供它。按后台状态和实际访问结果验收，不反复删除现有证书。

如果业务允许改成一层名称，例如 api.example.com，也可以调整公开入口。但这会影响客户端地址、回调、Cookie、跨域及已发布的链接，需要一起规划。仅在故障的 HTTPS 主机上添加重定向，不能修复建立 TLS 之前的失败：客户端要先完成握手，才能读到 HTTP 重定向。

关闭代理后的成功，要解释为换了一条连接路径

把记录改成 DNS only 后，浏览器可能直接连接源站并使用 Caddy 的证书。直连成功只证明这条路径可用，不证明 Cloudflare 的边缘证书问题已经修复；此时 Full (strict) 等代理模式也不能控制这条浏览器直连路径。

需要临时直连时，先确认源站有浏览器信任、覆盖实际名称的证书，并允许计划中的访问。Cloudflare Origin CA 证书不能单独承担普通浏览器的公网信任。原来仅允许 Cloudflare 地址的防火墙或依赖代理的访问规则，也可能让直连失败。

DNS only 会改变公开解析和流量入口，代理提供的访问控制与缓存等行为也随之变化。不要把关闭代理当作多层证书故障的无影响通用修复；回到代理路径前仍要完成对应边缘证书配置。

以原来的完整 HTTPS 地址验收

证书调整后，从实际访问网络请求原来失败的多层 URL，确认 TLS 能建立，证书与该名称匹配，随后应用内容和跳转符合预期。不同缓存与地址结果需要分别核对，一次从本机直连成功不能替代代理入口验收。

若随后出现 Cloudflare 525 或 526，那是继续检查 Cloudflare 到源站的握手或证书验证；浏览器到边缘已通过，与源站连接正常是两个独立结果。不要用降低源站校验模式处理边缘未覆盖名称。

需要撤回时，恢复保存的 DNS 和业务入口配置，并保留仍在使用的有效证书。DNS 缓存可能让新旧入口并存一段时间，回退期间两条计划中的路径都应有匹配的服务与证书。