Cloudflare 报错别急着重装网站:1016、521、1000、403、SSL 握手和 500 一次排清

Cloudflare 报错经常会让新手站长误判:看到 1016 就怀疑 WordPress 坏了,看到 521 就急着重装服务器,看到 403 就去禁用所有插件。实际上,大多数 Cloudflare 错误都可以按“DNS、源站、SSL、防火墙、缓存”五个层面逐步排查。只要顺序正确,通常不需要大规模回滚网站。

本文把 1016、521、1000、403、SSL handshake failed 和 500 放在同一套排查表里,适合 WordPress、Elementor、WooCommerce 和独立站使用。你可以先确认错误发生在哪一层,再决定是改 DNS、查主机、防火墙放行,还是清理页面缓存。

先判断错误属于哪一层

Cloudflare 位于访客和源站之间,所以报错不一定来自 WordPress。访问链路可以简化为:访客浏览器访问 Cloudflare,Cloudflare 再访问源站服务器,源站把页面返回给 Cloudflare,最后再返回给访客。任何一段出问题,前台都可能显示 Cloudflare 错误页。

DNS 层常见信号

如果错误提示涉及 DNS 解析、CNAME、A 记录或 origin error,优先检查 DNS。特别是 1016 和 1000,通常和记录配置、代理状态、指向目标有关。不要先动 WordPress 插件,因为插件不会改变 Cloudflare 是否能找到源站。

源站层常见信号

如果错误是 521、522、523 或偶发 500,通常要看服务器是否能被 Cloudflare 访问。源站宕机、防火墙拦截 Cloudflare IP、端口未开放、PHP-FPM 崩溃、Nginx 配置错误,都可能造成这类问题。

Cloudflare 1016、521、1000 错误排查截图
Cloudflare 1016、521、1000 错误排查截图

1016 Origin DNS Error 怎么排查

1016 表示 Cloudflare 无法解析到源站。常见原因有三类:DNS 记录不存在、CNAME 指向的目标失效、使用了 Cloudflare 不支持的记录组合。排查时先进入 Cloudflare DNS 页面,确认根域名和 www 都有正确记录,并且指向当前主机提供的 IP 或 CNAME。

如果你刚迁移主机,最容易忘的是把旧 IP 更新为新 IP。还要检查是否把 CNAME 指向了一个同样开启 Cloudflare 代理的域名,导致循环解析。对于 WordPress 站点,建议先用灰云模式测试源站是否能打开,再重新开启橙云代理。

521 Web Server Is Down 怎么排查

521 不是 Cloudflare 自己宕机,而是 Cloudflare 连接不到源站 Web 服务。先在服务器上检查 Nginx 或 Apache 是否运行,再看 80 和 443 端口是否开放。如果你使用安全组、防火墙或宝塔面板,确认没有拦截 Cloudflare IP 段。

源站正常但仍然 521

有些服务器能从本机访问,却拒绝 Cloudflare 节点访问。这时要看防火墙日志、WAF 规则和主机商安全策略。不要只刷新缓存,因为缓存无法解决源站拒绝连接。站内关于 主题配置路线图 的文章也提醒过,上线前应把主机、主题和缓存分开验证。

1000 DNS points to prohibited IP 怎么排查

1000 通常表示 DNS 记录指向了 Cloudflare 禁止代理的 IP,例如 Cloudflare 自己的 IP、保留地址或错误的内部地址。解决方法是把 A 记录改成真实源站 IP,或者把 CNAME 改成主机商给出的正确目标。不要把域名指回自己,也不要把 www 指向一个会再跳回根域名的错误代理层。

403 Forbidden 怎么排查

403 可能来自 Cloudflare,也可能来自源站。先看错误页样式:如果页面带 Cloudflare Ray ID,多半是 Cloudflare 防火墙、安全规则、Bot Fight Mode 或地区拦截;如果是主机默认 403,可能是目录权限、Nginx 配置、WordPress 安全插件或 .htaccess 规则。

排查 403 时建议先查看 Cloudflare Security Events,按 Ray ID 搜索请求。如果命中了规则,可以临时放行自己的 IP,再调整规则范围。WordPress 侧则检查安全插件是否拦截 REST API、登录页或 Elementor 请求。类似前台显示异常,也可参考 Elementor 页面内容显示不对的排查顺序

Cloudflare 403、SSL handshake failed、500 错误排查截图
Cloudflare 403、SSL handshake failed、500 错误排查截图

SSL handshake failed 怎么排查

SSL 握手失败通常和证书模式不匹配有关。Cloudflare 的 SSL/TLS 模式如果设置为 Full strict,源站必须有有效证书,证书域名也要匹配。如果源站只有自签证书或证书过期,就可能握手失败。临时排查可以切到 Full 测试,但长期建议修复源站证书,而不是一直降低安全等级。

Flexible 模式的风险

Flexible 会让浏览器到 Cloudflare 是 HTTPS,但 Cloudflare 到源站是 HTTP。它看似省事,却容易造成 WordPress 后台重定向循环、混合内容和登录异常。正式站点更建议使用 Full 或 Full strict,并在 WordPress 后台正确设置站点 URL。

500 错误不要只怪 Cloudflare

500 多数来自源站程序。Cloudflare 只是把错误展示给访客。排查时先绕过 Cloudflare,用源站 IP 或灰云模式访问,再查看 PHP error log、Nginx error log 和 WordPress debug log。插件冲突、主题函数错误、PHP 内存不足、数据库连接异常都可能导致 500。

如果 500 只在发布文章或编辑 Elementor 时出现,重点查 PHP 内存、对象缓存、REST API 和安全插件。性能类插件也可能改变缓存行为,排查时可以参考 Perfmatters、WP Rocket、Imagify、Smush 对比清单,先区分缓存、图片压缩和脚本优化各自负责的部分。

推荐的排查顺序

第一步,看错误代码和 Ray ID;第二步,在 Cloudflare 后台查 DNS、SSL 和安全事件;第三步,用灰云模式或源站 hosts 验证服务器;第四步,看主机日志;第五步,再检查 WordPress 插件、主题和缓存。按这个顺序能避免把网络层问题误判为网站程序问题。

上线前的预防清单

上线前建议保存 DNS 记录截图、源站 IP、SSL 模式、缓存规则和防火墙规则。迁移主机时先降低 TTL,确认新源站能直接访问,再切换 Cloudflare。需要更系统地理解代理和自动化巡检,可以查看 OpenClaw 官方文档,把错误检查纳入每日运营任务。

总结

Cloudflare 报错的核心不是背代码,而是定位链路。1016 和 1000 先查 DNS,521 先查源站连接,403 先分清 Cloudflare 规则还是源站权限,SSL 握手失败先查证书模式,500 先看服务器和 WordPress 日志。只要按层排查,就能避免无效重装和盲目禁用插件。

THE END
喜欢就支持一下吧
点赞5 分享
评论 抢沙发

请登录后发表评论

    暂无评论内容