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、缓存插件的普通内容站。

先别急着改:用 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 和服务器日志。
线上站点排障最怕“看到一个错误就全部重置”。更安全的做法是记录错误信息、按层级定位、一次只改一个变量。这样不仅能更快恢复访问,也能避免把本来正常的后台、支付、接口和缓存系统一起改乱。
| 联系我们 | |
|---|---|
| 教程看不懂?联系我们为您免费解答!免费助力个人,小企站点! |
客服微信
|
| ① 电话:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| ③ 邮件:[email protected] | |
| ④ 工作时间:周一至周五,9:30-18:30,节假日休息 | |

















3月11日 13:490
现在肯定还是做SEO的,只是玩法变了。 以前靠堆内容、堆关键词就能有流量,现在更看重 内容质量 + 品牌信任 + 用户体验。 另外单靠SEO其实越来越难,很多做得好的基本都是 SEO + 社媒 + 内容营销 + 私域转化 一起做。 SEO本质还是一个长期获客渠道,但不能再当成唯一渠道了。嘻嘻在干活
3月11日 10:540
正常,收录只代表 Google 看到了页面,不代表马上给排名,“已收录但没排名”通常是因为: 关键词竞争大、页面权重低、内容不够强、页面还比较新。 先继续优化长尾关键词、内容质量和内链,通常需要一点时间,排名会慢慢出来Amelia Foster 3月6日 16:200
有截图吗子非鱼也安知鱼之乐 3月6日 09:230
别先堆优化插件,先定位瓶颈: 用 Query Monitor 看慢 SQL、慢 Hook。 暂停全部插件做对比,再逐个开启。 检查 autoload 过大(options 表)。 检查数据库索引与大表查询。 服务器 TTFB 高就先处理主机/数据库性能。嘻嘻在干活
3月3日 16:470
你好风之旅,其实真不用搞复杂的本地环境,普通人按这几步来,更新基本不会崩站👇 先备份全站,文件 + 数据库都备一下,这是底线,出问题能一键回退。 更的时候别一键全更,分批更,先更不重要的插件,再更核心的。 更新完立刻清缓存,去前台检查首页、文章页、按钮、表单这些关键位置。 最好再装个支持版本回滚的插件,万一崩了,一秒切回旧版。 总结来说:先备份、分批更、更完查、留退路,稳得很✅😎希望能帮到你bugbang 3月2日 09:550
通常不是支付没成功,而是回调(webhook)没把订单状态写回来。 排查步骤: WooCommerce → 状态 → 日志:看支付网关是否有 webhook error / signature error / timeout 检查站点是否被 WAF 拦截(Cloudflare、宝塔防火墙、安全插件) 检查是否启用了“缓存结账页/接口路径”(结账页和回调接口不应缓存) 看服务器错误日志是否有 500/致命错误导致回调执行中断 解决方案: 放行 wp-json、wc-api、支付网关回调 URL(按网关文档配置) 关闭结账页的缓存与 JS 合并压缩测试一次 若使用 Cloudflare:为回调 URL 设置 不挑战、不拦截 的规则乌拉那拉甄嬛 1月31日 09:360
1) 先判断这是“正常等待”还是“异常卡住” 可以先看 3 个信号:页面发布时间是否在 7–14 天以内、是否 只有少量页面 出现该状态、页面是否已经出现在 XML Sitemap 中。 如果三个都满足,多半属于正常爬取与评估阶段,不需要立刻动手。 2) 什么情况下“等”是没用的? 以下情况基本不会靠时间自动解决:页面几乎没有内链(孤立页)、内容与站内已有页面高度相似、canonical 指向了别的 URL、同一主题短时间发布太多相似文章。 这种情况下,Google 已经抓取,但判断“当前不值得进入索引”。 3) 最有效的人工干预方式(不折腾) 优先做这 3 件事:加内链、从相关旧文章或栏目页链接到该页面、增强首屏信息密度 前 2–3 段直接回答用户问题,避免铺垫太多,确认 canonical 为自指,避免被判定为重复页,做完再去 GSC 请求重新编入索引即可。 4) 什么“干预动作”反而容易适得其反? 不太推荐:频繁删除重发、连续多次点“请求编入索引”、为了收录强行堆关键词、随意改 URL 或标题 这些操作会让 Google 重新评估页面稳定性,反而拖慢收录。 5) 一个实用判断标准 如果一篇文章:已被抓取、没有 noindex / robots 问题、有至少 1–2 条相关内链、内容明显解决了一个独立问题,那它 是否被收录,只是时间问题,不是插件问题。帖子搬运工 1月30日 10:000
新站前期不做外链完全可以,先把内容和站内结构做好更稳。只靠内容一般能拿到收录和部分长尾词排名,但中高竞争词起量会慢。建议等网站稳定收录、有30–50篇质量内容、关键词开始进前20/30后,再少量做外链,优先品牌词/裸链/引用型,别一上来追数量。👍