El servicio Private Origins de Cloudflare ya está en disponibilidad general, lo que permite a los clientes apuntar un registro DNS proxied a una dirección IP privada y hacer que Cloudflare llegue al origen a través de una conexión existente de Cloudflare One, según la publicación del blog de Cloudflare que anuncia el lanzamiento. El origen nunca expone una IP pública, y los servicios de aplicación de la compañía — WAF, bot management, rate limiting, caching y Workers — se aplican a ese tráfico de la misma manera que lo hacen para orígenes públicos.
El mecanismo es un atributo de registro DNS. Un registro A o AAAA proxied estándar recibe una marca private_routing, y la plataforma proxy de Cloudflare consulta lo que la publicación llama la Origin API de Cloudflare para decidir hacia dónde enviar el tráfico. Cuando esa respuesta de la API incluye private_routing: true, el proxy entrega la solicitud a la capa de redes privadas de Cloudflare en lugar de intentar una conexión directa a través de la internet pública. Esa capa luego enruta la conexión a través de la conectividad privada que el cliente ya utiliza: IPsec, GRE, Cloudflare Tunnel, CNI o Cloudflare Mesh, según la publicación.
El enrutamiento de red privada se activa automáticamente para tres rangos de direcciones: direcciones IPv4 privadas RFC 1918, direcciones CGNAT RFC 6598 (100.64.0.0/10) y direcciones IPv6 unique local RFC 4193 (fc00::/7). La publicación de Cloudflare es explícita en que esto no puede deshabilitarse para esos rangos — los intentos de desactivarlo a través de la API devuelven un error. Para orígenes que usan una IP pública alcanzable solo a través de una red privada, el ajuste debe habilitarse manualmente. La terminación TLS, WAF, reglas y caching continúan ejecutándose en la red de Cloudflare independientemente de la ruta.
Del lado del operador, Cloudflare WAN no requiere ningún software conector en el origen; Cloudflare Mesh ejecuta un conector dentro de la red privada que puede servir a múltiples orígenes. De cualquier manera, los equipos que se conectan a través de Cloudflare WAN o Mesh necesitan configurar una ruta de retorno para los rangos de origen de Cloudflare — 100.64.0.0/12 para IPv4 y 2606:4700:cf1:5000::/64 para IPv6. La publicación señala esto directamente desde su propia experiencia en la beta: "Una ruta faltante para el rango de origen de Cloudflare fue la falla de configuración más común que vimos", y el consejo general cuando las solicitudes expiran sin que nada llegue al origen es revisar primero esa ruta de retorno.
El conjunto de funciones tiene vacíos reales en la disponibilidad general. Argo Smart Routing y Dedicated CDN Egress IPs no son compatibles, y las verificaciones de estado del origen requieren Load Balancing — limitaciones que Cloudflare lista directamente en la publicación, remitiendo a su documentación para desarrolladores para el conjunto completo. El acceso tampoco es autoservicio en el sentido habitual: el derecho de Private Origins debe ser activado por el equipo de cuenta del cliente, y las cuentas necesitan tener habilitado Unified Routing a menos que se conecten específicamente a través de Cloudflare Tunnel, que no lo necesita.
Lo que se lanzó hoy solo cubre el tráfico público que llega a orígenes privados — solicitudes de internet de socios, clientes o, como la publicación nombra específicamente, backends de agentes de IA y servidores MCP que llegan a infraestructura que nunca fue construida para enfrentar internet. El tráfico privado-a-privado, donde servicios o agentes en una red privada llegan a aplicaciones en otra red privada a través de Cloudflare, todavía está en desarrollo. Cloudflare dice que apunta a una beta cerrada para eso a principios de 2027, abierta a clientes que hablen con su equipo de cuenta.
Para los equipos que ya ejecutan infraestructura de origen detrás de Cloudflare, el movimiento práctico es acotado y específico: esto elimina la necesidad de exponer una IP pública, abrir un puerto de firewall o ejecutar cloudflared junto al origen solo para obtener WAF y rate limiting en una API interna o backend de agente, pero solo cierra el tramo público-a-privado — cualquier cosa que cruce entre dos redes privadas todavía espera la beta de 2027.