Cloudflare Tunnel na VPS bez otwierania portów

Czym jest Cloudflare Tunnel i co w praktyce oznacza brak otwartych portów

Cloudflare Tunnel uruchamia na serwerze VPS niewielki proces (daemon) o nazwie cloudflared. Proces ten nawiązuje połączenie wychodzące do infrastruktury Cloudflare i utrzymuje je w stanie aktywnym. Żądania kierowane na nazwę hosta trafiają do węzła brzegowego Cloudflare, skąd są przesyłane dalej przez istniejące połączenie. Dzięki temu nie ma potrzeby nawiązywania połączeń przychodzących bezpośrednio do serwera.

Krok, którego pomija większość poradników: sama instalacja tunelu nie zamyka żadnych portów. Jeśli porty 80 i 443 pozostają otwarte w zaporze sieciowej (firewall), a aplikacja nadal nasłuchuje na 0.0.0.0, dodano jedynie drugą drogę dostępu zamiast zastąpić pierwszą. Adres IP serwera źródłowego pozostaje osiągalny, co pozwala każdemu, kto go pozna, na ominięcie ochrony Cloudflare. Zamknięcie tych portów jest czynnością wykonywaną ręcznie i to właśnie ten krok sprawia, że cała wcześniejsza konfiguracja ma sens.

Proces cloudflared wymaga dostępu wychodzącego do region1.v2.argotunnel.com oraz region2.v2.argotunnel.com na porcie 7844. Wykorzystuje on protokół UDP dla QUIC, a w razie potrzeby przełącza się na TCP dla HTTP/2. W sieciach z filtrowaniem ruchu wychodzącego należy zezwolić na oba protokoły lub wymusić użycie ścieżki TCP za pomocą flagi --protocol http2.

Przed rozpoczęciem

• Domena dodana do konta Cloudflare, korzystająca z serwerów nazw Cloudflare dla danej strefy. cloudflared tunnel route dns zapisuje rekordy w tej strefie, dlatego musi ona istnieć wcześniej.
• Dostęp wychodzący z VPS na porcie 7844, zarówno dla protokołu UDP, jak i TCP.
• Aplikacja nasłuchująca lokalnie, nawet jeśli na potrzeby pierwszego testu jest to tylko python3 -m http.server 8080.
• sudo zainstalowane na serwerze oraz otwarta druga sesja SSH przed przystąpieniem do konfiguracji firewalla.

Instalacja cloudflared w systemie Ubuntu lub Debian

Firma Cloudflare dołącza pakiet .deb do każdego wydania cloudflared, więc instalacja sprowadza się do jednego pobrania i jednego wywołania dpkg.

curl -fsSL -o /tmp/cloudflared.deb \
  https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i /tmp/cloudflared.deb
cloudflared --version

Jeśli nie masz pewności, jaka to architektura systemu, najpierw uruchom dpkg --print-architecture. W przypadku architektury 64-bit ARM nazwa pliku kończy się na arm64, a nie amd64; poza tym nic się nie zmienia. Wyświetlenie ciągu wersji przez cloudflared --version jest jedynym potwierdzeniem wymaganym przed przejściem dalej.

Pakiet zainstalowany w ten sposób znajduje się poza ścieżką aktualizacji apt, więc apt-get upgrade nigdy go nie zaktualizuje, a dbanie o nowe wersje staje się Twoim zadaniem. Polecenie sudo cloudflared update pobiera najnowsze wydanie i zastępuje plik binarny w miejscu; gdy usługa już istnieje, wykonaj po nim sudo systemctl restart cloudflared, aby uruchomiony proces korzystał z nowej wersji pliku binarnego. Uwzględnij to w harmonogramie prac konserwacyjnych, ponieważ demon tunelu jest oprogramowaniem wystawionym na działanie Internetu, mimo że nie otwiera żadnego portu.

Logowanie i tworzenie nazwanego tunelu

cloudflared tunnel login

Na serwerze VPS bez interfejsu graficznego przeglądarka nie uruchomi się automatycznie. Należy skopiować wyświetlony adres URL do przeglądarki na komputerze lokalnym i wybrać strefę. Po zakończeniu operacji powstanie plik ~/.cloudflared/cert.pem.

