Cloudflare 报错最麻烦的地方,不是页面上出现了一个数字,而是站长很容易把所有问题都归到“CDN 坏了”。实际上,error 1016、error code 521、cloudflare error 1000、cloudflare 403、cloudflare ssl handshake failed、cloudflare error 500 分别对应 DNS、回源连接、安全拦截、SSL 握手和源站程序等不同层面。方向判断错了,重启服务器、清缓存、停用插件都可能白做。
下面这份排障指南按真实维护 WordPress 站点的顺序整理:先定位故障发生在哪一段,再针对每个错误代码给出可执行步骤。你可以把它当成一张检查清单,遇到客户反馈打不开网站时,从上往下逐项确认,而不是一次性乱改 Cloudflare、主机面板和 WordPress 后台。

第一步:先判断错误来自哪一层
Cloudflare 在访问链路里处于中间层:访客浏览器先连到 Cloudflare,Cloudflare 再回源到你的服务器。排查时要把问题拆成三段:浏览器到 Cloudflare、Cloudflare 到源站、源站应用自身处理请求。只要分清这一点,很多错误会马上变得清晰。
- 错误页面上如果出现 Ray ID,说明请求已经到达 Cloudflare,可以拿 Ray ID 去 Security Events 或日志里反查。
- 如果提示 Origin DNS、DNS points to prohibited IP,多半还没进入 WordPress,优先查 DNS 记录。
- 如果提示 Web server is down、SSL handshake failed,重点查 Cloudflare 到源站这一段的连接、端口、防火墙和证书。
- 如果是 403 或 500,要同时判断是 Cloudflare 拦截,还是源站的 WordPress、安全插件、Nginx/Apache 返回。
实操建议:每次只改一个变量。比如先修 DNS,复测后再动 SSL;先查 WAF 事件,再停用安全插件。一次改太多,问题虽然可能消失,但下次复发时你依然不知道根因。
常见 Cloudflare 错误代码快速对照
| falso | 优先怀疑 | 第一检查点 |
|---|---|---|
| error 1016 | 源站 DNS 无法解析 | A/AAAA/CNAME、Origin Hostname、负载均衡池 |
| error code 521 | 源站拒绝 Cloudflare 连接 | Web 服务状态、80/443 端口、防火墙、Cloudflare IP 白名单 |
| cloudflare error 1000 | DNS 指向禁止地址或回环 | 是否指向 Cloudflare IP、内网 IP、127.0.0.1 或 CNAME 循环 |
| cloudflare 403 | Cloudflare WAF 或源站权限拦截 | Security Events、IP Access Rules、WordPress 安全插件、服务器 deny 规则 |
| cloudflare ssl handshake failed | Cloudflare 与源站 TLS 握手失败 | SSL 模式、源站证书、证书链、SNI、TLS 版本 |
| cloudflare error 500 | 源站程序或服务器返回 500 | PHP error_log、插件主题冲突、数据库、.htaccess/Nginx rewrite |
error 1016:Cloudflare 找不到有效源站
error 1016 的常见文案是 Origin DNS error。它的核心含义是:Cloudflare 想回源,但找不到可解析、可用的源站地址。这个问题通常不在 WordPress 后台,也不是 Elementor、WooCommerce、缓存插件造成的,而是 DNS 配置层面出了错。
具体处理步骤
- 进入 Cloudflare DNS 页面,找到出错的主机名,例如根域名 @、www、shop、blog 或 api。
- 根域名一般应使用 A/AAAA 记录指向真实源站 IP;www 可按主机商要求 CNAME 到根域名或指定主机名。
- 如果你填写的是 CNAME,复制 CNAME 目标,用 dig、nslookup 或在线 DNS Checker 检查它是否能在公网解析。
- 检查是否把 CNAME 指向了拼写错误的域名、已删除的临时域名、只在主机商内部可见的地址。
- 使用 Cloudflare Load Balancing 时,逐个检查 Origin Hostname 和健康检查路径,避免某个 origin 池失效导致间歇性 1016。
如果你只遇到 1016,可以继续看站内这篇 Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程,里面对 A 记录、CNAME 和 origin hostname 的区别讲得更细。
error code 521:源站没有接收 Cloudflare 请求
error code 521 经常让人误以为服务器完全宕机。实际上,服务器可能还在运行,只是 Cloudflare 连接源站的 80 或 443 端口时被拒绝了。常见原因包括 Web 服务停止、云服务器安全组没放行、主机防火墙拦截、Fail2ban/CSF/宝塔把 Cloudflare 节点误判为攻击流量。

