Dostawca webhooków potrzebuje adresu URL, pod który może wysłać POST, a twój serwer siedzi na localhost:3000. Albo kolega chce przeklikać branch, który akurat uruchomiłeś, albo telefon musi trafić do serwera deweloperskiego, żeby sprawdzić layout. Serwer działa. Nic spoza twojej sieci się do niego nie dostanie.

Przekierowanie portu na routerze by zadziałało, ale wystawia twój domowy IP i wymaga uprawnień administratora, których często nie masz. Cloudflare Tunnel idzie w drugą stronę. cloudflared, mały daemon uruchomiony obok serwera, otwiera połączenie wychodzące do brzegu sieci Cloudflare, a Cloudflare odsyła przez nie ruch z powrotem. Nie otwierasz żadnego portu przychodzącego i nie potrzebujesz publicznego IP.

Występuje w dwóch formach. Quick tunnel daje publiczny adres HTTPS jedną komendą, pod losową nazwą hosta, która znika po zatrzymaniu procesu. To narzędzie na pięciominutowe demo albo test webhooka. Named tunnel daje stabilną nazwę hosta na twojej własnej domenie, która przetrwa restart, dzięki czemu staje się elementem prawdziwej infrastruktury.

Jak Cloudflare Tunnel działa bez otwartego portu

Sztuczka polega na zmianie kierunku. Udostępnienie usługi zwykle oznacza otwarcie portu przychodzącego: coś w internecie inicjuje połączenie z twoją maszyną, więc maszyna potrzebuje adresu routowalnego i reguły firewalla, która wpuści ten ruch. Blokowanie dokładnie tego jest zadaniem NAT-u i większości firewalli domowych czy biurowych.

cloudflared nigdy nie nasłuchuje połączeń przychodzących. Łączy się wychodząco z brzegiem Cloudflare przez zwykłe HTTPS, dokładnie taki typ połączenia, jaki twoja przeglądarka otwiera cały dzień, i trzyma je otwarte. Cloudflare następnie wpycha żądania przez to połączenie i odczytuje z niego odpowiedzi, podobnie jak serwer wypycha wiadomości przez WebSocket do przeglądarki, która sama zainicjowała połączenie. Twój firewall widzi jedno wychodzące połączenie, na które i tak już pozwala. Dlatego tunel działa tak samo za NAT-em, jak i na laptopie bez publicznego IP: połączeniu wychodzącemu to nie przeszkadza.

Koszt jest taki, że Cloudflare teraz siedzi na trasie. Nazwa hosta twojego tunelu wskazuje na Cloudflare, które deszyfruje każde żądanie na swoim brzegu, potem szyfruje je ponownie i wysyła dalej przez tunel do twojego daemona. To ta sama architektura co praca za CDN albo za reverse proxy: oddajesz bezpośredni dostęp w zamian za middlebox, który terminuje TLS i może zastosować reguły dostępu, zanim cokolwiek dotrze do twojej maszyny.

Jak stworzyć quick tunnel jedną komendą

Najpierw zainstaluj cloudflared: brew install cloudflared na macOS, pakiet .deb/.rpm z repozytorium Cloudflare na Linuksie albo instalator dla Windows ze strony z releases na GitHubie. Potem, mając już coś nasłuchującego na lokalnym porcie:

1

cloudflared tunnel --url http://localhost:3000

Kilka sekund później dostajesz wynik podobny do tego:

1
2
3
4
5

2026-09-23T10:14:02Z INF Thank you for trying Cloudflare Tunnel. Doing so...
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+
2026-09-23T10:14:03Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2026-09-23T10:14:03Z INF |  https://wise-juvenile-pink-recovered.trycloudflare.com                                   |
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+

Ten adres URL serwuje HTTPS z certyfikatem zarządzanym przez Cloudflare, więc nigdy nie dotykasz konfiguracji TLS. Daj mu kilka sekund, zanim zacznie się rozwiązywać. Od tego momentu każdy z linkiem dociera do twojego localhost:3000, dopóki nie wciśniesz Ctrl-C. Nazwa hosta znika wtedy na dobre, a kolejne uruchomienie generuje nową. Nie logujesz się, nie tworzysz rekordu DNS ani nie potrzebujesz konta.

Ograniczenia są jednak realne. Nazwa hosta jest losowa, więc nie da się jej wpisać w konfigurację webhooka, która musi przetrwać restart. Cloudflare ogranicza quick tunnele do 200 równoczesnych żądań i nie wspiera na nich Server-Sent Events, więc długo żyjący strumień SSE się urwie. Nie ma też gwarancji dostępności: regulamin Cloudflare traktuje quick tunnele jako wygodę testową.

Do debugowania webhooka tu i teraz albo podpięcia telefonu do serwera deweloperskiego to wszystko, czego potrzebujesz. Jeśli ma to jeszcze działać jutro, ustaw named tunnel.

Jak skonfigurować named tunnel na własnej domenie

Named tunnel potrzebuje darmowego konta Cloudflare i domeny, której DNS jest na Cloudflare. Setup robisz raz.

1. Uwierzytelnij cloudflared względem swojego konta:

