Czasami podczas pracy nad aplikacją, API, lokalnym serwerem czy jakimś narzędziem opartym o AI pojawia się dość prozaiczny problem.
Mamy coś uruchomionego lokalnie, przykładowo pod adresem:
http://localhost:3000
i chcielibyśmy dostać się do tego z innego komputera, telefonu albo udostępnić aplikację komuś przez internet.
Normalnie zaczyna się wtedy kombinowanie:
- przekierowanie portów na routerze,
- firewall,
- publiczne IP,
- konfiguracja domeny,
- czasami jeszcze problemy z NAT-em operatora.
Można jednak zrobić to zdecydowanie prościej.
Jednym z rozwiązań jest Cloudflare Quick Tunnel, czyli bardzo szybki sposób na wystawienie lokalnie działającej aplikacji do internetu.
I naprawdę słowo „szybki” jest tutaj na miejscu, bo w najprostszym przypadku sprowadza się to właściwie do jednej komendy.
Co to jest Cloudflare Quick Tunnel?
Cloudflare Quick Tunnel jest uproszczoną wersją usługi Cloudflare Tunnel.
Pozwala utworzyć publiczny adres internetowy prowadzący bezpośrednio do aplikacji działającej na naszym komputerze.
Przykładowo mamy aplikację działającą lokalnie:
http://localhost:8080
Uruchamiamy:
cloudflared tunnel --url http://localhost:8080
Cloudflare utworzy dla nas losowy adres w domenie:
trycloudflare.com
czyli przykładowo:
https://jakies-losowe-slowa.trycloudflare.com
Od tej chwili wejście na ten adres powoduje przekierowanie ruchu przez sieć Cloudflare do aplikacji uruchomionej na naszym komputerze.
Nie potrzebujemy własnej domeny.
Nie musimy konfigurować DNS.
Nie musimy nawet posiadać konta Cloudflare.
Według aktualnej dokumentacji Cloudflare Quick Tunnel został właśnie zaprojektowany przede wszystkim do szybkiego testowania i developmentu.
Jak działa Cloudflare Quick Tunnel?
Najprościej można przedstawić to tak:
Użytkownik w internecie
↓
https://xxxxx.trycloudflare.com
↓
Sieć Cloudflare
↓
zaszyfrowane połączenie
↓
cloudflared na naszym komputerze
↓
localhost:8080
↓
nasza aplikacja
Kluczowy jest tutaj program:
cloudflared
Instalujemy go na komputerze, na którym działa nasza lokalna aplikacja.
Następnie cloudflared sam zestawia połączenie wychodzące z infrastrukturą Cloudflare.
I to jest istotna różnica względem klasycznego wystawiania serwera do internetu.
Nie musimy otwierać portu przychodzącego na routerze.
Cloudflare opisuje Tunnel jako rozwiązanie wykorzystujące połączenia wychodzące do swojej sieci, dzięki czemu lokalny serwer nie musi posiadać wystawionego publicznego adresu IP ani otwartych portów przychodzących.
W praktyce oznacza to:
Internet
↓
Cloudflare
↑
│
połączenie wychodzące
│
nasz komputer
a nie klasyczne:
Internet
↓
router
↓
otwarty port
↓
nasz komputer
To właśnie dlatego rozwiązanie jest tak wygodne.
Najprostszy przykład użycia
Załóżmy, że stworzyliśmy prostą aplikację w Pythonie.
Może działać przykładowo pod:
http://127.0.0.1:8000
Normalnie adres ten działa tylko na naszym komputerze.
Uruchamiamy więc:
cloudflared tunnel --url http://localhost:8000
Po chwili w terminalu otrzymamy publiczny adres:
https://randomowa-nazwa.trycloudflare.com
Teraz możemy otworzyć ten adres np. na telefonie korzystającym z internetu komórkowego.
Możemy też wysłać go drugiej osobie.
I będzie ona mogła zobaczyć aplikację działającą fizycznie na naszym komputerze.
To jest chyba najlepszy sposób, żeby zrozumieć ideę Quick Tunnel.
Po co mi Cloudflare Quick Tunnel?
Zastosowań jest naprawdę sporo, szczególnie jeżeli pracujemy z aplikacjami webowymi, Pythonem, AI, automatyzacjami czy API.
1. Udostępnienie lokalnie tworzonej strony
Tworzę przykładowo aplikację:
localhost:3000
i chcę pokazać ją klientowi.
Zamiast wrzucać całość na hosting czy tworzyć środowisko stagingowe, mogę na chwilę uruchomić tunel i wysłać klientowi link.
Klient wchodzi:
https://xxxxx.trycloudflare.com
i ogląda wersję działającą bezpośrednio na moim komputerze.
Do szybkiego podglądu – bardzo wygodne.
2. Testowanie aplikacji na telefonie
To jest prosty, ale bardzo praktyczny przykład.
Tworzę aplikację na komputerze:
localhost:5173
Chcę zobaczyć, jak działa na telefonie.
Uruchamiam:
cloudflared tunnel --url http://localhost:5173
Otwieram wygenerowany adres na smartfonie i testuję.
Nie muszę nawet kombinować z adresami IP w sieci lokalnej.
3. Testowanie webhooków
Tutaj zaczyna robić się jeszcze ciekawiej.
Wiele usług internetowych korzysta z webhooków.
Webhook działa mniej więcej tak:
zewnętrzna usługa
↓
wysyła żądanie HTTP
↓
nasze API
Problem polega na tym, że zewnętrzna usługa nie może wysłać żądania do:
localhost:8000
bo localhost oznacza komputer, na którym dana aplikacja działa.
Cloudflare Quick Tunnel rozwiązuje problem.
Mamy:
localhost:8000/webhook
robimy:
cloudflared tunnel --url http://localhost:8000
i dostajemy:
https://xxxxx.trycloudflare.com/webhook
Taki adres można już podać zewnętrznemu systemowi.
Bardzo przydatne podczas tworzenia integracji.
4. Lokalne API wystawione do internetu
Przykładowo tworzę API w FastAPI:
http://localhost:8000
Quick Tunnel pozwala bardzo szybko udostępnić je jako:
https://xxxxx.trycloudflare.com
Możemy więc testować aplikację mobilną, zewnętrzny frontend albo inne narzędzie korzystające z tego API.
5. Projekty AI
W moim przypadku to jedno z ciekawszych zastosowań.
Coraz więcej eksperymentuję z lokalnymi aplikacjami AI, RAG, modelami językowymi i różnego rodzaju narzędziami pośredniczącymi między API różnych dostawców.
Załóżmy, że lokalnie uruchamiamy serwer kompatybilny z API OpenAI:
http://localhost:4000/v1
Możemy wystawić go poprzez:
cloudflared tunnel --url http://localhost:4000
i otrzymać:
https://xxxxx.trycloudflare.com/v1
Teoretycznie inne aplikacje mogą teraz komunikować się z naszym lokalnym serwerem przez internet.
Może być to przydatne m.in. przy testowaniu:
- agentów AI,
- lokalnych modeli LLM,
- systemów RAG,
- aplikacji korzystających z API,
- własnych gatewayów do modeli,
- automatyzacji,
- integracji pomiędzy różnymi środowiskami.
Tutaj oczywiście trzeba już znacznie bardziej uważać na bezpieczeństwo.
Cloudflare Quick Tunnel a ngrok
Jeżeli ktoś wcześniej bawił się aplikacjami webowymi, prawdopodobnie kojarzy ngrok.
Idea jest bardzo podobna.
Mamy:
localhost
i dostajemy:
publiczny adres HTTPS
Cloudflare Quick Tunnel może być więc w wielu zastosowaniach prostą alternatywą dla ngrok.
Cloudflare samo wskazuje Tunnel jako rozwiązanie pozwalające udostępniać lokalne środowiska developerskie przez publiczny adres.
W moim przypadku największą zaletą Quick Tunnel jest po prostu minimalizm.
Jedna komenda:
cloudflared tunnel --url http://localhost:8080
i działa.
Czy potrzebuję konta Cloudflare?
Do Quick Tunnel – nie.
Nie trzeba:
- zakładać konta,
- podpinać domeny,
- ustawiać DNS,
- tworzyć tunelu w panelu Cloudflare.
Cloudflare automatycznie generuje losową subdomenę:
*.trycloudflare.com
i kieruje ją do naszego lokalnego serwera.
To właśnie odróżnia Quick Tunnel od normalnego Cloudflare Tunnel.
Cloudflare Quick Tunnel a normalny Cloudflare Tunnel
Tutaj trzeba rozróżnić dwie rzeczy.
Quick Tunnel służy przede wszystkim do testowania.
Normalny Cloudflare Tunnel możemy skonfigurować jako stały element naszej infrastruktury.
Przykładowo:
api.mojadomena.pl
może prowadzić przez Cloudflare Tunnel do:
localhost:8000
albo do serwera znajdującego się w naszej sieci lokalnej.
W Quick Tunnel dostajemy natomiast losowy adres:
xxxxx.trycloudflare.com
który jest powiązany z uruchomionym procesem cloudflared.
W przypadku szybkiego tunelu nie powinniśmy więc traktować wygenerowanego URL jako stałego adresu naszej aplikacji. Quick Tunnels są anonimowe i tymczasowe, a Cloudflare nie przeznacza ich do środowisk produkcyjnych.
Quick Tunnel nie jest hostingiem
To również ważne.
Cloudflare nie kopiuje naszej aplikacji na swój serwer.
Aplikacja nadal działa:
na naszym komputerze
Cloudflare jedynie przekazuje ruch.
Jeżeli wyłączymy aplikację:
localhost:8080
to publiczny adres przestanie działać poprawnie.
Jeżeli wyłączymy cloudflared, tunel również przestanie działać.
Jeżeli wyłączymy komputer – tym bardziej.
To nie jest więc odpowiednik hostingu czy VPS.
To bardziej:
bezpieczny pośrednik
pomiędzy internetem a usługą działającą lokalnie.
Czy Cloudflare Quick Tunnel jest bezpieczny?
Sam mechanizm jest zdecydowanie bezpieczniejszy niż przypadkowe otwieranie portów na routerze, ponieważ cloudflared inicjuje połączenie wychodzące i nie musimy udostępniać publicznego IP naszego serwera.
Ale jest tutaj jedno bardzo ważne „ale”.
Jeżeli wystawimy:
http://localhost:8000
przez Quick Tunnel, to otrzymany adres jest publicznie dostępny.
Czyli ktoś, kto pozna:
https://xxxxx.trycloudflare.com
może próbować dostać się do naszej aplikacji.
Dlatego nie wystawiałbym w ten sposób bez dodatkowego zabezpieczenia:
- panelu administratora,
- phpMyAdmin,
- bazy danych,
- aplikacji posiadającej poufne dane,
- panelu zarządzającego serwerem,
- lokalnego API posiadającego niebezpieczne funkcje,
- aplikacji bez uwierzytelniania.
Quick Tunnel traktowałbym przede wszystkim jako narzędzie developerskie.
Jakie są ograniczenia Cloudflare Quick Tunnel?
Cloudflare jasno zaznacza, że Quick Tunnels przeznaczone są do testów i developmentu, a nie do produkcyjnego hostowania aplikacji.
Według dokumentacji z 2026 roku obowiązuje między innymi limit 200 jednocześnie obsługiwanych żądań będących w trakcie realizacji. Po jego przekroczeniu serwer może odpowiedzieć kodem HTTP 429.
Quick Tunnel nie obsługuje również Server-Sent Events (SSE).
To drugie może mieć znaczenie szczególnie przy aplikacjach AI.
Niektóre interfejsy modeli językowych wykorzystują SSE do streamowania odpowiedzi token po tokenie.
Jeżeli więc robimy aplikację typu:
pytanie
↓
LLM
↓
odpowiedź pojawiająca się na żywo
Quick Tunnel może nie być właściwym rozwiązaniem.
W takim przypadku lepiej wykorzystać normalny Cloudflare Tunnel lub inne rozwiązanie.
Przykład z Pythonem
Możemy zrobić bardzo prosty test.
Wchodzimy do dowolnego katalogu i uruchamiamy:
python -m http.server 8000
Python uruchomi prosty serwer HTTP:
http://localhost:8000
Teraz w drugim terminalu:
cloudflared tunnel --url http://localhost:8000
Cloudflare poda adres podobny do:
https://some-random-name.trycloudflare.com
Otwieramy go na telefonie albo innym komputerze.
I właśnie wystawiliśmy lokalny serwer Pythona do internetu.
Bez hostingu.
Bez domeny.
Bez przekierowania portów.
Bez grzebania w routerze.
Co właściwie dzieje się pod spodem?
Można to sobie wyobrazić następująco.
Normalny lokalny serwer:
APLIKACJA
↑
localhost:8000
jest niewidoczny dla internetu.
Po uruchomieniu:
cloudflared tunnel --url http://localhost:8000
powstaje:
INTERNET
↓
CLOUDFLARE
↓
TUNEL
↓
CLOUDFLARED
↓
LOCALHOST:8000
↓
APLIKACJA
Cloudflare staje się więc swego rodzaju bramą pomiędzy internetem a naszym komputerem.
Gdzie widzę dla tego zastosowanie?
Dla zwykłego użytkownika komputera prawdopodobnie niewielkie.
Ale jeśli ktoś tworzy:
- strony internetowe,
- aplikacje,
- API,
- integracje,
- automatyzacje,
- projekty Python,
- lokalne modele AI,
- systemy RAG,
- webhooki,
to jest to jedno z tych małych narzędzi, które warto mieć gdzieś z tyłu głowy.
Szczególnie podczas prototypowania.
Zamiast zastanawiać się:
jak teraz udostępnić mój localhost w internecie?
można po prostu wpisać:
cloudflared tunnel --url http://localhost:8080
i po kilkunastu sekundach pracować dalej.
Podsumowanie
Cloudflare Quick Tunnel rozwiązuje bardzo konkretny problem.
Pozwala zamienić:
http://localhost:8080
w publicznie dostępny:
https://xxxxx.trycloudflare.com
bez własnego serwera, bez publicznego IP, bez przekierowania portów i bez konfiguracji domeny.
Nie jest to rozwiązanie produkcyjne.
Nie zastępuje hostingu.
Nie powinno być również traktowane jako sposób na bezmyślne wystawianie prywatnych usług do internetu.
Ale do developmentu, testowania API, webhooków, aplikacji Python czy eksperymentowania z AI jest naprawdę użyteczne.
I jest to dokładnie ten rodzaj narzędzia, który lubię najbardziej:
rozwiązuje konkretny problem, a jego podstawowe użycie można zamknąć w jednej komendzie:
cloudflared tunnel --url http://localhost:8080
Czasami naprawdę nie trzeba komplikować rzeczy bardziej, niż jest to konieczne.