Cloudflare 报错页面一出现,很多站长第一反应就是“服务器挂了”或“SSL 坏了”。但真正排查时,error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed 和 cloudflare error 500 分别指向不同层面:有的是 DNS 写错,有的是源站拒绝连接,有的是安全规则拦截,有的才是 WordPress 或服务器程序本身报错。
这篇文章按普通 WordPress 站长能执行的顺序来写:先判断错误来自哪一层,再给出每个代码的具体处理步骤。你不需要一次性改完所有设置,反而应该一次只改一个变量,记录修改时间,再用无痕窗口、手机网络和在线检测工具复测。

先做 3 个判断:别一上来就重装插件
Cloudflare 位于访客和源站之间。浏览器访问域名时,请求先到 Cloudflare,再由 Cloudflare 回源到你的服务器。因此,同样是“打不开网站”,可能卡在浏览器到 Cloudflare、Cloudflare 到源站、源站程序处理请求这三段中的任意一段。
- 看错误页是否有 Cloudflare Ray ID。如果有,说明请求已经到达 Cloudflare;如果没有,可能是本地网络、DNS 传播或源站直接返回。
- 看关键词:Origin DNS、web server is down、SSL handshake、WAF blocked、Internal Server Error 分别对应 DNS、连接、证书、安全规则、源站程序。
- 先保存截图、Ray ID、访问 URL、发生时间和访客地区。后面查 Cloudflare Security Events、主机日志和 PHP error_log 时,这些信息非常关键。
如果你使用 WordPress,建议同时打开主机面板、Cloudflare DNS 页面、SSL/TLS 页面和站点日志。不要在问题未定位前同时切换 SSL 模式、删除 DNS 记录、停用所有插件、关闭 WAF,这样只会让问题更难复盘。
快速对照表:常见代码该先查哪里
| エラーコード | 最可能的问题层 | 优先检查项 |
|---|---|---|
| error 1016 | DNS / 源站主机名 | A、AAAA、CNAME 是否存在,CNAME 目标是否能公开解析 |
| error code 521 | Cloudflare 回源连接 | Web 服务、80/443 端口、防火墙、Cloudflare IP 白名单 |
| cloudflare error 1000 | DNS 指向违规地址 | 是否指向 Cloudflare IP、内网 IP、回环地址或形成 CNAME 循环 |
| cloudflare 403 | WAF 或源站权限 | Security Events、IP Access Rules、WordPress 安全插件、Nginx/Apache deny |
| SSL handshake failed | 证书 / TLS | SSL 模式、源站证书、证书链、SNI、TLS 1.2/1.3 |
| cloudflare error 500 | 源站应用或平台异常 | PHP fatal error、插件冲突、数据库、.htaccess、服务器错误日志 |
Error 1016:Origin DNS error 怎么修?
error 1016 的核心含义是 Cloudflare 找不到可用的源站地址。它不是 WordPress 插件错误,也不是缓存问题,而是 Cloudflare 在回源之前就无法把你填写的主机名解析到有效 IP。最常见情况是 A 记录被删、CNAME 写错、CNAME 指向的域名过期,或者负载均衡里的 origin hostname 无法公开解析。
排查步骤
- 进入 Cloudflare → DNS,找到出错的主机名,例如 @、www、blog 或 api。
- 根域名通常使用 A/AAAA 记录指向源站 IP;www 可以 CNAME 到根域名,也可以按主机商要求 CNAME 到指定目标。
- 如果你使用 CNAME,复制目标域名后用 dig、nslookup 或 DNS Checker 检查它能否在公网解析。
- 不要把 CNAME 指向内网主机名、拼写错误的域名、已删除的临时域名或只在主机商内部可见的地址。
- 使用 Cloudflare Load Balancing 时,逐个检查 origin hostname 和健康检查地址,确保不是某个池里的地址失效。
如果只遇到 1016,可以继续看站内的 Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程,里面有更细的 DNS 指向案例。
Error code 521:源站拒绝了 Cloudflare
error code 521 页面经常显示 Web server is down,但它并不等于服务器一定宕机。更准确地说,是 Cloudflare 连接源站时被拒绝了。源站可能仍然能在本机访问,只是 80/443 端口没有对公网开放,或防火墙、主机 WAF、宝塔安全规则、Fail2ban 把 Cloudflare 节点当成异常流量拦截了。

