Cloudflare otwiera private origins na GA: prywatne API i backendy AI za WAF-em bez publicznego IP

Cloudflare ogłosił 30 października 2026 roku ogólną dostępność (GA) funkcji „services for private origins”. W praktyce oznacza to, że proxied rekord DNS typu A lub AAAA może wskazywać prywatny adres IP, a Cloudflare dotrze do tego originu przez istniejące połączenie Cloudflare One — bez publicznego adresu IP i bez otwierania portu w firewallu. Funkcja wyszła z zamkniętej bety, w której pozostawała od czerwca 2026 roku.

Zmiana dotyczy przede wszystkim zespołów, które utrzymują wewnętrzne API, backendy agentów AI, serwery MCP i narzędzia operacyjne potrzebne partnerom, klientom lub automatom, ale nieprzeznaczone do bezpośredniej ekspozycji w internecie. Dotąd postawienie Cloudflare przed takim serwisem wymagało publicznego IP, reguły otwierającej port albo uruchomienia cloudflared obok originu. Efektem było to, że aplikacje prywatne nie korzystały z tych samych zabezpieczeń co publiczne — WAF, bot management, rate limiting, cache czy Workers. Teraz mają działać tak samo, przy zachowaniu prywatnego adresu originu.

Co dokładnie jest dostępne

Producent deklaruje, że po wskazaniu proxied rekordu A lub AAAA na prywatny adres IP usługi aplikacyjne Cloudflare działają jak dla publicznych originów. W komunikacie wymieniono:

• WAF i managed rules,
• bot management,
• rate limiting,
• caching,
• reguły transformacji i rewrite,
• Workers.

To deklaracja producenta. Nie mamy w materiale dowodowym niezależnych testów potwierdzających, że każde z tych zachowań jest identyczne jak dla publicznych originów w każdym scenariuszu — warto to traktować jako punkt wyjścia do własnych testów akceptacyjnych, a nie jako gwarancję.

Ograniczenia, które producent wymienia wprost

Cloudflare przyznaje, że część funkcji nie jest wspierana. To nie są drobiazgi — przy niektórych architekturach mogą przesądzić o sensie wdrożenia:

Ograniczenie	Znaczenie operacyjne
Brak Argo Smart Routing	Nie skorzystasz z optymalizacji tras Argo dla ruchu do prywatnego originu. Jeśli Argo było elementem modelu wydajności, trzeba to przeliczyć.
Brak Dedicated CDN Egress IP	Jeśli origin lub zapora po drodze filtruje ruch po adresach wyjściowych Cloudflare, dedykowane zakresy egress nie są dostępne dla tej funkcji.
Health checks originu wymagają Load Balancing	Bez Load Balancing nie ma wbudowanych health checków originu. Monitoring dostępności trzeba zorganizować inaczej.

Producent odsyła po pełną listę ograniczeń do dokumentacji deweloperskiej. W materiale dowodowym tej pełnej listy nie ma — nie uzupełniamy jej domysłami.

Tło techniczne prostym językiem

W klasycznym modelu Cloudflare pełni rolę odwrotnego proxy: użytkownik trafia na adresy brzegowe Cloudflare, tam kończy się TLS, przechodzą reguły WAF i cache, a potem Cloudflare łączy się z originem. Problem w tym, że ten ostatni krok wymagał, by origin był osiągalny z internetu — czyli miał publiczny adres albo otwarty port.

Private origins zmienia ten ostatni odcinek. Cloudflare nadal obsługuje ruch na swoim brzegu, ale połączenie do originu odbywa się przez prywatną sieć klienta, zbudowaną na Cloudflare One. Origin zachowuje prywatny adres IP i nie potrzebuje wyjątku w firewallu dla ruchu przychodzącego z internetu.

Mechanizm działa na poziomie rekordów DNS. Gdy rekord jest proxied i wskazuje prywatny adres, platforma proxy Cloudflare odpytuje wewnętrzne API originu o metadane docelowego hosta. Odpowiedź zawiera informację, że cel ma być osiągnięty ścieżką prywatną. Wtedy zamiast próby bezpośredniego połączenia z prywatnym adresem przez internet, żądanie trafia do warstwy sieci prywatnej, która prowadzi je przez istniejące połączenie klienta — IPsec, GRE, Cloudflare Tunnel, CNI lub Cloudflare Mesh.

