网站突然出现 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 模式同时引发循环跳转,可以继续看 Error fatal en el modo 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 缓存。
resúmenes
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 与服务器日志。按这个顺序排查,通常比反复切换设置更稳,也更不容易造成二次故障。
| 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/87712/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. 👍