排查步骤
- 临时把该 DNS 记录从橙云切到灰云,或通过 hosts 指向源站 IP,确认源站本身能否直接返回页面。测试完记得恢复代理。
- 在服务器检查 Nginx、Apache、LiteSpeed 是否运行,例如 systemctl status nginx 或 systemctl status apache2。
- 确认 80 和 443 端口对公网开放,云服务器安全组、主机防火墙和面板防火墙都要检查。
- 把 Cloudflare 官方 IP 段加入允许列表,尤其是开启了 WAF、Fail2ban、CSF、宝塔防火墙的站点。
- 查看 access log:如果完全没有 Cloudflare 请求,多半是网络或防火墙;如果有请求但返回异常,再继续查站点配置。
521 与 502、503、504 很容易混淆。站内这篇 Cloudflare 500/502/503 真相 可以帮助你先分清“Cloudflare 连不上源站”和“源站返回了错误”之间的区别。
Cloudflare Error 1000:DNS 指到了禁止 IP
cloudflare error 1000 通常是 DNS 记录指向了 Cloudflare 不允许代理的地址,例如 Cloudflare 自己的边缘节点 IP、127.0.0.1、10.x、192.168.x 等内网地址,或者配置形成了回环。它和 1016 都与 DNS 有关,但 1016 是“找不到源站”,1000 是“找到了不该指向的地址”。

排查步骤
- 检查 A/AAAA 记录,确保填写的是主机商给你的真实源站 IP,而不是 Cloudflare 代理后的 IP。
- 删除重复冲突的记录。同一个主机名不要同时保留多条来源不明的 A、AAAA、CNAME。
- 如果主机商要求使用 CNAME,就按文档填写 CNAME,不要把中间解析出来的 IP 复制回来。
- 检查根域名和 www 是否互相 CNAME,避免形成循环。
- 改完后等待 DNS 生效,并清理 Cloudflare 缓存再复测。
Cloudflare 403:先确认是谁拦截的
cloudflare 403 的关键不是立刻关闭所有安全功能,而是判断 403 来自 Cloudflare 还是源站。如果 Cloudflare Security Events 里能看到同一时间、同一 IP、同一路径的记录,通常是 WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 或托管规则误拦。如果 Security Events 没有记录,问题更可能来自源站:WordPress 安全插件、Nginx deny、Apache .htaccess、文件权限或主机 WAF。
排查步骤
- 进入 Cloudflare → Security → Events,按 Ray ID、IP、路径和时间筛选。
- 如果是 WAF 误拦 wp-admin、wp-json、支付回调、登录接口,不要全站关闭 WAF,而是为特定 URI、IP 或 User-Agent 建立 Skip 规则。
- 检查 IP Access Rules 是否误封了管理员 IP、支付网关 IP 或监控服务 IP。
- 如果 Cloudflare 没有拦截记录,去源站查 Nginx/Apache 日志,以及 Wordfence、iThemes Security 等插件日志。
- 修复后用退出登录、无痕窗口、手机 4G/5G 和不同地区节点复测,避免只有管理员环境正常。
如果 403 和 WordPress 安全插件有关,可以参考 Wordfence Security 插件安装配置指南,并检查是否对 wp-json、xmlrpc.php、上传目录设置了过度限制。
Cloudflare SSL handshake failed:重点看源站证书
很多人搜索 cloudflare ssl handshake failed,实际页面可能是 525 SSL handshake failed 或 526 Invalid SSL certificate。这类问题发生在 Cloudflare 与源站建立 HTTPS 连接时。常见原因包括源站没有安装证书、证书过期、证书域名不匹配、证书链不完整、服务器只支持过旧 TLS,或者 Cloudflare SSL 模式与源站配置不一致。
排查步骤
- Cloudflare SSL/TLS 模式建议使用 Full (strict),前提是源站证书有效、域名匹配、证书链完整。
- 检查证书是否同时覆盖 example.com 和 www.example.com,尤其是迁站或换主机后。
- 如果使用 Cloudflare Origin Certificate,确认服务器已绑定正确证书和私钥,而不是只在 Cloudflare 后台点了生成。
- 检查服务器 TLS 配置,至少支持 TLS 1.2,优先启用 TLS 1.3。
- 如果刚改过 DNS,确认 Cloudflare 回源到的是新服务器 IP,而不是旧服务器上已经过期的证书。
SSL 模式还可能引发循环跳转。遇到 ERR_TOO_MANY_REDIRECTS 时,可以看 Flexible SSL 模式的致命误区 歌で応える Cloudflare SSL設定でTOO_MANY_REDIRECTSが発生する場合の解決策.
Cloudflare Error 500:多数要回到 WordPress 和服务器日志
cloudflare error 500 是最容易误判的一类。很多站长看到 Cloudflare 页面就以为 CDN 出问题,但真正的 500 往往来自源站应用:WordPress 插件冲突、主题 PHP fatal error、PHP 版本不兼容、内存不足、数据库连接异常、.htaccess 写错、Nginx rewrite 错误、文件权限异常等。Cloudflare 只是把源站返回的 500 展示给访客。
排查步骤
- 临时灰云或 hosts 直连源站,如果绕过 Cloudflare 仍然 500,基本就是源站问题。
- 打开 WordPress debug log 或主机 PHP error_log,搜索 fatal error、memory exhausted、database、permission denied。
- 回滚最近更新的插件、主题和 PHP 版本,优先检查缓存、安全、页面构建器、支付、SMTP 插件。
- 检查 PHP memory_limit、max_execution_time、max_input_vars 是否满足主题和插件要求。
- 恢复 WordPress 默认伪静态规则,确认 .htaccess 或 Nginx rewrite 没有语法错误。
通用恢复顺序:从最小改动开始
Cloudflare 报错排查的原则是:一次只改一个变量,复测后再继续。不要同时改 DNS、SSL、防火墙和插件,否则很难知道到底是哪一步修好的。
- 先记录错误代码、Ray ID、URL、时间、地区和截图。
- 查 DNS:记录是否存在、是否重复、是否指向真实源站。
- 查源站连接:Web 服务、端口、安全组、防火墙、Cloudflare IP 白名单。
- 查 SSL:模式、证书有效期、证书链、TLS 协议和 SNI。
- 查安全规则:Cloudflare Security Events、WAF、Bot、Rate Limiting、源站安全插件。
- 查 WordPress:PHP 错误日志、插件冲突、主题错误、缓存和重定向规则。
- 恢复后再逐步开启缓存、WAF 和优化规则,不要把安全功能永久关闭。
概要
Cloudflare 常见错误代码并不需要靠猜。error 1016 先查 DNS 是否能解析源站;error code 521 先查源站是否拒绝 Cloudflare 连接;cloudflare error 1000 先查 DNS 是否指向了禁止地址;cloudflare 403 先分清 Cloudflare WAF 和源站权限;cloudflare ssl handshake failed 重点看源站证书、SSL 模式和 TLS;cloudflare error 500 则优先回到 WordPress、PHP 和服务器日志。按“DNS—连接—SSL—安全规则—程序日志”的顺序排查,通常比反复重启服务器、重装插件更快,也更安全。
延伸阅读
- Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程
- SSL证书握手失败:深入解决 Cloudflare 525 错误
- Cloudflare 500/502/503 真相:一文理清本质区别
- 常见 WordPress 故障修复
| お問い合わせ | |
|---|---|
| チュートリアルが読めない?無料でお答えします!個人サイト、中小企業サイトのための無料ヘルプ! |
カスタマーサービス WeChat
|
| ① 電話:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| 三 Eメール:[email protected] | |
| ④ 勤務時間: 月~金、9:30~18:30、祝日休み | |
この記事へのリンクhttps://www.361sale.com/ja/87793/この記事は著作権で保護されており、必ず帰属表示を付けて複製してください。


