cert.pem to poświadczenie Twojego konta. Upoważnia ono do tworzenia tuneli, dodawania rekordów DNS w wybranej strefie oraz usuwania tuneli. Działający tunel nie korzysta z tego pliku. Należy traktować go jak hasło, ponieważ posiadanie kopii tego pliku wystarczy, aby opublikować nowe nazwy hostów w Twojej domenie.

cloudflared tunnel create homelab

Poprawne wykonanie polecenia wyświetli obie poniższe linie. Zawarty w nich identyfikator UUID to wartość, którą należy wkleić do pliku konfiguracyjnego.

Tunnel credentials written to /home/you/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json. cloudflared chose this file based on where your origin certificate was found. Keep this file secret. To revoke these credentials, delete the tunnel.
Created tunnel homelab with id 6ff42ae2-765d-4adf-8112-31c55c1551ef

Ten plik JSON stanowi tożsamość tunelu i jest jedynym poświadczeniem wymaganym przez działającą usługę. Każdy, kto go posiada, może zarejestrować się jako Twój tunel i odbierać Twój ruch sieciowy. Nie ma możliwości rotacji samego pliku: jego unieważnienie wymaga wykonania cloudflared tunnel delete homelab i utworzenia nowego tunelu.

Przechowywanie pliku z poświadczeniami w bezpiecznej lokalizacji

Usługa działa z uprawnieniami użytkownika root, dlatego plik należy umieścić w katalogu należącym do roota. Nie należy pozostawiać go w katalogu domowym, do którego dostęp może mieć zadanie kopii zapasowej lub współdzielone konto użytkownika.

sudo install -d -m 700 -o root -g root /etc/cloudflared
sudo install -m 600 -o root -g root \
  ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json \
  /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
rm ~/.cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
sudo ls -l /etc/cloudflared
cloudflared tunnel list

ls -l powinno wyświetlić -rw------- root root dla pliku JSON. cloudflared tunnel list odczytuje cert.pem, dzięki czemu usługa działa poprawnie i powinna wypisać nazwę tunelu, jego UUID oraz liczbę aktualnie utrzymywanych połączeń.

Utworzenie pliku config.yml z właściwymi regułami ingress

Plik konfiguracyjny należy utworzyć w /etc/cloudflared/config.yml, a nie w katalogu domowym. Powód jest następujący: cloudflared service install kopiuje znalezioną konfigurację do /etc/cloudflared/config.yml, a następnie na sztywno wpisuje --config /etc/cloudflared/config.yml do jednostki systemd. Jeśli plik zostanie utworzony w ~/.cloudflared/config.yml, kopia ta będzie jednorazowym zrzutem. Każda późniejsza edycja pliku w katalogu domowym nie przyniesie efektu, usługa będzie nadal korzystać ze starych reguł, a system nie wyświetli żadnego ostrzeżenia. Tworzenie pliku bezpośrednio w docelowej lokalizacji eliminuje ten problem.

tunnel: 6ff42ae2-765d-4adf-8112-31c55c1551ef
credentials-file: /etc/cloudflared/6ff42ae2-765d-4adf-8112-31c55c1551ef.json
loglevel: info

ingress:
  - hostname: app.example.com
    service: http://127.0.0.1:8080
  - hostname: files.example.com
    service: http://127.0.0.1:8081
  - hostname: grafana.example.com
    path: ^/api/
    service: http://127.0.0.1:3000
  - service: http_status:404

Reguły są odczytywane od góry do dołu, a pierwsze dopasowanie wygrywa. Reguła bez hostname pasuje do każdej nazwy hosta, dlatego reguła przechwytująca (catch-all) musi znajdować się na końcu. W przypadku jej pominięcia konfiguracja zostanie odrzucona z błędem The last ingress rule must match all URLs (i.e. it should not have a hostname or path filter). http_status:404 to wbudowana usługa, która zwraca 404 i nie wykonuje żadnych innych działań. Jest ona niezbędna: bez niej żądanie dla nazwy hosta, której nie zamierzano publikować, trafi do ostatniej zdefiniowanej reguły.

W adresie URL service: należy użyć 127.0.0.1 zamiast localhost. W systemie Ubuntu localhost najpierw rozwiązuje nazwę do ::1, a aplikacja powiązana wyłącznie z interfejsem zwrotnym IPv4 odrzuci takie połączenie. W dzienniku pojawi się wpis dial tcp [::1]:8080: connect: connection refused, a użytkownik otrzyma błąd 502.