Automatyczne włączanie routingu prywatnego

Dla określonych zakresów adresów routing prywatny włącza się sam. Chodzi o:

• RFC 1918 — prywatne adresy IPv4,
• RFC 6598 — przestrzeń CGNAT 100.64.0.0/10,
• RFC 4193 — unikalne adresy lokalne IPv6 fc00::/7.

W tych zakresach nie da się routingu prywatnego wyłączyć — próba zrobienia tego przez API zwraca błąd. Jeśli origin ma publiczny adres IP osiągalny wyłącznie przez sieć prywatną, ustawienie można włączyć ręcznie.

Jak to wygląda w API

Dla zespołów automatyzujących wdrożenia private routing to dodatkowy atrybut na standardowym rekordzie DNS. Przykład z komunikatu producenta pokazuje rekord typu A z polem private_routing ustawionym na true, obok proxied i standardowych pól TTL oraz nazwy. To ważne z perspektywy infrastruktury jako kodu: nie trzeba nowego typu zasobu, wystarczy rozszerzenie istniejącego.

Wymagania wdrożeniowe

Producent wymienia cztery warunki wstępne:

1. Uprawnienie Private Origins na koncie — trzeba poprosić zespół konta o jego włączenie.
2. Łączność Cloudflare One przez IPsec, GRE, CNI, Cloudflare Tunnel lub Cloudflare Mesh.
3. Unified Routing włączony na koncie — z wyjątkiem połączenia przez Cloudflare Tunnel, które go nie wymaga. Nowe i istniejące konta mogą przejść na Unified Routing przez zespół konta.
4. Dla Cloudflare WAN lub Mesh: trasa powrotna do zakresów źródłowych Cloudflare — 100.64.0.0/12 dla IPv4 i 2606:4700:cf1:5000::/64 dla IPv6.

Różnica między WAN a Mesh jest istotna przy projektowaniu. W Cloudflare WAN nie trzeba instalować oprogramowania connectora na originie. W Cloudflare Mesh connector działa w sieci prywatnej i może obsługiwać wiele originów — to rozwiązanie bardziej elastyczne, ale wymaga utrzymania elementu w sieci.

Realne konsekwencje dla organizacji

Najważniejsza konsekwencja jest architektoniczna, nie kosmetyczna. Do tej pory zespół miał zwykle trzy drogi: wystawić publiczny IP z restrykcjami firewall, uruchomić cloudflared obok aplikacji albo zrezygnować z ochrony aplikacyjnej. Private origins dokłada czwartą opcję, w której ochrona aplikacyjna działa, a origin pozostaje nieosiągalny z internetu bez pośrednictwa Cloudflare.

Druga konsekwencja dotyczy spójności polityk. Skoro WAF, reguły i cache działają na tym samym hostname tak samo jak dla publicznych aplikacji, zespół może utrzymywać jeden zestaw reguł zamiast dwóch równoległych modeli — jednego dla tego, co publiczne, i drugiego dla tego, co „jakoś” chronione. To upraszcza audyt i ogranicza liczbę wyjątków.

Trzecia konsekwencja jest organizacyjna. Włączenie funkcji zależy od uprawnienia Private Origins i od Unified Routing, a te wymagają kontaktu z zespołem konta. To nie jest przełącznik w panelu, który każdy administrator włączy samodzielnie w piątek po południu. W praktyce oznacza to zależność od procesu handlowego i od gotowości sieci do zmiany routingu.

Czego materiał dowodowy nie rozstrzyga

W komunikacie nie ma informacji o cenie uprawnienia Private Origins ani o tym, czy Unified Routing wiąże się z dodatkowymi kosztami. Nie ma też danych o limitach przepustowości, opóźnieniach dodawanych przez warstwę prywatną ani o zachowaniu funkcji w scenariuszach awarii łączności Cloudflare One. Te elementy trzeba potwierdzić w dokumentacji i u swojego opiekuna konta przed podjęciem decyzji.

Scenariusze ryzyka

