网站挂在 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 模式还引发循环跳转,可以参考 Error fatal en el modo 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 缓存、缓存插件缓存,并用手机流量复测前台、后台、表单和支付页面。
resúmenes
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,先定位,再小步修改,才是对线上站点最安全的做法。
| 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/87750/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. 👍