Cómo conectar un sitio web a Cloudflare

Cómo conectar un sitio web a Cloudflare

Cloudflare puede situarse delante de un sitio web de dos maneras muy distintas. Puedes mover todo el dominio al DNS y al proxy de Cloudflare, o puedes mantener una configuración reducida y activar una sola función a la vez. Esa elección cambia los pasos, el riesgo y el plan de reversión.

Empieza por ahí. Un sitio de marketing con unas pocas páginas tiene necesidades distintas a las de un dominio corporativo con mucho correo, y un dominio que ya da servicio a un sitio web de empresa requiere un manejo más cuidadoso de los registros que un lanzamiento completamente nuevo. Si además estás pensando en la seguridad del sitio web, Cloudflare suele entrar en la conversación precisamente por eso.

1. Decide si necesitas control total del DNS o solo una función de Cloudflare

Cloudflare no es un único interruptor. Puede gestionar DNS, actuar como proxy del tráfico web, almacenar contenido en caché, filtrar solicitudes y situarse entre los visitantes y tu servidor de origen. Si solo quieres una función, como la gestión de DNS o una capa de seguridad, aun así debes entender que los servidores de nombres del dominio suelen ser el punto en el que Cloudflare toma el control.

Para un sitio informativo sencillo, el control total suele ser una buena opción. Para una configuración con enrutamiento de correo, servicios de verificación y varios subdominios, la decisión es más delicada. Una infraestructura de red privada, por ejemplo, puede necesitar que ciertos hostnames queden fuera del proxy, mientras que las páginas web pueden pasar por Cloudflare sin problemas.

Hazte una pregunta práctica: ¿qué debe seguir funcionando el primer día? Si la respuesta incluye correo electrónico, callbacks de API o un flujo de pagos, no solo estás “conectando un sitio web a Cloudflare”; estás cambiando la forma en que resuelve el dominio. Esa diferencia importa.

Una regla corta ayuda: no adivines. Si el sitio depende de algún servicio fuera del servidor web, haz una lista antes de tocar los servidores de nombres. Esa lista será tu red de seguridad.

2. Audita la configuración actual del dominio antes de cambiar los servidores de nombres

Antes de mover nada, comprueba dónde se gestiona ahora el DNS. El registrador y el proveedor de DNS no siempre son la misma empresa, y esa diferencia provoca errores evitables. Consulta los servidores de nombres actuales y luego revisa los registros de la zona que existen allí.

Necesitas tener la imagen completa: registros A y AAAA para el sitio web, registros CNAME para subdominios, registros MX para el correo, registros TXT para verificación y cualquier registro poco habitual usado por herramientas de terceros. Un registro TXT que falte puede romper un flujo de inicio de sesión. Un registro MX incorrecto puede detener el correo.

No confíes en la memoria. Un dominio que lleva años activo puede contener registros añadidos por distintas personas en distintos momentos, y algunos quizá ya no estén documentados en ningún otro sitio. Si el propietario del sitio no puede explicar un registro, eso es una razón para conservarlo hasta saber qué hace.

También es el momento de anotar redirecciones y hostnames antiguos. Si el tráfico sigue llegando a un subdominio viejo, apúntalo ahora. Una redirección que funciona en el origen puede fallar después si el hostname no se copió a Cloudflare.

Guarda una copia de la zona actual fuera de la cuenta del registrador. Un archivo de texto plano basta. También sirve una hoja de cálculo. Lo importante es poder recuperarla.

3. Crea el sitio en Cloudflare e importa los registros DNS existentes

Después de la auditoría, añade el dominio a Cloudflare. Cloudflare escaneará los registros DNS existentes e intentará importarlos a su zona. Ese escaneo ahorra tiempo, pero no garantiza que todo se haya importado correctamente.

Revisa los registros importados línea por línea. Puede faltar un registro, un subdominio puede estar duplicado o un valor puede estar desactualizado. La primera pasada trata de precisión, no de velocidad. Si ves un hostname que debería apuntar a tu servidor web pero ahora apunta a otro sitio, corrígelo antes de tocar el registrador.

Dos comprobaciones sencillas detectan muchos errores. Primero, compara los registros importados con tu lista de auditoría. Segundo, confirma que el dominio raíz y el hostname común “www” resuelven al lugar correcto. Esos son los registros que los usuarios tocarán primero.