3月11日 13:490
今はまだ間違いなくSEOを行っているが、ただ遊び方が変わっただけだ。 以前はコンテンツの山に依存し、キーワードの山は、トラフィックを持つことができ、今ではコンテンツの質+ブランドの信頼+ユーザーエクスペリエンスにもっと注意を払う。 SEOだけに頼ることに加えて、実際にはますます困難であり、多くの良い基本的にSEO +ソーシャルメディア+コンテンツマーケティング+一緒に行うには、プライベートドメインの変換。 SEOは依然として長期的な顧客獲得チャネルであるが、もはや唯一のチャネルとして捉えることはできない。ヒヒは仕事中
3月11日 10:540
ノーマルは、Googleに代わってページを参照してくださいにのみ含まれ、すぐにランキングにそのことを意味するものではありませんが、"含まれているが、ランク付けされていない "通常のため: キーワードの競争は、ページの重量が低い、コンテンツが十分に強力ではない、ページが比較的新しいです。 ロングテールキーワード、コンテンツの品質と内部チェーンを最適化し続け、通常は少し時間がかかり、ランキングは徐々に出てくるだろう!アメリア・フォスター 3月6日 16:200
スクリーンショットはありますか?魚でない息子も魚の喜びを知っている。 3月6日 09:230
最初に最適化プラグインを積み上げるのではなく、最初にボトルネックを特定する: クエリモニタを使って、遅いSQL、遅いフックを確認する。 すべてのプラグインを一時停止して比較し、それから1つずつオンにする。 オートロードが大きすぎないかチェックする(オプションテーブル)。 大きなテーブルクエリでデータベースのインデックスをチェックする。 サーバーのTTFBが高い場合は、まずホスト/データベースのパフォーマンスに取り組んでください。ヒヒは仕事中
3月3日 16:470
ウィンドジャマーさん、複雑なローカル環境をいじくる必要はありません。普通の人はこの手順に従って更新すれば、基本的にサイトがクラッシュすることはありません👇。 まず、サイト全体のバックアップ、ファイル+データベースの準備、これが肝心です。 サイトのアップデートをする場合、ワンクリックで全部行わず、一括で行い、まず重要でないプラグインを変更し、次にコアなプラグインを変更する。 更新後すぐにキャッシュをクリアし、フォアグラウンドに移動してトップページ、記事ページ、ボタン、フォーム、これらの重要な位置をチェックする。 バージョンのロールバックをサポートするプラグインをインストールしておくと、クラッシュした場合、一瞬で古いバージョンに戻すことができる。 まとめると:まずバックアップ、一括変更、変更後チェック、戻る方法を残す、非常に安定している ✅😎 これが役立つことを願っています!バグバング 3月2日 09:550
通常、決済がうまくいかなかったのではなく、コールバック(ウェブフック)が注文状況を書き戻さなかったのです。 トラブルシューティングの手順 WooCommerce → Status → Logs: ペイメントゲートウェイにウェブフックエラー/シグネチャーエラー/タイムアウトがあるか確認してください。 サイトがWAF(Cloudflare、Pagoda Firewall、セキュリティプラグイン)によってブロックされていないか確認する。 Cache checkout pages/interface paths "が有効になっているか確認する(チェックアウトページとコールバックインターフェースはキャッシュされるべきではない) サーバーのエラーログを見て、コールバックの実行を中断させるような500/致命的なエラーがないか確認する。 解決方法 wp-json、wc-api、ペイメントゲートウェイのコールバックURLを解放する。 チェックアウトページのキャッシュとJSマージ圧縮テストを一度無効にする。 Cloudflareを使用している場合: コールバックURLのno-challenge、no-blockルールを設定する。ウラ・ナラ・ジェンファン(18嬛嬛) 1月31日 09:360
1) 「正常な待機」なのか「異常な停滞」なのかを判断する。 まず3つのシグナルを見ることができる:ページ公開時間が7-14日以内か、このステータスのページは少数か、XMLサイトマップにページが登場しているか。 この3つが満たされていれば、通常のクロールと評価の段階である可能性が高く、すぐに行う必要はない。 2)どのような場合に「待つ」ことが無駄になるのか? 内部リンクがほとんどないページ(孤立したページ)、サイト内の既存ページと内容が酷似している、カノニカルポイントが他のURLになっている、同じトピックで似たような記事が短期間に公開されすぎている、などの場合は、時間が経過しても自動的には解決されません。 この場合、Googleはクロールはしているが「インデックスに登録する価値はない」と判断している。 3)手動で介入する最も効果的な方法(手間をかけない) 内部リンクの追加、関連する古い記事やコラムからページへのリンク、最初の画面の情報密度を高める。 最初の2-3段落はユーザーの質問に直接答える、詰め込みすぎを避ける、重複ページと判定されないようにcanonicalを自己参照として確認する、そしてGSCに再インデックスを依頼しに行く。 4) 逆効果になる「介入行動」とは? 頻繁に削除や再投稿を繰り返す、「インデックスリクエスト」を何度も連続でクリックする、インデックスされるためにキーワードを無理やり重ねる、URLやタイトルを恣意的に変更する、など。 これらの操作は、Googleにページの安定性を再評価させるが、インクルードが遅くなる。 5) 現実的な判断基準 記事:クロールされている、noindex/robotsの問題がない、少なくとも1-2個の関連する内部リンクがある、コンテンツが明らかに独立した問題を解決している、プラグインの問題ではなく時間の問題である。ポスト・ポーター 1月30日 10:000
新しい駅は完全に外部リンクを行うことはできませんが、最初のコンテンツと駅の構造は、より安定した良い仕事をする。コンテンツにのみ依存して、一般的にロングテールの単語のランキングの一部が含まれて得ることができますが、高い競争の量が遅くなります。それは、サイトが安定してインクルード、30〜50品質のコンテンツを待つことをお勧めします、キーワードはトップ20/30を入力するようになったし、外部リンクの少量は、優先順位のブランド語/裸チェーン/引用型は、番号を追いかけて出てこない。👍