Cloudflare 错误代码不用猜：1016、521、1000、403、SSL 握手失败和 500 逐个修

Cloudflare 报错最麻烦的地方，是页面只给你一个代码，却没有直接告诉你该改 DNS、证书、防火墙，还是 WordPress 程序。很多站长看到 error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed、cloudflare error 500 后，第一反应是清缓存、切 SSL 模式、关插件。偶尔能碰巧恢复，但也可能把后台登录、支付回调、REST API 和图片 CDN 一起弄乱。

更安全的处理方式是按层级排查：DNS 能不能找到源站，Cloudflare 能不能连到源站，SSL 握手是否通过，WAF 有没有拦截，最后再看 WordPress、PHP 和数据库日志。下面这份清单按真实站点维护顺序写，适合 WordPress、WooCommerce、企业官网、Elementor 页面站使用。

排查前先记录 6 个信息

不要一看到错误就连续改配置。Cloudflare 的 Security Events、服务器日志、缓存刷新都有时间差，如果连续改三四个地方，后面很难判断是哪一步修好的，也容易把一个小问题变成多个问题。

• 错误代码和完整页面截图，特别是 Ray ID。
• 出错 URL，是全站、后台、某个接口，还是只有图片文件。
• 发生时间和访客地区，便于对照 Cloudflare 事件。
• DNS 当前是橙云代理还是灰云直连。
• 最近是否改过 DNS、SSL 模式、缓存插件、安全插件或主机防火墙。
• 源站直连是否正常，可以用 hosts、灰云或服务器临时域名测试。

站内之前整理过 Cloudflare 报错别乱改：1016、521、1000、403、SSL 握手失败和 500 的修复顺序，本文会更偏向“看到某个错误代码后，具体点哪里、查什么、怎么改”。

Error 1016：Origin DNS error，先修 DNS 解析链

error 1016 的意思是 Cloudflare 找不到源站 DNS。它通常不是 WordPress 插件报错，也不是服务器内存不足，而是某个主机名没有解析记录、CNAME 目标失效、迁站后记录没改全，或者第三方平台已经取消了绑定。

处理步骤

1. 进入 Cloudflare 后台 DNS，找到出错主机名，例如 @、www、shop、cdn、api。
2. 确认它有 A、AAAA 或 CNAME 记录。没有记录时，Cloudflare 就不知道回源到哪里。
3. 如果使用 A/AAAA，目标必须是当前源站公网 IP，不要填旧主机 IP、内网 IP、127.0.0.1，也不要填 Cloudflare 边缘 IP。
4. 如果使用 CNAME，把 CNAME 目标复制出来单独查询，确认目标域名仍然有效。SaaS 平台解绑后，CNAME 目标失效很容易触发 1016。
5. 检查根域名和 www 是否都配置完整。很多迁站只改了 @，www 还留在旧服务。
6. 修改后等待 DNS 生效，再用无痕窗口和手机流量复测。

如果只想单独看 1016，可参考 Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程。1016 的关键不是清缓存，而是让 Cloudflare 能解析到一个真实可访问的源站。

Error code 521：Cloudflare 能找到源站，但连接被拒绝

error code 521 常见于服务器防火墙、主机安全策略或 Web 服务异常。它表示 Cloudflare 已经尝试连接源站，但源站拒绝连接。常见原因包括 Nginx/Apache/LiteSpeed 没启动、80/443 端口未开放、安全组没放行，或者防火墙把 Cloudflare IP 当成异常流量拦掉。

处理步骤

1. 在服务器面板确认 Web 服务正在运行，必要时重启 Nginx、Apache 或 LiteSpeed。
2. 确认 80 和 443 端口对公网开放；云服务器还要检查安全组、网络 ACL 和主机商防火墙。
3. 把 Cloudflare 官方 IP 段加入白名单，尤其是 CSF、Imunify360、宝塔防火墙、安全狗、主机 WAF 这类工具。
4. 查看 access log。如果完全没有 Cloudflare 请求，多半是网络层或防火墙阻断；如果有请求但马上断开，再查 error log。
5. 临时切灰云直连测试。灰云正常、橙云 521，重点就在 Cloudflare 到源站这段连接。
6. 恢复橙云后再测试首页、后台登录、wp-json、结账页和表单提交。

不要把“关闭 Cloudflare”当成长期修复。灰云适合定位问题，但修复后仍建议恢复代理，再处理缓存和安全规则。

Cloudflare error 1000：DNS 指向了 Cloudflare 不接受的地址

cloudflare error 1000 也主要是 DNS 问题，但和 1016 不同，它往往是记录存在，却指向了错误或被禁止的地址。例如把 ping 出来的 Cloudflare IP 当作源站 IP 填回 DNS、把 A 记录写成内网地址，或者根域名和 www 做成循环 CNAME。

1. 检查所有 A/AAAA 记录，目标必须是你的真实源站公网 IP。
2. 不要把 Cloudflare 代理后的 IP 当成源站 IP。橙云下 ping 到的通常是 Cloudflare 节点，不是你的服务器。
3. 删除 127.0.0.1、10.x、172.16-31.x、192.168.x 这类本地或内网地址。
4. 检查 @ 和 www 是否互相 CNAME，避免解析回环。
5. 迁站时删除旧主机残留记录，避免同一主机名同时指向多套服务。