Private origins nie eliminuje ryzyka — przesuwa je w inne miejsce. Poniżej najważniejsze obszary, które warto przeanalizować przed wdrożeniem.

1. Błędna trasa powrotna

Producent wprost pisze, że w becie najczęstszą przyczyną problemów były żądania kończące się timeoutem, gdy nic nie docierało do originu — z powodu braku trasy powrotnej dla zakresu źródłowego Cloudflare. To pierwszy punkt do sprawdzenia przy każdym „nie działa”.

2. Zależność od łączności Cloudflare One

Ruch do originu idzie przez istniejące połączenie. Jeśli to połączenie padnie, aplikacja staje się niedostępna dla ruchu z zewnątrz, nawet jeśli sam origin działa. To trzeba uwzględnić w planach ciągłości działania i w monitoringu — awaria łącza ma teraz bezpośredni wpływ na dostępność usługi biznesowej.

3. Mylne poczucie, że „prywatne = bezpieczne”

Origin pozostaje prywatny, ale przyjmuje ruch przetworzony przez Cloudflare. Reguły WAF, rate limiting i bot management nadal trzeba skonfigurować — sama zmiana routingu nie chroni przed niczym. Zespoły, które traktują włączenie funkcji jako zamknięcie tematu bezpieczeństwa, popełniają podstawowy błąd.

4. Luki w monitoringu

Bez Load Balancing nie ma health checków originu po stronie Cloudflare. Jeśli dotąd monitoring opierał się na tych mechanizmach, trzeba go zastąpić lub uzupełnić zewnętrznym sprawdzaniem dostępności przez publiczny hostname.

5. Nieoczekiwane zachowanie dla zakresów CGNAT

Dla 100.64.0.0/10 routing prywatny włącza się automatycznie i nie da się go wyłączyć. Organizacje, które używają tej przestrzeni w nietypowy sposób, powinny sprawdzić, czy nie koliduje to z ich adresacją.

Jak sprawdzić, czy problem dotyczy Twojej organizacji

Poniższe pytania pomagają szybko ocenić, czy private origins jest w ogóle tematem do rozważenia.

• Czy utrzymujesz wewnętrzne API lub serwisy, do których muszą sięgać partnerzy, klienci albo automaty, ale które nie powinny być publicznie osiągalne?
• Czy masz backendy agentów AI lub serwery MCP, które nie były projektowane pod ekspozycję w internecie?
• Czy dziś wystawiasz takie usługi przez publiczny IP z restrykcjami firewall albo przez cloudflared?
• Czy korzystasz już z Cloudflare One — przez IPsec, GRE, CNI, Tunnel lub Mesh?
• Czy używasz Argo Smart Routing lub Dedicated CDN Egress IP w sposób, który byłby krytyczny dla tej usługi?
• Czy Twój monitoring originu opiera się na health checkach Cloudflare wymagających Load Balancing?

Jeśli na pierwsze trzy pytania odpowiadasz twierdząco, a na kolejne nie masz twardych „nie”, funkcja jest warta analizy. Jeśli korzystasz z Argo lub dedykowanych adresów egress w sposób krytyczny, najpierw policz, co tracisz.

Plan reakcji krok po kroku

1. Inwentaryzacja. Wypisz hostname’y, które dziś są wystawione przez publiczny IP lub cloudflared, i oceń, które z nich kwalifikują się do przeniesienia.
2. Weryfikacja wymagań. Potwierdź u opiekuna konta dostępność uprawnienia Private Origins i stan Unified Routing. Ustal, czy łączność idzie przez WAN, Mesh czy Tunnel.
3. Projekt trasy powrotnej. Dla WAN i Mesh zaplanuj trasy do 100.64.0.0/12 i 2606:4700:cf1:5000::/64. Zapisz to w dokumentacji sieci, nie tylko w głowie inżyniera.
4. Środowisko testowe. Zacznij od jednego, niekrytycznego hostname’u. Sprawdź, czy żądania docierają do originu, czy WAF i cache działają zgodnie z oczekiwaniami.
5. Testy negatywne. Sprawdź zachowanie przy zerwaniu łączności Cloudflare One, przy błędnej trasie powrotnej i przy originie niedostępnym.
6. Monitoring. Zapewnij zewnętrzne sprawdzanie dostępności przez publiczny hostname, jeśli rezygnujesz z health checków Cloudflare.
7. Migracja etapowa. Przenoś hostname’y partiami, z możliwością szybkiego wycofania przez zmianę rekordu DNS.
8. Dokumentacja i przekazanie. Opisz konfigurację, wymagania i punkty kontrolne tak, by zespół dyżurny wiedział, gdzie szukać przyczyny problemu.

