网站突然显示 Cloudflare 错误代码时,很多站长第一反应是清缓存、重启服务器,甚至直接把橙云关掉。但从维护 WordPress 站点的经验看,error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed 和 cloudflare error 500 并不是同一种故障。它们分别指向 DNS、回源连接、安全拦截、SSL 握手、源站程序等不同位置。
这篇文章不做代码大全式堆砌,而是按真实排障顺序写成一份可执行清单。你可以先用前面的快速判断找到问题所在,再到对应错误代码下面逐项处理。尤其适合 WordPress、WooCommerce、Elementor 站点在更换服务器、接入 CDN、启用 WAF、更新证书或修改 DNS 后出现打不开的情况。

先别乱改:用 3 个问题判断故障位置
Cloudflare 位于访客和源站之间。访客先访问 Cloudflare 节点,Cloudflare 再去你的服务器取内容。排障时最怕把所有问题都当成“CDN 抽风”。建议先回答下面 3 个问题:
- 错误页是否带有 Cloudflare Ray ID?如果有,说明请求至少到达了 Cloudflare,可以去 Security Events 或日志里进一步筛选。
- 灰云直连或 hosts 指向源站 IP 后是否正常?如果直连也错误,优先查服务器、WordPress、PHP 和数据库。
- 错误是否只发生在 wp-admin、wp-json、支付回调、登录页等特定路径?如果是,优先怀疑 WAF、Bot 规则、安全插件或权限规则。
经验建议:排查 Cloudflare 报错时,每次只调整一个变量。比如先修 DNS,再测回源;先临时跳过某条 WAF,再复测接口。一次改太多,即使网站恢复,也很难知道真正原因。
错误代码快速对照表
| 错误代码/提示 | 最常见原因 | 优先检查 |
|---|---|---|
| error 1016 | Cloudflare 找不到可解析的源站 | A/AAAA/CNAME、Origin Hostname、负载均衡源站 |
| error code 521 | 源站拒绝 Cloudflare 连接 | Web 服务、80/443 端口、防火墙、Cloudflare IP 白名单 |
| cloudflare error 1000 | DNS 指向禁止地址或形成回环 | 是否指向 Cloudflare IP、127.0.0.1、内网 IP、CNAME 循环 |
| cloudflare 403 | Cloudflare 或源站返回禁止访问 | Security Events、WAF、IP 规则、安全插件、服务器 deny |
| cloudflare ssl handshake failed | Cloudflare 与源站 TLS 握手失败 | SSL 模式、证书有效期、证书链、TLS 版本、SNI |
| cloudflare error 500 | 源站应用或服务器内部错误 | PHP error_log、debug.log、插件主题冲突、rewrite 规则 |
error 1016:先修 DNS,不要先动插件
error 1016 的常见提示是 Origin DNS error。简单说,Cloudflare 想回源,但无法把源站主机名解析成可用地址。这类问题通常发生在迁站、修改 CNAME、删除旧主机记录、配置负载均衡或接入第三方托管平台之后。它一般不是 Elementor、缓存插件或主题模板造成的。
排查步骤
- 进入 Cloudflare → DNS,检查出错的主机名,例如 @、www、blog、shop、cdn 或 api。
- 根域名通常使用 A/AAAA 指向真实源站 IP;www 可按主机商要求 CNAME 到根域名或指定主机名。不要把已开启代理后解析出的 Cloudflare IP 当作源站 IP 填回去。
- 如果记录是 CNAME,复制目标域名,用 dig、nslookup 或 DNS Checker 检查它在公网是否能解析。只在主机商内部可解析的地址,Cloudflare 无法正常回源。
- 检查是否有拼写错误、过期临时域名、已删除的负载均衡源站、重复记录或错误的 AAAA 记录。
- 修改后等待 DNS 生效,并用无痕窗口、手机网络和外部检测工具复测。
站内可以延伸阅读 Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程,适合单独处理 1016 和 Origin DNS 问题。
error code 521:Cloudflare 连不到你的 Web 服务
error code 521 的意思并不一定是整台服务器宕机,而是 Cloudflare 连接源站时被拒绝。常见场景包括 Nginx/Apache/LiteSpeed 没启动、80/443 端口没开放、云安全组拦截、服务器防火墙误封 Cloudflare IP、Fail2ban/CSF/宝塔安全规则把 Cloudflare 节点当成异常请求。