Cloudflare 403：先判断是谁返回的 403

cloudflare 403 很容易误判。它可能是 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 拦截，也可能是源站 Nginx deny、.htaccess、WordPress 安全插件、目录权限、防盗链规则返回的 403。第一步不是关掉所有安全功能，而是确认 403 来自哪一层。

• Cloudflare 后台有同时间 Security Events：打开事件详情，看命中的规则名称、路径、IP、国家地区和动作。
• 如果是 wp-admin、wp-login.php、wp-json、支付 webhook 被拦，建议做精确 Skip 规则，不要全站关闭 WAF。
• 如果 Cloudflare 没有拦截记录，去源站查 access log、error log、安全插件日志和文件权限。
• 只有图片 403 时，检查防盗链、对象存储权限、CDN 域名、Nginx location 和缓存插件重写规则。
• 只有后台 403 时，检查登录保护、国家封锁、IP 黑名单、REST API 限制和 XML-RPC 限制。

Cloudflare ssl handshake failed：重点查 525/526、证书链和 SSL 模式

用户搜索 cloudflare ssl handshake failed 时，页面上常见是 525 SSL handshake failed 或 526 Invalid SSL certificate。简单说，Cloudflare 已经能访问源站，但 HTTPS 握手没有成功。原因可能是源站证书过期、证书不匹配、证书链不完整、TLS 版本太旧，或者 Cloudflare SSL 模式和服务器配置不匹配。

处理步骤

1. 生产站优先使用 Full (strict)，前提是源站证书有效；不要长期依赖 Flexible。
2. 检查源站证书是否过期，是否覆盖 example.com 和 www.example.com，证书链是否完整。
3. 如果使用 Cloudflare Origin Certificate，确认服务器绑定的是对应证书和私钥，而不是旧证书。
4. 服务器至少启用 TLS 1.2，建议启用 TLS 1.3；旧系统或旧 OpenSSL 可能导致握手失败。
5. 迁站后确认 DNS 已指向新服务器，否则 Cloudflare 可能还在访问旧服务器上的旧证书。
6. 如果刚改过 SSL 模式并出现循环跳转，回看服务器强制 HTTPS、WordPress 地址、缓存插件和 Cloudflare Always Use HTTPS 是否重复。

如果 SSL 模式引发 ERR_TOO_MANY_REDIRECTS，可以继续看 Flexible SSL 模式的致命误区：ERR_TOO_MANY_REDIRECTS。SSL 问题不要靠反复切模式碰运气，证书和回源地址才是关键。

Cloudflare error 500：多数要回到 WordPress 和服务器日志

cloudflare error 500 不一定是 Cloudflare 平台故障。对 WordPress 站来说，更常见的是插件冲突、主题函数报错、PHP 版本不兼容、内存不足、数据库异常、伪静态规则错误。Cloudflare 只是把源站返回的 500 展示给访客。

1. 先灰云或 hosts 直连源站。如果直连也 500，问题基本在源站。
2. 查看 PHP error_log、WordPress debug.log、Nginx/Apache error log，优先搜索 fatal error、memory exhausted、database error。
3. 回想最近更新过的插件、主题、PHP 版本、缓存规则和安全规则，先回滚最近一次变更。
4. 临时停用高风险插件：缓存、安全、页面构建器、支付、会员、SMTP、重定向插件，再逐个恢复。
5. 恢复默认 .htaccess 或 Nginx rewrite，排除伪静态写错。
6. WooCommerce 结账、支付回调、会员中心 500 时，优先看支付插件日志和 PHP 错误日志。

如果同时遇到 502、503、522，可以延伸阅读 Cloudflare 500/502/503 真相，先把应用错误、网关错误和连接超时分开。

一套适合线上站点的安全修复顺序

原则很简单：一次只改一个变量，改完立刻复测，并记录时间。线上站点最怕“连续乱改后刚好恢复”，因为下次还会复发。

1. 保存截图、Ray ID、URL、时间、地区和访客 IP。
2. 查 Cloudflare Security Events：有记录先看规则，没有记录再回源站。
3. 查 DNS：1016 和 1000 优先处理解析记录、CNAME、源站 IP。
4. 查连接：521 优先处理 Web 服务、端口、安全组和 Cloudflare IP 白名单。
5. 查 SSL：handshake failed、525、526 优先处理证书、证书链、TLS 和 SSL 模式。
6. 查程序：500 优先处理 WordPress 插件、主题、PHP、数据库和伪静态。
7. 恢复后清理 Cloudflare 缓存和网站缓存插件缓存，再测试首页、后台、表单、REST API、结账页。

总结

Cloudflare 常见错误代码并不难，难的是不要一开始就跑错方向。error 1016 看 DNS 是否能找到源站；error code 521 看源站是否拒绝 Cloudflare；cloudflare error 1000 看 DNS 是否指向了错误地址；cloudflare 403 先分清 Cloudflare 拦截还是源站权限；cloudflare ssl handshake failed 查证书、证书链、TLS 和 SSL 模式；cloudflare error 500 则回到 WordPress、PHP 和服务器日志。按层级排查、小步修改、每次复测，才是维护线上网站最稳的做法。