Cloudflare 525 和 526 怎么排查：源站 TLS、证书与 SNI

区分 525 握手失败与 526 证书验证失败，保留域名直连源站，并检查 A、AAAA、代理日志和 Origin CA 信任。

浏览器连到 CDN，不代表源站 TLS 正常

Cloudflare 返回 525 或 526，先定位它到源站的 HTTPS 连接。525 表示这段 TLS 握手失败；526 表示源站证书无法通过验证。只确认浏览器地址栏有 HTTPS，还不足以说明源站证书和站点配置正确。

保存发生时间、完整域名、Ray ID 和 SSL/TLS 模式。若只有 www 或一个子域名报错，先检查该名称对应的 DNS、证书和站点块，不立即更改全部域名的加密设置。

525 的检查项包括源站 HTTPS 端口、防火墙、SNI、证书部署以及 TLS 协议和密码套件。526 在 Full (strict) 下重点查证书有效期、域名匹配、信任链与证书部署位置。

核对 Cloudflare 控制台实际保存的源站地址。橙云开启时，公开 DNS 通常返回 Cloudflare 地址；这不能用来确认源站 IP。多条 A、AAAA 或负载均衡源站要逐个检查，避免其中一台仍使用旧证书。

下面的 example.com 和 203.0.113.10 是示例，换成错误页面所用域名与真实源站 IPv4。在自己的电脑或可信诊断机器执行，保留证书验证：

bash；使用前请核对本文前提。

curl --resolve example.com:443:203.0.113.10 \
  -I --connect-timeout 5 --max-time 15 https://example.com/

这条命令连接指定 IP，同时使用 example.com 作为 Host 和 TLS SNI。直接请求 https://IP/ 可能得到默认证书或错误站点，无法代替按域名回源。HEAD 返回 405 时，可以改用不带 -I 的请求检查实际页面。

若源站使用 Cloudflare Origin CA 证书，普通系统信任库可能不认识它。此时 curl 的信任失败不能单独证明 Cloudflare 也不信任；应按 Origin CA 文档配置相应根证书，或从控制台和源站检查证书链。curl -k 会跳过证书验证，不能作为 526 已修好的证明。

如果 Caddy 运行在宿主机，可读取近期日志；Docker 部署则用真实代理服务名读取对应容器日志：

bash；使用前请核对本文前提。

journalctl -u caddy --since '30 minutes ago' --no-pager
# Docker 部署时把 proxy 换成实际服务名
docker compose logs --since=30m --tail=200 proxy

检查失败域名是否命中正确站点，HTTPS 是否在预期端口监听，证书是否过期或续签失败。改配置前保存原文件与证书数据，按所用代理的配置检查命令验证后再重载。证书挑战方式取决于部署条件，不由一次 525 推导出必须更换 DNS 插件。

修复后在预期的 Full (strict) 模式访问原来的完整 URL，并分别核对所有源站地址。检查登录、资源加载和子域名，确认没有只修好首页而遗漏其他站点。

若错误仍间歇出现，将新的发生时间与源站日志对应，再排查某个节点或网络路径。换 IP 本身不会修复证书域名、信任链或 SNI 配置；准备迁站时也应在切 DNS 前完成这些检查。