Cloudflare 常见错误代码怎么修？1016、521、1000、403、SSL 握手和 500 一次讲清-光子波动网

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 Error 1016 Origin DNS error 官方文档截图

先判断：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 排查教程和 Cloudflare Error 1016：DNS 指向与源站连接怎么修。如果你只遇到 1016，可以优先看这两篇更细的 DNS 案例。

Error code 521：源站拒绝 Cloudflare 连接

Error code 521 页面常写着 web server is down，但它不一定代表主机真的宕机。很多时候是源站服务器在线，却拒绝了 Cloudflare 的连接请求。原因可能是 Web 服务没启动、80/443 端口没监听、防火墙拦截 Cloudflare IP、主机商安全策略把 Cloudflare 当成异常流量，或者服务器连接数被打满。

Cloudflare Error 521 web server is down 官方文档截图

具体解决步骤

先绕过 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 记录来回复制，最容易把“目标地址”和“代理地址”搞混。

Cloudflare Error 1000 DNS points to prohibited IP 官方文档截图

具体解决步骤

检查 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 插件安装配置指南，以及常见 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 模式的致命误区：ERR_TOO_MANY_REDIRECTS 和 Cloudflare SSL 设置引发 TOO_MANY_REDIRECTS 的解决方案。

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，不要在问题未定位前把所有安全规则永久关闭。

总结

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 模式更快、更安全。

延伸阅读

联系我们
教程看不懂？联系我们为您免费解答！免费助力个人，小企站点！	客服微信
① 电话：020-2206-9892
② QQ咨询：1025174874
③ 邮件：[email protected]
④ 工作时间：周一至周五，9:30-18:30，节假日休息