网站突然出现 Cloudflare 报错时,很多站长第一反应是“Cloudflare 坏了”或“服务器挂了”。但从实际维护 WordPress、WooCommerce 和企业站的经验看,同一个 Cloudflare 错误页面,背后可能是 DNS 记录、源站防火墙、SSL 证书、WAF 规则、PHP 程序报错等不同问题。盲目切换 SSL 模式、清空缓存或重启服务器,反而容易把一个小问题扩大成全站故障。
本文把站长高频搜索的 error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed、cloudflare error 500 放在同一套排查流程里讲。你不需要一次性改完所有配置,只要按“先定位层级,再改一个变量,再复测”的方式操作,通常可以更快找到真正原因。

一、先做 3 个快速判断,避免越修越乱
Cloudflare 报错并不等于所有问题都在 Cloudflare。建议先记录错误代码、Ray ID、访问 URL、发生时间、访问地区,然后做三步判断。第一,页面是否带有 Cloudflare 标识和 Ray ID;第二,Cloudflare 后台 Security Events 是否有对应拦截记录;第三,绕过 Cloudflare 直连源站时是否仍然报错。
- 如果直连源站也打不开,优先查服务器、端口、程序和证书。
- 如果直连正常、橙云代理后报错,优先查 Cloudflare DNS、SSL、WAF 与回源连接。
- 如果只有个别地区或个别 IP 报错,优先查安全规则、速率限制、Bot 防护和主机商防火墙。
- 如果后台刚改过 DNS、SSL、缓存插件或安全插件,先回滚最近一次修改。
站内已有一篇偏总览的 Cloudflare 报错别乱改:1016、521、1000、403、SSL 握手与 500 排查指南,本文会更偏“按错误代码直接动手”。
二、Error 1016:Origin DNS error 怎么修?
error 1016 的意思是 Cloudflare 找不到源站 DNS。最常见的情况是 A 记录、AAAA 记录或 CNAME 写错了,或者 CNAME 指向的目标域名本身已经无法解析。它和源站是否安装 WordPress、是否开启缓存关系不大,核心在 DNS 链路。
排查步骤
- 进入 Cloudflare DNS,找到报错的主机名,例如 @、www、shop、api。
- 确认它至少有一条有效的 A、AAAA 或 CNAME 记录,并且目标不是拼错的域名。
- 如果是 CNAME,复制目标域名到 DNS 查询工具里单独查,确认它能解析出公网地址。
- 如果使用负载均衡或第三方 SaaS,检查 origin hostname 是否仍然有效。
- 保存后等待几分钟,再用无痕窗口或手机网络访问,不要只依赖本机缓存。
需要更细的 1016 案例,可以看 Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程.
三、Error code 521:源站拒绝了 Cloudflare
error code 521 页面经常写着 Web server is down,但真实原因不一定是服务器宕机。只要源站主动拒绝 Cloudflare 的连接,或者 80/443 端口没有正确监听,就可能出现 521。尤其是新服务器刚上线、换了主机商、防火墙规则较严格时,这个错误很常见。
排查步骤
- 在服务器面板确认 Nginx、Apache 或 LiteSpeed 正在运行。
- 检查 80 和 443 端口是否对公网开放,云服务器安全组也要一起看。
- 把 Cloudflare 官方 IP 段加入源站防火墙、主机 WAF、宝塔防火墙的允许列表。
- 查看 access log:如果完全没有 Cloudflare 请求,多半是防火墙或网络层拦截;如果有请求但异常中断,再查 Web 服务配置。
- 临时切灰云测试源站是否能直接访问,确认后再恢复橙云代理。
如果同时出现 502、503 或 522,可以参考 Cloudflare 500/502/503 真相,先区分源站超时、网关错误和应用异常。
四、Cloudflare error 1000:DNS 指向了不该指向的 IP
cloudflare error 1000 通常与 DNS 指向有关,典型原因是把记录指向了 Cloudflare 自己的 IP、内网 IP、保留 IP,或者让域名解析形成了回环。迁站、复制旧记录、照抄主机商教程时最容易发生。
- 检查 A/AAAA 记录,目标必须是你的真实源站公网 IP。
- 不要把 Cloudflare 代理后的 IP 当成源站 IP 填回 DNS。
- 不要填写 127.0.0.1、10.x、172.16-31.x、192.168.x 等内网地址。
- 检查 www 与根域名是否互相 CNAME,避免循环。
- 删除重复冲突记录,只保留当前主机商要求的解析方案。
五、Cloudflare 403:先确认是谁拦截的
cloudflare 403 最容易误判。它可能是 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 拦截,也可能是源站安全插件、Nginx deny、.htaccess、文件权限或目录保护返回的 403。判断方法很简单:去 Cloudflare Security Events 查同一时间是否有记录。
- 有拦截记录:查看命中的规则名称,针对后台、接口、支付回调等路径做精确 Skip 或 Allow,不要直接关闭全部 WAF。
- 没有拦截记录:去源站查访问日志、安全插件日志和文件权限。
- 只拦某些国家或 IP:检查国家封锁、IP 黑名单、速率限制和 Bot 规则。
- 只拦 wp-json 或后台:检查安全插件是否限制 REST API、登录路径或 XML-RPC。

