La Problemática: Eliminar Puntos Únicos de Fallo en Infraestructura Híbrida
En el diseño de infraestructura, la Alta Disponibilidad (HA) y la mitigación de puntos únicos de fallo suelen requerir arquitecturas complejas y costosas. Cuando buscamos resiliencia para servicios personales o plataformas documentales, el objetivo es garantizar que el tráfico web conmute automáticamente si un nodo físico o proveedor de nube se cae.
Un enfoque para lograr esto es mantener una arquitectura híbrida: un VPS comercial como nodo principal y un servidor On-Premise como respaldo. Mediante CI/CD (como GitHub Actions) se puede compilar y sincronizar el código fuente simultáneamente hacia ambos nodos. Los datos y los contenedores web están replicados, pero el desafío radica en el enrutamiento: ¿cómo hacemos el failover del tráfico público sin pagar por un Load Balancer dedicado?
Aquí es donde entra Cloudflare Tunnels (Zero Trust), y donde se presenta el principal obstáculo de configuración.
El Límite de Cloudflare: Colisiones DNS y Errores 502
La lógica convencional dicta instalar un agente de cloudflared en el VPS y otro en el servidor On-Premise, creando dos túneles distintos en el panel. El problema surge al intentar enrutar el dominio principal hacia ambos túneles.
Balanceo en un solo túnel usando varias reglas: Configurar reglas secuenciales (Regla 1 al VPS, Regla 2 al On-Prem) resulta en un error 502 Bad Gateway. El Agente que recibe la petición intentará resolver un objetivo que no existe en su propia red local, cortando la conexión en lugar de saltar a la segunda regla.
Túneles separados: Asignar el mismo dominio exacto a dos túneles lógicos diferentes genera un error de colisión DNS. Cloudflare crea un registro CNAME automático por túnel y no permite que dos túneles compitan por el mismo dominio raíz en su capa gratuita.
La plataforma reserva el enrutamiento inteligente para su producto comercial de Load Balancing. Sin embargo, existe una alternativa arquitectónica robusta.
La Solución: Arquitectura de Túnel Único con Múltiples Réplicas
Para lograr HA y failover automático, la estrategia consiste en utilizar un solo túnel lógico con múltiples conectores físicos (réplicas).
Al utilizar el mismo token de autorización en múltiples servidores, Cloudflare agrupa esos agentes. Para que esto opere de manera transparente, la infraestructura de red a nivel de Docker debe estar estandarizada para abstraer las diferencias de los hosts físicos.
Paso 1: Abstracción de IPs mediante Redes Aisladas de Docker
Este es el punto crítico de la configuración. Es altamente probable que el VPS y el servidor On-Premise operen en subredes IP distintas. Si configuras Cloudflare para apuntar a una IP estática (ej. 172.25.0.3), la configuración se romperá si el nodo secundario asigna una IP diferente a su contenedor.
La solución es exponer el servicio a través del nombre del contenedor, no de su IP. Para ello, el agente de Cloudflare (cloudflared) y el servidor web (nginx) deben coexistir dentro de la misma red aislada en Docker (tunnel_net). El DNS interno de Docker resolverá el nombre del contenedor sin importar la IP subyacente asignada por el host.
El nombre del contenedor web debe ser idéntico en ambos servidores.
# docker-compose.yml - Aplicar la misma estructura en AMBOS servidores
services:
web:
image: nginx:alpine
container_name: Dedicated_CT_mxlit_web
volumes:
- /home/deploy/site/public:/usr/share/nginx/html:ro
networks:
- tunnel_net
restart: unless-stopped
cloudflared:
image: cloudflare/cloudflared:latest
container_name: Dedicated_CT_mxlit_agent
command: tunnel run
environment:
- TUNNEL_TOKEN=${CLOUDFLARE_TOKEN}
networks:
- tunnel_net
restart: unless-stopped
networks:
tunnel_net:
driver: bridge
Paso 2: Configurar la Ruta Única
En el panel de Cloudflare Zero Trust, elimina cualquier túnel redundante y conserva solo uno. En la pestaña de Public Hostnames, crea una única regla apuntando al nombre del contenedor que definimos en el paso anterior:
- Public Hostname:
tudominio.com - Service:
http://Dedicated_CT_mxlit_web:80
Paso 3: Despliegue del Conector Identico
En lugar de crear un túnel nuevo para el nodo secundario, utiliza exactamente el mismo token de acceso (TUNNEL_TOKEN) en el archivo docker-compose.yml tanto del VPS como del servidor local. Al levantar los contenedores, ambos agentes se reportarán a Cloudflare bajo la misma identidad lógica.
Funcionamiento Técnico: Balanceo Geográfico y Failover Activo
Al revisar la pestaña Overview del túnel en Cloudflare, notarás que se listan múltiples “Réplicas” conectadas. Lo que la plataforma está ejecutando bajo el capó con esta configuración de un solo túnel es un Balanceo de Carga Geográfico (Activo-Activo) sumamente sofisticado.
To understand how traffic is routed, we must analyze three key concepts reflected in the panel:
1. Conexiones a los “Edge Locations”
Cada agente cloudflared (réplica) abre conexiones seguras de salida hacia los centros de datos (Edges) de Cloudflare que se encuentran geográficamente más cerca de ese servidor. Observando una configuración real:
Réplica del VPS (Europa): Se conecta a nodos fra (Frankfurt, Alemania). Esto indica que el VPS está alojado en un centro de datos europeo.
Réplica On-Premise (América): Se conecta a nodos qro (Querétaro, México) y dfw (Dallas, EE.UU.). Al estar el servidor local físicamente en México, el agente busca automáticamente la ruta de fibra óptica más rápida disponible en su región.
2. Ruteo Inteligente por Latencia (Anycast)
Ambos servidores están activos y procesando tráfico simultáneamente. Cloudflare no enruta al azar; siempre intentará enviar al usuario hacia el servidor que le ofrezca el menor tiempo de respuesta (latencia).
Escenario A (Tráfico Europeo): Si un visitante accede a la web desde España, su petición llega al Edge de Cloudflare en Europa. Al detectar que existe una réplica conectada ahí mismo (Frankfurt), Cloudflare le entrega el tráfico directamente al VPS.
Escenario B (Tráfico en América): Si un visitante accede desde México o Estados Unidos, la petición entra por los Edges de Querétaro o Los Ángeles. Cloudflare detecta que el servidor On-Premise está conectado a esos Edges locales, por lo que le manda el tráfico directo a tu servidor en casa.
3. Failover Estructural Transparente
Aquí es donde brilla el diseño de Alta Disponibilidad. ¿Qué sucede si el VPS en Europa sufre un corte de red, falla de hardware o lo apagas para mantenimiento?
Las conexiones del agente hacia Frankfurt se interrumpen. Si ese mismo visitante europeo intenta acceder al sitio, Cloudflare determina: “Mi réplica en Frankfurt ya no responde, pero la réplica de Dallas/Querétaro sigue operativa”.
En cuestión de milisegundos, Cloudflare toma la petición del usuario europeo, la transporta a través de su propia red troncal de fibra óptica cruzando el océano, y la entrega a tu servidor On-Premise. El visitante nunca se topa con un error 502; el sitio simplemente se mantiene en línea, y la transición es imperceptible para el usuario final más allá de unos milisegundos adicionales de carga por la distancia física.
Consideración Operativa: El Estado del Contenedor Web
Existe un escenario específico que interrumpe esta lógica. Si el contenedor del Agente (Dedicated_CT_mxlit_agent) permanece activo, pero el contenedor web (Dedicated_CT_mxlit_web) se detiene o entra en un ciclo de reinicio (crash loop), Cloudflare seguirá reportando la réplica como “Saludable”.
El tráfico será enviado al agente, pero este no podrá resolver la conexión en la red interna de Docker, devolviendo un error 502 al visitante. El failover estructural de Cloudflare reacciona ante la pérdida de conexión del agente con internet, no ante fallos de los servicios internos locales.
Mitigación: Es fundamental garantizar la estabilidad del contenedor web mediante la directiva restart: unless-stopped o always. Esto asegura que el servicio interno se recupere automáticamente tras reinicios del host, permitiendo que el mecanismo de failover externo se reserve exclusivamente para fallas a nivel de infraestructura o red del proveedor.
Consideraciones Finales: Arquitecturas Stateless en HA
El Requisito Crucial: Arquitecturas Stateless (Sin Estado)
Toda esta arquitectura de balanceo Activo-Activo funciona de manera impecable por una razón técnica fundamental: el sitio es estático y no tiene estado (stateless).
Al utilizar un generador de sitios estáticos (como Hugo) y desplegar mediante un pipeline automatizado (GitHub Actions), nos aseguramos de que el servidor físico en Europa y el servidor local en México reciban exactamente el mismo código y los mismos archivos (rsync) al mismo tiempo. Los contenedores web se vuelven clones independientes y desechables.
Es vital entender que este diseño de “túnel único con múltiples réplicas geográficas” no es una solución universal y tiene limitaciones estrictas dependiendo de la aplicación que estés alojando.
¿Cuándo funciona perfectamente?
- Sitios Estáticos: Blogs generados con Hugo, Jekyll, Astro, o páginas HTML/CSS puras.
- Aplicaciones Stateless: APIs o contenedores que no guardan sesiones locales ni requieren bases de datos sincronizadas en tiempo real, donde cualquier nodo puede responder a cualquier petición sin depender de un historial previo.
¿Cuándo causará un desastre?
- Aplicaciones con Bases de Datos Locales: Si intentas hacer esto con un WordPress tradicional, un e-commerce o cualquier sistema que dependa de sesiones de usuario y bases de datos no sincronizadas.
- El problema del estado: Si un usuario entra a tu tienda y Cloudflare lo enruta al VPS en Europa, el usuario añade un producto a su carrito (sesión guardada en Europa). Si en su siguiente clic Cloudflare decide que la latencia hacia México es menor o el VPS tiene un micro-corte, el usuario será redirigido al servidor On-Premise. Como ese servidor en México no tiene la base de datos sincronizada, el usuario verá su carrito vacío o su sesión cerrada.
Para aplicaciones dinámicas (stateful), requerirías replicación de bases de datos multi-región (como un clúster de Galera o bases de datos en la nube), lo cual añade una capa de complejidad y latencia que rompe el propósito de este despliegue sencillo y de bajo costo.
Conclusión
Construir una infraestructura de HA a costo cero es posible aprovechando los túneles de Cloudflare más allá de su caso de uso tradicional. Aprovechar el protocolo Anycast de Cloudflare asignando el mismo túnel a proveedores y continentes distintos es una manera excelente de construir una CDN (Content Delivery Network) privada, tolerante a fallos y gratuita. Al abstraer los nombres de los contenedores en Docker y eliminar la dependencia de bases de datos, logramos una infraestructura resiliente de grado empresarial, optimizada específicamente para cargas de trabajo estáticas. Esta orquestación simétrica garantiza que tu plataforma permanezca disponible y resiliente, sin importar el origen físico del tráfico o la estabilidad de un proveedor específico.