具体处理步骤
- 在 Cloudflare DNS 中临时把出错记录从橙云改成灰云,或在本机 hosts 指向源站 IP,确认源站直连是否能打开。测试后记得恢复代理。
- 在服务器执行 systemctl status nginx、systemctl status apache2、systemctl status lsws 等命令,确认 Web 服务正在运行。
- 检查云服务器安全组、主机面板防火墙、iptables/ufw,确保 80 和 443 对公网开放。
- 把 Cloudflare 官方 IP 段加入允许列表,尤其是站点安装了主机 WAF、Fail2ban、CSF、宝塔防火墙时。
- 查看 access log。如果日志里完全没有 Cloudflare 请求,多半是网络或防火墙层拦截;如果有请求但返回异常,再查站点虚拟主机配置。
521 与 502、503、504 容易混淆。建议配合阅读 Cloudflare 500/502/503 真相,先确认是“连不上源站”,还是“源站已经返回错误”。
cloudflare error 1000:DNS 指到了不该指向的地址
cloudflare error 1000 通常说明 DNS 记录指向了 Cloudflare 禁止代理的地址,例如 Cloudflare 自己的边缘节点 IP、127.0.0.1、10.x、192.168.x、172.16.x-172.31.x 这类内网地址,或者根域名和 www 之间形成了回环。它和 1016 都属于 DNS 问题,但 1016 是“找不到”,1000 是“找到了不允许的目标”。

