接入 Cloudflare 后，网站访问速度和安全性通常会更好，但一旦出现 error 1016,error code 521,cloudflare error 1000,cloudflare 403,cloudflare ssl handshake failed maybe cloudflare error 500，很多站长第一反应就是清缓存、暂停代理、停用插件。这样做有时能临时恢复，却很容易错过真正原因，甚至把 DNS、SSL、WAF 和 WordPress 程序错误混在一起。
这篇文章按真实排障顺序来写：先判断请求卡在 DNS、回源连接、SSL 握手、安全拦截，还是 WordPress/PHP 源站程序层；再分别给出可执行步骤。适合 WordPress、WooCommerce、Elementor 网站在迁站、换 IP、启用防火墙、更新证书、修改解析后快速定位问题。
排查前先做 4 件事
- 保存错误页截图，记录 Cloudflare Ray ID、访问 URL、发生时间和访客地区。
- 回想最近 24 小时是否改过 DNS、服务器 IP、SSL 证书、WAF 规则、缓存插件、主题或 PHP 版本。
- 用无痕窗口、手机网络和不同地区检测工具复测，避免只被本地 DNS 或浏览器缓存误导。
- 每次只修改一个变量。一次同时关 WAF、灰云、删插件、改 SSL，即使恢复也不知道是哪一步有效。
错误代码快速对照表
| error code | 通常含义 | 优先处理位置 |
|---|---|---|
| error 1016 | Cloudflare 无法解析源站主机名 | DNS 记录、CNAME 目标、错误 AAAA |
| error code 521 | 源站拒绝 Cloudflare 连接 | Web 服务、80/443 端口、防火墙 |
| cloudflare error 1000 | DNS 指向被禁止的地址或形成回环 | 真实源站 IP、CNAME 循环、内网 IP |
| cloudflare 403 | 访问被 Cloudflare 或源站拒绝 | WAF、Bot、IP 规则、安全插件 |
| cloudflare ssl handshake failed | Cloudflare 到源站 TLS 握手失败 | SSL/TLS 模式、源站证书、证书链 |
| cloudflare error 500 | 源站程序或服务器内部错误 | PHP 日志、插件主题冲突、数据库、伪静态 |
error 1016：先查 DNS，别先动主题
error 1016 常见提示是 Origin DNS error。意思是 Cloudflare 想回源，但找不到可用的源站地址。它常发生在迁站后删除旧解析、把 www 改成 CNAME、使用第三方托管平台、配置负载均衡或误删根域名记录之后。
解决步骤
- 进入 Cloudflare → DNS，检查 @、www、shop、blog、api 等主机名是否都有正确记录。
- 根域名一般用 A/AAAA 指向主机商提供的真实服务器 IP；www 可 CNAME 到根域名或平台指定 hostname。
- 不要把 ping 域名得到的 Cloudflare 边缘 IP 填回 A 记录，这会引出 1000 或回源异常。
- 如果用了 CNAME，复制目标域名用 nslookup/dig 检查公网是否能解析。只能在服务商内网解析的目标，Cloudflare 不能使用。
- 检查是否残留错误 AAAA 记录。服务器没有 IPv6 却保留 AAAA，可能导致部分地区访问异常。
如果你只遇到 1016，可继续参考 Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程The
error code 521：服务器拒绝 Cloudflare 连接
521 经常显示 Web server is down，但并不一定是服务器整机宕机。更常见的是 Nginx、Apache、OpenLiteSpeed 没有监听端口，云安全组没放行 80/443，或者防火墙、安全插件、主机商 WAF 把 Cloudflare IP 当成异常流量拦截。
解决步骤
- 短时间灰云或本地 hosts 指向真实源站 IP 测试，确认源站本身是否可访问。
- 登录服务器检查 Web 服务状态：systemctl status nginx/apache2/lsws，确认站点虚拟主机加载成功。
- 检查云服务器安全组、面板防火墙、ufw/iptables/CSF 是否放行 80 和 443。
- 把 Cloudflare 官方 IP 段加入白名单，尤其是使用宝塔、防火墙、Fail2ban、ModSecurity 的站点。
- 查看源站 access log：没有请求说明被网络或防火墙拦住；有请求但 5xx，则继续看 PHP 和程序日志。
如果同时看到 502、503、504，可延伸阅读 Cloudflare 500/502/503 真相：一文理清本质区别The
cloudflare error 1000：DNS 指向了不允许代理的目标
cloudflare error 1000 与 DNS 配错高度相关。常见原因包括 A 记录指向 Cloudflare 自己的 IP、127.0.0.1、10.x/192.168.x 内网地址，或者根域名和 www 互相 CNAME 形成循环。1016 是找不到源站，1000 则是目标地址不允许被代理。
- 核对所有 A/AAAA 记录，只保留真实源站 IP。
- 删除迁站遗留的重复记录、测试记录和旧服务器记录。
- 不要把 CNAME 的解析结果手动复制成 A 记录，按平台文档保持 CNAME 即可。
- 避免 @ 与 www 互相 CNAME。常见做法是 @ 指向源站，www CNAME 到 @，或完全按托管平台要求配置。
cloudflare 403：先判断拦截发生在哪里
403 可能来自 Cloudflare，也可能来自源站。比如 Cloudflare WAF、Bot Fight Mode、Rate Limiting、IP Access Rules 会返回 403；源站 Nginx/Apache deny、Wordfence、iThemes Security、All In One WP Security、主机商 WAF 也会返回 403。
- 用 Ray ID、访客 IP、路径和时间到 Cloudflare → Security → Events 查询。
- 如果命中 WAF 规则，对 wp-admin、wp-json、支付回调、会员登录等必要路径做精确 Skip，不要直接关闭全站 WAF。
- 如果 Cloudflare 没有安全事件，就去源站 access/error log 和安全插件日志查 403 来源。
- 对管理员固定 IP、支付网关、监控服务和搜索引擎爬虫做必要放行，但不要把整站全放白。
使用 Wordfence 的站点可以结合 Wordfence Security 插件安装配置指南 检查是否与 Cloudflare 规则重复拦截。
cloudflare ssl handshake failed：源站证书也必须正确
SSL 握手失败通常对应 525 或 526。很多人只看浏览器地址栏的小锁，却忘了 Cloudflare 和源站之间也要完成 HTTPS 握手。Full (strict) 模式下，源站证书必须有效、未过期、域名匹配，并且证书链完整。
- 建议使用 Full (strict)，但先确认源站证书覆盖根域名和 www。
- 如果使用 Cloudflare Origin Certificate，要把证书和私钥安装到服务器站点配置里，而不是只在 Cloudflare 后台生成。
- 检查源站 TLS 版本和加密套件，老系统或过旧 OpenSSL 可能握手失败。
- 确认 DNS 已指向新服务器，避免 Cloudflare 回源到旧机器上的过期证书。
SSL 设置还可能引发跳转循环，可参考 Flexible SSL 模式的致命误区 respond in singing Solution for Cloudflare SSL Settings that Raise TOO_MANY_REDIRECTSThe
cloudflare error 500：回到 WordPress 和 PHP 日志
cloudflare error 500 多数时候并不是 Cloudflare 自己坏了，而是源站返回了内部错误。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 版本和缓存配置，Elementor、WooCommerce、缓存、安全、支付插件要重点排查。
- 检查 memory_limit、max_execution_time、max_input_vars 和数据库连接，必要时临时启用 WP_DEBUG_LOG。
- 恢复固定链接规则，确认 .htaccess 或 Nginx rewrite 没有语法错误。
推荐的恢复顺序
- DNS：记录是否存在、是否重复、是否指向真实源站，是否有错误 AAAA 或 CNAME 回环。
- 回源：Web 服务是否运行，80/443 是否开放，Cloudflare IP 是否被防火墙拦截。
- SSL：Cloudflare SSL 模式、源站证书、证书链、TLS 版本和回源 IP。
- 安全：Cloudflare Security Events、WAF、Bot、Rate Limiting、源站安全插件。
- WordPress：debug.log、插件主题冲突、缓存、数据库、伪静态和 PHP 配置。
summarize
处理 Cloudflare 常见错误代码，关键不是死记代码，而是按链路分层。error 1016 先修 DNS；error code 521 查源站连接和防火墙；cloudflare error 1000 纠正禁止地址或 CNAME 回环；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/88156/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. 👍