Si gestionas un sitio que se comporta como un sitio web corporativo, vigila de cerca los subdominios. Un portal de soporte, un hostname de staging y un host de archivos suelen convivir junto al sitio principal, y un solo registro que falte puede bastar para provocar una caída difícil de diagnosticar.

Un apunte práctico: la importación de Cloudflare es útil, pero no sustituye tu propia revisión. El escaneo es un punto de partida. Tu auditoría es la comprobación final.

4. Elige qué registros deben seguir proxied y cuáles deben quedarse solo en DNS

Cloudflare te permite elegir en muchos registros. La nube naranja significa que el tráfico pasa por el proxy de Cloudflare. La nube gris significa solo DNS. Esa elección no es estética. Cambia la forma en que viajan las solicitudes.

El tráfico web del sitio público suele ir proxied. Los registros de correo no. Los registros de verificación no. Algunos subdominios que sirven APIs o herramientas especializadas también deberían seguir solo en DNS, a menos que hayas probado con cuidado toda la ruta. Si quieres una regla rápida, proxya el sitio web y deja los servicios que no son web en paz, salvo que tengas un motivo para cambiarlos.

Un error común es proxyar todo porque parece más ordenado. No tarda en dejar de estarlo. Un registro MX detrás del proxy fallará. Un hostname de verificación puede dejar de ser reconocido por otro servicio. Un endpoint de transferencia de archivos puede comportarse de forma extraña porque nunca estuvo pensado para pasar por el proxy web.

Piensa en términos de función, no de apariencia. El sitio web puede ir proxied para mejorar rendimiento y seguridad. El correo normalmente debería quedarse solo en DNS. Si tu configuración incluye píxeles de seguimiento, endpoints de webhooks o hosts de verificación de terceros, prueba cada uno por separado.

El tráfico que debe permanecer como DNS puro suele ser precisamente el tráfico que menos quieres romper. Ten presente esa idea antes de pulsar demasiadas veces la nube naranja.

5. Actualiza los servidores de nombres del dominio en tu registrador

Cloudflare asignará dos servidores de nombres para el dominio. Debes sustituir los servidores de nombres actuales en tu registrador por esos dos valores. Este es el paso que entrega la autoridad del DNS a Cloudflare, así que cópialos exactamente como aparecen. Si vas a configurar DNS en Cloudflare, este es el momento en que la delegación empieza a contar de verdad.

En el registrador, busca la sección de servidores de nombres y elimina la pareja anterior. Después introduce la pareja asignada por Cloudflare. Guarda el cambio.

No te alarmes si el sitio no cambia de inmediato. Los cambios de DNS no se sincronizan con un único reloj. Un visitante puede seguir llegando al camino anterior durante un tiempo, y eso es normal. Si el antiguo proveedor de DNS sigue activo durante la transición, reduces el riesgo de búsquedas fallidas.

Una frase breve aquí: sé exacto. Un solo carácter erróneo en la entrada de los servidores de nombres puede impedir que la delegación funcione.

Tampoco cambies más de una cosa a la vez. Si renombras registros, cambias de host y editas los servidores de nombres en la misma sesión, complicas mucho más la resolución de problemas de lo necesario.

6. Confirma que el dominio está activo en Cloudflare y prueba rutas reales de tráfico

Después del cambio de servidores de nombres, Cloudflare debería mostrar el dominio como activo. Si no lo hace, normalmente el problema es uno de tres: el cambio en el registrador no se guardó, los servidores de nombres se introdujeron mal o el registrador todavía tiene datos en caché. Comprueba eso antes de culpar al servidor de origen.

Después prueba rutas reales, no solo la página principal. Abre el dominio principal, la versión “www”, una subpágina clave y cualquier subdominio importante. Si el sitio tiene una página de inicio de sesión, pruébala también. Si ofrece una descarga de archivos o el envío de un formulario, prueba esas acciones. Las páginas pueden cargar aunque un endpoint oculto esté roto.

Aquí es donde ayuda una herramienta de monitorización. Si usas una plataforma de analítica y monitorización web, compara las primeras solicitudes en vivo tras el cambio con el patrón habitual. Un aumento repentino de errores en un hostname suele ser la primera señal de que un registro DNS o una configuración del proxy necesita atención.

