Cloudflare stellt Private Origins allgemein bereit: Proxy-Anfragen erreichen private Dienste über vorhandene Verbindungen

Am 30. Oktober 2026 hat Cloudflare angekündigt, dass seine Dienste für private Ursprungsserver allgemein verfügbar sind. Ein Websitebetreiber richtet einen proxierten DNS-Eintrag auf eine private IP-Adresse, und Cloudflare erreicht den Ursprungsserver über eine Cloudflare-One-Verbindung, die der Kunde schon hat. Der Ursprungsserver bleibt privat; laut Cloudflare funktionieren seine Web Application Firewall (WAF), das Caching, das Bot-Management und Workers wie bei öffentlichen Ursprungsservern.

Cloudflare sagt, es habe die Funktion im Juni als geschlossene Beta eingeführt, nachdem Kunden interne APIs, Backends von KI-Agenten, MCP-Server und Betriebswerkzeuge beschrieben hatten, die nicht für das Internet gebaut wurden, aber trotzdem Anfragen von Partnern, Kunden oder Agenten annehmen müssen. Vor der Beta hieß es, Cloudflare vor einen solchen Dienst zu stellen: eine öffentliche IP freigeben, einen Firewall-Port öffnen oder cloudflared neben dem Ursprungsserver betreiben. Diese Wege ließen private Anwendungen oft ohne die Schutzfunktionen öffentlicher Anwendungen. Während der Beta lief der Zugang über die Kundenbetreuung, und der Beitrag sagt, dass Cloudflare den Zugang heute über diese Gruppe hinaus öffnet. Auch die allgemeine Verfügbarkeit setzt die Berechtigung Private Origins im Konto voraus; der Beitrag fordert Kunden auf, sie bei ihrem Account-Team freischalten zu lassen.

Die Einrichtung ist ein proxierter A- oder AAAA-Eintrag. Die Einstellung „Use private network routing“ schaltet sich für private IPv4-Adressen nach RFC 1918, CGNAT-Adressen nach RFC 6598 (100.64.0.0/10) und Unique-Local-IPv6-Adressen nach RFC 4193 (fc00::/7) automatisch ein; für diese Bereiche lässt sie sich nicht ausschalten, ein Versuch über die API liefert einen Fehler. Hat ein Ursprungsserver eine öffentliche IP, die nur über das private Netz des Kunden erreichbar ist, kann man die Einstellung von Hand einschalten. In der API ist es ein zusätzliches Attribut an einem normalen DNS-Eintrag: private_routing mit dem Wert true. Cloudflares Proxy erfährt dieses Kennzeichen aus seiner Origin-API und verbindet sich dann nicht über das öffentliche Internet mit der Adresse, sondern übergibt die Anfrage an eine private Netzwerkschicht. Diese Schicht nutzt die vorhandene Anbindung des Kunden: IPsec, GRE, Cloudflare Tunnel, CNI oder Cloudflare Mesh. TLS-Terminierung, WAF, Regeln und Caching laufen weiter im Netz von Cloudflare. Der Ursprungsserver braucht keine eingehende Firewall-Ausnahme. Mit Cloudflare WAN ist keine Connector-Software auf dem Ursprungsserver nötig, und mit Cloudflare Mesh kann ein Connector im privaten Netz mehrere Ursprungsserver bedienen.

Vor dem Start braucht der Kunde die Berechtigung Private Origins, Cloudflare-One-Konnektivität über IPsec, GRE, CNI, Cloudflare Tunnel oder Cloudflare Mesh und aktiviertes Unified Routing im Konto, außer er verbindet sich über Cloudflare Tunnel, der es nicht braucht. Bei Cloudflare WAN oder Cloudflare Mesh muss er außerdem eine Rückroute für die Quelladressbereiche von Cloudflare einrichten: 100.64.0.0/12 für IPv4 und 2606:4700:cf1:5000::/64 für IPv6. Cloudflares Rat aus der Beta lautet: Laufen Anfragen in ein Timeout und kommt nichts beim Ursprungsserver an, zuerst die Rückroute prüfen, denn eine fehlende Route war der häufigste Einrichtungsfehler. Manche Funktionen werden nicht unterstützt: Argo Smart Routing und Dedicated CDN Egress IPs funktionieren mit privaten Ursprungsservern nicht, und Gesundheitsprüfungen des Ursprungsservers erfordern Load Balancing. Für die vollständige Liste der Einschränkungen verweist der Beitrag auf die Entwicklerdokumentation. Als wir diese Dokumentationsseite lasen, trug sie noch das Aktualisierungsdatum 7. Mai, die Kennzeichnung geschlossene Beta und den Hinweis „nur Enterprise“; Blogbeitrag und Dokumentationsseite stimmten also noch nicht überein.

Cloudflare sagt, der nächste Schritt sei Verkehr von privat zu privat, also Nutzer, Dienste und KI-Agenten in einem privaten Netz, die über Cloudflares Anwendungsdienste Anwendungen in einem anderen privaten Netz erreichen. Die Entwicklung läuft, eine geschlossene Beta ist für Anfang 2027 angepeilt. Für Teams, die IPsec, GRE, CNI, Tunnel oder Mesh bereits betreiben, ist die heutige Veröffentlichung ein Weg, WAF, Ratenbegrenzung und Caching vor interne Dienste zu stellen, ohne sie dem Internet auszusetzen, sofern Berechtigung und Rückroute vorhanden sind.