Cloudflare Routes Public Traffic to Private IPs Without Exposing Them

A single boolean flag on a DNS record now decides whether Cloudflare’s proxy routes traffic over the public Internet or through your existing IPsec, GRE, or Cloudflare Mesh tunnel. That’s the entire surface area of the change, and it kills a decade of workarounds.

Public-to-private routing has historically meant either exposing a private origin to the Internet (defeating the point) or running connector software like cloudflared. Cloudflare’s Application Services for Private Origins removes both options as requirements. Toggle use_private_routing: true on a proxied A or AAAA record pointing to an RFC 1918 address, and Cloudflare’s WAF, rate limiting, bot management, caching, and transform rules all fire as normal. The only difference is the final hop: the request hits your private network over an existing tunnel, not the public Internet.

The API Surface Is a Single Attribute

The API change is minimal. POST /zones/{zone_id}/dns_records with "proxied": true and "use_private_routing": true — that’s it. Behind the scenes, Cloudflare’s Origin API returns metadata including a use_private_routing flag to the proxy infrastructure. When the proxy sees that flag, it hands the connection to Cloudflare’s private networking layer instead of attempting a direct TCP handshake to a private IP. The tunnel type (IPsec, GRE, CNI, Cloudflare Tunnel, Cloudflare Mesh) is abstracted away. Customers define routing through the dashboard or API, not per-product networking stacks.

Spectrum follows the same model for TCP/UDP services. Instead of creating a load-balancer pool as an intermediary, you specify a virtual_network_id directly in the Spectrum application config. Cloudflare validates that the private IP matches a route in your Cloudflare Tunnel before saving; if not, the API rejects the request. No public IP, no connector software, no load balancer.

Four Quadrants, One Control Plane

Cloudflare frames the traffic model as four combinations: public-to-public (their classic CDN), private-to-public (Cloudflare One), public-to-private (this launch), and private-to-private (next). The last quadrant—private users reaching private apps—is the target for post-GA. When that lands, an employee on Cloudflare One Client accessing wiki.company.internal will get the same WAF rules and bot management as a customer hitting a public API. The vision is a single security stack that doesn’t care where either endpoint sits.

Closed beta for eligible Enterprise customers starts today. GA is targeted for Q4 2026. You’ll need Cloudflare One connectivity (IPsec, GRE, CNI, or Cloudflare Mesh) and a return route for Cloudflare’s source IP range 100.64.0.0/12 in your private network. The toggle is automatic for RFC 1918, CGNAT (100.64.0.0/10), and ULA (FC00::/7) ranges; for public IPs reachable only through private tunnels, you enable it manually. This is the kind of incremental but brutal simplification that makes me wonder why it took so long to treat private IPs as first-class origin targets.

Source: Route public traffic to private applications with Cloudflare
Domain: blog.cloudflare.com