网站挂在 Cloudflare 后,最怕的不是看到错误代码,而是不知道该从哪里下手。很多站长一遇到 error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed 或 cloudflare error 500,就开始反复切换 SSL 模式、清缓存、重启服务器。结果可能错误没修好,后台、支付回调、图片 CDN 还被一起影响。
更稳的做法是:先判断错误发生在哪一层,再只改一个变量。Cloudflare 夹在访客和源站之间,页面上显示的代码可能来自 DNS、Cloudflare 安全规则、回源连接、SSL 证书,也可能只是 WordPress 或 PHP 返回的 500。下面这份处理清单按“站长实际排障顺序”整理,适合 WordPress、WooCommerce、企业官网和博客站。

先做这 5 个记录,后面排查会快很多
不要急着改配置。建议先保存错误页面截图,并记录 URL、错误代码、Ray ID、发生时间、访问地区和访客 IP。如果只是一两个用户报错,这些信息尤其重要,因为 Cloudflare Security Events 需要靠时间和 Ray ID 对照。
- 打开 Cloudflare 后台的 Security Events,看同一时间是否有拦截记录。
- 查看 DNS 页面,确认报错域名是橙云代理还是灰云直连。
- 用手机流量或无痕窗口复测,排除本机 DNS 和浏览器缓存影响。
- 如果能操作服务器,用 hosts 或灰云临时直连源站,判断源站本身是否正常。
- 最近如果改过 DNS、SSL、缓存插件、安全插件或主机防火墙,优先回看那一次改动。
站内之前写过一篇总览版 Cloudflare 报错怎么快速定位?1016、521、1000、403、SSL 握手失败和 500 实战处理,这篇会更偏“看到代码后直接怎么修”。
Error 1016:Origin DNS error,先查解析链
error 1016 的核心意思是 Cloudflare 找不到源站 DNS。它通常不是 WordPress 插件问题,也不是 PHP 内存问题,而是解析记录缺失、写错、CNAME 目标失效,或者第三方服务已经取消绑定。
具体解决步骤
- 进入 Cloudflare DNS,找到报错的主机名,例如 @、www、shop、api。
- 确认该主机名存在 A、AAAA 或 CNAME 记录;如果没有记录,Cloudflare 就不知道该回源到哪里。
- 如果是 A/AAAA,确认 IP 是当前服务器的公网 IP,不要填旧主机、内网 IP 或 Cloudflare 的边缘 IP。
- 如果是 CNAME,把目标域名单独拿去查询,确认目标还能解析。很多 1016 是因为 CNAME 指向的 SaaS 域名已删除。
- 如果刚迁站,检查 www 和根域名是否都改完;很多站只改了根域名,www 仍指向旧服务。
如果你只想单独处理 1016,可以延伸阅读 Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程.
Error code 521:Cloudflare 连到了源站,但被拒绝
error code 521 常被误读成“服务器一定宕机”。实际更准确的说法是:Cloudflare 尝试连接源站,但源站拒绝了连接。常见原因包括 Web 服务没启动、80/443 端口没监听、云服务器安全组没放行、主机防火墙拦截了 Cloudflare IP。
具体解决步骤
- 在服务器面板确认 Nginx、Apache 或 LiteSpeed 正在运行。
- 确认 80 和 443 端口对公网开放;如果使用云服务器,还要检查安全组和主机商防火墙。
- 把 Cloudflare 官方 IP 段加入允许列表,尤其是宝塔防火墙、CSF、Imunify360、主机 WAF 这类工具。
- 查看 access log:如果没有任何 Cloudflare 请求,多半是网络层或防火墙拦截;如果有请求但断开,再查 Web 服务错误日志。
- 临时切灰云直连测试。如果灰云正常、橙云 521,重点就在 Cloudflare 到源站这段连接。
不要用“关闭 Cloudflare”当长期方案。灰云只能帮助定位,确认原因后仍建议恢复橙云代理,再做一次前台和后台登录测试。
Cloudflare error 1000:DNS 指向了禁止或错误的地址
cloudflare error 1000 多数和 DNS 配置有关。常见场景是把 DNS 记录指向了 Cloudflare 自己的 IP、保留地址、内网地址,或者根域名和 www 做成了循环 CNAME。复制旧教程、迁站时照抄解析记录,很容易踩这个坑。
- 检查所有 A/AAAA 记录,目标必须是你的真实源站公网 IP。
- 不要把 ping 出来的 Cloudflare 代理 IP 当成源站 IP 填回 DNS。
- 不要使用 127.0.0.1、10.x、172.16-31.x、192.168.x 这类本地或内网地址。
- 检查根域名和 www 是否互相 CNAME,避免解析回环。
- 删除重复冲突记录:同一个主机名不要同时保留旧主机和新主机的多套解析。
Cloudflare 403:先分清是 Cloudflare 拦,还是源站拦
cloudflare 403 是最容易排错方向跑偏的一个。它可能来自 Cloudflare WAF、Bot Fight Mode、IP Access Rules、Rate Limiting,也可能来自 WordPress 安全插件、Nginx deny、.htaccess、目录权限或防盗链规则。判断方法是先看 Cloudflare 后台有没有同一时间的 Security Events。
- 如果有拦截记录:打开事件详情,看命中的规则名称、路径和国家地区。对 wp-admin、wp-json、支付 webhook 等路径做精确 Skip,不要直接关掉全部 WAF。
- 如果没有拦截记录:去源站查 access log、error log、安全插件日志和文件权限。
- 如果只有后台 403:检查登录保护、REST API 限制、XML-RPC 限制、国家封锁和 IP 黑名单。
- 如果只有图片或静态文件 403:检查防盗链、对象存储权限、缓存插件 CDN 域名和 Nginx location 规则。