Zwykłe http:// jest tutaj poprawne, ponieważ ruch nie opuszcza maszyny. Używaj https:// tylko wtedy, gdy lokalna aplikacja wymaga TLS (transport layer security); w przeciwnym razie należy spodziewać się błędu x509: certificate is valid for example.com, not localhost, gdy certyfikat nie pasuje do wywoływanej nazwy. Problem ten można rozwiązać za pomocą originServerName w sekcji originRequest lub zaakceptować ryzyko, stosując noTLSVerify: true.

Przed uruchomieniem czegokolwiek należy sprawdzić reguły:

sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress validate
sudo cloudflared --config /etc/cloudflared/config.yml tunnel ingress rule https://app.example.com/login

ingress validate informuje, czy konfiguracja jest poprawna, lub wskazuje regułę, która powoduje błąd. ingress rule przyjmuje jeden adres URL i wyświetla pierwszą pasującą regułę, co jest najszybszym sposobem na sprawdzenie, czy wyrażenie regularne path działa zgodnie z założeniami.

Skierowanie DNS na tunel

cloudflared tunnel route dns homelab app.example.com
cloudflared tunnel route dns homelab files.example.com
cloudflared tunnel route dns homelab grafana.example.com

Każde wywołanie tworzy rekord CNAME wskazujący na 6ff42ae2-765d-4adf-8112-31c55c1551ef.cfargotunnel.com. Ten cel jest rozpoznawany wyłącznie wewnątrz sieci Cloudflare, dlatego publiczna odpowiedź DNS dla danej nazwy hosta zawiera adres Cloudflare, a adres IP serwera VPS nie jest ujawniany. Rekord wieloznaczny hostname w config.yml nadal wymaga dopasowanego rekordu DNS dla każdej używanej nazwy.

Jeśli rekord już istnieje, polecenie kończy się niepowodzeniem w następujący sposób:

Failed to add route: code: 1003, reason: Failed to create record app.example.com with err An A, AAAA, or CNAME record with that host already exists.

Istniejący rekord to niemal zawsze stary rekord typu A wskazujący na publiczny adres IP serwera VPS, czyli dokładnie ten rekord, który należy usunąć. Należy usunąć go w panelu Cloudflare, a następnie ponownie wykonać polecenie. Pozostawienie go sprawia, że DNS nadal publikuje adres IP serwera źródłowego, przez co tunel nie zapewnia ukrycia danych.

Instalacja jako usługa zapewniająca działanie po restarcie

Uruchom proces w pierwszym planie, ponieważ błędy są znacznie łatwiejsze do odczytania w terminalu niż w dzienniku systemowym.

sudo cloudflared --config /etc/cloudflared/config.yml tunnel run homelab

Poprawny start generuje w logach kilka linii Registered tunnel connection, po jednej dla każdej lokalizacji brzegowej, z których każda posiada własny connIndex. Wczytaj jedną ze swoich nazw hostów w przeglądarce i potwierdź, że reguły ruchu przychodzącego kierują na właściwy cel, a następnie zatrzymaj proces za pomocą Ctrl-C.

sudo cloudflared --config /etc/cloudflared/config.yml service install
systemctl status cloudflared

Polecenie to zapisuje /etc/systemd/system/cloudflared.service wraz z cloudflared-update.service oraz cloudflared-update.timer, a następnie wykonuje systemctl enable cloudflared.service i systemctl start cloudflared.service. Kluczowe znaczenie ma tutaj enable, ponieważ to ten element przywraca tunel po restarcie systemu. Wartość ExecStart jednostki to cloudflared --no-autoupdate --config /etc/cloudflared/config.yml tunnel run, dlatego ścieżka do konfiguracji jest niezmienna.

Trzy błędy na tym etapie mają precyzyjne komunikaty. possible conflicting configuration in /home/you/.cloudflared/config.yml and /etc/cloudflared/config.yml oznacza, że oba pliki istnieją, a cloudflared odmawia zgadywania: usuń plik, który nie jest potrzebny. configuration file ... must contain entries for the tunnel to run and its associated credentials (tunnel: TUNNEL-UUID, credentials-file: CREDENTIALS-FILE) oznacza, że konfiguracja używa skróconego zapisu url: zamiast kluczy nazwanych tuneli, a ten zapis nie może działać jako usługa. cloudflared service is already installed oznacza, że w systemie znajduje się starsza jednostka, więc należy najpierw wykonać sudo cloudflared service uninstall.

