Cloudflare 报错最让人头疼的地方，不是页面上出现了英文代码，而是很多代码看起来都像“服务器坏了”。比如 error 1016 和 cloudflare error 1000 都与 DNS 有关，但处理方向完全不同；error code 521 像源站宕机，实际也可能只是防火墙挡住了 Cloudflare；cloudflare ssl handshake failed 通常对应 525/526 一类握手问题；cloudflare 403 和 cloudflare error 500 又要先判断错误来自 Cloudflare、源站程序还是安全规则。
这篇文章按站长实际排查顺序整理：先判断错误发生在哪一层，再分别处理 1016、521、1000、403、SSL handshake failed 和 500。你可以一边打开 Cloudflare 后台，一边对照源站主机面板、DNS 记录、SSL 证书和服务器日志逐项排除。
先判断：Cloudflare 报错到底卡在哪一层？
不要一看到 Cloudflare 错误就马上改 DNS 或重启服务器。更稳妥的做法是先分层：浏览器到 Cloudflare、Cloudflare 到源站、源站应用本身。浏览器能看到 Cloudflare 的错误页面，说明访问者大概率已经到达 Cloudflare；如果错误提示 origin、web server、SSL handshake，多半是 Cloudflare 回源时遇到问题；如果页面样式像 WordPress、Nginx 或主机默认 500 页面，则要优先查源站。
- 先在 Cloudflare 后台确认域名状态是否 Active，DNS 记录是否被代理（橙云）。
- 用本地命令或在线工具查询 A/CNAME 记录，看是否解析到正确源站。
- 临时将可疑记录切为 DNS only（灰云）测试源站是否能直接访问，测试后再恢复。
- 查看源站防火墙、安全组、Fail2ban、宝塔/主机 WAF 是否拦截 Cloudflare IP。
- 查看服务器错误日志和网站程序日志，确认是否有 PHP fatal error、数据库连接失败或证书错误。
Error 1016：Origin DNS error，Cloudflare 找不到源站地址
Error 1016 的核心意思是：Cloudflare 无法解析源站 Web 服务器的 IP 地址。常见场景包括：你把 www 做成 CNAME，但 CNAME 指向的目标已经不存在；A 记录被删除；记录写错；使用了第三方 SaaS 域名但对方没有正确返回解析；或者负载均衡、源站池里的 hostname 无法解析。
具体解决步骤
- 进入 Cloudflare DNS 页面，检查出错主机名对应的 A、AAAA 或 CNAME 记录是否存在。
- 如果是根域名，优先使用正确的 A 记录或 AAAA 记录；如果是 www，可以用 CNAME 指向根域名或主机商给出的目标。
- 避免把 CNAME 指向一个无法公开解析的内网域名、已过期域名或拼写错误的主机名。
- 如果使用 Cloudflare Load Balancing，检查每个 origin hostname 是否能在公网 DNS 中解析。
- 保存后等待几分钟，再用 dig/nslookup 或 DNS Checker 确认解析链路正常。
站内之前也单独写过 Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程 respond in singing Cloudflare Error 1016: DNS pointing to a connection with the source how to fix it。如果你只遇到 1016，可以优先看这两篇更细的 DNS 案例。
Error code 521：源站拒绝 Cloudflare 连接
Error code 521 页面常写着 web server is down，但它不一定代表主机真的宕机。很多时候是源站服务器在线，却拒绝了 Cloudflare 的连接请求。原因可能是 Web 服务没启动、80/443 端口没监听、防火墙拦截 Cloudflare IP、主机商安全策略把 Cloudflare 当成异常流量，或者服务器连接数被打满。
具体解决步骤
- 先绕过 Cloudflare 直接访问源站 IP 或临时灰云，确认 Nginx/Apache/LiteSpeed 是否能返回页面。
- 在服务器执行 systemctl status nginx/apache2/httpd/lsws，确认 Web 服务正在运行。
- 检查安全组、防火墙、宝塔防火墙、主机 WAF，把 Cloudflare 官方 IP 段加入允许列表。
- 确认 80 和 443 端口对公网开放，不要只允许本机或特定办公 IP。
- 查看 access log 和 error log：如果完全没有 Cloudflare 请求，优先查网络和防火墙；如果有请求但返回异常，继续查源站配置。
如果你还分不清 500、502、503 与 521 的区别，可以参考 Cloudflare 500/502/503 真相。它能帮助你判断问题是 CDN 层、源站层，还是应用层。
Cloudflare Error 1000：DNS 指向了禁止 IP
cloudflare error 1000 通常表示 DNS 记录指向了 Cloudflare 禁止代理的 IP，例如指向 Cloudflare 自己的 IP、保留地址、内网地址，或者形成了错误的回环。很多新手在迁站时把 CNAME、A 记录来回复制，最容易把“目标地址”和“代理地址”搞混。
具体解决步骤
- 检查 A/AAAA 记录，不要填 Cloudflare 边缘节点 IP，也不要填 127.0.0.1、10.x、172.16-31.x、192.168.x 等内网地址。
- 如果主机商提供的是 CNAME，按主机商要求填写 CNAME，不要自行把它解析后的中间 IP 填进 Cloudflare。
- 确认根域名和 www 不要互相 CNAME 成死循环。
- 删除重复、冲突的 DNS 记录，例如同一主机名同时存在多条不确定来源的 A 记录。
- 改完后清理 Cloudflare 缓存，并等待 DNS 生效。
Cloudflare 403：先分清是 Cloudflare 拦截，还是源站返回
cloudflare 403 的排查重点是“谁返回的 403”。如果页面明确显示 Cloudflare Ray ID，或者后台 Security Events 能看到拦截记录，通常是 WAF、Bot Fight Mode、IP Access Rules、Rate Limiting、托管规则误拦。若页面是主机或 WordPress 插件样式，则可能是源站权限、目录规则、Wordfence/安全插件、Nginx deny、.htaccess 或文件权限导致。
具体解决步骤
- 在 Cloudflare 后台进入 Security Events，按访问时间、IP、路径筛选，查看触发了哪条规则。
- 如果是 WAF 误拦后台、支付回调、API 路径，可为特定 URI、国家、IP 或 User-Agent 建立更精确的 Skip/Allow 规则。
- 如果 Security Events 没有记录，去源站查 Nginx/Apache 日志和 WordPress 安全插件日志。
- 检查 wp-admin、wp-json、xmlrpc.php、上传目录等路径是否被过度限制。
- 修复后用无痕窗口、手机网络和不同地区节点复测，避免只在管理员网络正常。
如果 403 与 WordPress 权限或安全插件有关，可以继续看 Wordfence Security 插件安装配置指南as well as 常见 WordPress 故障修复 分类里的排查文章。
Cloudflare SSL handshake failed：重点看证书、模式和 SNI
很多人搜索 cloudflare ssl handshake failed，实际遇到的常是 525 SSL handshake failed 或 526 invalid SSL certificate。它表示 Cloudflare 与源站建立 HTTPS 连接时握手失败。常见原因包括：源站没有安装有效证书、证书过期、证书域名不匹配、只支持过旧 TLS、源站要求特殊 SNI、Cloudflare SSL 模式与服务器配置不一致。
具体解决步骤
- 在 Cloudflare SSL/TLS 中确认模式。生产站建议使用 Full (strict)，前提是源站证书有效且域名匹配。
- 检查源站证书是否覆盖 example.com 和 www.example.com，是否过期，证书链是否完整。
- 如果使用 Cloudflare Origin Certificate，确认服务器已正确部署证书和私钥，并绑定到对应站点。
- 检查 Nginx/Apache 的 TLS 配置，启用 TLS 1.2/1.3，不要只保留过旧协议。
- 如果刚迁站，确认 Cloudflare 回源到的是新服务器，而不是仍然解析到旧 IP 的证书。
如果 SSL 配置同时引发循环跳转，可以参考 Flexible SSL Mode Fatal Mistake: ERR_TOO_MANY_REDIRECTS respond in singing Solution for Cloudflare SSL Settings that Raise TOO_MANY_REDIRECTSThe
Cloudflare Error 500：不要只盯着 Cloudflare
cloudflare error 500 是最容易误判的一类。真正的 500 多数来自源站应用：WordPress 插件冲突、主题 fatal error、PHP 版本不兼容、内存不足、数据库连接异常、.htaccess 写错、文件权限错误等。Cloudflare 只是把源站返回的 500 展示给访客。只有在 Cloudflare 官方状态页异常、多个无关站点同时受影响时，才更像 Cloudflare 平台侧问题。
具体解决步骤
- 把 DNS 临时切灰云或通过 hosts 指向源站 IP，确认绕过 Cloudflare 后是否仍然 500。
- 开启 WordPress 调试日志或查看主机 PHP error_log，寻找 fatal error、memory exhausted、database error 等关键词。
- 临时停用最近更新的插件和主题，尤其是缓存、安全、页面构建器、支付、SMTP 插件。
- 检查 PHP 版本、memory_limit、max_execution_time 是否满足当前主题和插件。
- 确认 .htaccess 或 Nginx rewrite 没有语法错误，必要时恢复 WordPress 默认伪静态规则。
一张通用排查清单：从快到慢处理
先不要同时改 DNS、SSL、防火墙和插件。一次只改一个变量，记录修改时间，复测结果才可信。
- 截图保存错误页面，记录错误代码、Ray ID、访问 URL、发生时间和访问者地区。
- 看 Cloudflare Analytics 与 Security Events，确认是否有 WAF 拦截或回源错误峰值。
- 检查 DNS：A/AAAA/CNAME 是否正确、是否有重复记录、是否指向源站而不是 Cloudflare IP。
- 检查源站：Web 服务、端口、防火墙、Cloudflare IP 白名单。
- 检查 SSL：模式、证书有效期、证书链、TLS 协议、SNI。
- 检查 WordPress：插件冲突、PHP 错误日志、缓存插件、重定向规则。
- 恢复访问后再打开缓存与 WAF，不要在问题未定位前把所有安全规则永久关闭。
summarize
Cloudflare 常见错误代码看似复杂，但背后的逻辑并不乱：error 1016 是 Cloudflare 找不到源站 DNS；error code 521 是源站拒绝连接；cloudflare error 1000 是 DNS 指向了禁止 IP；cloudflare 403 要分清 Cloudflare WAF 与源站权限；cloudflare ssl handshake failed 重点检查证书和 TLS；cloudflare error 500 则多半要回到 WordPress、PHP 和服务器日志。按“DNS—源站—SSL—安全规则—程序日志”的顺序排查，通常比盲目重装插件或反复切换 SSL 模式更快、更安全。
延伸阅读
- Cloudflare Error 1016 怎么解决？DNS Origin Error 排查教程
- Cloudflare 500/502/503 真相：一文理清本质区别
- SSL Certificate Handshake Failed: A Deep Dive into Resolving Cloudflare's 525 Error
- Server operation and maintenance
Link to this article:https://www.361sale.com/en/87619/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. 👍