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 排查教程 responder cantando Cloudflare Error 1016: DNS apuntando a una conexión con el origen cómo solucionarlo。如果你只遇到 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 插件安装配置指南así como 常见 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 配置同时引发循环跳转,可以参考 Error fatal en el modo SSL flexible: ERR_TOO_MANY_REDIRECTS responder cantando Solución para la configuración SSL de Cloudflare que aumenta 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,不要在问题未定位前把所有安全规则永久关闭。
resúmenes
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 真相:一文理清本质区别
- Fallo en el protocolo de enlace del certificado SSL: análisis detallado para resolver el error 525 de Cloudflare
- Funcionamiento y mantenimiento del servidor
| 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/87619/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. 👍