网站突然出现 Cloudflare 报错时，很多站长第一反应是“Cloudflare 坏了”或“服务器挂了”。但从实际维护 WordPress、WooCommerce 和企业站的经验看，同一个 Cloudflare 错误页面，背后可能是 DNS 记录、源站防火墙、SSL 证书、WAF 规则、PHP 程序报错等不同问题。盲目切换 SSL 模式、清空缓存或重启服务器，反而容易把一个小问题扩大成全站故障。
本文把站长高频搜索的 error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed、cloudflare error 500 放在同一套排查流程里讲。你不需要一次性改完所有配置，只要按“先定位层级，再改一个变量，再复测”的方式操作，通常可以更快找到真正原因。
一、先做 3 个快速判断，避免越修越乱
Cloudflare 报错并不等于所有问题都在 Cloudflare。建议先记录错误代码、Ray ID、访问 URL、发生时间、访问地区，然后做三步判断。第一，页面是否带有 Cloudflare 标识和 Ray ID；第二，Cloudflare 后台 Security Events 是否有对应拦截记录；第三，绕过 Cloudflare 直连源站时是否仍然报错。
- 如果直连源站也打不开，优先查服务器、端口、程序和证书。
- 如果直连正常、橙云代理后报错，优先查 Cloudflare DNS、SSL、WAF 与回源连接。
- 如果只有个别地区或个别 IP 报错，优先查安全规则、速率限制、Bot 防护和主机商防火墙。
- 如果后台刚改过 DNS、SSL、缓存插件或安全插件，先回滚最近一次修改。
站内已有一篇偏总览的 Cloudflare 报错别乱改：1016、521、1000、403、SSL 握手与 500 排查指南，本文会更偏“按错误代码直接动手”。
二、Error 1016：Origin DNS error 怎么修？
error 1016 的意思是 Cloudflare 找不到源站 DNS。最常见的情况是 A 记录、AAAA 记录或 CNAME 写错了，或者 CNAME 指向的目标域名本身已经无法解析。它和源站是否安装 WordPress、是否开启缓存关系不大，核心在 DNS 链路。
排查步骤
- 进入 Cloudflare DNS，找到报错的主机名，例如 @、www、shop、api。
- 确认它至少有一条有效的 A、AAAA 或 CNAME 记录，并且目标不是拼错的域名。
- 如果是 CNAME，复制目标域名到 DNS 查询工具里单独查，确认它能解析出公网地址。
- 如果使用负载均衡或第三方 SaaS，检查 origin hostname 是否仍然有效。
- 保存后等待几分钟，再用无痕窗口或手机网络访问，不要只依赖本机缓存。
需要更细的 1016 案例，可以看 Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程The
三、Error code 521：源站拒绝了 Cloudflare
error code 521 页面经常写着 Web server is down，但真实原因不一定是服务器宕机。只要源站主动拒绝 Cloudflare 的连接，或者 80/443 端口没有正确监听，就可能出现 521。尤其是新服务器刚上线、换了主机商、防火墙规则较严格时，这个错误很常见。
排查步骤
- 在服务器面板确认 Nginx、Apache 或 LiteSpeed 正在运行。
- 检查 80 和 443 端口是否对公网开放，云服务器安全组也要一起看。
- 把 Cloudflare 官方 IP 段加入源站防火墙、主机 WAF、宝塔防火墙的允许列表。
- 查看 access log：如果完全没有 Cloudflare 请求，多半是防火墙或网络层拦截；如果有请求但异常中断，再查 Web 服务配置。
- 临时切灰云测试源站是否能直接访问，确认后再恢复橙云代理。
如果同时出现 502、503 或 522，可以参考 Cloudflare 500/502/503 真相，先区分源站超时、网关错误和应用异常。
四、Cloudflare error 1000：DNS 指向了不该指向的 IP
cloudflare error 1000 通常与 DNS 指向有关，典型原因是把记录指向了 Cloudflare 自己的 IP、内网 IP、保留 IP，或者让域名解析形成了回环。迁站、复制旧记录、照抄主机商教程时最容易发生。
- 检查 A/AAAA 记录，目标必须是你的真实源站公网 IP。
- 不要把 Cloudflare 代理后的 IP 当成源站 IP 填回 DNS。
- 不要填写 127.0.0.1、10.x、172.16-31.x、192.168.x 等内网地址。
- 检查 www 与根域名是否互相 CNAME，避免循环。
- 删除重复冲突记录，只保留当前主机商要求的解析方案。
五、Cloudflare 403：先确认是谁拦截的
cloudflare 403 最容易误判。它可能是 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 拦截，也可能是源站安全插件、Nginx deny、.htaccess、文件权限或目录保护返回的 403。判断方法很简单：去 Cloudflare Security Events 查同一时间是否有记录。
- 有拦截记录：查看命中的规则名称，针对后台、接口、支付回调等路径做精确 Skip 或 Allow，不要直接关闭全部 WAF。
- 没有拦截记录：去源站查访问日志、安全插件日志和文件权限。
- 只拦某些国家或 IP：检查国家封锁、IP 黑名单、速率限制和 Bot 规则。
- 只拦 wp-json 或后台：检查安全插件是否限制 REST API、登录路径或 XML-RPC。
六、cloudflare ssl handshake failed：重点查证书与 SSL 模式
用户搜索 cloudflare ssl handshake failed 时，常见对应错误是 525 或 526。简单说，Cloudflare 能连到源站，但 HTTPS 握手没有成功。常见原因包括源站证书过期、证书域名不匹配、证书链不完整、服务器只支持过旧 TLS、Cloudflare SSL 模式与源站配置不一致。
- 生产站建议使用 Full (strict)，前提是源站证书有效；不要长期依赖 Flexible。
- 检查证书是否覆盖根域名和 www，是否过期，证书链是否完整。
- 如果使用 Cloudflare Origin Certificate，确认 Nginx/Apache 绑定了正确证书和私钥。
- 启用 TLS 1.2/1.3，避免服务器只支持旧协议或旧加密套件。
- 迁站后确认 Cloudflare 回源 IP 已更新，别让它连到旧服务器的旧证书。
如果 SSL 模式同时引发循环跳转，可以继续看 Flexible SSL Mode Fatal Mistake: ERR_TOO_MANY_REDIRECTSThe
七、Cloudflare error 500：多半要回源站查 WordPress
cloudflare error 500 并不一定是 Cloudflare 平台故障。对 WordPress 站点来说，更常见的是插件冲突、主题函数报错、PHP 版本不兼容、内存不足、数据库异常、.htaccess 规则错误。Cloudflare 只是把源站返回的 500 展示给访客。
排查步骤
- 临时灰云或通过 hosts 直连源站，如果仍然 500，说明问题在源站。
- 查看 PHP error_log、WordPress debug.log、服务器 error log，优先搜索 fatal error、memory exhausted、database。
- 回想最近是否更新了插件、主题、PHP 版本或缓存规则，先回滚最近变更。
- 临时停用缓存、安全、页面构建器、支付和 SMTP 等高风险插件。
- 恢复默认伪静态规则，检查 .htaccess 或 Nginx rewrite 是否写错。
八、推荐的安全处理顺序
一次只改一个变量。改 DNS、SSL、防火墙、插件时都要记录时间，否则后面很难判断到底是哪一步修好的。
- 保存错误截图、Ray ID、URL、时间和访客地区。
- 查 Cloudflare Security Events 与 Analytics，确认是否有拦截或回源错误峰值。
- 查 DNS：1016 和 1000 优先处理解析记录。
- 查源站：521 优先处理 Web 服务、端口和防火墙。
- 查 SSL：525/526 或 handshake failed 优先处理证书与 TLS。
- 查程序：500 优先处理 WordPress、PHP、数据库和伪静态。
- 确认恢复后再开启缓存预热，并按需清理 Cloudflare 缓存。
summarize
Cloudflare 常见错误代码并不是一套玄学。error 1016 查 DNS 是否能解析；error code 521 查源站是否拒绝 Cloudflare；cloudflare error 1000 查 DNS 是否指向禁止 IP；cloudflare 403 查 WAF 与源站权限；cloudflare ssl handshake failed 查证书、TLS 和 SSL 模式；cloudflare error 500 则回到 WordPress 与服务器日志。按这个顺序排查，通常比反复切换设置更稳，也更不容易造成二次故障。
Link to this article:https://www.361sale.com/en/87712/The article is copyrighted and must be reproduced with attribution.
简体中文 
English 
日本語 
Français 
Español 
0
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 reposting, clicking "request to index" several times in a row, forcing keywords to be stacked for 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. 👍