六、cloudflare ssl handshake failed:重点查证书与 SSL 模式
用户搜索 cloudflare ssl handshake failed 时,常见对应错误是 525 或 526。简单说,Cloudflare 能连到源站,但 HTTPS 握手没有成功。常见原因包括源站证书过期、证书域名不匹配、证书链不完整、服务器只支持过旧 TLS、Cloudflare SSL 模式与源站配置不一致。
- 生产站建议使用 Full (strict),前提是源站证书有效;不要长期依赖 Flexible。
- 检查证书是否覆盖根域名和 www,是否过期,证书链是否完整。
- 如果使用 Cloudflare Origin Certificate,确认 Nginx/Apache 绑定了正确证书和私钥。
- 启用 TLS 1.2/1.3,避免服务器只支持旧协议或旧加密套件。
- 迁站后确认 Cloudflare 回源 IP 已更新,别让它连到旧服务器的旧证书。
如果 SSL 模式同时引发循环跳转,可以继续看 柔軟なSSLモードの致命的な誤り:ERR_TOO_MANY_REDIRECTS.
七、Cloudflare error 500:多半要回源站查 WordPress
cloudflare error 500 并不一定是 Cloudflare 平台故障。对 WordPress 站点来说,更常见的是插件冲突、主题函数报错、PHP 版本不兼容、内存不足、数据库异常、.htaccess 规则错误。Cloudflare 只是把源站返回的 500 展示给访客。
排查步骤
- 临时灰云或通过 hosts 直连源站,如果仍然 500,说明问题在源站。
- 查看 PHP error_log、WordPress debug.log、服务器 error log,优先搜索 fatal error、memory exhausted、database。
- 回想最近是否更新了插件、主题、PHP 版本或缓存规则,先回滚最近变更。
- 临时停用缓存、安全、页面构建器、支付和 SMTP 等高风险插件。
- 恢复默认伪静态规则,检查 .htaccess 或 Nginx rewrite 是否写错。
八、推荐的安全处理顺序
一次只改一个变量。改 DNS、SSL、防火墙、插件时都要记录时间,否则后面很难判断到底是哪一步修好的。
- 保存错误截图、Ray ID、URL、时间和访客地区。
- 查 Cloudflare Security Events 与 Analytics,确认是否有拦截或回源错误峰值。
- 查 DNS:1016 和 1000 优先处理解析记录。
- 查源站:521 优先处理 Web 服务、端口和防火墙。
- 查 SSL:525/526 或 handshake failed 优先处理证书与 TLS。
- 查程序:500 优先处理 WordPress、PHP、数据库和伪静态。
- 确认恢复后再开启缓存预热,并按需清理 Cloudflare 缓存。
概要
Cloudflare 常见错误代码并不是一套玄学。error 1016 查 DNS 是否能解析;error code 521 查源站是否拒绝 Cloudflare;cloudflare error 1000 查 DNS 是否指向禁止 IP;cloudflare 403 查 WAF 与源站权限;cloudflare ssl handshake failed 查证书、TLS 和 SSL 模式;cloudflare error 500 则回到 WordPress 与服务器日志。按这个顺序排查,通常比反复切换设置更稳,也更不容易造成二次故障。
| お問い合わせ | |
|---|---|
| チュートリアルが読めない?無料でお答えします!個人サイト、中小企業サイトのための無料ヘルプ! |
カスタマーサービス WeChat
|
| ① 電話:020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| 三 Eメール:[email protected] | |
| ④ 勤務時間: 月~金、9:30~18:30、祝日休み | |
この記事へのリンクhttps://www.361sale.com/ja/87712/この記事は著作権で保護されており、必ず帰属表示を付けて複製してください。

















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を入力するようになったし、外部リンクの少量は、優先順位のブランド語/裸チェーン/引用型は、番号を追いかけて出てこない。👍