Pointing a proxied DNS record at a private IP now works in production: Cloudflare's services for private origins have graduated from closed beta to general availability. The proxy reaches the origin across whichever Cloudflare One connection the customer already runs, so the origin keeps its private address with no inbound firewall exception, and the application stack behaves as it does for public origins.
Services attached to a private hostname
Once a proxied A or AAAA record targets a private IP, Cloudflare applies the following on its network:
- WAF and managed rules
- Bot management
- Rate limiting
- Caching
- Transform and rewrite rules
- Workers
The gap the capability closes is a familiar one: internal APIs, AI agent backends, MCP servers and operational tools were never built to face the Internet, yet they still take requests from partners, customers or agents over it. Previously that meant exposing a public IP, opening a firewall port, or running cloudflared next to the origin — and private applications often went without the controls their public counterparts received.
The beta was invitation-only through account teams; the release opens access beyond that group. Some limitations stay in place. Argo Smart Routing and Dedicated CDN Egress IPs are not supported, and origin health checks depend on Load Balancing. The developer documentation lists the rest.
Connector requirements depend on the connectivity in use. Cloudflare WAN needs no software on the origin at all, while Cloudflare Mesh runs a connector inside the private network that can front multiple origins.
How the routing decision is made
Creating the record is most of the work. Private network routing switches on automatically for supported private ranges; if the origin sits on a public IP reachable only through the private network, the setting is enabled by hand. TLS termination, WAF, rules and caching continue to execute on Cloudflare's network as before.
Automatic activation and lock-in apply to RFC 1918 private IPv4, RFC 6598 CGNAT addresses (100.64.0.0/10) and RFC 4193 unique local IPv6 addresses (fc00::/7). For these ranges the setting cannot be disabled, and API attempts to turn it off return an error.
POST /zones/{zone_id}/dns_records
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"ttl": 300,
"proxied": true,
"private_routing": true
}
Internally, the proxy platform resolves where traffic for a hostname such as app.example.com should go by querying Cloudflare's Origin API. The answer carries metadata marking the destination as reachable only over a private path.
{
"zone_name": "example.com",
"ipv4_addresses": ["10.0.0.50"],
"private_routing": true
}The private_routing flag drives the fork in behaviour. Rather than dialing the private IP over the public Internet, the proxy passes the request to the private networking layer, which carries it over the customer's existing connectivity: IPsec, GRE, Cloudflare Tunnel, CNI or Cloudflare Mesh. The original beta post documents the routing layer in more depth.
Prerequisites for setup
- The Private Origins entitlement on the account, enabled by the account team.
- Cloudflare One connectivity via IPsec, GRE, CNI, Cloudflare Tunnel or Cloudflare Mesh.
- Unified Routing enabled, unless the connection is Cloudflare Tunnel, which does not require it. New and existing accounts can upgrade through their account team.
- For Cloudflare WAN or Cloudflare Mesh, a return route for Cloudflare's source ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6.
With those in place, create the proxied A or AAAA record for the private IP and verify that Use private network routing is on. Any WAF, cache and bot management configuration already associated with the hostname applies without modification. If requests time out and nothing reaches the origin, the return route is the first thing to check — the most common failure during the beta was a missing route for Cloudflare's source range. The developer documentation walks through the full procedure.
Beyond public-to-private
This release covers public traffic arriving at private origins. The next phase is private-to-private: users, services and AI agents on one private network reaching applications on another through Cloudflare's application services. Engineering work is under way with a closed beta targeted for early 2027; those interested should contact their account team.
The intent is parity of controls. An employee opening wiki.company.internal could get WAF, rate limiting and bot management, and service-to-service traffic between clouds and data centers could use the same protections even when neither end touches the public Internet.
