直接答案：Cloudflare 525 表示 Cloudflare 已尝试与源站建立 TLS，但握手失败，常见于源站 443 未监听、证书缺失或过期、SNI 选错证书、支持的 TLS 版本/加密套件不相交，或源站在高负载下重置连接。先用源站 IP 配合业务域名 SNI 做 openssl s_client 和 curl --resolve，再把同一时间的源站 TLS 错误日志与 Cloudflare Ray ID 对齐。525 在 Full/Full (Strict) 回源场景出现，重试不能替代修复。
本文聚焦 Cloudflare 边缘到源站的握手。若访客浏览器在到达 Cloudflare 之前提示证书不受信、域名不匹配，或 Cloudflare 返回 526，应分别检查边缘证书与严格验证失败的边界，不能把所有 SSL 错误都写成 525。
本文按 2026 年 9 月可查的官方文档核对。示例命令以只读取证为主；凡涉及删除、覆盖、重启、权限、网络或数据库参数的动作，都应先确认操作对象、备份、维护窗口和带外恢复入口。不同发行版与软件版本的路径可能不同，必须先查询实际配置再改。
先用证据判断故障在哪一层
| 现象或检查点 | 它能说明什么 | 直接证据 | 不要误判为 |
|---|---|---|---|
| 所有请求持续 525 | 源站 443、证书或协议配置普遍错误 | 直源握手与源站 error log | 浏览器缓存 |
| 仅某个主机名 525 | SNI 虚拟主机或证书覆盖错误 | 带不同 servername 的握手结果 | 整机网络故障 |
| 高峰期间间歇 525 | 连接、CPU、文件描述符或 TLS 资源耗尽 | 时间序列、握手失败和资源指标 | 证书一定过期 |
| 直源 IP 正常、带域名失败 | 默认站点与 SNI 站点不同 | openssl -servername 对照 | Cloudflare 节点故障 |
| 只有部分 Cloudflare 节点失败 | 路由、ACL 或源站限速可能按来源不同 | Ray ID、colo、源站来源与防火墙日志 | 随机用户问题 |
这张表的用法不是“看到一个关键词就改一个参数”，而是把客户端、DNS或边缘、Web 代理、应用、数据层依次分开。至少保留故障时间、完整 URL、状态码、关键响应头、同一时刻的服务日志和一份正常样本。只有时间能够对齐，才能判断两个现象是否属于同一次故障。
六步排查与修复顺序
1. 确认错误属于 525
保存错误页面时间、完整 URL、Ray ID 和客户端网络。查看 Cloudflare 分析中的边缘状态与源站状态，区分 525、526、522 与源站自己返回的 5xx；不同代码对应不同故障阶段。
2. 检查源站 443 与网络放行
在源站确认 443 监听的进程、地址族和虚拟主机，核对云安全组、系统防火墙和上游 ACL 是否允许 Cloudflare 当前回源网段。不要为了测试把管理端口和全部服务永久向全网开放。
3. 带正确 SNI 测试握手
使用业务域名作为 -servername 直连源站 IP，检查协商协议、证书主题、SAN、签发链、有效期与 verify return code。只访问 https://IP 常会命中默认虚拟主机，不能证明业务域名握手正常。
4. 核对证书链与协议组合
确认源站发送完整中间证书链，私钥与证书匹配，TLS 版本和加密套件与 Cloudflare 回源兼容。Full (Strict) 还要求证书有效且名称正确；不要通过全局启用陈旧协议来迁就单个旧客户端。
5. 调查间歇性资源问题
若只在高峰出现，按时间查看 Nginx/OpenSSL 错误、连接数、CPU、负载、文件描述符、accept 队列和证书热更新。多台源站要逐台测试，负载均衡中的一台坏节点会造成间歇 525。
6. 修复后从两条路径复验
先验证直源带 SNI 握手，再通过正式 Cloudflare 域名请求首页与动态接口。连续观察多个边缘位置和高峰窗口，确认不再出现 525/526，证书续期和 reload 也不会恢复到错误配置。
可复制的只读取证命令
以下命令中的域名、服务名、路径和时间范围要替换为自己的真实值。先执行查询命令并保存原始输出；不要把“命令能运行”误当成“业务已恢复”。
text
ss -lntp | grep ':443'
timeout 10s openssl s_client -connect 203.0.113.10:443 -servername www.your-domain.tld -showcerts
curl -sv --resolve www.your-domain.tld:443:203.0.113.10 https://www.your-domain.tld/ -o /dev/null
nginx -T
journalctl -u nginx --since '15 minutes ago' --no-pager
ss -lntp | grep ':443'：确认 443 的监听地址和进程；无输出时先修服务层timeout 10s openssl s_client -connect 203.0.113.10:443 -servername www.your-domain.tld -showcerts：带 SNI 直连源站查看证书链与协商结果，并限制等待时间curl -sv --resolve www.your-domain.tld:443:203.0.113.10 https://www.your-domain.tld/ -o /dev/null：使用正式 Host 与 SNI 验证源站 HTTP 响应nginx -T：读取实际生效的 listen、server_name、ssl_certificate 与协议配置journalctl -u nginx --since '15 minutes ago' --no-pager：查看故障窗口内 TLS、连接或 reload 错误；服务名按实际修改
如命令输出包含公网 IP、用户名、Cookie、令牌、数据库连接串或客户数据，分享工单前先脱敏。对比时保留时间戳、时区和命令本身，否则后来无法复现同一观察条件。
五个最容易扩大故障的误区
- 只检查浏览器证书：525 发生在 Cloudflare 到源站，浏览器看到的是边缘证书。
- 直接访问 IP 说握手正常：不带 SNI 可能命中另一张默认证书。
- 把 Full 改 Flexible 长期绕过：会取消边缘到源站 TLS，并可能引入重定向循环。
- 允许所有来源访问源站：排障范围过大，会暴露绕过 CDN 的路径。
- 忽略间歇性与节点差异：多源站或高峰资源耗尽时，一次成功握手不能排除故障。
变更、回滚与数据边界
证书或 Nginx 变更前备份配置、证书链与私钥权限，并用 nginx -t 验证。若 reload 后 525 增加，立即恢复上一份已验证配置和证书文件，再做平滑 reload；不要删除旧证书直至新链在正式 Host 下通过。调整 Cloudflare 模式只能作为有记录的短时缓解，必须设恢复 Full (Strict) 的条件和期限。
如果只能先恢复服务、还不能确认根因，应把措施标记为“临时缓解”，例如限流、摘除单节点、切回上一配置或临时绕过一层代理。恢复后仍要在受控环境复现原因，并验证同类故障不会在下一次重启、发布或高峰重新出现。
统一验收清单
- [ ] 443 在预期 IPv4/IPv6 地址监听
- [ ] 安全组和防火墙仅放行必要回源来源
- [ ] 带 SNI 的 openssl 验证成功
- [ ] 证书 SAN、有效期和完整链正确
- [ ] TLS 版本与套件有共同集合
- [ ] 每台源站节点均单独通过
- [ ] 正式域名不再返回 525/526
- [ ] 证书续期与 Nginx reload 已演练
验收必须同时覆盖机器内部和真实外部路径。首页返回 200 不能证明上传、长连接、登录、数据库写入或移动端都正常；同样，控制台显示“运行中”也不能证明应用已能处理请求。至少选一个正常请求、一个边界请求和一个失败请求，记录预期与实际结果。
相关内容与隔离测试入口
建议先阅读Cloudflare 521到524排查、SSL证书续期失败、服务器正常但网站打不开，把本问题放回完整请求链路。若生产环境不适合直接试验，可查看美国弹性云服务器的当前规格与库存，搭建与生产隔离的复现环境；测试机不能替代生产备份，价格、库存和可选配置以实时产品页为准。
常见问题
525 和 526 有什么区别？
525 是握手本身失败；526 通常表示在严格模式下源站证书验证无效。两者排查会重叠，但结论不能混写。
源站用自签证书可以吗？
Full 可能加密但不严格验证；Full (Strict) 需要 Cloudflare 信任的公开证书或符合要求的 Origin CA。应按威胁模型使用严格验证。
为什么重启 Nginx 后暂时正常？
可能释放了资源或加载了不同配置，但不能说明根因。要对齐高峰指标、错误日志和配置版本，排除文件描述符或坏节点。
525 是 Cloudflare 故障吗？
官方定义指边缘与源站握手失败，重点检查源站证书、端口、SNI、套件和日志；若多站同时异常再结合 Cloudflare 状态信息判断。
证书没过期为什么仍 525？
握手还依赖私钥、链、SNI、协议、套件、网络和资源。有效期只是其中一项。