---
title: "Cloudflare ya protege servidores con IP privada: WAF, caché y Workers sin abrir un solo puerto"
url: https://hernandez.systems/es/articulos/cloudflare-ya-protege-servidores-con-ip-privada-waf-cache-y
lang: es
type: NewsArticle
section: Infraestructura
published: "2026-11-01T14:33:30+00:00"
modified: "2026-11-02T15:01:05+00:00"
publisher: Osky Networks
image: https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-01/e40-portada-3f8d30be.png
alternate_en: https://hernandez.systems/en/articles/cloudflare-now-protects-servers-with-private-ips-waf-cache-and-workers-without-opening-a-single-port
---

# Cloudflare ya protege servidores con IP privada: WAF, caché y Workers sin abrir un solo puerto

> Cloudflare anunció el 30 de octubre de 2026 la disponibilidad general de Cloudflare services for private origins: ahora puedes crear un registro DNS proxied (la nube naranja) que apunte a una IP privada, como 10.0.0.50, y Cloudflare llega a ese servidor por la conexión privada que ya tienes con su red, no por Internet. El origen se queda sin IP pública y sin puerto abierto, pero recibe el mismo WAF, caché, manejo de bots, rate limiting y Workers que cualquier sitio público. Para quien tiene APIs internas, backends de agentes de IA o servidores MCP que necesitan recibir tráfico de fuera, el cambio importa: quita la excusa de "esto no lo protegemos porque no está en Internet". Eso sí, no es un switch para todo el mundo, y ahí está la letra chiquita.

Cloudflare anunció el 30 de octubre de 2026 la disponibilidad general de **Cloudflare services for private origins**: ahora puedes crear un registro DNS *proxied* (la nube naranja) que apunte a una **IP privada**, como `10.0.0.50`, y Cloudflare llega a ese servidor por la conexión privada que ya tienes con su red, no por Internet. El origen se queda sin IP pública y sin puerto abierto, pero recibe el mismo WAF, caché, manejo de bots, rate limiting y Workers que cualquier sitio público. Para quien tiene APIs internas, backends de agentes de IA o servidores MCP que necesitan recibir tráfico de fuera, el cambio importa: quita la excusa de "esto no lo protegemos porque no está en Internet". Eso sí, no es un switch para todo el mundo, y ahí está la letra chiquita.

## Qué problema resuelve

Cloudflare lo explica así en su anuncio: muchas APIs internas, backends de agentes, servidores MCP y herramientas operativas "no se construyeron para dar la cara a Internet", pero igual tienen que aceptar peticiones de socios, clientes o agentes. Antes, poner a Cloudflare delante de esos servicios implicaba una de tres cosas: exponer una IP pública, abrir un puerto en el firewall o correr `cloudflared` (el conector de Cloudflare Tunnel) junto al origen.

La consecuencia, según la propia empresa, era que esas aplicaciones privadas se quedaban sin las protecciones que sí tenían las públicas. Mi lectura: es el patrón de siempre en infraestructura. Lo público se blinda porque todos lo ven; lo interno se queda con "total, nadie lo conoce", hasta que alguien lo conoce.

La función se lanzó en **beta cerrada en junio** para clientes Enterprise elegibles, y en ese momento Cloudflare puso como meta la disponibilidad general en el cuarto trimestre de 2026. Cumplió el calendario.

## Cómo funciona

El truco está en el último salto. Todo lo demás sigue igual: la terminación TLS, el WAF, las reglas y la caché corren en la red de Cloudflare como siempre. La diferencia es que, en lugar de intentar conectarse a la IP del origen por Internet pública, el proxy le pasa la petición a la capa de red privada de Cloudflare, que la enruta por la conectividad que ya opera el cliente: túneles IPsec o GRE, CNI (interconexión directa), Cloudflare Tunnel o Cloudflare Mesh.

