Cloudflare 报 525 或 526，源站证书怎么查？

Cloudflare 返回 525 或 526，先查它到源站的连接。浏览器到 Cloudflare 是 HTTPS，也不能说明源站证书正常；这是两段不同的连接。

525 和 526 分别查什么

525 表示 Cloudflare 与源站的 TLS 握手失败；常见检查项包括 443 可达性、SNI、证书部署和协议配置。526 表示源站证书无法通过验证，在 Full (strict) 场景下应检查有效期、域名匹配和信任链。

先保存完整 URL、发生时间、Ray ID 与 SSL/TLS 模式。只有 www 或某个子域名失败时，核对该名称的 DNS、站点块和证书覆盖范围，不先改全站加密模式。

直连源站时保留域名

将示例域名和文档专用 IP 换成自己的值。第一条让请求连接指定源站，同时保留 HTTP Host、TLS SNI 和域名校验；第二条查看握手与服务器发送的证书：

curl -v --resolve example.com:443:203.0.113.10 https://example.com/
openssl s_client -connect 203.0.113.10:443 \
  -servername example.com -showcerts </dev/null

直接请求 IP 可能拿到默认站点证书，结果不能代表域名。openssl s_client 打印出证书也不等于已经通过完整验证，要结合验证结果、证书域名与信任关系看。

源站只允许 Cloudflare 地址，或启用了 Authenticated Origin Pulls 时，普通客户端直连可能被拒绝。应在授权网络内诊断或查看源站日志，不长期关闭限制。使用 Cloudflare Origin CA 的源站证书可能不受本机系统 CA 信任；本机报不受信任，不能单独证明它对 Cloudflare 无效。

每个源站地址分别核对

若域名配置多个 A、AAAA 或多个源站，逐一检查相同主机名下的结果。一台节点证书正常、另一台过期，会出现间歇成功。只刷新一次看到 200，不能解释失败节点。

证书签发失败时，看当前挑战类型与日志。Caddy 的 HTTP、TLS-ALPN 和 DNS 挑战有不同前提，不能由一次错误推导出所有 Cloudflare 网站都必须装 DNS 插件。systemd 运行的 Caddy 可以读取：

journalctl -u caddy --since '30 minutes ago' --no-pager

Docker 部署则读取实际代理容器日志。把错误域名和时间对应起来，保存原配置与证书数据，验证配置后重载；不靠删除证书目录反复申请。

修好后，在 Full (strict) 下再访问

修复证书、域名或端口以后，在预期的 Full (strict) 设置下访问原来的完整 URL，检查所有相关节点。curl -k 只适合辅助查看响应，它跳过证书校验，不能作为证书问题修复的证据。

这类错误通常先从现有部署处理。准备迁移服务器时，应先按建站主机的域名、备份与迁移条件选方案，在新源站验证同一域名的证书和站点，再切 DNS；换 IP 本身不会修正证书配置。

确需更换源站时，先选能按现有部署方式配置域名、有效证书和 CDN 回源规则的 Linux 实例。个人网站可比较 雨云 RCS 的建站入口与系统，或查看 ECS 的网络与存储方案。直连新源站时保留域名，检查证书和网站，再切正式流量；证书链、SNI 与信任问题仍需修复，换 IP 不能自动解决 525 或 526。