1

cloudflared tunnel login

To otwiera przeglądarkę i prosi o wybranie domeny do autoryzacji. Potem zapisuje certyfikat w ~/.cloudflared/cert.pem, z którego korzysta każda kolejna komenda.

2. Utwórz tunel i zapisz jego ID:

1

cloudflared tunnel create my-app

To rejestruje tunel o nazwie my-app i zapisuje plik z danymi uwierzytelniającymi, <TUNNEL-ID>.json, do ~/.cloudflared/. Ten plik to tożsamość tunelu. Traktuj go jak sekret: każdy, kto go posiada, może puszczać ruch przez twój tunel.

3. Napisz konfigurację. Utwórz ~/.cloudflared/config.yml:

1
2
3
4
5
6
7
8
9

tunnel: my-app
credentials-file: /home/you/.cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

ingress to uporządkowana lista reguł hostname-do-usługi, dopasowywana od góry do dołu. Jeśli skonfigurowałeś nginx jako reverse proxy przed swoimi aplikacjami, to ten sam pomysł na routing, tylko zapisany w YAML zamiast dyrektyw proxy_pass. Jeden tunel może obsługiwać kilka lokalnych usług pod różnymi nazwami hostów. Ostatnia reguła jest obowiązkowa. To catch-all, który zwraca 404 dla każdej nazwy hosta, jakiej nie złapały reguły wyżej, a cloudflared odmawia startu bez niej.

4. Skieruj DNS na tunel:

1

cloudflared tunnel route dns my-app app.example.com

To tworzy rekord CNAME dla app.example.com, wskazujący na <TUNNEL-ID>.cfargotunnel.com. To zwykłe rozwiązywanie DNS, celujące w infrastrukturę tunelową Cloudflare zamiast w IP serwera. Uruchom to raz dla każdej nazwy hosta z listy ingress.

5. Uruchom go:

1

cloudflared tunnel run my-app

app.example.com serwuje teraz cokolwiek, co nasłuchuje na localhost:3000, przez HTTPS. Cloudflare terminuje TLS na brzegu, a twój origin może zostać na zwykłym HTTP, bo połączenie tunelowe jest już zaszyfrowane.

Tunel odpalony w terminalu umiera razem z terminalem. Żeby przetrwał reboot, zainstaluj go jako usługę systemową:

1

sudo cloudflared service install

Na Linuksie, uruchamiając to przez sudo, $HOME zmienia się na /root i cloudflared przestaje widzieć config.yml, który stworzyłeś jako zwykły użytkownik. Wskaż plik jawnie:

1

sudo cloudflared --config /home/you/.cloudflared/config.yml service install

To kopiuje twoją konfigurację do /etc/cloudflared/config.yml i rejestruje cloudflared w systemd (albo launchd, albo menedżerze usług Windows), więc startuje przy boocie i restartuje się po crashu.

Kiedy Cloudflare Tunnel to zły wybór

Tunel pasuje, gdy ruch zaczyna się poza twoją siecią i musi dotrzeć do maszyny bez publicznego IP, albo takiej, której nie chcesz wystawiać bezpośrednio: laptopa, domowego serwera, boxa za firmowym NAT-em. W tych przypadkach to zły dobór narzędzia:

  • Masz już serwer z publicznym IP. Tunel dokłada brzeg Cloudflare jako dodatkowy hop bez żadnego zysku. Rekord A w DNS plus własny reverse proxy albo terminacja TLS to prostsze rozwiązanie z jednym ruchomym elementem mniej do popsucia.
  • Potrzebujesz gwarantowanie niskich opóźnień albo przenosisz duże wolumeny danych. Każdy bajt przechodzi przez sieć Cloudflare. Dla większości ruchu webowego ten koszt jest pomijalny; dla obciążeń wymagających dużej przepustowości albo wrażliwych na opóźnienia — nie.
  • Usługa musi działać dalej, gdy maszyna padnie. Jeden cloudflared na jednej maszynie to pojedynczy punkt awarii, a service install pokrywa tylko restarty procesu. Jeśli ten host umrze, nazwa hosta gaśnie. Redundancja oznacza puszczenie tego samego tunelu z drugiej maszyny.
  • Twój kod ufa adresowi źródłowemu TCP przy decyzjach związanych z bezpieczeństwem. Żądania trafiają do twojego origin z zakresów IP Cloudflare. Prawdziwy IP klienta przychodzi w nagłówku CF-Connecting-IP, a wszystko, co czyta adres z socketu, zobaczy brzeg Cloudflare zamiast niego.

Quick tunnel czy named tunnel: od czego zacząć

Jeśli nie jesteś pewien, którego potrzebujesz, potrzebujesz quick tunnela. Uruchom cloudflared tunnel --url http://localhost:<port> na tym, nad czym akurat pracujesz, i otwórz adres URL. Przejdź na named tunnel, gdy trafisz na jedno z jego dwóch realnych ograniczeń: nazwę hosta, która musi przetrwać zamknięcie sesji terminala, albo usługę, która musi działać bez nadzoru.

Powiązane artykuły