Cloudflare 525 与 526：按域名、握手和证书分开排查
从网友误访旧子域名的 525 案例出发，区分握手失败与证书验证失败，保留 SNI、证书链、签发日志及配置恢复的检查路径。
网站经过 Cloudflare 后出现 525 或 526，浏览器地址栏显示 HTTPS，并不能证明源站的 TLS 正常。请求经过浏览器到 Cloudflare、Cloudflare 到源站两段连接；这两类错误需要检查后一段。
先保留出错的完整域名、发生时间、Ray ID 和当前 SSL/TLS 模式。525 表示 Cloudflare 与源站 TLS 握手失败；526 在 Full (strict) 等相关场景下表示源站证书无法通过验证。不要见到这两个数字就反复重启应用，或把加密模式降级作为长期修复。
先确认你访问的确实是当前域名
域名曾因证书签发限额或其他原因切换时，旧书签、跳转或配置仍可能把请求送到旧子域名。重启偶尔恢复并不能证明当前请求使用了正确的域名和证书。
核对实际请求的主机名：浏览器书签、跳转、反向代理站点块和证书 SAN 中的名字是否一致。example.com 与 www.example.com 是两个主机名，为其中一个签发证书，不保证另一个也在证书范围中。
如果只有一个子域名失败，而其他域名都正常，优先检查这个域名对应的 DNS 记录、站点配置和证书，不要先改动全站的 TLS 策略。
握手失败与证书不被信任，要看不同证据
| 现象 | 优先检查 | 需要保留的证据 |
|---|---|---|
| 525，连握手也无法完成 | 源站 443、SNI、TLS 配置、客户端证书要求 | 同时间的源站 TLS 日志和直接连接结果 |
| 526，证书验证失败 | 有效期、域名匹配、信任链、证书是否正确部署 | 源站实际返回的证书及完整链 |
| 部分请求或部分地址失败 | 不同源站节点、A/AAAA、不同站点配置 | 每个源站地址与相同域名的检查结果 |
| 签发阶段报 ACME 错误 | 挑战类型、解析、端口和令牌权限 | 证书管理程序的签发日志 |
不同错误可能同时存在。例如修复握手问题后，又暴露出证书验证失败。应记录当前错误的变化，而不是要求一个操作同时解决所有层次。
直接检查源站，但保留请求域名
下列地址只是示例，使用时替换为你自己的域名和源站 IP：
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
curl --resolve 让这一次请求连接指定 IP，同时保留域名用于 HTTP Host、TLS SNI 和证书校验。直接请求 https://203.0.113.10/ 可能拿到默认站点证书，无法代表实际域名的结果。openssl 用来查看握手与服务器返回的证书；它的输出也要结合验证结果解释，不能把“打印出了证书”当作证书已经受信任。
如果源站防火墙只允许 Cloudflare 地址，或启用了 Authenticated Origin Pulls，普通客户端直连可能被拒绝。这时应在授权网络内诊断或查看源站日志，不能因为本机连不上，就认定 Cloudflare 一定也连不上。不要为了测试而长期关闭这些限制。
Cloudflare Origin CA 证书也不一定被本机系统 CA 信任。curl 在这种情况下报不受信任，不能单独证明它对 Cloudflare Full (strict) 无效；需要按 Origin CA 的信任关系判断。若借助 -k 只查看返回内容，它绕过了证书验证，结果不能用于证明证书问题已经修复。
Caddy 签发失败时，不要只改业务代理
如果签发日志报 ACME 的 TLS-ALPN 挑战失败，要检查验证连接是否直接到达 Caddy。TLS-ALPN 验证要求签发机构与 Caddy 协商 TLS；Cloudflare 代理介入后，验证连接先到 Cloudflare，可能导致这条签发路径失败。仅凭这个错误，不能认定所有使用 Cloudflare 的 Caddy 都必须安装 DNS 插件。
Caddy 支持不同挑战方式。选择 HTTP 挑战时要满足对应入口可达要求；选择 DNS 挑战时需要相应 DNS 模块、令牌权限和解析配置。根据实际签发错误选择路径，而不是频繁删除证书数据或强制重签。
Docker 部署查看证书管理服务日志；systemd 部署可以查看：
journalctl -u caddy --since '30 minutes ago' --no-pager
日志中的挑战名称、失败域名和时间应对应当前请求。脱敏令牌、账户信息和内部地址后再分享。修复证书部署或域名配置前保存原配置及证书数据，先检查配置，再重载服务；不要用删除持久化目录来触发重新签发。
恢复后从真实入口确认
保留 Full (strict) 等预期的安全配置，通过原来出错的完整 URL 再访问，检查所有配置中的源站节点和相关主机名。既要确认 Cloudflare 入口不再返回同一错误，也要确认源站部署的证书、站点配置与当前域名对应。
如果仍有间歇错误，把每次 Ray ID、时间和失败节点关联起来。一次刷新成功可能只是请求换到了正常节点，不能替代对异常节点的检查。