Typowe błędy

• Pominięcie trasy powrotnej. Najczęstsza przyczyna timeoutów według producenta.
• Traktowanie funkcji jako zamiennika konfiguracji WAF. Routing prywatny nie konfiguruje reguł za zespół.
• Brak testu awarii łączności. Zespół odkrywa zależność dopiero przy pierwszym incydencie.
• Próba wyłączenia routingu prywatnego dla zakresów RFC 1918, CGNAT lub ULA. API zwróci błąd — to nie usterka, to projekt.
• Zalożenie, że Argo i dedykowane egress IP będą działać. Nie będą — trzeba to uwzględnić w projekcie.
• Oczekiwanie health checków bez Load Balancing. Ich nie ma.
• Wdrożenie bez uzgodnienia z zespołem sieci. Zmiana routingu dotyka infrastruktury, nie tylko konfiguracji aplikacji.

Działania krótkoterminowe i długoterminowe

Krótkoterminowo (najbliższe tygodnie)

• Zidentyfikuj kandydatów do migracji i oceń ich krytyczność.
• Potwierdź uprawnienia i stan Unified Routing u opiekuna konta.
• Przeprowadź pilotaż na jednym hostname w środowisku testowym.
• Zweryfikuj, czy obecny monitoring przetrwa rezygnację z health checków Cloudflare.

Długoterminowo (kwartał i dalej)

• Ujednolić polityki WAF i rate limiting dla hostname’ów publicznych i prywatnych.
• Wpisz zależność od Cloudflare One do planów ciągłości działania.
• Przygotuj się na zapowiedziany kierunek: ruch prywatno-prywatny. Producent deklaruje prace nad scenariuszem, w którym użytkownicy, usługi i agenci AI z sieci prywatnych sięgają aplikacji w innych sieciach prywatnych przez usługi aplikacyjne Cloudflare, z zamkniętą betą planowaną na początek 2027 roku. To deklaracja, nie fakt — nie planuj na jej podstawie zobowiązań.
• Uwzględnij private origins w standardzie wdrożeniowym nowych usług wewnętrznych.

Checklista przed wdrożeniem

Obszar	Do potwierdzenia
Uprawnienia	Private Origins aktywne; Unified Routing włączony (lub połączenie przez Tunnel)
Łączność	IPsec / GRE / CNI / Tunnel / Mesh działające i monitorowane
Routing	Trasy powrotne do 100.64.0.0/12 i 2606:4700:cf1:5000::/64 dla WAN i Mesh
DNS	Proxied rekord A/AAAA na prywatny adres; pole private_routing ustawione zgodnie z potrzebą
Bezpieczeństwo	Reguły WAF, rate limiting i bot management zaplanowane dla nowego hostname
Wydajność	Wpływ braku Argo Smart Routing oceniony
Egress	Wpływ braku Dedicated CDN Egress IP oceniony
Monitoring	Zewnętrzne sprawdzanie dostępności; plan na brak health checków bez Load Balancing
Ciągłość działania	Scenariusz awarii łączności Cloudflare One opisany i przetestowany
Wycofanie	Procedura powrotu do poprzedniej konfiguracji przećwiczona

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy lub osoba odpowiedzialna za ryzyko powinna przede wszystkim zrozumieć, że ta zmiana nie jest „kolejną funkcją w panelu”. Przeniesienie wewnętrznych API i backendów agentów AI za Cloudflare oznacza, że dostępność tych usług zaczyna zależeć od łączności Cloudflare One. To decyzja o architekturze, nie o konfiguracji. Warto zapytać zespół o trzy rzeczy: które usługi kwalifikują się do migracji, co się stanie z nimi przy awarii łącza oraz czy obecny monitoring to wychwyci. Odpowiedzi powinny być na piśmie, nie w prezentacji.

