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 报错到底卡在哪一层?
不要一看到 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 排查教程 répondre en chantant Erreur Cloudflare 1016 : DNS pointant vers une connexion avec la source comment la corriger。如果你只遇到 1016,可以优先看这两篇更细的 DNS 案例。
Error code 521:源站拒绝 Cloudflare 连接
Error code 521 页面常写着 web server is down,但它不一定代表主机真的宕机。很多时候是源站服务器在线,却拒绝了 Cloudflare 的连接请求。原因可能是 Web 服务没启动、80/443 端口没监听、防火墙拦截 Cloudflare IP、主机商安全策略把 Cloudflare 当成异常流量,或者服务器连接数被打满。

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

具体解决步骤
- 检查 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 插件安装配置指南ainsi que 常见 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 配置同时引发循环跳转,可以参考 Erreur fatale du mode SSL flexible : ERR_TOO_MANY_REDIRECTS répondre en chantant Solution pour les paramètres SSL de Cloudflare qui augmentent 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,不要在问题未定位前把所有安全规则永久关闭。
résumés
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 模式更快、更安全。
延伸阅读
- Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程
- Cloudflare 500/502/503 真相:一文理清本质区别
- Échec de la négociation du certificat SSL : analyse approfondie de la résolution de l'erreur 525 de Cloudflare
- Fonctionnement et maintenance du serveur
Lien vers cet article :https://www.361sale.com/fr/87619/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. 👍