排查步骤
- 先确认源站是否能直连。可以临时灰云,或在本机 hosts 指向源站 IP 测试;测试后记得恢复 Cloudflare 代理。
- 在服务器检查 Web 服务状态:Nginx、Apache、OpenLiteSpeed 或 LiteSpeed 是否正常运行,站点虚拟主机是否加载成功。
- 确认云服务器安全组、防火墙、iptables/ufw、主机面板安全规则都允许 80 和 443 端口。
- 将 Cloudflare 官方 IP 段加入白名单,尤其是开启 WAF、Fail2ban、CSF、宝塔防火墙、主机商防护时。
- 查看 access log。如果完全没有 Cloudflare 请求,多半被网络或防火墙挡住;如果有请求但返回错误,再继续看站点配置。
如果你还遇到 502、503、504,可参考 Cloudflare 500/502/503 真相:一文理清本质区别,先区分“连不上源站”和“源站处理失败”。
cloudflare error 1000:DNS 指到了 Cloudflare 不允许的目标
cloudflare error 1000 常见于 DNS 记录指向了禁止代理的地址,例如 Cloudflare 自己的边缘 IP、127.0.0.1、10.x、192.168.x、172.16.x 到 172.31.x 等内网地址,或者 www 与根域名之间形成循环 CNAME。它和 1016 都属于 DNS 层问题,但 1016 是“找不到有效源站”,1000 是“找到了不该指向的目标”。