Administrator lub inżynier odpowiedzialny za wdrożenie powinien zacząć od inwentaryzacji hostname’ów i weryfikacji wymagań u opiekuna konta. Następnie — od pilotażu na jednym, niekrytycznym serwisie, z jawnie zdefiniowanym kryterium sukcesu i procedurą wycofania. Kluczowe jest sprawdzenie trasy powrotnej przed pierwszym testem, bo to najczęstsza przyczyna problemów wskazana przez producenta. Dopiero po udanym pilocie warto planować migrację etapową, z podziałem na partie i z monitoringiem zewnętrznym od pierwszego dnia.

Osobno warto ustalić, kto w organizacji odpowiada za reguły WAF dla nowych hostname’ów. Private origins przenosi ruch pod ochronę Cloudflare, ale nie tworzy reguł. Bez właściciela polityk aplikacyjnych funkcja da prywatność bez ochrony — a to nie jest to, po co się ją wdraża.

Praktyczna weryfikacja konfiguracji po wdrożeniu

Po utworzeniu proxied rekordu A lub AAAA wskazującego na prywatny adres IP weryfikacja powinna przebiegać warstwowo — od DNS, przez routing, po zachowanie usług aplikacyjnych. Poniższa kolejność pozwala odizolować problem, zanim obejmie ruch produkcyjny.

Warstwa DNS i sygnału routingu

1. Sprawdź przez API, że rekord ma ustawione proxied: true oraz private_routing: true. Dla zakresów RFC 1918, CGNAT (100.64.0.0/10) i ULA (fc00::/7) flaga włącza się automatycznie — potwierdź to odczytem rekordu, nie założeniem.
2. Upewnij się, że adres w polu content mieści się w zakresie obsługiwanym automatycznie albo — w przypadku publicznego IP osiągalnego wyłącznie przez sieć prywatną — że flaga została włączona ręcznie.
3. Zapisz w dokumentacji wartość ttl i typ rekordu. Przy migracji etapowej TTL decyduje o szybkości wycofania.

Warstwa routingu prywatnego

• Dla Cloudflare WAN i Cloudflare Mesh potwierdź istnienie trasy powrotnej do 100.64.0.0/12 (IPv4) oraz 2606:4700:cf1:5000::/64 (IPv6).
• Dla Cloudflare Tunnel sprawdź, że łączność działa bez Unified Routing — Tunnel nie wymaga tego mechanizmu.
• Ustal, który wariant łączności jest używany: IPsec, GRE, CNI, Cloudflare Tunnel czy Cloudflare Mesh. W Mesh connector działa w sieci prywatnej i może obsługiwać wiele originów; w WAN connector na originie nie jest potrzebny.

Warstwa aplikacyjna

Wyślij żądanie przez publiczny hostname i potwierdź, że dociera do originu. Następnie sprawdź, czy WAF, managed rules, rate limiting, caching, reguły transform i rewrite oraz Workers zachowują się tak samo jak dla originu publicznego. Istniejąca konfiguracja WAF, cache i bot management applies się do hostname’u bez dodatkowych zmian — ale to trzeba zweryfikować empirycznie, nie na podstawie założenia.

Monitoring po wdrożeniu

Private origins zmienia punkt, w którym można obserwować dostępność usługi. Cloudflare nadal terminuje TLS i przetwarza żądania, ale origin pozostaje w sieci prywatnej, a health checki originu wymagają Load Balancing. Bez niego monitoring trzeba oprzeć na innych mechanizmach.

Co monitorować obowiązkowo

• Dostępność przez publiczny hostname — zewnętrzne sprawdzanie z lokalizacji poza siecią organizacji, z progiem alertu krótszym niż czas reakcji zespołu dyżurnego.
• Opóźnienia i błędy na poziomie Cloudflare — osobno dla żądań obsłużonych i odrzuconych przez WAF oraz rate limiting, aby odróżnić blokadę polityki od awarii łączności.
• Stan łączności Cloudflare One — IPsec, GRE, CNI, Tunnel lub Mesh, z alertem na zerwanie sesji.
• Poprawność trasy powrotnej — okresowy test syntetyczny wysyłany przez publiczny hostname z weryfikacją, że żądanie dotarło do originu.