Nie istnieje funkcja przeładowania. Po edycji /etc/cloudflared/config.yml należy wykonać sudo systemctl restart cloudflared. Następnie zweryfikuj działanie po restarcie, zamiast zakładać, że zadziała:

sudo reboot
# once it is back
systemctl is-enabled cloudflared
systemctl is-active cloudflared
journalctl -u cloudflared -n 50 --no-pager
curl -sI https://app.example.com

Wyświetlenie enabled przez is-enabled oraz active przez is-active jest głównym celem tej sekcji. Gdy trasy istnieją, a usługa działa, cert.pem nie ma dalszych zadań na serwerze: rm ~/.cloudflared/cert.pem. Dodanie nowej nazwy hosta w przyszłości wymaga jedynie ponownego wykonania cloudflared tunnel login.

Zamknięcie portów 80 i 443; w przeciwnym razie tunel stanowi jedynie dodatkową ścieżkę

Wymagane są dwie zmiany i obie są niezbędne. Wykonanie tylko jednej z nich pozostawia serwer źródłowy dostępny z zewnątrz.

Po pierwsze, powiąż aplikację z adresem loopback. W nginx oznacza to użycie listen 127.0.0.1:8080; zamiast listen 80;, co opisano szczegółowo w wyjaśnieniu konfiguracji reverse proxy nginx. W Docker Compose oznacza to użycie ports: - "127.0.0.1:8080:80". Standardowy zapis "8080:80" publikuje usługę na wszystkich interfejsach, a Docker tworzy własne reguły NAT (network address translation), które pakiety napotykają przed ufw, przez co reguła deny w ufw nie zatrzyma ruchu. Ta pułapka została opisana w artykule: dlaczego opublikowane porty Dockera ignorują ufw.

sudo ss -lntp

Każda przeniesiona usługa powinna teraz wyświetlać 127.0.0.1:8080 w kolumnie Local Address. Wiersz zawierający 0.0.0.0:8080 lub *:8080 oznacza, że usługa nadal nasłuchuje na połączenia z zewnątrz.

Po drugie, zamknij porty.

sudo ufw status numbered
sudo ufw delete allow 'Nginx Full'
sudo ufw status

Usuń reguły zezwalające (allow) dla portów 80 i 443 zamiast nakładać na nie reguły blokujące (deny), ponieważ ufw zatrzymuje się na pierwszej pasującej regule, a nieaktualna reguła zezwalająca znajdująca się wyżej na liście będzie miała pierwszeństwo. Zachowaj regułę dla SSH. Podstawy zapory sieciowej ufw opisują resztę tego zestawu reguł. Większość dostawców VPS udostępnia również oddzielną zaporę sieciową w panelu sterowania, która nie jest ufw, więc tam również należy zamknąć porty 80 i 443.

Teraz zweryfikuj dostępność z zewnątrz, ponieważ curl http://127.0.0.1:8080 uruchomione na samym serwerze nie daje żadnych informacji o stanie widoczności z Internetu.

# run these from a different machine
nc -vz 203.0.113.10 443
curl -sI https://app.example.com

Odmowa połączenia lub przekroczenie czasu oczekiwania przy użyciu nc skierowanego na adres IP, przy jednoczesnym sukcesie 200 przez nazwę hosta, to pożądany rezultat. Weryfikacja czy port jest rzeczywiście otwarty zawiera więcej metod testowania.

Tunel zapewnia transport, a nie uwierzytelnianie. Wszystko, co publikujesz przez tunel, jest publicznie dostępne, chyba że zabezpieczysz to logowaniem – za pomocą Cloudflare Access na brzegu sieci lub proxy OAuth2 umieszczonego przed aplikacją na serwerze. SSH również wymaga własnego zabezpieczenia, ponieważ tunel go nie obejmuje: pozostaw port 22 otwarty, ale ogranicz dostęp do własnych adresów źródłowych.

Korzyści i koszty korzystania z Cloudflare Tunnel