排查步骤
- 检查 A/AAAA 记录,确认填写的是主机商提供的真实源站 IP,而不是浏览器解析到的 Cloudflare 节点 IP。
- 删除重复、旧主机、测试平台遗留的 DNS 记录,避免同一主机名下多条冲突记录。
- 如果托管平台要求 CNAME 接入,严格按平台文档填写 CNAME,不要把 CNAME 中间解析出的 IP 再复制到 Cloudflare。
- 检查 www、根域名、子域名之间是否存在循环引用。
- 保存后清理本地 DNS 缓存,换网络复测,避免被本机缓存误导。
cloudflare 403:先确认是谁返回的 403
cloudflare 403 最容易误判。它可能是 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 返回的,也可能是源站 Nginx/Apache、主机商 WAF、Wordfence、iThemes Security、All In One WP Security 等插件返回的。处理前必须先确认“谁拦截”。
排查步骤
- 复制错误页 Ray ID、访客 IP、访问路径和发生时间,进入 Cloudflare → Security → Events 搜索。
- 如果能看到命中的规则,不要直接关闭全站 WAF,而是针对 wp-admin、wp-json、支付回调、会员登录接口、搜索引擎爬虫等建立更精确的 Skip 或 Allow 规则。
- 检查 IP Access Rules、Country Blocking、Rate Limiting、Bot 相关设置,确认没有误封管理员、支付网关、监控服务或 Google/Bing 爬虫。
- 如果 Cloudflare 没有事件记录,去源站查 access/error log,以及 WordPress 安全插件日志。
- 修复后使用退出登录状态、无痕窗口、手机 4G/5G 测试,不要只用管理员浏览器判断。
如果站点安装了 Wordfence,可参考 Wordfence Security 插件安装配置指南,重点检查登录保护、REST API、xmlrpc.php 和目录访问限制。
cloudflare ssl handshake failed:重点检查源站证书
用户搜索 cloudflare ssl handshake failed 时,实际页面可能是 525 SSL handshake failed,也可能是 526 Invalid SSL certificate。它们通常出现在 Cloudflare 与源站建立 HTTPS 连接的阶段,常见原因是源站证书过期、域名不匹配、证书链不完整、服务器 TLS 版本过旧,或 Cloudflare SSL/TLS 模式与源站状态不匹配。
排查步骤
- 优先使用 Full (strict) 模式,但前提是源站证书有效、域名匹配、证书链完整。
- 检查证书是否同时覆盖根域名和 www。迁站或换证书时,经常只绑定了其中一个域名。
- 如果使用 Cloudflare Origin Certificate,确认已经把证书和私钥安装到服务器虚拟主机,而不是只在 Cloudflare 后台生成。
- 检查服务器 TLS 版本和加密套件,过旧环境可能无法和 Cloudflare 正常握手。
- 确认 Cloudflare 当前回源 IP 是新服务器,不是仍然指向旧服务器上的过期证书。
SSL 配置还可能导致循环跳转,相关排查可看 Flexible SSL 模式的致命误区 respond in singing Solution for Cloudflare SSL Settings that Raise TOO_MANY_REDIRECTSThe
cloudflare error 500:多数要回到 WordPress 和服务器日志
cloudflare error 500 不是一个单一原因。很多时候 Cloudflare 只是把源站返回的 500 展示出来,真正的问题在 WordPress、PHP、数据库或服务器配置。典型原因包括插件更新后 fatal error、主题函数冲突、PHP 版本不兼容、内存不足、数据库连接异常、.htaccess 损坏、Nginx rewrite 写错、文件权限错误。
排查步骤
- 临时灰云或 hosts 直连源站。如果绕过 Cloudflare 仍然 500,基本就是源站问题。
- 查看 PHP error_log、WordPress wp-content/debug.log、Nginx/Apache error log,优先搜索 fatal error、memory exhausted、permission denied、database error。
- 回滚最近更新的插件、主题、PHP 版本和缓存配置。页面构建器、缓存、安全、支付、SMTP、SEO 插件都值得重点检查。
- 检查 PHP memory_limit、max_execution_time、max_input_vars 是否满足当前站点规模。
- 恢复 WordPress 默认伪静态规则,确认 .htaccess 或 Nginx rewrite 没有语法错误。
推荐的恢复顺序:从外到内,不要跳步
- 记录错误截图、错误代码、Ray ID、URL、发生时间、访客地区和操作路径。
- 先查 DNS:记录是否存在、是否重复、是否指向真实源站,是否有错误 AAAA 或 CNAME 循环。
- 再查回源:Web 服务、80/443 端口、云安全组、防火墙、Cloudflare IP 白名单。
- 继续查 SSL:SSL/TLS 模式、证书有效期、证书链、SNI、TLS 版本和回源 IP。
- 然后查安全规则:Cloudflare Security Events、WAF、Bot、Rate Limiting、源站安全插件。
- 最后查 WordPress:debug.log、插件主题冲突、缓存、重定向、数据库和伪静态。
- 网站恢复后再逐步打开缓存、WAF、Bot 规则和性能优化,避免为了临时恢复把安全功能长期关闭。
summarize
Cloudflare 常见错误代码的核心思路,是先定位链路,再解决具体问题。error 1016 优先修 DNS 解析;error code 521 优先查源站连接和防火墙;cloudflare error 1000 检查 DNS 是否指向禁止地址或形成回环;cloudflare 403 要分清 Cloudflare 拦截还是源站权限;cloudflare ssl handshake failed 回到源站证书和 TLS 配置;cloudflare error 500 则重点看 WordPress、PHP 和服务器日志。按这个顺序处理,通常比反复清缓存、重启服务器、停用全部插件更快,也更安全。
延伸阅读
- Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程
- SSL证书握手失败:深入解决 Cloudflare 525 错误
- Cloudflare 500/502/503 真相:一文理清本质区别
- 常见 WordPress 故障修复
Link to this article:https://www.361sale.com/en/88048/The article is copyrighted and must be reproduced with attribution.

