Sygnały charakterystyczne dla tej konfiguracji

Timeouty przy braku jakiegokolwiek ruchu na originie to według producenta najczęstszy objaw błędnej trasy powrotnej. W takim przypadku kolejność diagnozy jest stała: najpierw trasa powrotna do 100.64.0.0/12 i 2606:4700:cf1:5000::/64, potem stan łączności Cloudflare One, na końcu konfiguracja aplikacji. Monitoring powinien rozróżniać te trzy kategorie, inaczej dyżurny zaczyna od niewłaściwego końca.

Monitoring a brak health checków

Jeśli dotychczasowa obserwacja opierała się na health checkach Cloudflare wymagających Load Balancing, po wdrożeniu trzeba ją zastąpić lub uzupełnić. Warto zdefiniować dla każdego zmigrowanego hostname’u jawny próg: ile kolejnych nieudanych prób oznacza incydent i kto jest powiadamiany. Bez tego zespół dowie się o awarii od partnera lub klienta.

Checklista weryfikacyjna po pierwszym tygodniu

Pilotaż na jednym, niekrytycznym hostname jest punktem wyjścia, nie końcem. Po pierwszym tygodniu eksploatacji warto przejść przez poniższą listę, zanim ruszy migracja etapowa.

1. Czy potwierdzono odczytem API, że rekord ma private_routing: true i proxied: true?
2. Czy dla WAN lub Mesh trasa powrotna do 100.64.0.0/12 i 2606:4700:cf1:5000::/64 jest zapisana w dokumentacji sieci?
3. Czy przetestowano scenariusz zerwania łączności Cloudflare One i zapisano wynik?
4. Czy przetestowano origin niedostępny oraz błędną trasę powrotną?
5. Czy WAF, rate limiting i bot management mają przypisanego właściciela i działają na nowym hostname?
6. Czy monitoring zewnętrzny działa od pierwszego dnia i czy alerty docierają do dyżurnego?
7. Czy oceniono wpływ braku Argo Smart Routing i Dedicated CDN Egress IP na wydajność i adresy wyjściowe?
8. Czy procedura wycofania przez zmianę rekordu DNS została przećwiczona z uwzględnieniem TTL?
9. Czy zespół sieci zatwierdził zmianę routingu i zna punkt kontaktu po stronie Cloudflare?
10. Czy dla zakresów CGNAT sprawdzono, że automatyczne włączenie routingu prywatnego nie koliduje z adresacją organizacji?

Checklista przed migracją kolejnych partii hostname’ów

Migracja etapowa ma sens tylko wtedy, gdy każda partia przechodzi te same bramki jakości co pilotaż. Poniższa lista porządkuje warunki wejścia dla kolejnych grup.

• Hostname ma zdefiniowane kryterium sukcesu i osobę odpowiedzialną za decyzję o kontynuacji lub wycofaniu.
• Reguły WAF, rate limiting i bot management są zaplanowane przed zmianą DNS, nie po niej.
• Zewnętrzne sprawdzanie dostępności jest aktywne przed przełączeniem ruchu.
• Scenariusz awarii łączności Cloudflare One jest opisany i przetestowany dla tej partii.
• Wpływ braku Argo Smart Routing i Dedicated CDN Egress IP został oceniony dla każdego hostname’u osobno.
• Procedura powrotu jest znana zespołowi dyżurnemu i nie wymaga eskalacji do architekta.
• Zmiana jest uzgodniona z zespołem sieci, a nie tylko z zespołem aplikacji.

Dopiero po przejściu obu checklist warto planować kolejne partie. Private origins jest ogólnie dostępne, ale to nie zwalnia z dyscypliny wdrożeniowej — zwłaszcza że dostępność usług zaczyna zależeć od łączności Cloudflare One, a nie wyłącznie od originu.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

1. Cloudflare services for private origins is now generally available (blog.cloudflare.com)

Zdjęcie wyróżniające: Brett Sayles / Pexels.