Cloudflare Private Origins: route a public hostname to a private IP — no public address required

Cloudflare entered closed beta on June 10 with Application Services for Private Origins, a feature that lets a proxied DNS A/AAAA record point to an RFC 1918 (or CGNAT / ULA) address and still get the full Cloudflare edge stack — WAF, DDoS mitigation, Bot Management, load balancing — on top. 1

Until now, proxying a private IP through Cloudflare produced Error 1002 ("DNS points to prohibited IP"). 2 Private Origins removes that constraint for Enterprise customers who already have a Cloudflare WAN connection in place.

コンテンツカードを読み込んでいます…

What it actually does

The core primitive is a single new toggle in the DNS record editor: "Use private network routing." 1

DNS record editor showing the "Use private network routing" toggle on an A record pointing to 10.1.0.1 — Cloudflare DNS dashboard — the `private_routing` toggle on an A record with a private IPv4 address. 3

Once enabled, inbound requests to dash.example.com travel through Cloudflare's global edge normally — TLS termination, WAF inspection, cache — and then the origin-fetch leg travels back through the customer's existing encrypted tunnel to reach 10.1.0.1 inside their private network. The origin never needs a public IP, an inbound firewall rule, or any agent software installed on the host. 4

At the API level, the private_routing field on a DNS record defaults to true for any RFC 1918, CGNAT (100.64.0.0/10), or ULA (fc00::/7) address — it is auto-detected. Setting it to false on a private-IP record returns an error; the field is unsupported on non-A/AAAA record types. 3 When a hostname has multiple A/AAAA records and at least one has private routing enabled, all records for that name travel via private routing.

How the tunnel gets there: transport options

Getting Cloudflare's edge to talk to your private network is the harder half of the setup. Private Origins doesn't add a new tunnel type — it reuses whatever Cloudflare WAN connectivity you already have. The four supported transports are: 4 1

Transport	How it connects	Redundancy model	Best fit
IPsec anycast	Bidirectional encrypted tunnels to Cloudflare's anycast IPs	Requires two tunnels with prioritized static routes for failover	On-prem or cloud networks with a hardware/software firewall that speaks IKEv1/v2
GRE	Unencrypted GRE over Cloudflare's anycast network	Same dual-tunnel + static route model as IPsec	Environments where encryption is handled at a different layer (MPLS, MACsec, etc.)
CNI (Cloud Network Interconnect)	Direct Layer 2/3 cross-connects at carrier-neutral facilities	Carrier-level redundancy built in	Colocation deployments that already have a Cloudflare cross-connect
Cloudflare Mesh	Software-defined overlay using Cloudflare's own WireGuard-based mesh	Mesh inherits its own redundancy	Multi-site or all-cloud setups already enrolled in Cloudflare One / Magic WAN

One mandatory configuration note: Automatic return routing must be disabled for private origins traffic. Return routing was designed for public-to-public traffic patterns; leaving it on causes asymmetric routing that breaks origin reachability. Health checks must use the defaults (type=reply, direction=bidirectional, rate=mid) to correctly track tunnel liveness. 4

Five prerequisites before you can enable it

The docs list the requirements explicitly, and they all point at the same thing: this is an add-on to an existing Enterprise WAN deployment, not a standalone feature. 4

Active Cloudflare WAN subscription
Account-level Private Origins permission (separate from standard DNS edit permissions — your team needs to request it)
At least two anycast IPsec tunnels (for the IPsec path) configured with bidirectional health checks
Static routes with priority ordering so traffic fails over correctly between tunnels
Cloudflare Source IP configured to a private range (e.g., 100.64.0.0/12) so origin servers accept the return traffic

Spectrum and Workers VPC also gain private-origin support — Spectrum uses the virtual_network_id field, and Workers VPC bindings use the same private_routing mechanism — though dedicated documentation pages for both were not yet live as of June 12. 1

Where this sits in Cloudflare's connectivity matrix

Cloudflare's announcement maps Private Origins to one cell of a four-quadrant connectivity matrix — Public User × Private Origin — which is labeled "Today's Release": 1

Public → Public: classic Cloudflare CDN / WAF (unchanged)
Public → Private: Private Origins (this release)
Private → Public: Cloudflare One / Gateway (existing egress security)
Private → Private: on the roadmap, no timeline given

The blog post from Cloudflare's Enrique Somoza, Steve Welham, and Shruti Mittal frames this as a philosophical shift: "Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit." 1 Until Private Origins, teams running internal apps had to choose between exposing the app publicly (to get Cloudflare's edge services) or keeping it private (and losing those services). Private Origins removes that trade-off for the inbound path.