Zyski są wymierne. Adres IP serwera źródłowego nie jest publikowany, żaden port przychodzący nie jest wystawiony, a konfiguracja działa nawet na maszynie bez publicznego adresu IP. Certyfikat publiczny jest obsługiwany przez Cloudflare, więc na serwerze nie musi działać żaden klient ACME (automatic certificate management environment), a ataki wolumetryczne są przejmowane na brzegu sieci, zamiast obciążać dostępne pasmo.

Koszty są równie realne. Cloudflare dokonuje terminacji TLS na brzegu swojej sieci: żądanie użytkownika jest tam odszyfrowywane i ponownie szyfrowane wewnątrz tunelu, co oznacza, że Cloudflare ma wgląd w ruch. Jest to niezbędne do działania firewalla, buforowania oraz reguł Access i nie istnieje ustawienie pozwalające to wyłączyć przy korzystaniu z proxy. Jeśli powierzenie danych w postaci jawnej stronie trzeciej jest nieakceptowalne, należy zrezygnować z tego rozwiązania na rzecz innego.

Cloudflare staje się również krytyczną zależnością dla dostępności usług. Gdy cloudflared nie jest połączony, użytkownicy otrzymują stronę błędu 1033 zamiast docelowej aplikacji, a bezpośrednia ścieżka połączenia, która mogłaby stanowić rozwiązanie awaryjne, została celowo usunięta.

Z poziomu standardowej przeglądarki pod publiczną nazwą hosta dostępne są wyłącznie protokoły HTTP, HTTPS oraz WebSocket. Każdy inny protokół TCP, taki jak SSH, RDP (remote desktop protocol) czy serwer gier, wymaga zainstalowania oprogramowania po stronie klienta: cloudflared access tcp przekierowującego lokalny port lub klienta WARP. Nie istnieje ścieżka dostępu niewymagająca klienta dla tych protokołów.

Treść żądań jest ograniczona na brzegu sieci, a przesyłanie danych przekraczające limit jest odrzucane z kodem HTTP 413, zanim dotrze do aplikacji. Według stanu na sierpień 2026 limit ten wynosi 100 MB w planach Free i Pro oraz jest wyższy w płatnych wersjach, dlatego przed zaprojektowaniem architektury należy sprawdzić aktualną stronę z limitami Cloudflare. Regulamin usług samoobsługowych Cloudflare ogranicza również wykorzystanie proxy głównie do serwowania wideo oraz innych dużych plików niebędących HTML, co warto przeczytać przed skierowaniem biblioteki multimediów na darmowy tunel.

Cloudflare Tunnel, odwrotny tunel SSH lub Tailscale Funnel

Wszystkie trzy rozwiązania działają wyłącznie w trybie wychodzącym, dzięki czemu funkcjonują na serwerach bez otwartych portów przychodzących i publicznego adresu IP. Różnią się one tym, kto ma dostęp do niezaszyfrowanych danych oraz jaką nazwę hosta widzą użytkownicy publiczni.

Odwrotny tunel SSH wymaga drugiej maszyny z publicznym adresem IP, która pełni rolę bramy wejściowej: certyfikat, reverse proxy oraz firewall pozostają w pełni pod kontrolą administratora. Nikt inny nie odszyfrowuje ruchu. Rozwiązanie to składa się z większej liczby elementów i wymaga użycia autossh lub jednostki systemd z Restart=always, aby przetrwać chwilowe przerwy w łączności. Przewodnik po odwrotnym tunelu SSH dla CGNAT opisuje proces budowy takiej konfiguracji.

Tailscale Funnel jest najbardziej zbliżonym rozwiązaniem. Działa w ten sam sposób w trybie wychodzącym, a terminacja TLS odbywa się na własnej maszynie, więc przekaźniki Tailscale nigdy nie widzą danych w postaci jawnej. Ceną są ograniczenia dotyczące nazewnictwa i portów: Funnel obsługuje tylko nazwy w domenie ts.net twojej sieci tailnet oraz wyłącznie porty 443, 8443 i 10000. Różnice między Tailscale Serve a Funnel omawia oba te mechanizmy.