Cloudflare ssl handshake failed:重点看 525/526、证书和 SSL 模式
用户搜索 cloudflare ssl handshake failed,实际页面常见是 525 SSL handshake failed 或 526 Invalid SSL certificate。简单理解:Cloudflare 已经能连接到源站,但 HTTPS 握手失败。问题多半在源站证书、证书链、TLS 版本或 Cloudflare SSL 模式。
具体解决步骤
- 生产站优先使用 Full (strict),但前提是源站证书有效;不要长期使用 Flexible。
- 检查源站证书是否过期,是否覆盖根域名和 www,证书链是否完整。
- 如果使用 Cloudflare Origin Certificate,确认 Web 服务器绑定的是正确证书和私钥。
- 服务器至少启用 TLS 1.2,最好启用 TLS 1.3;过旧系统可能只支持旧协议导致握手失败。
- 迁站后确认 Cloudflare DNS 指向新服务器,不要让 Cloudflare 继续访问旧服务器上的旧证书。
如果 SSL 模式还引发循环跳转,可以参考 Erreur fatale du mode SSL flexible : ERR_TOO_MANY_REDIRECTS。SSL 问题不要靠反复切模式碰运气,证书和回源地址才是关键。
Cloudflare error 500:多数要回到 WordPress 和服务器日志
cloudflare error 500 并不等于 Cloudflare 平台出故障。对 WordPress 站点来说,更常见的是插件冲突、主题函数报错、PHP 版本不兼容、内存不足、数据库连接异常、伪静态规则错误。Cloudflare 只是把源站返回的 500 展示给访客。
- 先灰云或 hosts 直连源站。如果直连也 500,问题就在源站。
- 查看 PHP error_log、WordPress debug.log、Nginx/Apache error log,优先搜索 fatal error、memory exhausted、database error。
- 回想最近更新过的插件、主题、PHP 版本和缓存规则,先回滚最近一次变更。
- 临时停用缓存、安全、页面构建器、支付、SMTP 等高风险插件,再逐个恢复。
- 恢复默认 .htaccess 或 Nginx rewrite,排除伪静态写错。
- 如果是 WooCommerce 结账、回调或会员中心 500,优先查支付插件日志和服务器 PHP 错误日志。
如果同时遇到 502、503、522 这类回源问题,可以再看 Cloudflare 500/502/503 真相,先把应用错误、网关错误和连接超时分开。
一套更稳的处理顺序
排查 Cloudflare 报错时,最重要的原则是:一次只改一个变量,改完就复测,并记录时间。
- 先保存截图、Ray ID、URL、时间、地区和访客 IP。
- 查 Cloudflare Security Events:有记录就先看规则,没有记录就回源站。
- 查 DNS:1016 和 1000 优先处理解析记录、CNAME、源站 IP。
- 查连接:521 优先处理 Web 服务、端口、安全组和 Cloudflare IP 白名单。
- 查 SSL:handshake failed、525、526 优先处理证书、证书链、TLS 和 SSL 模式。
- 查程序:500 优先处理 WordPress 插件、主题、PHP、数据库和伪静态。
- 恢复后再清理 Cloudflare 缓存、缓存插件缓存,并用手机流量复测前台、后台、表单和支付页面。
résumés
Cloudflare 常见错误代码并不难,只要按层级排查就会清楚很多:error 1016 看 DNS 能不能找到源站;error code 521 看源站是否拒绝 Cloudflare;cloudflare error 1000 看 DNS 是否指向了禁止或错误 IP;cloudflare 403 先分清 Cloudflare 拦截还是源站权限;cloudflare ssl handshake failed 查证书、TLS 和 SSL 模式;cloudflare error 500 则回到 WordPress、PHP 和服务器日志。不要一上来就清缓存或乱切 SSL,先定位,再小步修改,才是对线上站点最安全的做法。
Lien vers cet article :https://www.361sale.com/fr/87750/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. 👍