← Все новости

Cloudflare открыла WAF и Workers для приватных origin: публичный трафик без публичного IPCloudflare opens WAF and Workers to private origins: public traffic without a public IP

Cloudflare сделала общедоступной маршрутизацию публичного трафика к приватным origin через Cloudflare One. Достаточно proxied A/AAAA-записи на приватный адрес, и WAF, bot management, кэш и Workers работают как для обычного сайта.Cloudflare has made public-to-private origin routing generally available over Cloudflare One. Point a proxied A/AAAA record at a private address and WAF, bot management, caching and Workers work as they do for a public site.

В июне Cloudflare запустила эту возможность в закрытой бете, теперь открыла её всем клиентам с подключением Cloudflare One. Идея простая: внутренние API, бэкенды AI-агентов, MCP-серверы и операционные инструменты не должны смотреть в интернет, но им всё равно нужно принимать запросы от партнёров, клиентов или агентов.

Раньше, чтобы поставить Cloudflare перед таким сервисом, приходилось либо публиковать IP и открывать порт, либо запускать cloudflared рядом с origin. В результате приватные приложения оставались без WAF, rate limiting и кэша, которые давно есть у публичных.

Что доступно

Нужно направить proxied A или AAAA-запись на приватный IP. Для RFC 1918, CGNAT 100.64.0.0/10 и ULA fc00::/7 режим включается автоматически и отключить его нельзя. Дальше работают:

  • WAF и managed rules;
  • bot management;
  • rate limiting;
  • кэширование;
  • transform и rewrite rules;
  • Workers.

Ограничения тоже есть: Argo Smart Routing и Dedicated CDN Egress IPs не поддерживаются, а health checks требуют Load Balancing. Для Cloudflare WAN коннектор на origin не нужен, для Mesh он работает внутри сети и может обслуживать несколько origin.

Что проверить при настройке

Кроме entitlement Private Origins и самого подключения Cloudflare One (IPsec, GRE, CNI, Tunnel или Mesh), нужен Unified Routing — кроме варианта с Tunnel. Если трафик идёт через WAN или Mesh, обязателен обратный маршрут для диапазонов Cloudflare: 100.64.0.0/12 для IPv4 и 2606:4700:cf1:5000::/64 для IPv6. В бете самой частой ошибкой был именно забытый return route: запросы уходили в таймаут и до origin не доходили.

Следующий шаг — трафик между приватными сетями. Закрытая бета запланирована на начало 2027 года.

Cloudflare launched this capability in closed beta in June and has now opened it to every customer with Cloudflare One connectivity. The premise is simple: internal APIs, AI agent backends, MCP servers and operational tools should not face the internet, yet they still need to accept requests from partners, customers or agents.

Previously, putting Cloudflare in front of such a service meant either exposing an IP and opening a port, or running cloudflared next to the origin. Private applications ended up without the WAF, rate limiting and caching that public ones have had for years.

What is available

Point a proxied A or AAAA record at a private IP. For RFC 1918, CGNAT 100.64.0.0/10 and ULA fc00::/7 ranges the mode turns on automatically and cannot be disabled. Then the following work as usual:

  • WAF and managed rules;
  • bot management;
  • rate limiting;
  • caching;
  • transform and rewrite rules;
  • Workers.

There are limits: Argo Smart Routing and Dedicated CDN Egress IPs are not supported, and health checks require Load Balancing. Cloudflare WAN needs no connector on the origin; Mesh runs a connector inside the network and can serve several origins.

What to check when setting up

Beyond the Private Origins entitlement and Cloudflare One connectivity (IPsec, GRE, CNI, Tunnel or Mesh), you need Unified Routing — except with Tunnel. If traffic goes over WAN or Mesh, a return route for Cloudflare’s ranges is mandatory: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. A missing return route was the most common beta failure: requests timed out and never reached the origin.

The next step is private-to-private traffic, targeted for a closed beta in early 2027.

Источники