具体处理步骤
- 检查 A/AAAA 记录,确认填写的是主机商给你的真实源站 IP,而不是打开代理后解析出来的 Cloudflare IP。
- 删除同一主机名下来源不明的重复 A、AAAA、CNAME 记录,避免解析混乱。
- 如果主机商要求 CNAME 接入,就按文档填写 CNAME,不要把中间解析出的 IP 再复制回 Cloudflare。
- 检查 www 是否 CNAME 到根域名,而根域名又通过某种方式 CNAME 回 www,避免循环。
- 修改后等待 DNS 传播,并用无痕窗口、手机网络和外部 DNS 工具复测。
cloudflare 403:不要急着关闭全部安全规则
cloudflare 403 的排查重点是“谁返回了 403”。如果 Cloudflare Security Events 里能看到同一时间、同一 IP、同一路径的记录,通常是 WAF、Bot Fight Mode、IP Access Rules、Rate Limiting 或托管规则触发。如果 Cloudflare 没有任何事件,403 很可能来自源站,例如 WordPress 安全插件、Nginx deny、Apache .htaccess、文件权限或主机商 WAF。
具体处理步骤
- 复制错误页的 Ray ID,进入 Cloudflare → Security → Events,按 Ray ID、IP、路径和时间筛选。
- 如果是 WAF 误拦 wp-admin、wp-json、支付回调、会员登录接口,不要全站关闭 WAF,而是针对具体 URI、IP 或 User-Agent 建立 Skip 规则。
- 检查 IP Access Rules、Country Blocking、Bot 相关设置,确认没有误封管理员 IP、支付网关 IP、监控服务或搜索引擎。
- 如果 Cloudflare 没有拦截记录,去源站查 Nginx/Apache 日志,以及 Wordfence、iThemes Security、All In One WP Security 等插件日志。
- 修复后用退出登录状态、无痕窗口、手机 4G/5G 复测,避免只在管理员浏览器里正常。
如果你的网站使用 Wordfence,可以参考 Wordfence Security 插件安装配置指南,重点检查登录保护、REST API、xmlrpc.php 和上传目录访问规则是否过严。
cloudflare ssl handshake failed:回到源站证书检查
搜索 cloudflare ssl handshake failed 时,实际遇到的页面可能是 525 SSL handshake failed,也可能是 526 Invalid SSL certificate。这类问题发生在 Cloudflare 与源站建立 HTTPS 连接时,常见原因是源站没有有效证书、证书过期、证书域名不匹配、证书链不完整、服务器 TLS 配置过旧,或 Cloudflare SSL/TLS 模式与源站现状不匹配。
具体处理步骤
- Cloudflare SSL/TLS 模式优先使用 Full (strict),前提是源站证书有效且域名匹配。
- 检查证书是否覆盖 example.com 和 www.example.com,迁站或更换主机后尤其容易漏掉其中一个域名。
- 如果使用 Cloudflare Origin Certificate,确认服务器上已经正确绑定证书和私钥,而不是只在 Cloudflare 后台生成了证书。
- 检查服务器是否支持 TLS 1.2 或 TLS 1.3,过旧的 TLS/加密套件可能导致握手失败。
- 如果刚改过 DNS,确认 Cloudflare 回源到的是新服务器 IP,而不是旧服务器上过期或不匹配的证书。
SSL 设置还可能引发循环跳转。遇到 ERR_TOO_MANY_REDIRECTS 时,可以参考 Flexible SSL 模式的致命误区 responder cantando Solución para la configuración SSL de Cloudflare que aumenta TOO_MANY_REDIRECTS.
cloudflare error 500:多数根因在源站应用
cloudflare error 500 很容易被误认为 CDN 平台异常,但在 WordPress 站点里,真正根因多数来自源站:插件更新后 PHP fatal error、主题函数报错、PHP 版本不兼容、内存不足、数据库异常、.htaccess 规则损坏、Nginx rewrite 写错、文件权限不正确等。Cloudflare 只是把源站返回的 500 展示给访客。
具体处理步骤
- 临时灰云或 hosts 直连源站。如果绕过 Cloudflare 仍然 500,基本可判断为源站问题。
- 查看 PHP error_log、WordPress debug.log 和主机错误日志,搜索 fatal error、memory exhausted、database、permission denied。
- 回滚最近更新的插件、主题和 PHP 版本,优先检查缓存、安全、页面构建器、支付、SMTP、SEO 插件。
- 检查 PHP memory_limit、max_execution_time、max_input_vars 是否满足当前主题和插件要求。
- 恢复 WordPress 默认伪静态规则,确认 .htaccess 或 Nginx rewrite 没有语法错误。
一套更稳的恢复顺序
- 记录错误代码、Ray ID、访问 URL、发生时间、访客地区和截图。
- 先查 DNS:记录是否存在、是否重复、是否指向真实源站。
- 再查回源连接:Web 服务、80/443 端口、安全组、防火墙、Cloudflare IP 白名单。
- 然后查 SSL:模式、证书有效期、证书链、TLS 版本、SNI 和回源 IP。
- 继续查安全规则:Cloudflare Security Events、WAF、Bot、Rate Limiting、源站安全插件。
- 最后查 WordPress:PHP 错误日志、插件主题冲突、缓存、重定向和伪静态。
- 确认恢复后,再逐步开启缓存、WAF、Bot 规则和性能优化,不要为了临时恢复把安全功能永久关闭。
resúmenes
处理 Cloudflare 常见错误代码,关键不是背代码,而是按链路定位。error 1016 先查 DNS 是否能解析到有效源站;error code 521 先查源站是否接收 Cloudflare 连接;cloudflare error 1000 先查 DNS 是否指向禁止地址或形成回环;cloudflare 403 要分清 Cloudflare WAF 和源站权限;cloudflare ssl handshake failed 重点看 SSL 模式与源站证书;cloudflare error 500 则优先回到 WordPress、PHP 和服务器日志。按这个顺序排查,通常比反复清缓存、重启服务器、停用全部插件更快,也更不容易把小问题改成大问题。
延伸阅读
- Cloudflare Error 1016 怎么解决?DNS Origin Error 排查教程
- SSL证书握手失败:深入解决 Cloudflare 525 错误
- Cloudflare 500/502/503 真相:一文理清本质区别
- 常见 WordPress 故障修复
延伸阅读:如果你正在把内容流程接入 AI 自动化,也可以参考 OpenClaw 官方文档,把发布、验证和告警拆成可追踪步骤。
| Contacte con nosotros | |
|---|---|
| ¿No puede leer el tutorial? Póngase en contacto con nosotros para obtener una respuesta gratuita. Ayuda gratuita para sitios personales y de pequeñas empresas |
Servicio de atención al cliente WeChat
|
| ① Tel: 020-2206-9892 | |
| ② QQ咨询:1025174874 | |
| (iii) Correo electrónico: [email protected] | |
| ④ Horario de trabajo: de lunes a viernes, de 9:30 a 18:30, días festivos libres | |
Enlace a este artículo:https://www.361sale.com/es/87892/El artículo está protegido por derechos de autor y debe ser reproducido con atribución.

