Wybór zależy od ograniczeń, które są kluczowe w danej sytuacji. Wybierz Cloudflare Tunnel, jeśli użytkownicy publiczni muszą korzystać z własnej domeny i akceptujesz fakt, że Cloudflare ma wgląd w ruch. Wybierz Tailscale Funnel, gdy nazwa hosta ts.net jest akceptowalna, a przekazywanie danych w postaci jawnej do proxy jest niedopuszczalne. Wybierz odwrotny tunel SSH, jeśli posiadasz już publiczny serwer i chcesz całkowicie wyeliminować strony trzecie z toru transmisji.

FAQ

Czy przy użyciu Cloudflare Tunnel nadal muszę mieć otwarty port 443?

Nie. cloudflared nawiązuje połączenie wychodzące do Cloudflare na porcie 7844, a każde żądanie wraca tym samym kanałem, więc żaden port przychodzący nie jest używany. Instalacja tunelu nie zamyka jednak automatycznie portów. Należy usunąć reguły zezwalające dla portów 80 i 443 w ufw, zamknąć je w zewnętrznym firewallu dostawcy, powiązać aplikację z 127.0.0.1 oraz usunąć pozostałe rekordy A, które publikują adres IP serwera VPS. Stan portów należy zweryfikować za pomocą sudo ss -lntp na serwerze oraz nc -vz <your-ip> 443 z innej maszyny.

Dlaczego dla mojej nazwy hosta wyświetlany jest błąd Cloudflare Error 1033?

Błąd 1033 oznacza, że Cloudflare posiada rekord DNS dla danej nazwy hosta, ale nie może znaleźć aktywnego cloudflared, który odebrałby żądanie. Proces może być wyłączony lub działać, ale nie mieć łączności z Cloudflare. Należy sprawdzić systemctl status cloudflared oraz journalctl -u cloudflared -n 50, a następnie upewnić się, że port wychodzący 7844 jest otwarty zarówno dla protokołu UDP, jak i TCP. Firewall blokujący UDP i QUIC bez zezwolenia na fallback TCP powoduje właśnie ten problem. cloudflared tunnel info homelab wyświetla połączenia widoczne obecnie dla Cloudflare; pusta lista wskazuje na problem po stronie serwera.

Dlaczego przez tunel otrzymuję błąd 502 Bad Gateway?

Błąd 502 oznacza, że cloudflared otrzymało żądanie, ale nie mogło połączyć się z usługą lokalną, więc przyczyna leży między tymi dwoma punktami, a nie po stronie Cloudflare. Należy sprawdzić dziennik. dial tcp [::1]:8080: connect: connection refused oznacza, że pod wskazanym adresem nic nie nasłuchuje, a [::1] w tym komunikacie zazwyczaj wynika z wpisania localhost w adresie URL service:, podczas gdy aplikacja nasłuchuje tylko na IPv4; w takim przypadku należy wpisać http://127.0.0.1:8080. HTTP/1.x transport connection broken: malformed HTTP response to odwrotny problem: wpisano https:// dla źródła obsługującego zwykły protokół HTTP.

Czy przez Cloudflare Tunnel mogę uruchomić SSH, RDP lub serwer gry?

Nie przy użyciu standardowego klienta. Publiczna nazwa hosta w tunelu obsługuje HTTP, HTTPS oraz WebSocket, czyli protokoły używane przez przeglądarki. Każdy inny protokół TCP wymaga dodatkowego oprogramowania na maszynie klienckiej, takiego jak cloudflared access tcp przekierowujące lokalny port lub klient WARP. Jeśli wymagany jest dostęp SSH z dowolnej maszyny bez instalowania dodatkowych narzędzi, tunel nie jest właściwym rozwiązaniem. Należy pozostawić port 22 otwarty, ograniczając dostęp do konkretnych adresów źródłowych.

Czy Cloudflare widzi mój ruch przesyłany przez tunel?

Tak. Cloudflare kończy połączenie TLS na swoim brzegu sieci, odszyfrowuje żądanie i szyfruje je ponownie wewnątrz tunelu do serwera. To odszyfrowanie umożliwia działanie firewalla, buforowania oraz polityk Access, co oznacza, że dane w postaci jawnej istnieją na serwerach Cloudflare. Żadna konfiguracja nie pozwala tego uniknąć przy korzystaniu z ich proxy. Jeśli jest to nieakceptowalne, należy użyć Tailscale Funnel lub uruchomić własny reverse proxy na publicznym serwerze.