March 11, 13:490
Now definitely still do SEO, just play changed. Previously rely on heaps of content, heaps of keywords can have traffic, and now pay more attention to the quality of content + brand trust + user experience. In addition to relying solely on SEO is actually more and more difficult, a lot of good basically SEO + social media + content marketing + private domain conversion to do together. SEO is still a long-term customer acquisition channel, but can no longer be taken as the only channel.Hehe is working.
March 11, 10:540
Normal, included only on behalf of Google to see the page, does not mean that the ranking immediately, "has been included but not ranked" usually because: Keyword competition, page weight is low, the content is not strong enough, the page is relatively new. Continue to optimize the long-tail keywords, content quality and internal chain, usually takes a little time, the ranking will slowly come out!Amelia Foster March 6, 16:200
Do you have a screenshot?lit. even a son who is not a fish knows the joy of fish March 6, 09:230
Don't pile on the optimization plugins first, locate the bottlenecks first: Use Query Monitor to see slow SQL, slow hooks. Pause all plugins for comparison, then turn them on one by one. Check autoload is too big (options table). Check database indexes with large table queries. Tackle host/database performance first if server TTFB is high.Hehe is working.
March 3, 16:470
Hi Windjammer, there's really no need to mess with complicated local environments, regular people follow these steps and the update basically won't crash the site 👇 First, backup the whole site, files + database are prepared, this is the bottom line, out of the problem can be a key to go back. Don't change the whole thing in one click, change it in batches, change the unimportant plug-ins first, and then change the core ones. Immediately after the update, clear the cache, go to the foreground to check the home page, article page, buttons, forms, these key positions. It is best to install a plug-in that supports version rollback, in case of a crash, cut back to the old version in a second. To summarize: backup first, change in batches, check after changing, leave a way back, stable ✅😎 Hope this helps!bugbang March 2, 09:550
Usually it's not that the payment didn't work, but that the callback (webhook) didn't write back the order status. Troubleshooting steps: WooCommerce → Status → Logs: see if the payment gateway has webhook error / signature error / timeout Check if the site is blocked by WAF (Cloudflare, Pagoda Firewall, security plugins) Check if "Cache checkout pages/interface paths" is enabled (checkout pages and callback interfaces should not be cached) Look at the server error logs for 500/fatal errors that interrupt the callback execution. Solution: Release wp-json, wc-api, payment gateway callback URLs (configure as per gateway documentation) Disable cache and JS merge compression test on checkout page once If using Cloudflare: set no-challenge, no-block rules for callback URLsUlla Nala Zhenhuan (18嬛嬛嬛) January 31st, 09:360
1) Determine whether it is "Normal Waiting" or "Abnormally Stuck". You can first look at 3 signals: whether the page release time is within 7-14 days, whether there are only a small number of pages with this status, and whether the page has appeared in the XML Sitemap. If all three are satisfied, most likely belong to the normal crawling and evaluation stage, do not need to do it immediately. 2) Under what circumstances is it useless to "wait"? The following cases will not be solved automatically by time: the page has almost no internal links (isolated page), the content is highly similar to the existing pages on the site, canonical points to other URLs, and too many similar articles are published on the same topic for a short period of time. In this case, Google has been crawled, but judged that "it is not worth entering the index". 3) The most effective way of manual intervention (no tossing) Prioritize these 3 things: add internal links, link to the page from related old articles or columns, and enhance the density of information on the first screen. The first 2-3 paragraphs directly answer the user's question, avoid too much padding, confirm canonical as self-referential, avoid being judged as a duplicate page, and then go to GSC to request reindexing after doing so. 4) What "intervention actions" are counterproductive? It is not recommended: frequent deletion and re-posting, clicking "request to index" several times in a row, forcing keywords to be stacked for the sake of indexing, changing URLs or titles arbitrarily. These operations will allow Google to reassess the stability of the page, but slow down the inclusion. 5) a practical judgment standard If an article: has been crawled, there is no noindex / robots problem, there are at least 1-2 related internal links, the content obviously solves an independent problem, then it is included, just a matter of time, not a plug-in problem.Post Porter January 30th 10:000
The new station does not do external links can be completely, the first content and station structure to do a good job more stable. Only rely on the content can generally get included and part of the long-tail word rankings, but the amount of high competition will be slow. It is recommended to wait for the site stable inclusion, 30-50 quality content, keywords began to enter the top 20/30, and then a small amount of external links, priority brand words/naked chain/citation type, do not come up to chase the number. 👍