网站突然出现 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 模式同时引发循环跳转,可以继续看 Erreur fatale du mode SSL flexible : 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 缓存。
résumés
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 与服务器日志。按这个顺序排查,通常比反复切换设置更稳,也更不容易造成二次故障。
Lien vers cet article :https://www.361sale.com/fr/87712/L'article est protégé par le droit d'auteur et doit être reproduit avec mention.

















11 mars 13:490
Aujourd'hui, le référencement est toujours d'actualité, mais le jeu a changé. Auparavant, on s'appuyait sur des tas de contenus, des tas de mots-clés pour obtenir du trafic, et maintenant on accorde plus d'attention à la qualité du contenu + à la confiance dans la marque + à l'expérience de l'utilisateur. En plus de s'appuyer uniquement sur le SEO est en fait de plus en plus difficile, beaucoup de bonnes SEO + médias sociaux + marketing de contenu + conversion de domaine privé à faire ensemble. Le référencement reste un canal d'acquisition de clients à long terme, mais il ne peut plus être considéré comme le seul canal.Il travaille dur.
11 mars 10:540
Normal, inclus seulement au nom de Google pour voir la page, ne signifie pas qu'immédiatement au classement, "a été inclus mais n'a pas été classé" habituellement parce que : la concurrence des mots-clés, le poids de la page est faible, le contenu n'est pas assez fort, la page est relativement nouvelle. Continuez à optimiser les mots-clés à longue traîne, la qualité du contenu et la chaîne interne, il faut généralement un peu de temps pour que le classement s'améliore lentement !Amelia Foster 6 mars 16:200
Avez-vous une capture d'écran ?lit. même un fils qui n'est pas un poisson connaît la joie du poisson 6 mars 09:230
Ne commencez pas par utiliser les plugins d'optimisation, mais localisez d'abord les goulets d'étranglement : Utilisez Query Monitor pour voir les SQL lents, les crochets lents. Mettez tous les plugins en pause pour les comparer, puis activez-les un par un. Vérifier que l'autoload est trop grand (tableau des options). Vérifier les index de la base de données avec les requêtes de tables volumineuses. S'attaquer d'abord aux performances de l'hôte et de la base de données si le TTFB du serveur est élevé.Il travaille dur.
3 mars 16:470
Bonjour Windjammer, il n'y a vraiment pas besoin de s'embêter avec des environnements locaux compliqués, les gens ordinaires suivent ces étapes et la mise à jour ne fera pas planter le site 👇. Tout d'abord, sauvegarder l'ensemble du site, fichiers + base de données sont préparés, c'est la ligne de fond, hors du problème peut être une clé pour revenir en arrière. Si vous voulez mettre à jour votre site, ne le faites pas en un seul clic, mais faites-le par lots, changez d'abord les plugins sans importance, puis les principaux. Immédiatement après la mise à jour, videz le cache, passez au premier plan pour vérifier la page d'accueil, la page d'article, les boutons, les formulaires, ces positions clés. Il est préférable d'installer un plug-in qui prend en charge le retour à la version précédente ; en cas de panne, il est possible de revenir à l'ancienne version en une seconde. En résumé : sauvegarder d'abord, changer par lots, vérifier après avoir changé, laisser un moyen de revenir en arrière, très stable ✅😎 J'espère que cela vous aidera !bugbang 2 mars 09:550
En général, ce n'est pas le paiement qui n'a pas fonctionné, mais le rappel (webhook) qui n'a pas renvoyé l'état de la commande. Étapes de dépannage : WooCommerce → Statut → Logs : voir si la passerelle de paiement a une erreur de webhook / une erreur de signature / un dépassement de délai. Vérifiez si le site est bloqué par un WAF (Cloudflare, Pagoda Firewall, plugins de sécurité). Vérifiez si l'option "Cache checkout pages/interface paths" est activée (les pages de paiement et les interfaces de rappel ne doivent pas être mises en cache). Recherchez dans les journaux d'erreurs du serveur les erreurs 500/fatal qui interrompent l'exécution du callback. Solution : Libérer les URLs de rappel de wp-json, wc-api et de la passerelle de paiement (configurer selon la documentation de la passerelle). Désactiver le cache et le test de compression JS merge sur la page de paiement une fois. Si vous utilisez Cloudflare : définissez les règles "no-challenge" et "no-block" pour les URL de rappel.Ulla Nala Zhenhuan (18嬛嬛嬛) 31 janvier 09:360
1) Déterminer s'il s'agit d'une "attente normale" ou d'un "blocage anormal". Vous pouvez d'abord examiner trois signaux : si le délai de publication de la page est compris entre 7 et 14 jours, s'il n'y a qu'un petit nombre de pages avec ce statut et si la page est apparue dans le plan du site XML. Si ces trois éléments sont réunis, il s'agit très probablement d'une étape normale d'exploration et d'évaluation, et il n'est pas nécessaire d'intervenir immédiatement. 2) Dans quelles circonstances "attendre" est-il inutile ? Les cas suivants ne seront pas résolus automatiquement par le temps : la page n'a presque pas de liens internes (page isolée), le contenu est très similaire aux pages existantes sur le site, les points canoniques renvoient à d'autres URL, et trop d'articles similaires sont publiés sur le même sujet pendant une courte période. Dans ce cas, Google a été parcouru, mais a jugé que "cela ne vaut pas la peine d'entrer dans l'index". 3) La façon la plus efficace d'intervenir manuellement (sans chichis) La priorité est de faire ces 3 choses : ajouter des liens internes, créer un lien vers la page à partir d'anciens articles ou rubriques connexes, améliorer la densité de l'information sur le premier écran. Les 2-3 premiers paragraphes répondent directement à la question de l'utilisateur, évitent trop de remplissage, confirment que la page canonique est autoréférentielle pour éviter d'être jugée comme une page dupliquée, puis vont au SGC pour demander la réindexation. 4) Quelles sont les "actions d'intervention" contre-productives ? Déconseillées : supprimer et reposter fréquemment, cliquer plusieurs fois de suite sur "demander l'indexation", forcer l'empilement de mots-clés pour être indexé, changer arbitrairement d'URL ou de titre. Ces opérations permettront à Google de réévaluer la stabilité de la page, mais ralentiront l'inclusion. 5) Une norme de jugement pratique Si un article : a été crawlé, il n'y a pas de problème de noindex / robots, il y a au moins 1-2 liens internes connexes, le contenu résout manifestement un problème indépendant, il est inclus, ce n'est qu'une question de temps, ce n'est pas un problème de plug-in.Porteur de poste 30 janvier 10:000
La nouvelle station ne fait pas de liens externes peut être complètement, le premier contenu et la structure de la station pour faire un bon travail plus stable. En s'appuyant uniquement sur le contenu, il est généralement possible d'inclure une partie des mots-clés à longue traîne dans le classement, mais la quantité de concurrence élevée sera lente. Il est recommandé d'attendre l'inclusion stable du site, 30-50 contenu de qualité, les mots clés ont commencé à entrer dans le top 20/30, et puis une petite quantité de liens externes, les mots de marque prioritaires / chaîne nue / type de citation, ne viennent pas à chasser le nombre. 👍