网站接入 Cloudflare 后，偶尔会遇到一串看起来很吓人的错误代码：error 1016,error code 521,cloudflare error 1000,cloudflare 403,cloudflare ssl handshake failed,cloudflare error 500。很多新手站长会第一时间清缓存、暂停 CDN、停用插件，结果问题没有解决，反而把原本可定位的故障搞乱。
正确做法不是背错误代码，而是先判断故障发生在访问链路的哪一层：DNS 是否能把域名指向真实源站？Cloudflare 能不能连到服务器？SSL 证书是否能完成握手？请求是不是被 WAF 或安全插件拦截？源站 WordPress 本身有没有 PHP 或数据库错误？本文按真实排障顺序整理，适合 WordPress、WooCommerce、Elementor 网站在迁站、换 IP、开启 WAF、更新证书、修改 DNS 后快速恢复访问。
先用 1 分钟判断：问题在 Cloudflare，还是在源站？
Cloudflare 的位置在访客和你的服务器之间。访客请求先到 Cloudflare 节点，Cloudflare 再回源到服务器拿页面。因此，同样是打不开网站，可能是 DNS 层、网络层、SSL 层、安全层，也可能是 WordPress 应用层。排查前建议先记录错误页截图、Ray ID、访问 URL、发生时间、访客地区和最近做过的改动。
- 如果错误页显示 Cloudflare Ray ID，说明请求已经到达 Cloudflare，可到 Cloudflare 后台 Security Events 或日志里继续查。
- 如果临时灰云或 hosts 指向源站 IP 后仍然报错，通常是源站 Web 服务、WordPress、PHP、数据库或服务器配置问题。
- 如果只在 wp-admin、wp-login.php、wp-json、支付回调、搜索页等路径报错，多半与 WAF、Bot 规则、安全插件或权限配置有关。
- 如果刚刚换服务器、换 IP、改 CNAME、生成 SSL 证书，优先检查 DNS 和 SSL，不要先怀疑主题模板。
实战建议：每次只改一个变量，改完立刻用无痕窗口和手机网络复测。一次同时改 DNS、SSL、WAF、缓存和插件，即使网站恢复，也很难知道真正原因。
Cloudflare 常见错误代码快速对照
| 错误/关键词 | 常见含义 | 优先排查方向 |
|---|---|---|
| error 1016 | Cloudflare 找不到可解析的源站 | DNS 记录、CNAME 目标、负载均衡源站、错误 AAAA |
| error code 521 | 源站拒绝 Cloudflare 连接 | Web 服务状态、80/443 端口、防火墙、Cloudflare IP 白名单 |
| cloudflare error 1000 | DNS 指向禁止目标或产生回环 | Cloudflare IP、内网 IP、127.0.0.1、循环 CNAME |
| cloudflare 403 | 请求被禁止访问 | Cloudflare WAF、Bot、IP 规则、源站安全插件、服务器 deny |
| cloudflare ssl handshake failed | Cloudflare 与源站 TLS 握手失败 | SSL/TLS 模式、证书有效期、证书链、SNI、TLS 版本 |
| cloudflare error 500 | 源站内部错误或程序异常 | PHP error_log、debug.log、插件主题冲突、rewrite、数据库 |
error 1016：DNS 找不到源站，先别动 WordPress
error 1016 通常会提示 Origin DNS error。它的核心意思是 Cloudflare 想回源，但无法把你配置的源站主机名解析到可访问地址。这个错误常出现在迁站、删除旧 DNS 记录、把 www 改成 CNAME、使用负载均衡、接入第三方托管平台之后。它和 Elementor、主题样式、缓存插件关系不大。
具体解决步骤
- 进入 Cloudflare → DNS，找到报错主机名对应的 A、AAAA 或 CNAME 记录，例如 @、www、shop、blog、api。
- 根域名通常应使用 A/AAAA 指向主机商提供的真实源站 IP；www 可按主机商要求 CNAME 到根域名或指定 hostname。
- 不要把开启橙云后解析出来的 Cloudflare 边缘 IP 当作源站 IP 再填回 DNS。这样很容易引发 1000 或回源异常。
- 如果使用 CNAME，复制目标域名，用 dig、nslookup 或第三方 DNS Checker 检查它在公网是否能解析。只在主机商内部解析的地址，Cloudflare 无法使用。
- 检查是否存在错误 AAAA 记录。很多站点服务器并未配置 IPv6，却残留了旧 AAAA，导致部分地区访问异常。
- 保存 DNS 后等待生效，再用无痕窗口、手机 4G/5G 和不同地区检测工具复测。
如果你的站点单独卡在 1016，可继续看站内教程 Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程，里面对 DNS Origin Error 有更细的处理思路。
error code 521：Cloudflare 连到了门口，但服务器拒绝开门
error code 521 常见提示是 Web server is down，但它不一定代表服务器整机宕机。更多时候是 Cloudflare 节点尝试连接源站的 80 或 443 端口时被拒绝。原因可能是 Nginx、Apache、OpenLiteSpeed 没启动，云服务器安全组没放行端口，iptables/ufw、CSF、Fail2ban、宝塔防火墙或主机商 WAF 把 Cloudflare IP 拦住。
具体解决步骤
- 先检查源站是否能直连。可以短时间灰云测试，或在本地 hosts 指向真实源站 IP。测试完成后记得恢复代理。
- 登录服务器，确认 Web 服务正在运行：Nginx、Apache、OpenLiteSpeed 或 LiteSpeed 是否 active，站点虚拟主机是否加载成功。
- 确认 80 和 443 端口在云安全组、防火墙、主机面板和服务器系统层都已放行。
- 把 Cloudflare 官方 IP 段加入白名单，尤其是安装了 Fail2ban、CSF、宝塔防火墙、ModSecurity 或主机商安全防护时。
- 查看源站 access log。如果完全没有 Cloudflare 请求，说明请求在网络或防火墙层被挡住；如果有请求但返回 5xx，再继续查程序和配置。
如果同时遇到 502、503、504，可以参考 Cloudflare 500/502/503 真相：一文理清本质区别，先区分连接失败、超时和源站应用错误。
cloudflare error 1000：DNS 指向了不允许代理的地址
cloudflare error 1000 经常和 DNS 配错有关。常见情况是 A/AAAA 记录指向 Cloudflare 自己的边缘 IP、127.0.0.1、10.x、192.168.x、172.16.x 到 172.31.x 内网地址，或者 www 与根域名互相 CNAME，形成循环。它和 1016 都是 DNS 类问题，但区别在于：1016 是找不到有效源站，1000 是找到了一个 Cloudflare 不允许代理的目标。
具体解决步骤
- 核对 A/AAAA 记录，确保填写主机商提供的真实源站 IP，而不是 ping 域名得到的 Cloudflare IP。
- 删除迁站前遗留的测试记录、旧主机记录、重复记录，避免同一主机名下多条冲突解析。
- 如果平台要求 CNAME 接入，按平台文档填写 CNAME，不要把 CNAME 中间解析结果复制成 A 记录。
- 检查根域名与 www 是否互相引用。一般建议根域名指向源站，www CNAME 到根域名，或按托管平台指定方式配置。
- 修改后清理浏览器缓存和本地 DNS 缓存，再换网络复测。
cloudflare 403：先分清是 Cloudflare 拦截，还是源站拒绝
cloudflare 403 是最容易误判的一类。它可能来自 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting，也可能来自源站 Nginx/Apache、主机商 WAF、Wordfence、iThemes Security、All In One WP Security 等插件。不要一看到 403 就关闭所有安全功能，先确认拦截发生在哪里。
具体解决步骤
- 记录 403 页面上的 Ray ID、访问路径、访客 IP 和发生时间。
- 进入 Cloudflare → Security → Events，用 Ray ID、IP 或路径筛选。如果看到命中的 WAF 规则，优先做精确 Skip 或 Allow，不要直接关掉全站 WAF。
- 重点检查 wp-admin、wp-login.php、wp-json、xmlrpc.php、支付回调、会员登录、搜索接口是否被 Bot 或 Rate Limiting 误伤。
- 如果 Cloudflare 没有任何安全事件记录，就到源站 access/error log 和 WordPress 安全插件日志中查 403 来源。
- 对管理员 IP、支付网关 IP、监控服务、Google/Bing 爬虫做必要放行，但避免把整站路径全部放白。
使用 Wordfence 的站点，可结合 Wordfence Security 插件安装配置指南 检查登录保护、REST API 和目录访问限制，避免和 Cloudflare 规则重复拦截。
cloudflare ssl handshake failed：检查源站证书，而不只是 Cloudflare 证书
搜索 cloudflare ssl handshake failed 的用户，实际可能看到 525 SSL handshake failed，也可能看到 526 Invalid SSL certificate。问题发生在 Cloudflare 与源站建立 HTTPS 连接时。很多人只盯着浏览器地址栏的小锁，但忽略了 Cloudflare 到源站之间也需要一张有效证书，尤其是在 Full (strict) 模式下。
具体解决步骤
- 推荐使用 Full (strict)，但前提是源站证书有效、未过期、域名匹配、证书链完整。
- 检查证书是否覆盖根域名和 www。迁站或重新签发证书时，经常只绑定其中一个。
- 如果使用 Cloudflare Origin Certificate，确认已经把证书和私钥安装到服务器站点配置中，而不是只在 Cloudflare 后台生成。
- 检查源站 TLS 版本和加密套件，过旧系统可能无法和 Cloudflare 正常握手。
- 确认 DNS 已指向新服务器，避免 Cloudflare 回源到旧服务器上的过期证书。
SSL 配错还可能造成循环跳转，推荐延伸阅读 Flexible SSL 模式的致命误区 respond in singing Solution for Cloudflare SSL Settings that Raise TOO_MANY_REDIRECTSThe
cloudflare error 500：多数时候要回到 WordPress 日志
cloudflare error 500 并不总是 Cloudflare 本身故障。更多情况下，Cloudflare 只是把源站返回的 500 展示给访客。对于 WordPress 站点，常见原因包括插件更新后 fatal error、主题 functions.php 冲突、PHP 版本不兼容、内存不足、数据库连接异常、.htaccess 损坏、Nginx rewrite 写错、文件权限异常。
具体解决步骤
- 临时灰云或 hosts 直连源站。如果绕过 Cloudflare 仍然 500，基本就是源站问题。
- 查看 PHP error_log、wp-content/debug.log、Nginx/Apache error log，优先搜索 fatal error、memory exhausted、permission denied、database error。
- 回滚最近更新的插件、主题、PHP 版本、缓存配置和安全规则。缓存、安全、支付、SEO、SMTP、页面构建器插件都值得重点检查。
- 检查 PHP memory_limit、max_execution_time、max_input_vars 是否适合当前站点规模。WooCommerce 和 Elementor 站点尤其容易受内存限制影响。
- 恢复默认固定链接规则，确认 .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 检查是否指向禁止地址或形成 CNAME 回环；cloudflare 403 先确认拦截来源；cloudflare ssl handshake failed 回到源站证书和 TLS；cloudflare error 500 则重点看 WordPress、PHP 和服务器日志。按这个顺序处理，通常能更快恢复网站，也能避免把原本安全、稳定的配置误删。
延伸阅读
- Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程
- SSL证书握手失败：深入解决 Cloudflare 525 错误
- Cloudflare 500/502/503 真相：一文理清本质区别
- 常见 WordPress 故障修复
运营检查提示：如果你也在做批量内容排期，建议把发布后核验、WP-Cron 漏发检查、媒体库配图和内链数量写进固定流程；自动化调度思路可参考 OpenClaw 官方文档The
Link to this article:https://www.361sale.com/en/88086/The article is copyrighted and must be reproduced with attribution.
简体中文 
English 
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 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. 👍