Error 500 en Cloudflare Pages: cómo resolverlo
Un desarrollador que agregó CTAs de afiliados a sus sitios SEO se encontró con que Cloudflare Pages retornaba HTTP 500 en 80 páginas de detalle, aunque el build mostraba “deploy/success” y la homepage funcionaba perfecto. La causa: una URL de referral de DigitalOcean (m.do.co) en el contenido renderizado activó algún filtro o límite interno de la plataforma. Solucionar el error 500 en Cloudflare Pages requirió bisección de commits para aislar el cambio exacto.
En 30 segundos
- El error 500 apareció en 78 páginas de detalle después de agregar CTAs con URLs de referral; la homepage no se vio afectada.
- El deploy mostraba éxito y los builds locales generaban HTML válido de 23 KB; el problema ocurría al servir el contenido en el edge.
- El cuerpo de la respuesta HTTP venía vacío, lo que descarta un error de aplicación genérico y apunta a un problema de entrega en el edge de Cloudflare.
- La bisección de commits identificó que la URL
m.do.coen el HTML renderizado era la causa raíz. - La solución pasó por revertir el deploy anterior y ajustar cómo se construían las URLs de referral antes de volver a publicar.
Cloudflare es un servicio de CDN y plataforma de ciberseguridad fundada por Matthew Prince, Michelle Zatlyn y Lee Holloway en 2009, que proporciona aceleración web, protección DDoS, gestión DNS y servicios como Cloudflare Pages. Optimiza la distribución de contenido y protege contra amenazas de seguridad.
¿Qué causó el error HTTP 500 en Cloudflare Pages?
Cloudflare Pages es la plataforma de hosting estático de Cloudflare que permite publicar sitios directamente desde un repositorio con CDN global y funciones edge. En este caso, según el reporte publicado el 7 de mayo de 2026, un desarrollador estaba agregando bloques de CTAs de afiliados con control por variable de entorno a tres sitios de directorios SEO. El código en sí eran 60 líneas de TypeScript. Nada del otro mundo.
La lógica era: si la env var está vacía, la sección no se renderiza; si tiene valor, muestra un anchor por proveedor. Uno de esos proveedores era DigitalOcean, con URL de referral corta: m.do.co.
Después del deploy, 78 páginas de detalle con URLs tipo /alternatives/1password/ o /alternatives/airtable/ devolvían 500 con cuerpo vacío. La homepage andaba. Un proyecto hermano con el mismo patrón de componentes también andaba. Todo indicaba que el problema era el contenido específico de esas páginas, no la arquitectura.
¿Qué tenían en común esas páginas? Exacto: todas renderizaban el bloque de afiliados con la URL m.do.co.
Diferencia entre error 500 en build vs en runtime/delivery
Acá está el punto que más confunde a los desarrolladores que se topan con este tipo de fallo. Para más detalles técnicos, mirá cómo configurar correctamente sitios multiidioma.
El build logueó “deploy/success”. Los 321 archivos subieron correctamente. Los HTMLs locales eran válidos y pesaban 23 KB cada uno. Todo eso era real. El problema no estaba en el build: estaba en la capa de entrega, cuando el edge de Cloudflare procesaba el archivo antes de enviarlo al cliente.
Esto significa que build success ≠ content delivery success. Cloudflare puede aceptar un deploy, procesar todos los archivos y sin embargo fallar al servir algunos de ellos si algo en el contenido activa un filtro, regla o límite en el edge. El cuerpo vacío en la respuesta 500 es la pista más clara: si el error fuera de la aplicación, habría al menos algún mensaje de error; el cuerpo vacío apunta a que Cloudflare mismo cortó la respuesta antes de entregarla.
Debugging: cómo identificar la causa raíz con bisección
El método que usó el desarrollador para aislar el problema fue bisección de commits, que es básicamente lo mismo que git bisect pero aplicado a deploys: revertís a la mitad del historial de cambios y probás si el error sigue. Dependiendo del resultado, avanzás o retrocedés hasta llegar al commit exacto que rompe todo.
Para aplicar esto en Cloudflare Pages, los pasos concretos son:
- Identificar el último deploy conocido como bueno en el dashboard de Cloudflare (Deployments → buscar el commit anterior al problema).
- Revertir a ese deploy con “Rollback to this deployment”.
- Confirmar que el error desaparece.
- Hacer deploys incrementales de los cambios, de a uno, hasta que el error vuelva a aparecer.
- Ese último cambio que rompe todo es tu causa raíz.
Eso sí: durante el debugging, revisá siempre el cuerpo de la respuesta HTTP con curl -v URL 2>&1 | grep -A5 "< HTTP" o con las DevTools del navegador en la pestaña Network. Un 500 con body vacío es un síntoma diferente a un 500 con stack trace o mensaje de error.
Errores comunes con variables de entorno en Cloudflare Pages
Las variables de entorno son una fuente frecuente de errores silenciosos en Cloudflare Pages, especialmente cuando contienen URLs o tokens. Relacionado: alternativas de hosting confiables.
En este caso el problema fue que la URL m.do.co terminó siendo parte del HTML renderizado, y algo en el procesamiento edge de Cloudflare no le gustó eso (si es un filtro de WAF, una regla interna o un límite de contenido, no está documentado públicamente). Pero hay otros escenarios típicos:
- Env var vacía en build pero requerida en runtime: el build pasa, pero en producción el código intenta usar un valor que es
undefinedonull. - Env var configurada en local pero no en el dashboard de Cloudflare: clásico. Funcionás en local, fallás en producción.
- URLs en env vars que Cloudflare interpreta como contenido malicioso: este caso específico. URLs de redirect o acortadores pueden activar reglas de seguridad.
- Diferencias entre variables de Preview y Production: Cloudflare Pages tiene entornos separados; una variable que pusiste en Preview puede no estar en Production.
La regla práctica: si una env var contiene una URL, probá qué pasa cuando esa URL aparece en el HTML renderizado y Cloudflare la procesa. No alcanza con probar en local.
Herramientas nativas de debugging en Cloudflare Pages
El dashboard de Cloudflare tiene tres lugares donde buscar cuando algo se rompe:
- Deployments: muestra el historial de deploys con status. Te permite ver qué archivos se subieron y hacer rollback a cualquier versión anterior.
- Functions (si usás Workers): tiene logs en tiempo real y errores de ejecución.
- Analytics: muestra status codes de respuesta por path. Si ves 500 concentrados en URLs con un patrón, el problema está en el contenido de esas páginas.
Lo que no te da Cloudflare Pages de forma nativa es un log de errores de edge granular por request. Para eso necesitás Cloudflare Workers Logs (si tenés el plan correspondiente) o configurar un endpoint de error personalizado.
La documentación oficial de debugging en Cloudflare Pages recomienda revisar los logs de build primero, pero en este caso el build no era el problema. El paso que más ayuda cuando el build es exitoso y el error ocurre en entrega es comparar la respuesta entre el ambiente local (wrangler pages dev) y producción.
Soluciones paso a paso para recuperarse de un error 500
Ponele que tu sitio está devolviendo 500 ahora mismo. El orden de acciones:
- Paso 1 — Rollback inmediato: En Cloudflare Pages → Deployments → encontrá el último deploy bueno → “Retry deployment” o usá el rollback. Esto recupera el sitio mientras investigás.
- Paso 2 — Aislá el cambio: Revisá el diff entre el deploy bueno y el que rompe. Si son muchos cambios, aplicá bisección.
- Paso 3 — Revisá las env vars: Comparando Settings → Environment Variables entre Preview y Production. Verificá que todas las variables necesarias estén configuradas en el entorno correcto.
- Paso 4 — Probá con Wrangler local:
wrangler pages dev ./distcon las mismas env vars que producción. Si el error no aparece localmente pero sí en prod, el problema está en el edge. - Paso 5 — Deploy incremental: Reintroducí los cambios de a uno, haciendo deploy después de cada uno, hasta que el error vuelva a aparecer.
¿El 500 es de Cloudflare o del servidor de origen?
Cloudflare Pages es un hosting estático: no hay servidor de origen propio. Todos los archivos se sirven desde el edge. Entonces cualquier 500 que veas en un sitio de Pages puro es generado por Cloudflare mismo.
La situación es diferente si usás Pages con Workers o si tenés configurado un proxy hacia un origen externo. En esos casos, según la documentación oficial de errores 5xx de Cloudflare, el error 500 puede venir del origen y Cloudflare lo retransmite tal cual.
| Escenario | Origen del 500 | Cómo identificarlo |
|---|---|---|
| Pages estático puro | Edge de Cloudflare | Cuerpo de respuesta vacío o mensaje de CF |
| Pages + Workers | Puede ser el Worker | Logs en Workers → Functions |
| Pages como proxy a origen | Servidor de origen | El body tiene el error del servidor de origen |
| Regla de WAF o firewall | Cloudflare (regla) | Header CF-RAY presente, body vacío |
El header CF-RAY en la respuesta siempre identifica el request en los sistemas de Cloudflare. Si tenés soporte, ese ID es lo primero que te van a pedir. Te puede servir nuestra cobertura de herramientas alternativas para construir.
Qué está confirmado y qué no en este caso
- Confirmado: El error 500 desapareció al revertir el deploy que introdujo las URLs
m.do.co. - Confirmado: El build fue exitoso; los 321 archivos se subieron sin errores.
- Confirmado: El problema afectaba específicamente las páginas que renderizaban el bloque con la URL de referral, no el sitio completo.
- No confirmado: El mecanismo exacto por el que Cloudflare rechaza o falla al servir páginas con esa URL específica. No hay documentación pública de este comportamiento.
- No confirmado: Si el problema es reproducible con cualquier URL acortada o es específico de
m.do.co.
Errores comunes al diagnosticar un 500 en Cloudflare Pages
Error 1: Asumir que build success = sitio funcionando. El log de deploy exitoso no garantiza que el edge sirva el contenido correctamente. Siempre validá las páginas afectadas haciendo un request real después de cada deploy.
Error 2: Buscar el problema en el build cuando ocurre en delivery. Si el HTML local es válido pero el 500 ocurre en producción, dejá de mirar los logs de build y concentrarte en qué hace Cloudflare con ese HTML al servirlo.
Error 3: No comparar con un proyecto hermano. El desarrollador de este caso tenía un proyecto con el mismo patrón de componentes que funcionaba. Esa comparación fue clave para descartar un problema de arquitectura. Si tenés otro sitio similar en Pages, compará.
Error 4: Hacer rollback sin aislar la causa. Revertir el deploy recupera el sitio, pero si no sabés exactamente qué lo rompió, lo vas a volver a romper. El rollback es el paso 1, no el paso final.
Error 5: Ignorar el cuerpo vacío de la respuesta. Un 500 con body vacío habla de un problema en la capa de infraestructura, no de la aplicación. Si ves esto, no busques un bug en tu código de aplicación: buscá qué está haciendo Cloudflare con tu contenido. Lo explicamos a fondo en protección y seguridad adicional.
Preguntas Frecuentes
¿Cómo soluciono el error HTTP 500 en mi sitio de Cloudflare Pages?
El primer paso es hacer rollback al último deploy conocido como bueno desde el dashboard de Cloudflare (Deployments → seleccioná el deploy anterior → Retry). Después, comparás el diff entre ese deploy y el que rompió el sitio, aislás los cambios e introducís cada uno de a uno hasta reproducir el error. Si el cuerpo de la respuesta 500 viene vacío, el problema probablemente está en el edge de Cloudflare y no en tu código de aplicación.
¿Por qué mi deploy en Cloudflare Pages muestra error 500 en algunas páginas pero no en otras?
El error selectivo por página indica que el problema está en el contenido específico de esas páginas, no en la configuración general del sitio. En el caso documentado en mayo de 2026, el contenido que causaba el 500 era una URL de referral (m.do.co) que aparecía solo en las páginas de detalle. Comparar las páginas que fallan con las que funcionan, buscando diferencias en el contenido renderizado, es el camino más rápido para identificar la causa.
¿Cómo debuggear un error 500 con cuerpo vacío en Cloudflare Pages?
Un 500 con body vacío en Cloudflare Pages es una señal de que el edge cortó la respuesta antes de entregarla, no de que tu aplicación falló. Usá curl -v URL para inspeccionar los headers de respuesta, especialmente el header CF-RAY que identifica el request en los sistemas de Cloudflare. Compará el comportamiento entre wrangler pages dev local (con las mismas env vars que producción) y el entorno real. Si local anda y producción no, el problema está en el procesamiento edge.
¿Qué causa que Cloudflare Pages retorne 500 después de agregar código nuevo?
Las causas más frecuentes son: variables de entorno no configuradas en el entorno de producción (diferente a Preview), contenido en el HTML renderizado que activa reglas del WAF o filtros del edge, Workers que fallan en tiempo de ejecución, o dependencias incompatibles entre el entorno de build y el runtime de edge. En el caso específico de mayo de 2026, la causa fue una URL de referral en el HTML que Cloudflare no procesó correctamente al servir el contenido.
¿Cómo sé si el error 500 está en el deploy o en el build?
Si el log de Cloudflare muestra “deploy/success” y los archivos se subieron correctamente, el build no es el problema. El error está en la entrega (delivery). Para confirmarlo: verificá que los archivos HTML locales son válidos, hacé un request a una página que falla y revisá si el body de la respuesta está vacío. Body vacío + headers de Cloudflare = problema en el edge. Si el build mismo fallara, el deploy se marcaría como fallido y Cloudflare no publicaría la nueva versión.
Conclusión
Este caso confirma algo que cualquiera que trabaja con plataformas edge debería tener claro: el proceso de deploy y el proceso de entrega de contenido son dos cosas distintas. Que el build haya subido 321 archivos sin errores no dice nada sobre si el edge de Cloudflare va a poder servirlos correctamente.
El aprendizaje concreto para mayo de 2026: si usás Cloudflare Pages y agregás contenido con URLs de terceros (especialmente acortadores o URLs de referral), validá que esas páginas respondan correctamente después del deploy, no solo el build log. La bisección de commits es la herramienta más efectiva para aislar este tipo de problema.
Para hosting estático con menos sorpresas en la capa de entrega, donweb.com ofrece opciones de hosting con CDN que vale la pena evaluar si Cloudflare Pages te está dando dolores de cabeza recurrentes.
