Cloudflare es, en lo esencial, un proxy inverso con red de distribución: cuando lo activás, las visitas dejan de llegar directo a tu servidor y pasan primero por su red, que está repartida por el mundo. Con eso se obtienen cuatro cosas a la vez: caché de los archivos estáticos cerca de quien los pide, certificado y HTTPS sin configurarlo, filtrado de tráfico malicioso y DNS gestionado. La decisión que más importa en la configuración inicial es el modo de cifrado: el llamado Flexible deja el tramo entre Cloudflare y tu servidor sin cifrar, así que el candado que ve el visitante no representa el viaje completo. Y hay que asumir una dependencia nueva: si el intermediario falla, tu sitio falla.
Ver índice de contenidos
Qué es, en una frase
Un proxy inverso es un servidor que se pone delante del tuyo y atiende a las visitas en su nombre. Ellas hablan con el proxy; el proxy habla con tu servidor —el origen— cuando hace falta.
Una red de distribución de contenidos es ese mismo proxy replicado en muchas ciudades, de modo que cada persona sea atendida por el punto más cercano. Cloudflare combina las dos cosas y les suma DNS, certificados y filtrado.
De ahí salen sus cuatro funciones principales, y conviene tenerlas separadas porque se activan y se rompen por separado:
- Caché y aceleración: guarda copias de lo estático cerca de quien lo pide.
- Cifrado: emite el certificado del tramo público y termina la conexión HTTPS.
- Filtrado: bloquea tráfico malicioso antes de que llegue a tu servidor.
- DNS gestionado: administra la zona del dominio, con o sin proxy por registro.
Qué cambia al activar el proxy
| Aspecto | Sin proxy | Con proxy |
|---|---|---|
| Qué devuelve el DNS | La dirección real de tu servidor | Una dirección de la red del intermediario |
| Con quién habla el navegador | Con tu servidor | Con el punto más cercano de la red |
| De quién es el certificado | Tuyo | Del intermediario, en el tramo público |
| Dirección de tu servidor | Pública | Oculta, mientras no se filtre por otro lado |
| Qué tráfico te llega | Todo | Solo lo que pasa el filtro y no está en caché |
| Qué IP ve tu servidor | La del visitante | La del proxy: hay que leer una cabecera para saber la real |
La última fila causa problemas silenciosos: los registros del servidor pasan a mostrar la dirección del proxy en todas las visitas, y cualquier sistema que dependa de la IP —limitación por dirección, geolocalización, listas de bloqueo— empieza a funcionar mal. La solución es configurar el servidor para que tome la dirección real de la cabecera correspondiente, y hacerlo solo para peticiones que vengan de rangos del proxy, porque si no cualquiera puede falsear su origen.
DNS y la nube naranja
Para usar el proxy hay que delegar el DNS del dominio, es decir cambiar los servidores de nombres en el registrador. Desde ese momento la zona vive ahí, y cada registro tiene un interruptor: con proxy —la nube naranja— o solo DNS —la nube gris—.
| Registro | Estado | Por qué |
|---|---|---|
La web y www | Con proxy | Es lo que se quiere acelerar y proteger |
Registros MX del correo | Solo DNS | El proxy es para HTTP: no funciona con correo |
| El nombre del servidor de correo | Solo DNS | Si lo pasás por el proxy, deja de recibirse correo |
| Acceso remoto al servidor | Solo DNS | No es tráfico web y no pasa por el proxy |
Verificaciones en TXT | No aplica | Los registros de texto no se pueden pasar por proxy |
El error más común y más caro al activar el servicio es dejar el correo con la nube naranja. Deja de llegar sin ningún mensaje de error visible, y suele descubrirse cuando alguien avisa por otro canal que sus mensajes rebotan.
Los modos de cifrado
Acá está la decisión que más consecuencias tiene, porque al haber un intermediario la conexión se parte en dos tramos: del visitante al proxy, y del proxy a tu servidor. Cada modo define qué pasa en el segundo.
| Modo | Qué hace | Veredicto |
|---|---|---|
| Off | «No se usa cifrado para el tráfico entre los visitantes y Cloudflare ni entre Cloudflare y los orígenes» | No |
| Flexible | «El tráfico de los visitantes a Cloudflare puede cifrarse por HTTPS, pero el tráfico de Cloudflare al servidor de origen no» | Evitar. Ver la advertencia de abajo |
| Full | «Cloudflare hace coincidir el protocolo de la petición del visitante al conectarse al origen», sin validar el certificado | Aceptable como paso intermedio |
| Full (strict) | Igual que Full, «con validación adicional del certificado del servidor de origen» | Recomendado |
| Strict | «Cloudflare siempre se conecta al origen por HTTPS con validación de certificado», sin importar cómo llegó el visitante | El más estricto |
Con Flexible, la persona ve el candado y cree que la conexión está protegida de punta a punta. No lo está: el tramo entre el proxy y tu servidor viaja sin cifrar, y ese tramo atraviesa internet igual que cualquier otro. Cualquiera con acceso a la red intermedia puede leer las contraseñas que se envían.
Peor todavía, con WordPress suele producir un bucle de redirecciones: la aplicación ve que la petición llegó por HTTP, redirige a HTTPS, el proxy vuelve a pedir por HTTP, y así indefinidamente.
La documentación de Cloudflare recomienda Full o Full (strict), y señala que Flexible es «común para orígenes que no soportan TLS, aunque se recomienda actualizar la configuración del origen siempre que sea posible». Si el origen no soporta cifrado, el propio proveedor ofrece un certificado gratuito de origen para resolverlo.
Vale mencionar que el modo automático es hoy el predeterminado y elige el más seguro que sea compatible con tu origen. Es una mejora, pero conviene verificar en qué quedó y no suponerlo.
La caché
Por defecto se cachean los archivos estáticos por su extensión: imágenes, hojas de estilo, scripts, tipografías. El HTML no se cachea salvo que se configure una regla, y esa decisión por defecto es prudente: evita servir contenido personalizado a la persona equivocada.
Los dos problemas clásicos de la caché son opuestos:
- Cambié algo y no se ve. Hay una copia vieja. Se resuelve purgando —mejor por URL que todo— y, sobre todo, versionando los nombres de archivo para que cada cambio genere un nombre nuevo y el problema no vuelva a existir.
- Se cacheó algo que no debía. Un panel de administración o una página con datos de sesión. Se corrige excluyendo esas rutas por regla, y es un problema más serio que el anterior porque puede exponer datos entre usuarios.
Hay una función que conviene mirar con cuidado: la minificación y optimización automática. Reescribe CSS y JavaScript sobre la marcha, y de vez en cuando rompe algo. Si un sitio funciona en local y falla en producción con un error de JavaScript, es de los primeros lugares donde mirar.
Las funciones de seguridad
Con el proxy activo, el tráfico se filtra antes de llegar a tu servidor. Las tres capas que más se usan:
- Mitigación de denegación de servicioAbsorber una avalancha de tráfico es exactamente lo que una red grande hace bien, y es la función que más justifica el servicio.
- Cortafuegos de aplicaciónReglas que bloquean patrones de ataque conocidos antes de que lleguen a tu código. No reemplaza corregir el código: gana tiempo.
- Limitación de tasa y verificaciónFrenar intentos repetidos de inicio de sesión y distinguir automatización de personas.
Un ajuste que rinde y casi nadie hace: una vez que el proxy funciona, configurar el servidor de origen para que solo acepte conexiones desde los rangos del proxy. Sin eso, cualquiera que descubra la dirección real puede saltearse todas las capas anteriores conectándose directo, y todo el filtrado se vuelve decorativo.
Qué no resuelve
La sección más útil de esta guía, porque el servicio se vende como solución general y no lo es.
| No resuelve | Por qué |
|---|---|
| Un sitio lento por dentro | Si la página tarda tres segundos en generarse, va a seguir tardando. La caché ayuda con lo estático, no con la primera visita a contenido dinámico |
| Una aplicación insegura | El cortafuegos filtra patrones conocidos. Un fallo de lógica en tu código pasa igual |
| Los respaldos | No guarda copias de tu sitio ni de tu base de datos |
| Ocultar tu dirección si se filtra | Aparece por el correo saliente, por registros DNS viejos, por certificados históricos o por un subdominio sin proxy |
| La disponibilidad de tu origen | Si tu servidor está caído y la página no está en caché, el visitante ve un error |
Y hay una contrapartida que conviene asumir con los ojos abiertos: se agrega una dependencia crítica. El blog de Underc0de documentó la caída global de Cloudflare de noviembre de 2025, la peor en seis años: durante esas horas, miles de sitios con servidores perfectamente sanos quedaron inaccesibles.
La mitigación no es dejar de usarlo, sino tener el procedimiento de emergencia escrito y probado: cómo desactivar el proxy y volver a apuntar el DNS al origen. Para eso hace falta que el TTL no sea altísimo y que alguien sepa hacerlo sin improvisar.
Diagnóstico
# ¿El registro está pasando por el proxy? La IP no será la de tu servidor
dig underc0de.org A +short
# Las cabeceras dicen si respondió la caché y qué punto atendió
curl -sI https://underc0de.org | grep -i 'cf-cache-status|cf-ray|server'
# cf-cache-status: HIT respondió la caché
# cf-cache-status: MISS fue hasta tu servidor
# cf-cache-status: DYNAMIC no es cacheable por configuración
# Saltear el proxy y hablar DIRECTO con el origen: separa los problemas.
# Si acá funciona y por el nombre no, el problema está en el intermediario.
curl -sI https://underc0de.org --resolve underc0de.org:443:203.0.113.10El último comando es el que ordena cualquier discusión: prueba tu servidor sin pasar por la red intermedia. Si el origen responde bien y el sitio público no, el problema está en la configuración del proxy y no en tu aplicación.
Errores frecuentes
- Dejar el modo Flexible. Media conexión sin cifrar y bucles de redirección en WordPress.
- Pasar el correo por el proxy. Deja de llegar y no hay ningún error visible.
- No configurar la IP real del visitante. Los registros muestran siempre la del proxy y se rompe todo lo que dependa de la dirección.
- No cerrar el origen a los rangos del proxy. Quien encuentre la dirección real saltea todas las protecciones.
- Cachear HTML sin pensarlo. Puede servir contenido de una sesión a otra persona.
- Activar la optimización automática y olvidarlo. Es el sospechoso número uno cuando algo funciona en local y falla en producción.
- Suponer que reemplaza los respaldos o la seguridad de la aplicación. No hace ninguna de las dos cosas.
- No tener plan para cuando el intermediario falle. Conviene saber de antemano cómo desactivarlo.
Preguntas frecuentes
¿Qué hace exactamente el proxy cuando se activa?
Cambia a quién se conecta el visitante. Sin proxy, el DNS devuelve la dirección de tu servidor y el navegador habla directo con él. Con proxy activado, el DNS devuelve una dirección de la red del intermediario, el navegador se conecta ahí y esa red consulta a tu servidor solo cuando lo necesita. A partir de ese momento, el certificado que ve la visita es el del intermediario, la dirección real de tu servidor queda oculta mientras no se filtre por otro lado, y el tráfico se filtra y se cachea antes de llegar.
¿Por qué no conviene el modo de cifrado Flexible?
Porque cifra solo la mitad del viaje. El tramo del visitante al proxy va por HTTPS, pero el tramo del proxy a tu servidor viaja sin cifrar por internet, de modo que el candado que ve la persona no representa lo que realmente pasa: cualquiera con acceso a esa red intermedia puede leer las contraseñas enviadas. Además, con WordPress suele generar un bucle de redirecciones. La documentación recomienda Full o Full estricto, y si el origen no soporta cifrado, el proveedor ofrece un certificado gratuito para el origen.
¿Por qué dejó de llegar el correo después de activarlo?
Porque algún registro relacionado con el correo quedó pasando por el proxy. El proxy funciona con tráfico web, no con correo, así que los registros MX y el nombre del servidor de correo tienen que quedar en modo solo DNS. Es el error más habitual al migrar la zona, y lo complicado es que no produce ningún mensaje de error visible en el panel: simplemente los mensajes dejan de llegar, y suele descubrirse cuando alguien avisa por otro canal que sus correos rebotan.
¿Cloudflare hace que mi sitio sea rápido?
Hace que lo estático viaje menos distancia, que no es lo mismo. Si tu página tarda tres segundos en generarse en el servidor, va a seguir tardando tres segundos para quien pida contenido dinámico que no está en caché. Lo que sí mejora, y bastante, es la entrega de imágenes, hojas de estilo y scripts a visitantes lejanos, y la capacidad de aguantar picos de tráfico sobre contenido cacheable. Para un sitio lento por dentro, el trabajo sigue estando en la aplicación y en la base de datos.
¿Realmente oculta la dirección de mi servidor?
La oculta del DNS, que es el camino más obvio, pero se filtra por otros lados con más facilidad de la que parece: el correo saliente enviado desde el propio servidor, registros DNS históricos que quedaron indexados, certificados emitidos antes de activar el proxy, o cualquier subdominio que haya quedado sin proxy. Por eso ocultar la dirección no debe tratarse como una medida de seguridad en sí misma. Lo que sí protege es configurar el servidor para que solo acepte conexiones desde los rangos del proxy.
¿Qué pasa si Cloudflare se cae?
Tu sitio queda inaccesible aunque el servidor esté perfecto, porque toda la entrada pasa por ahí. No es hipotético: en noviembre de 2025 hubo una interrupción global, la peor del proveedor en seis años, y miles de sitios sanos quedaron fuera de línea. La mitigación no es dejar de usarlo sino tener escrito y probado el procedimiento de emergencia: cómo desactivar el proxy y volver a apuntar el DNS al origen. Para eso hace falta que el TTL no sea altísimo y que alguien sepa hacerlo sin improvisar.
Fuentes
Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 27 de julio de 2026.
Aportes de la comunidad Underc0de
- Underc0de, blog. Caída global de Cloudflare: su peor interrupción en 6 años, 19 de noviembre de 2025. El costo de concentrar la entrada de un sitio en un solo proveedor.
- Underc0de, foro. Sección Hosting y dominios. Consultas de la comunidad sobre configuración de proxy, caché y certificados.
Documentación oficial
- Cloudflare. SSL/TLS encryption modes. Las descripciones de los modos Off, Flexible, Full, Full (strict) y Strict, citadas en esta guía.
- Cloudflare. Cache. Qué se cachea por defecto y cómo se controla.
- Cloudflare. DNS. Registros con y sin proxy, y el comportamiento de la nube naranja.
- Cloudflare. Origin CA certificates. Los certificados gratuitos para el tramo entre el proxy y tu servidor.