Cloudflare 报错看起来都很像：页面中间一个错误代码，下面提示访客、Cloudflare、Host 三段状态。可真正修的时候，error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed 和 cloudflare error 500 完全不是一类问题。如果把它们都当成“清缓存”“切 SSL 模式”来处理，轻则浪费时间，重则把后台登录、支付回调、图片加载一起弄坏。
这篇文章按站长最常见的排查场景来写：先判断错误发生在 DNS、回源连接、安全拦截、SSL 握手还是 WordPress 程序层，再给出对应的处理步骤。适合 WordPress 企业站、WooCommerce 商城、外贸独立站和使用 Elementor、缓存插件的普通内容站。
Cloudflare Error 1016 DNS Origin Error 页面截图，用于说明 DNS 记录或 CNAME 目标失效导致 Cloudflare 找不到源站
先别急着改：用 3 分钟确认错误在哪一层
Cloudflare 位于访客和源站之间。访客打开页面时，先到 Cloudflare 边缘节点，再由 Cloudflare 回源到你的服务器。页面显示的错误代码，可能来自 Cloudflare 自己，也可能是源站返回后被 Cloudflare 展示出来。排错前先做几件小事，可以避免把方向搞错。
记录报错 URL、错误代码、Ray ID、发生时间和访问地区。Ray ID 对查 Cloudflare Security Events 很有用。同一个 URL 用无痕窗口、手机流量和另一台设备各测一次，排除浏览器缓存、本地 DNS 或公司网络代理影响。打开 Cloudflare 后台的 DNS、SSL/TLS、Security Events 三个页面，后面大部分问题都能在这里找到线索。如果你能管理服务器，准备好主机面板、Nginx/Apache 日志、PHP error_log 和 WordPress debug.log。
站内的 Cloudflare 报错先看这里 和 常见 WordPress 故障修复 分类也可以配合查看。本文更像一张“看到错误代码后按顺序处理”的操作清单。
Error 1016：Cloudflare 找不到源站 DNS
error 1016 的典型提示是 Origin DNS error。它的重点不是 WordPress，也不是服务器 CPU，而是 Cloudflare 不知道该把请求转发到哪里。常见原因包括：DNS 记录被删了、A 记录写成旧 IP、CNAME 指向的服务已经失效、www 和根域名只配置了一边、第三方建站平台解绑后没有更新解析。
1016 的处理步骤
进入 Cloudflare 后台 DNS，找到报错的主机名，例如 @、www、shop、cdn 或 api。确认它至少有一条有效的 A、AAAA 或 CNAME 记录。没有记录时，Cloudflare 就无法回源。如果是 A/AAAA，确认 IP 是当前源站公网 IP，不要填内网 IP、旧服务器 IP，也不要填 Cloudflare 边缘 IP。如果是 CNAME，把 CNAME 目标域名单独拿去解析，确认目标仍然存在。如果目标服务已删除或未绑定当前域名，就会触发 1016。刚迁站的用户要同时检查根域名和 www。有些站根域名正常，www 报 1016，就是因为只改了一条解析。
修完 DNS 后不要马上反复改第二次。先等几分钟，再用 Cloudflare 的 DNS 页面、命令行 dig/nslookup 或在线 DNS 查询工具确认记录是否生效。若只想看单独教程，可以参考站内 Cloudflare Error 1016 怎么解决。
Error code 521：Cloudflare 能找到源站，但连接被拒绝
error code 521 常见提示是 Web server is down。很多人第一反应是“服务器挂了”，但 521 更准确的含义是：Cloudflare 已经知道源站在哪里，并尝试连接，但源站没有接受连接。原因可能是 Web 服务没有启动，80/443 端口没开放，云服务器安全组拦截，或者服务器防火墙把 Cloudflare IP 当成异常流量拒绝了。
521 的处理步骤
登录服务器面板，确认 Nginx、Apache、OpenLiteSpeed 或 LiteSpeed 正在运行。检查 80 和 443 端口是否对公网开放。云服务器还要看安全组，虚拟主机要看主机商防火墙。查看 Web 服务日志。如果 access log 完全没有 Cloudflare 请求，优先查网络层、防火墙和安全组。把 Cloudflare 官方 IP 段加入允许列表，尤其是使用宝塔防火墙、CSF、Imunify360、ModSecurity 或主机 WAF 的站点。临时把该记录切成灰云直连测试。灰云正常、橙云 521，说明问题集中在 Cloudflare 到源站的连接路径。
注意，灰云只是定位手段，不建议长期把主站裸露出来。确认是防火墙或端口问题后，要恢复橙云，并用手机流量复测首页、后台、登录页、表单和 WooCommerce 结账页。
Cloudflare error 1000：DNS 指到了不该指的地址
cloudflare error 1000 常出现在迁站、复制教程或手动改 DNS 之后。它通常表示 DNS 配置违反了 Cloudflare 的规则，比如把域名指向 Cloudflare 自己的 IP、指向本地/内网地址，或者根域名和 www 之间形成循环。
检查 A 记录和 AAAA 记录，目标必须是你的真实源站公网地址。不要把浏览器 ping 到的 Cloudflare IP 当成源站 IP 填回 Cloudflare DNS。开启橙云后，外部看到的是 Cloudflare 边缘 IP，不是你的服务器 IP。删除 127.0.0.1、10.x、172.16-31.x、192.168.x 这类本地或内网地址。检查 CNAME 是否互相指向，例如 @ 指向 www，www 又指回 @，这种回环很容易出问题。同一个主机名不要保留多套冲突记录，迁站后要清掉旧主机商留下的解析。
error 1000 修复后，建议顺手整理 DNS 页面：不用的测试子域名删掉，旧服务记录备注清楚，根域名和 www 的来源保持一致。很多 Cloudflare 问题不是一次配置错，而是旧记录越堆越多导致判断困难。
Cloudflare 403：先判断是谁在拒绝访问
cloudflare 403 是排查中最容易走错方向的一个。403 的意思是 Forbidden，但拒绝访问的可能是 Cloudflare，也可能是源站。Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 会返回 403；WordPress 安全插件、.htaccess、Nginx deny、目录权限、防盗链规则同样会返回 403。
403 的处理步骤
先看 Cloudflare 后台 Security Events，按报错时间、访客 IP 或 Ray ID 搜索。如果有事件记录，打开详情看命中的规则名称。对 wp-admin、wp-json、admin-ajax.php、支付 webhook 这类路径做精准 Skip，不要直接关闭全部安全功能。如果 Security Events 没有记录，就去源站查 access log、error log、安全插件日志和文件权限。只后台 403 时，重点查登录保护、国家封锁、REST API 限制、XML-RPC 限制和管理员 IP 白名单。只图片或静态资源 403 时，重点查防盗链、对象存储权限、CDN 域名、缓存插件的静态文件规则。
一个实用判断方法：如果错误页面有明显的 Cloudflare 风格、Ray ID，并且后台 Security Events 有命中记录，多半是 Cloudflare 拦截；如果页面是主机商、Nginx、WordPress 插件自己的 403 样式，更多时候要回源站查。
Cloudflare ssl handshake failed：重点查 525/526、证书和 SSL 模式
用户搜索 cloudflare ssl handshake failed，实际常见页面是 525 SSL handshake failed 或 526 Invalid SSL certificate。它说明 Cloudflare 到源站的 HTTPS 握手没有成功。原因通常不是缓存，而是源站证书过期、证书链不完整、证书域名不匹配、TLS 协议太旧，或者 Cloudflare SSL/TLS 模式选错。
生产站优先使用 Full (strict)，前提是源站有有效证书。不要长期依赖 Flexible。检查源站证书是否覆盖当前访问域名，包括根域名和 www。检查证书是否过期，证书链是否完整。中间证书缺失时，有些浏览器可能能访问，但 Cloudflare 回源会失败。如果使用 Cloudflare Origin Certificate，确认 Web 服务器绑定的是对应证书和私钥，不要只在 Cloudflare 后台点了创建却没装到服务器。服务器至少启用 TLS 1.2，老系统或老面板可能仍使用过旧协议，需要升级配置。迁站后确认 DNS 已指向新服务器。很多 525/526 其实是 Cloudflare 还在访问旧服务器上的旧证书。
如果你曾经把 SSL 模式切到 Flexible 来“临时修复”，后续又遇到循环跳转，可以看站内 Flexible SSL 模式的致命误区。SSL 问题最好从证书和回源配置上解决，不要靠反复切模式碰运气。
Cloudflare error 500：多数要回到 WordPress、PHP 和数据库
cloudflare error 500 容易让人误会成 Cloudflare 故障，但对 WordPress 站点来说，500 更多是源站程序错误。比如插件冲突、主题函数报错、PHP 版本不兼容、内存不足、数据库连接异常、伪静态规则错误、缓存插件生成的文件损坏。Cloudflare 只是把源站返回的 500 展示给访客。
500 的处理步骤
把 DNS 临时切灰云，或用 hosts 直连源站。如果直连也 500，问题就在源站。查看 PHP error_log、WordPress debug.log、Nginx/Apache error log，优先搜索 fatal error、memory exhausted、database error。回忆最近更新过的插件、主题、PHP 版本、缓存规则和安全规则，先回滚最近一次变更。通过文件管理器把 plugins 目录临时改名，或停用最近新增的插件，再逐个恢复定位。恢复默认 .htaccess 或检查 Nginx rewrite，排除伪静态写错。WooCommerce 结账、支付回调、会员中心出现 500 时，优先查支付插件日志、Webhook 日志和服务器 PHP 错误。
如果同时遇到 502、503、522 这类回源错误，可以延伸阅读 Cloudflare 500/502/503 真相。先区分程序错误、网关错误和连接超时，才能避免无效操作。
一张实用排查顺序表
不要同时改 DNS、SSL、缓存、WAF 和插件。一次只改一个变量，记录修改时间，复测后再进入下一步。
看到 1016：先查 DNS 记录、CNAME 目标和源站 IP。看到 1000：先查是否指向 Cloudflare IP、内网 IP 或循环 CNAME。看到 521：先查 Web 服务、端口、安全组、源站防火墙和 Cloudflare IP 白名单。看到 403：先查 Security Events；有命中看 Cloudflare 规则，没有命中查源站权限和安全插件。看到 SSL handshake failed、525、526：先查源站证书、证书链、TLS 版本和 SSL/TLS 模式。看到 500：先直连源站，再查 WordPress、PHP、数据库、插件和主题日志。修复后清理 Cloudflare 缓存和站内缓存，用未登录窗口、手机流量复测关键页面。
总结
Cloudflare 常见错误代码其实有清晰边界：error 1016 是 Cloudflare 找不到源站 DNS；error code 521 是源站拒绝 Cloudflare 连接；cloudflare error 1000 多半是 DNS 指向了错误或禁止地址；cloudflare 403 要先分清 Cloudflare 拦截还是源站拒绝；cloudflare ssl handshake failed 重点检查证书、TLS 和 SSL 模式；cloudflare error 500 则大概率要回到 WordPress、PHP 和服务器日志。
线上站点排障最怕“看到一个错误就全部重置”。更安全的做法是记录错误信息、按层级定位、一次只改一个变量。这样不仅能更快恢复访问，也能避免把本来正常的后台、支付、接口和缓存系统一起改乱。