中文问答

Cloudflare 525 怎么修复（Nginx）

更新于 2026年6月7日

525 表示 Cloudflare 已连到你的源站，但 TLS 握手没有完成。Nginx 场景下，最常见原因是证书链错误、SNI 落到错误 server block、或 443 TLS 监听配置异常。

推荐排查顺序

1. 确认 Nginx 在 443 ssl 正常监听，且目标域名命中正确的 server_name。
2. 检查 ssl_certificate 与 ssl_certificate_key 指向的文件是否正确，证书链是否完整。
3. 用目标域名 + 源站 IP 强制握手，确认返回证书与域名一致。
4. 源站检查通过后，再回 Cloudflare 验证。

建议直接执行的命令

sudo nginx -t
sudo systemctl status nginx --no-pager -n 30
sudo journalctl -u nginx --since '30 minutes ago' --no-pager | tail -n 120

sudo ss -lntp | grep ':443'
sudo nginx -T | sed -n '/server_name yourdomain.com/,+50p'

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com -showcerts </dev/null | head -n 80
curl -Iv --resolve yourdomain.com:443:ORIGIN_IP https://yourdomain.com/

线上常见错误

• 只部署了叶子证书，没有中间证书链。
• 默认 TLS 站点先匹配，导致返回了别的证书。
• 复制旧 TLS 配置，协议/套件过旧导致握手不兼容。

Cloudflare SSL 模式对照

• Flexible：Cloudflare 与源站走 HTTP，不会触发 525，但一般不建议生产使用。
• Full：源站需要 TLS，证书校验相对宽松。
• Full (strict)：源站 TLS 和证书有效性都要通过域名与证书链校验。

如果你从 Full 切到 Full (strict) 后开始报 525，先查证书链与 SNI，再判断是否属于 526 的证书有效性问题。

可回滚的修复顺序

1. 先备份当前 Nginx 配置和证书文件。
2. 每次只改一个层面（证书链或 server block 映射）。
3. 执行 nginx -t 与源站直连握手验证。
4. reload Nginx 后再走 Cloudflare 复测。
5. 若仍失败，回滚本次改动，再检查下一层。

修复成功信号

修复后，Cloudflare 代理访问公开页面应以 200/301/304 为主，重复检查不再出现 525。

如果页面提示 526，可继续看：Cloudflare 526 怎么修复（证书无效）。

如果你用的是 Caddy，可参考：Cloudflare 525 怎么修复（Caddy）。

按你的环境生成排查清单