Cloudflare 报错经常会让新手站长误判:看到 1016 就怀疑 WordPress 坏了,看到 521 就急着重装服务器,看到 403 就去禁用所有插件。实际上,大多数 Cloudflare 错误都可以按“DNS、源站、SSL、防火墙、缓存”五个层面逐步排查。只要顺序正确,通常不需要大规模回滚网站。
本文把 1016、521、1000、403、SSL handshake failed 和 500 放在同一套排查表里,适合 WordPress、Elementor、WooCommerce 和独立站使用。你可以先确认错误发生在哪一层,再决定是改 DNS、查主机、防火墙放行,还是清理页面缓存。
先判断错误属于哪一层
Cloudflare 位于访客和源站之间,所以报错不一定来自 WordPress。访问链路可以简化为:访客浏览器访问 Cloudflare,Cloudflare 再访问源站服务器,源站把页面返回给 Cloudflare,最后再返回给访客。任何一段出问题,前台都可能显示 Cloudflare 错误页。
DNS 层常见信号
如果错误提示涉及 DNS 解析、CNAME、A 记录或 origin error,优先检查 DNS。特别是 1016 和 1000,通常和记录配置、代理状态、指向目标有关。不要先动 WordPress 插件,因为插件不会改变 Cloudflare 是否能找到源站。
源站层常见信号
如果错误是 521、522、523 或偶发 500,通常要看服务器是否能被 Cloudflare 访问。源站宕机、防火墙拦截 Cloudflare IP、端口未开放、PHP-FPM 崩溃、Nginx 配置错误,都可能造成这类问题。

1016 Origin DNS Error 怎么排查
1016 表示 Cloudflare 无法解析到源站。常见原因有三类:DNS 记录不存在、CNAME 指向的目标失效、使用了 Cloudflare 不支持的记录组合。排查时先进入 Cloudflare DNS 页面,确认根域名和 www 都有正确记录,并且指向当前主机提供的 IP 或 CNAME。
如果你刚迁移主机,最容易忘的是把旧 IP 更新为新 IP。还要检查是否把 CNAME 指向了一个同样开启 Cloudflare 代理的域名,导致循环解析。对于 WordPress 站点,建议先用灰云模式测试源站是否能打开,再重新开启橙云代理。
521 Web Server Is Down 怎么排查
521 不是 Cloudflare 自己宕机,而是 Cloudflare 连接不到源站 Web 服务。先在服务器上检查 Nginx 或 Apache 是否运行,再看 80 和 443 端口是否开放。如果你使用安全组、防火墙或宝塔面板,确认没有拦截 Cloudflare IP 段。
源站正常但仍然 521
有些服务器能从本机访问,却拒绝 Cloudflare 节点访问。这时要看防火墙日志、WAF 规则和主机商安全策略。不要只刷新缓存,因为缓存无法解决源站拒绝连接。站内关于 主题配置路线图 的文章也提醒过,上线前应把主机、主题和缓存分开验证。
1000 DNS points to prohibited IP 怎么排查
1000 通常表示 DNS 记录指向了 Cloudflare 禁止代理的 IP,例如 Cloudflare 自己的 IP、保留地址或错误的内部地址。解决方法是把 A 记录改成真实源站 IP,或者把 CNAME 改成主机商给出的正确目标。不要把域名指回自己,也不要把 www 指向一个会再跳回根域名的错误代理层。
403 Forbidden 怎么排查
403 可能来自 Cloudflare,也可能来自源站。先看错误页样式:如果页面带 Cloudflare Ray ID,多半是 Cloudflare 防火墙、安全规则、Bot Fight Mode 或地区拦截;如果是主机默认 403,可能是目录权限、Nginx 配置、WordPress 安全插件或 .htaccess 规则。
排查 403 时建议先查看 Cloudflare Security Events,按 Ray ID 搜索请求。如果命中了规则,可以临时放行自己的 IP,再调整规则范围。WordPress 侧则检查安全插件是否拦截 REST API、登录页或 Elementor 请求。类似前台显示异常,也可参考 Elementor 页面内容显示不对的排查顺序。

SSL handshake failed 怎么排查
SSL 握手失败通常和证书模式不匹配有关。Cloudflare 的 SSL/TLS 模式如果设置为 Full strict,源站必须有有效证书,证书域名也要匹配。如果源站只有自签证书或证书过期,就可能握手失败。临时排查可以切到 Full 测试,但长期建议修复源站证书,而不是一直降低安全等级。
Flexible 模式的风险
Flexible 会让浏览器到 Cloudflare 是 HTTPS,但 Cloudflare 到源站是 HTTP。它看似省事,却容易造成 WordPress 后台重定向循环、混合内容和登录异常。正式站点更建议使用 Full 或 Full strict,并在 WordPress 后台正确设置站点 URL。
500 错误不要只怪 Cloudflare
500 多数来自源站程序。Cloudflare 只是把错误展示给访客。排查时先绕过 Cloudflare,用源站 IP 或灰云模式访问,再查看 PHP error log、Nginx error log 和 WordPress debug log。插件冲突、主题函数错误、PHP 内存不足、数据库连接异常都可能导致 500。
如果 500 只在发布文章或编辑 Elementor 时出现,重点查 PHP 内存、对象缓存、REST API 和安全插件。性能类插件也可能改变缓存行为,排查时可以参考 Perfmatters、WP Rocket、Imagify、Smush 对比清单,先区分缓存、图片压缩和脚本优化各自负责的部分。
推荐的排查顺序
第一步,看错误代码和 Ray ID;第二步,在 Cloudflare 后台查 DNS、SSL 和安全事件;第三步,用灰云模式或源站 hosts 验证服务器;第四步,看主机日志;第五步,再检查 WordPress 插件、主题和缓存。按这个顺序能避免把网络层问题误判为网站程序问题。
上线前的预防清单
上线前建议保存 DNS 记录截图、源站 IP、SSL 模式、缓存规则和防火墙规则。迁移主机时先降低 TTL,确认新源站能直接访问,再切换 Cloudflare。需要更系统地理解代理和自动化巡检,可以查看 OpenClaw 官方文档,把错误检查纳入每日运营任务。
总结
Cloudflare 报错的核心不是背代码,而是定位链路。1016 和 1000 先查 DNS,521 先查源站连接,403 先分清 Cloudflare 规则还是源站权限,SSL 握手失败先查证书模式,500 先看服务器和 WordPress 日志。只要按层排查,就能避免无效重装和盲目禁用插件。






















![表情[wozuimei]-361Sale WordPress Care](https://www.361sale.com/wp-content/themes/zibll/img/smilies/wozuimei.gif)
![表情[baoquan]-361Sale WordPress Care](https://www.361sale.com/wp-content/themes/zibll/img/smilies/baoquan.gif)
暂无评论内容