证书部署完成后，网站可能出现证书不匹配、反复跳转、部分页面打不开或加速失效。排查HTTPS证书部署与加速兼容，不要先反复更换证书；先画清请求经过的路径：浏览器是否直接连接源站，还是先到代理或加速节点，再由它连接源站。证书、TLS终止位置和回源协议必须对应同一条路径。
先确认 HTTPS 在哪一层结束
如果用户连接的是边缘节点，浏览器看到的证书通常由该节点提供；边缘节点再通过 HTTP 或 HTTPS 访问源站。另一种常见方式是代理只转发加密流量，由源站完成 TLS 终止。两种模式都可用，但不能把它们的设置混在一起：前者要分别核对客户端侧和回源侧，后者要确认代理没有误处理加密连接。
查看域名解析、代理控制台中的 HTTPS 模式，以及源站的 Nginx、Caddy 等服务配置，标出 443 端口由谁监听、证书装在哪里。若近期改过代理模式或 DNS 指向，先确认请求是否仍走预期节点。
按故障现象逐层检查
浏览器报证书错误
核对证书的域名是否包含当前访问的主机名，证书是否过期，以及服务器是否发送完整的证书链。还要检查 SNI：同一 IP 承载多个站点时，服务端需依据客户端提供的域名选择证书。可用 OpenSSL 的 s_client 检查实际握手返回的证书与链，再与浏览器看到的结果对照；如果两者不同，问题可能在中间代理或不同节点配置不一致。
页面循环跳转或部分请求失败
检查代理与源站之间的协议。若边缘已通过 HTTPS 访问源站，而源站又根据未识别的转发协议强制跳转 HTTPS，可能形成循环。查看代理传递的原始协议标记，以及 Nginx 的跳转规则；确认源站能正确识别外部请求原本使用 HTTPS。也要核对 80、443 端口监听和防火墙规则，避免只开放了其中一段连接所需的端口。
加速失效但证书正常
证书主要影响 TLS 握手，并不会直接让静态文件缓存变慢。应检查 HTTPS 与 HTTP 是否套用了不同缓存规则、跳转响应是否被缓存，以及代理是否把动态请求误判为可缓存内容。清理相关缓存后，用同一资源连续请求并比较响应状态、缓存命中标记和响应头；若响应来自旧规则，继续检查节点配置是否已同步。
建议按这个顺序操作
- 记录故障域名、发生时间和浏览器错误；分别确认直连源站与经过加速层时的表现。
- 明确 TLS 终止点，并检查对应位置的证书域名、有效期、证书链和 SNI 选择。
- 核对源站回源协议、端口监听、转发协议标记及 HTTP 到 HTTPS 的跳转规则。
- 最后检查缓存策略和节点配置，清除相关缓存后再次验证；每次只改一项，便于确认原因。
如果代理与源站都配置证书，这本身不一定冲突：关键是客户端侧证书由正确的一层提供，且回源侧的加密要求与源站配置一致。按路径逐段验证，通常比同时改证书、跳转和缓存更容易定位问题。
常见问题
源站和加速节点都要安装证书吗？
取决于回源是否使用 HTTPS。客户端侧需要可被访问者信任的证书；HTTPS 回源时，源站还需提供符合代理校验要求的证书。
证书刚续期，为什么部分访问仍报旧证书？
不同节点或源站可能尚未更新到同一证书，也可能有多台服务使用不同配置。逐个检查实际握手结果，并确认部署已覆盖所有接入点。
开启 HTTP/2 会与证书冲突吗？
通常不会。应确认 TLS 已在对应层正确启用，并检查代理与源站支持的协议配置；若故障只在特定连接方式出现，再针对该层测试。
怎样判断问题在代理还是源站？
比较经过代理和直连源站时的证书、状态码及跳转次数。两种结果不同，优先检查代理侧；结果相同，再查源站服务和证书配置。
把接入层、回源层和缓存层分开验证，才能避免把多种故障混为一谈。对于HTTPS证书部署与加速兼容，先确认 TLS 终止点，再逐项检查证书、协议和跳转，是最稳妥的排查起点。