Usa otro navegador o una ventana privada para hacer una prueba limpia. Los datos en caché pueden ocultar problemas. También puede hacerlo una sesión de inicio de sesión antigua.

Si algo falla, prueba la ruta desde el dominio hacia fuera: DNS, respuesta del edge, respuesta del origen y luego lógica de la aplicación. Ese orden ahorra tiempo.

7. Configura las primeras opciones seguras de Cloudflare para una nueva conexión

Una vez que el dominio esté activo, mantén conservadora la configuración inicial. Elige un modo SSL/TLS que encaje con lo que tu origen realmente puede admitir, y no adivines. Si el certificado del origen no está listo, el navegador puede mostrar errores o Cloudflare puede rechazar la conexión. Eso sería una mala sorpresa el día del lanzamiento.

Las configuraciones básicas de seguridad deberían ser el siguiente paso. Si ya te preocupa la seguridad del sitio web, aquí es donde Cloudflare empieza a ayudar más allá del DNS. Empieza con los controles obvios y luego vuelve a probar el sitio. Los ajustes agresivos pueden esperar hasta que sepas que la base funciona correctamente.

El comportamiento de la caché también merece una primera revisión cuidadosa. Una página que cambia a menudo no debería tratarse igual que una que apenas cambia. Si no estás seguro, deja primero el comportamiento predeterminado, observa cómo responde el sitio y luego cambia una sola cosa cada vez.

Un hábito útil es separar “seguro ahora” de “mejor después”. Lo seguro ahora incluye acertar con la ruta SSL y confirmar que el sitio sigue abriéndose. Lo mejor después incluye ajustar encabezados de caché o endurecer reglas una vez que tengas registros que revisar. Ese orden evita caídas autoinducidas.

Mantén esta fase pequeña. Los cambios pequeños son más fáciles de deshacer.

8. Verifica casos límite: correo, subdominios, redirecciones y problemas de contenido mixto

Aquí es donde fallan muchos sitios. El correo electrónico suele depender de registros DNS que deben seguir solo en DNS. Comprueba que los registros MX sigan apuntando al host de correo correcto y que se hayan conservado los registros TXT de SPF, DKIM o DMARC. Si el correo se detiene, el sitio web puede seguir viéndose bien mientras desaparecen los mensajes de negocio.

Los subdominios merecen su propia lista de verificación. Un hostname de staging, un host de imágenes y un endpoint de subida pueden necesitar un tratamiento distinto cada uno. Si uno de ellos se proxied por error, quizá veas comportamientos extraños solo en ese hostname. Ese tipo de fallo hace perder tiempo porque la página principal funciona.

Las redirecciones también pueden sacar a la luz errores. Si el sitio antiguo enviaba visitantes de un hostname a otro, vuelve a probar ese recorrido después del cambio. Una cadena de redirección que antes funcionaba puede apuntar ahora a un hostname que nunca se añadió a Cloudflare. Un solo registro que falte puede romper todo el recorrido.

Los problemas de contenido mixto aparecen cuando el sitio carga algunos recursos por HTTP mientras la página se sirve por HTTPS. A los navegadores no les gusta esa combinación. Las imágenes pueden desaparecer, los scripts pueden fallar y un formulario puede dejar de enviarse. Corrige las URLs en la aplicación, no solo en el navegador.

Si tu dominio da soporte a un flujo de soporte del sitio web después del lanzamiento, mantén una lista corta de los hosts más frágiles: correo, staging, subidas, redirecciones y verificación de terceros. Esas cinco áreas son donde suelen aparecer los primeros tickets.

Una última comprobación práctica: prueba el sitio desde una red que no uses normalmente. Una conexión móvil puede revelar un problema de caché o un retraso de DNS que la red de tu oficina oculta. Distintas rutas muestran distintos problemas.

Y si estás conectando un sitio que ya tiene exigencias operativas estrictas, documenta cada registro DNS que hayas tocado. No después. Ahora.

Si más adelante necesitas migrar dominio a Cloudflare, hazlo solo después de repetir estas verificaciones y confirmar que correo, subdominios y redirecciones siguen estables.