11 de marzo 13:490
Ahora definitivamente todavía hacer SEO, sólo jugar cambiado. Anteriormente se basan en un montón de contenido, un montón de palabras clave puede tener tráfico, y ahora prestar más atención a la calidad del contenido + confianza de marca + experiencia de usuario. Además de confiar únicamente en SEO es en realidad cada vez más difícil, un montón de buena básicamente SEO + social media + marketing de contenidos + conversión de dominio privado para hacer juntos. SEO sigue siendo un canal de adquisición de clientes a largo plazo, pero ya no puede ser tomado como el único canal.Está trabajando duro.
11 de marzo 10:540
Normal, incluido sólo en nombre de Google para ver la página, no significa que de inmediato a la clasificación, "se ha incluido, pero no clasificado" por lo general debido a: La competencia de palabras clave, el peso de la página es baja, el contenido no es lo suficientemente fuerte, la página es relativamente nueva. ¡Continuar para optimizar las palabras clave de cola larga, la calidad del contenido y la cadena interna, por lo general toma un poco de tiempo, el ranking poco a poco va a salir!Amelia Foster 6 de marzo 16:200
¿Tiene una captura de pantalla?lit. incluso un hijo que no es un pez conoce la alegría de los peces 6 de marzo 09:230
No acumule primero los plugins de optimización, localice primero los cuellos de botella: Utiliza Query Monitor para ver el SQL lento y los ganchos lentos. Ponga en pausa todos los plugins para compararlos y, a continuación, actívelos uno a uno. Compruebe si la carga automática es demasiado grande (tabla de opciones). Compruebe los índices de la base de datos con consultas de tablas grandes. Si el TTFB del servidor es alto, solucione primero el rendimiento del host/base de datos.Está trabajando duro.
3 de marzo 16:470
Hola Windjammer, realmente no hace falta complicarse con entornos locales, la gente normal sigue estos pasos y la actualización básicamente no colapsará el sitio 👇 En primer lugar, copia de seguridad de todo el sitio, archivos + base de datos se preparan, esta es la línea de fondo, fuera del problema puede ser una clave para volver. Si desea actualizar su sitio, no lo haga todo en un solo clic, pero hacerlo en lotes, primero cambiar los plug-ins sin importancia, y luego cambiar el núcleo. Inmediatamente después de la actualización, borre la caché, vaya al primer plano para comprobar la página de inicio, la página de artículos, los botones, los formularios, estas posiciones clave. Lo mejor es instalar un plug-in que soporte la reversión de versiones, en caso de caída, volver a la versión anterior en un segundo. En resumen: copia de seguridad en primer lugar, el cambio en lotes, comprobar después de cambiar, dejar un camino de regreso, muy estable ✅😎 ¡Espero que esto ayude!bugbang 2 de marzo 09:550
Normalmente no es que el pago no haya funcionado, sino que el callback (webhook) no ha devuelto el estado del pedido. Pasos para solucionar el problema: WooCommerce → Estado → Registros: comprueba si la pasarela de pago tiene error de webhook / error de firma / timeout. Comprobar si el sitio está bloqueado por WAF (Cloudflare, Pagoda Firewall, plugins de seguridad). Comprueba si "Cachear páginas de pago / rutas de interfaz" está habilitado (las páginas de pago y las interfaces de devolución de llamada no deben almacenarse en caché) Busque en los registros de errores del servidor errores 500/fatal que interrumpan la ejecución de la devolución de llamada. Solución: Libere las URL de devolución de llamada de wp-json, wc-api, pasarela de pago (configure según la documentación de la pasarela). Desactivar la caché y la prueba de compresión JS merge en la página de pago una vez Si utiliza Cloudflare: establezca reglas de no desafío y no bloqueo para las URL de devolución de llamada.Ulla Nala Zhenhuan (18 años) 31 de enero 09:360
1) Determine si se trata de una "Espera normal" o de un "Atasco anormal". Puede fijarse primero en 3 señales: si el tiempo de liberación de la página es de entre 7 y 14 días, si sólo hay un pequeño número de páginas con este estado y si la página ha aparecido en el sitemap XML. Si se cumplen las tres condiciones, lo más probable es que se trate de una etapa normal de rastreo y evaluación, y no hay necesidad de hacerlo inmediatamente. 2) ¿En qué circunstancias es inútil "esperar"? Los siguientes casos no se resolverán automáticamente con el tiempo: la página casi no tiene enlaces internos (página aislada), el contenido es muy similar al de las páginas existentes en el sitio, los puntos canónicos apuntan a otras URL y se publican demasiados artículos similares sobre el mismo tema durante un breve periodo de tiempo. En este caso, Google lo ha rastreado, pero ha juzgado que "no merece la pena entrar en el índice". 3) La forma más eficaz de intervenir manualmente (sin complicaciones) Prioridad a hacer estas 3 cosas: añadir enlaces internos, enlazar a la página desde artículos o columnas antiguos relacionados, mejorar la densidad de la información en la primera pantalla. Los 2-3 primeros párrafos responden directamente a la pregunta del usuario, evitar demasiado relleno, confirmar canonical como autorreferencial para evitar ser juzgado como página duplicada, y luego ir a GSC para solicitar la reindexación. 4) ¿Qué "acciones de intervención" son contraproducentes? No se recomiendan: borrar y volver a publicar con frecuencia, hacer clic en "solicitar la indexación" varias veces seguidas, forzar el apilamiento de palabras clave para la indexación, cambiar arbitrariamente las URL o los títulos. Estas operaciones permitirán a Google volver a evaluar la estabilidad de la página, pero ralentizarán la inclusión. 5) Una norma de juicio práctica Si un artículo: ha sido rastreado, no hay ningún problema de noindex / robots, hay al menos 1-2 enlaces internos relacionados, el contenido obviamente resuelve un problema independiente, se incluye, sólo una cuestión de tiempo, no es un problema de inclusión.Post Porter 30 de enero 10:000
La nueva estación no hace enlaces externos pueden ser completamente, el primer contenido y la estructura de la estación para hacer un buen trabajo más estable. Confiar sólo en el contenido por lo general puede ser incluido y parte de la clasificación de palabras de cola larga, pero la cantidad de alta competencia será lento. Se recomienda esperar a que el sitio de inclusión estable, 30-50 contenido de calidad, palabras clave comenzó a entrar en la parte superior 20/30, y luego una pequeña cantidad de enlaces externos, palabras de marca prioridad / cadena desnuda / tipo de citación, no vienen a perseguir el número. 👍