The architectural reading from @0x_codex captures the shift well: "private apps are starting to get the same edge security/performance layer as public websites — without first pretending they are public." 5

コンテンツカードを読み込んでいます…

How it differs from Cloudflare Tunnel and WARP Connector

Private Origins, Cloudflare Tunnel, and WARP Connector all solve "how do I route traffic into a private network without exposing a public IP" — but they target different traffic directions and operator models:

	Private Origins (this release)	Cloudflare Tunnel (`cloudflared`)	WARP Connector
Traffic direction	Public internet → private origin	Public internet → private origin	Private user → private resource
Requires agent on origin host	No	Yes (`cloudflared` daemon)	Yes (WARP Connector daemon)
DNS record proxy	Standard Cloudflare proxied A/AAAA	CNAME to `.cfargotunnel.com`	Via Cloudflare One routing
Transport	IPsec / GRE / CNI / Mesh (WAN-level)	mTLS over HTTPS (host-level)	WireGuard (host-level)
Operational scope	Network-level (routes entire IP ranges)	Application-level (per-app or per-hostname)	User-level (device-to-resource)
Plan requirement	Enterprise + Cloudflare WAN	Free and up	Cloudflare One (Zero Trust)
GA status	Q4 2026 (currently closed beta)	GA	GA

The practical difference: if you already run Magic WAN / Cloudflare WAN at the network layer and want your internal services to inherit edge protection without touching each host, Private Origins is the right tool. If you're a team of any size that wants to expose a single internal app to the internet with minimal infrastructure, cloudflared Tunnel is faster to set up and available today on any plan.

How it compares to cloud-native private endpoints

AWS PrivateLink, GCP Private Service Connect, and Azure Private Link all solve an adjacent problem: private service-to-service connectivity within a single cloud. They don't need Cloudflare (or any CDN), but they are cloud-locked.

	Cloudflare Private Origins	AWS PrivateLink	GCP Private Service Connect	Azure Private Link
Cross-cloud / hybrid	✅ Any IPsec/GRE-capable infra	❌ AWS-only	❌ GCP-only	❌ Azure-only
Public traffic ingress	✅ Yes (core use case)	❌ No (service-to-service only)	❌ No	❌ No
Edge services (WAF, DDoS)	✅ Full Cloudflare stack	❌ No	❌ No	❌ No
Requires agent	No	No	No	No
Pricing	TBD (closed beta)	$0.01/GB + $0.01/hr/ENI 6	~$0.01/hr/endpoint (consumer) 7	Per-hour + per-GB (JS-rendered, not extractable) 8
GA	Q4 2026	GA	GA	GA

The cloud-native private endpoint services are not direct competitors — they solve private east-west connectivity, not public north-south ingress. If your concern is keeping service-to-service calls inside AWS, PrivateLink is the right answer. If your concern is routing public user traffic to an origin that shouldn't have a public IP, Private Origins is the first cloud-agnostic option that also carries full WAF/DDoS capability.

Migrate now or just watch?

Just watch — for most teams. The closed beta is Enterprise-only, requires an active Cloudflare WAN subscription, and won't reach GA until Q4 2026. 1 9 The community response reflects this: the official Reddit cross-post had 6 upvotes and one substantive comment at the time of writing, with the top commenter noting it "sounds like it's only going to be for Enterprise users." 10

Worth putting on your radar now if:

You run internal apps (dashboards, APIs, staging environments) that currently need a public IP solely to sit behind Cloudflare's WAF and DDoS protection.
You're already on Cloudflare Enterprise with Magic WAN / WAN connections in place — the delta to Private Origins is just the account-level permission and DNS toggle.
You operate in a regulated environment where exposing an origin IP, even behind Cloudflare, is a compliance risk.

What to watch before committing:

Pricing: not yet disclosed. Given the Enterprise prerequisite and WAN subscription requirement, expect a meaningful add-on cost.
Private-to-private routing: on the roadmap, but no date. Until it ships, Private Origins only covers the inbound public-traffic use case — internal service mesh routing still needs another approach.
Spectrum and Workers VPC integration: the blog mentions both, but the dedicated documentation pages were returning 404 as of this writing. 1

If you're already in the Cloudflare Enterprise tier with WAN, contact your account team now — closed beta access is invite-based, and early feedback typically shapes what makes it into GA.

Cover image from the Cloudflare blog post