![Diagrama antes y después: antes el origen necesitaba IP pública o puerto abierto; ahora Cloudflare llega a la IP privada por IPsec, GRE, CNI, Tunnel o Mesh](https://oskydj.sfo3.cdn.digitaloceanspaces.com/calamardo/news_item/2026-11-01/e40-flujo-cee631df.png)

En el DNS se activa con la opción **Use private network routing** en un registro A o AAAA con proxy. Para estos rangos se enciende sola y no se puede apagar:

- `10.0.0.0/8`, `172.16.0.0/12` y `192.168.0.0/16` (privados, RFC 1918).
- `100.64.0.0/10` (CGNAT, RFC 6598).
- `fc00::/7` (IPv6 de unidad local, RFC 4193).

Si tu origen tiene una IP pública que solo es alcanzable a través de tu red privada, puedes encenderla a mano. La documentación agrega un detalle que puede morder: la opción aplica **por nombre, no por registro**. Si tienes varios registros A o AAAA con el mismo nombre y uno solo tiene el enrutamiento privado activo, todos lo usan.

## El cambio que deben notar quienes automatizan

En la API, el enrutamiento privado es un atributo más del registro DNS. Aquí hay algo que vale la pena revisar si ya tenías scripts de la beta: en el anuncio de junio el campo se llamaba `use_private_routing`, y en el anuncio de disponibilidad general y en la documentación actual se llama `private_routing`.

```
POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "proxied": true,
  "private_routing": true
}
```

Según la documentación, en un registro proxied con IP privada el valor se pone en `true` solo; con IP pública queda en `false` por defecto; en tipos que no son A o AAAA el campo no existe. Y si mandas `private_routing: false` en un registro proxied con IP privada, la API responde con error. No lo probé; esto sale de la documentación oficial de Cloudflare.

## Qué funciona y qué no

| Funciona igual que con un origen público | No está soportado o tiene condiciones |
|---|---|
| WAF y reglas administradas | Argo Smart Routing (no soportado) |
| Manejo de bots | IPs dedicadas de salida del CDN (no soportado) |
| Rate limiting | Health checks del origen (solo con Load Balancing) |
| Caché | Registros que no sean A o AAAA |
| Reglas de transformación y reescritura | Registros sin proxy |
| Workers | |

Cloudflare remite a su documentación para la lista completa de limitaciones.

## Lo que necesitas para usarlo

Aquí está la letra chiquita. Cloudflare dice que hoy abre el acceso "más allá" del grupo de la beta, pero los requisitos que publica son:

1. Que tu cuenta tenga el permiso (*entitlement*) de Private Origins. Se lo pides a tu equipo de cuenta de Cloudflare.
2. Conectividad de Cloudflare One por IPsec, GRE, CNI, Cloudflare Tunnel o Cloudflare Mesh.
3. Unified Routing activado en la cuenta, salvo que te conectes por Cloudflare Tunnel, que no lo necesita.
4. Si te conectas por Cloudflare WAN o Mesh, una ruta de regreso para los rangos de origen de Cloudflare: `100.64.0.0/12` en IPv4 y `2606:4700:cf1:5000::/64` en IPv6.

Con Cloudflare WAN no hace falta software conector en el origen; con Mesh, un conector corre dentro de tu red privada y puede atender varios orígenes.

Ojo con un detalle: al momento de escribir esto, la página principal de la documentación de Private Origins todavía dice "beta" y "Enterprise-only", con fecha de actualización del 7 de mayo de 2026, y el anuncio de disponibilidad general no aclara si eso cambió. Mi lectura: si tienes plan Free o Pro, esto no es un botón que vas a encontrar mañana en el panel. Si proxeas una IP privada sin el permiso, la documentación dice que recibes el **error 1002** ("DNS points to prohibited IP").

## El error más común de la beta

Cloudflare compartió una lección de la beta: si las peticiones expiran y no llega nada al origen, revisa primero la **ruta de regreso**. Que faltara la ruta hacia el rango de origen de Cloudflare fue el error de configuración más frecuente que vieron. La guía de solución de problemas suma otros dos casos típicos: tiempos de espera porque la IP de origen de Cloudflare está configurada en un rango público (hay que ponerla en un `/12` privado) y tráfico que intenta salir por Internet porque el registro no tiene activado el enrutamiento privado.

## Qué sigue

Esta entrega cubre tráfico **público hacia privado**. Lo siguiente en el plan de Cloudflare es **privado a privado**: usuarios, servicios y agentes de IA en redes privadas que llegan a aplicaciones en otras redes privadas, pasando por los mismos servicios de aplicación. La empresa apunta a una beta cerrada a principios de 2027. Su ejemplo: un empleado que abre `wiki.company.internal` con WAF, rate limiting y manejo de bots, como si fuera una API pública.

## Lo que esto significa

Mi lectura es que Cloudflare está borrando la frontera entre "lo que va detrás del CDN" y "lo que va detrás de la VPN". Para equipos que ya pagan Cloudflare WAN o Mesh es una ganancia directa: reutilizan túneles que ya tienen para meter WAF y caché a servicios internos sin abrir nada. Para el resto, el mensaje práctico es otro: si hoy expones un servicio interno con IP pública y una lista de IPs permitidas, ese modelo sigue funcionando, pero la dirección de la industria es que el origen ni siquiera tenga cara pública. Y con agentes de IA consumiendo APIs internas cada vez más, tener un WAF y un rate limit delante de ese MCP que "nadie conoce" deja de ser lujo.

## Fuentes

- [Cloudflare services for private origins is now generally available (blog de Cloudflare, 30 de octubre de 2026)](https://blog.cloudflare.com/private-origins-public-to-private/)
- [Route public traffic to private applications with Cloudflare (blog de Cloudflare, beta de junio de 2026)](https://blog.cloudflare.com/private-origins-dns-routing/)
- [Private origins, documentación de Cloudflare DNS](https://developers.cloudflare.com/dns/private-origins/)
- [Private network routing, documentación de Cloudflare DNS](https://developers.cloudflare.com/dns/private-origins/private-network-routing/)
- [Troubleshooting de private origins, documentación de Cloudflare DNS](https://developers.cloudflare.com/dns/private-origins/troubleshooting/)