Logowanie do portalu przechwytującego polega na krótkim uwierzytelnieniu w specjalnej stronie logowania, która pojawia się tuż po podłączeniu do sieci Wi‑Fi, zanim otrzymasz normalny dostęp do internetu. Taki portal może wymagać zaakceptowania regulaminu, podania e‑maila, wykonania płatności lub zalogowania się innym sposobem. Dzięki temu operator sieci kontroluje, kto i na jakich zasadach korzysta z połączenia. Jeśli chcesz wiedzieć, jak dokładnie działa takie logowanie, gdzie je spotykasz na co dzień i jak je poprawnie skonfigurować oraz zabezpieczyć, przeczytaj cały artykuł.
Czym jest portal przechwytujący?
Portal przechwytujący to specjalny mechanizm w sieci, który „zatrzymuje” ruch użytkownika na stronie logowania, zanim urządzenie uzyska pełny dostęp do internetu. Jest używany w hotelach, na lotniskach, w samolotach, w sieciach miejskich Wi‑Fi, ale też w sieciach firmowych i szkolnych. Od strony technicznej to połączenie konfiguracji punktów dostępowych, serwera HTTP oraz reguł na routerze lub zaporze, które przekierowują ruch na stronę uwierzytelniania.
Tak zaprojektowana sieć najpierw sprawdza, czy użytkownik przeszedł proces uwierzytelniania na portalu, a dopiero potem zezwala na swobodne korzystanie z sieci. Ten sam mechanizm może zbierać zgody na regulamin, wymuszać logowanie kontem uczelnianym czy firmowym, a nawet naliczać czas sesji i limity danych. W nowoczesnych systemach opisuje się go wprost jako Captive Portal, bo to pojęcie trafiło nie tylko do dokumentacji producentów sprzętu, ale też do standardów sieciowych.
Kluczowa cecha portalu przechwytującego polega na tym, że przejmuje pierwszą komunikację użytkownika z siecią i wymusza logowanie lub akceptację warunków, zanim przepuści ruch dalej.
Jak działa logowanie do portalu przechwytującego od strony użytkownika?
Użytkownik dostrzega portal w bardzo prosty sposób – łączy się z Wi‑Fi, pojawia się powiadomienie lub automatycznie otwierana strona logowania i dopiero po jej „odhaczeniu” internet zaczyna działać. Ten przebieg jest podobny zarówno na laptopach z ChromeOS, jak i na smartfonach z Androidem, choć systemy używają nieco innych mechanizmów wykrywania portalu.
W ChromeOS, jeśli w zarządzanej sieci Wi‑Fi włączono wykrywanie portalu, system po połączeniu wyświetla wyraźny komunikat, że trzeba zalogować się w sieci. Otwiera wtedy okno przeglądarki z adresem strony logowania. Po pomyślnym zalogowaniu status połączenia zmienia się na „online” i wszystkie aplikacje mogą korzystać z sieci bez ograniczeń. Gdy wykrywanie portalu jest wyłączone, użytkownik musi sam otworzyć przeglądarkę i ręcznie przejść do dowolnej strony, żeby zostać przekierowanym do logowania – część osób uznaje wtedy, że „Wi‑Fi nie działa”.
Logowanie na Androidzie 5.0–11
Android już od wersji 5.0 ma własny mechanizm wykrywania portalu przechwytującego. System wysyła krótkie nieszyfrowane sondy HTTP (np. do connectivitycheck.gstatic.com) i analizuje odpowiedź. Jeśli zamiast zwykłego wyniku pojawia się przekierowanie HTTP, Android uznaje, że trafił na portal przechwytujący i pokazuje powiadomienie „Zaloguj się w sieci”. Po jego kliknięciu otwiera się małe okno logowania, w którym użytkownik widzi stronę portalu i może zaakceptować warunki lub podać wymagane dane.
Takie sondy działają w większości sieci, ale bywają zawodne – administrator może zmienić adresy docelowe, niektóre zapory filtrują ruch w nietypowy sposób, a część portali przechwytujących błędnie przepuszcza lub blokuje takie żądania zamiast je przekierować. To powoduje sytuacje, w których internet działa tylko częściowo, a ekran logowania nie pojawia się automatycznie.
Ulepszone wykrywanie portalu na Androidzie 11 i 12+
Android 11 rozszerzył obsługę portali przechwytujących o standard opisany w RFC7710bis. Urządzenie może teraz poznać adres interfejsu API portalu dzięki opcji DHCP Option 114
Od Androida 12 sytuację jeszcze poprawia Network Stack jako moduł Mainline – nowe algorytmy wykrywania portalu i obsługi logowania można aktualizować przez Google Play bez zmiany całego systemu. Dzięki temu urządzenia lepiej radzą sobie z różnymi modelami portali i rzadziej wpadają w stan „częściowej łączności”, gdzie część usług działa, a część nie. Sam proces logowania coraz częściej odbywa się w Chrome Custom Tabs, czyli w niestandardowych kartach przeglądarki, które wspierają autouzupełnianie, płatności jednym kliknięciem i działają poprawnie z VPN czy prywatnym DNS.
Jak portal przechwytujący jest wykrywany i zarządzany w sieci?
Z punktu widzenia administratora samo wyświetlenie strony logowania to tylko wierzchołek góry lodowej. Spód tej konstrukcji tworzą protokoły sieciowe, konfiguracja DHCP, moduły systemowe oraz aplikacje zarządzające logowaniem. Nowoczesne portale korzystają z dobrze opisanych standardów, aby urządzenia mogły je wykrywać bez zgadywania.
W Androidzie za ten proces odpowiada przede wszystkim komponent NetworkMonitor i współpracująca z nim aplikacja do logowania w portalu przechwytującym. Oba elementy są częścią modułu Network Stack, który sprawdza dostęp do internetu, wykrywa portal, uruchamia ekran logowania i przekazuje informację o stanie sieci do reszty systemu. Dzięki przeniesieniu tych komponentów do modułu Mainline można je rozwijać i dostosowywać do nowych implementacji portali bez czekania na pełną aktualizację systemu.
Rola Captive Portal API
Nowy sposób komunikacji pomiędzy siecią a urządzeniem opisuje interfejs Captive Portal API. Punkt dostępowy lub brama sieciowa udostępnia pod określonym adresem URL plik JSON, który zawiera m.in. informacje: czy wymagane jest logowanie, jaki jest adres strony logowania, link do strony z informacjami o miejscu (venue-info-url) oraz ile czasu pozostało do końca sesji. Telefon łączy się z tym adresem zaraz po połączeniu z Wi‑Fi i na tej podstawie wyświetla użytkownikowi powiadomienie o konieczności logowania.
Ten sam interfejs pozwala też sygnalizować, że portal może korzystać z niestandardowych kart Chrome. W tym celu w odpowiedzi JSON pojawia się pole x-android-use-custom-tabs ustawione na konkretną wartość wersji modułu Captive Portal Login – w 2026 roku jest to 361335020. Urządzenie, które ma taką lub nowszą wersję modułu, otwiera portal bezpośrednio w Chrome Custom Tabs, a nie w prostym oknie WebView.
Porównanie metod wykrywania
Przejście z prostych sond HTTP na pełnoprawny interfejs API zmienia sposób działania portalu i stabilność całego procesu. Dobrze widać to w krótkim zestawieniu:
| Metoda | Sposób działania | Typowe problemy |
| Sondy HTTP/HTTPS | Urządzenie wysyła zapytania do stałych adresów i szuka przekierowania HTTP. | Filtry sieciowe, brak standardowego URL, błędne przekierowania. |
| DHCP Option 114 + Captive Portal API | Serwer DHCP ogłasza URL interfejsu API, urządzenie pobiera JSON ze stanem portalu. | Wymóg poprawnego certyfikatu HTTPS i konfiguracji serwera API. |
| Chrome Custom Tabs | Proces logowania odbywa się w niestandardowej karcie powiązanej z główną przeglądarką. | Wymaga Androida 12+ i prawidłowej wartości x-android-use-custom-tabs. |
Jak skonfigurować logowanie do portalu przechwytującego w ChromeOS?
Administratorzy zarządzający urządzeniami z ChromeOS w firmach i szkołach mogą kontrolować sposób wykrywania portali przechwytujących z poziomu konsoli administracyjnej Google. Opcja ta jest szczególnie ważna w sieciach dla gości, w których logowanie przez portal jest normalną częścią korzystania z sieci – na przykład w sieciach hotelowych, sieciach miejskich lub sieciach dla rodziców i uczniów.
Aby włączyć wykrywanie portalu przechwytującego w istniejącym profilu sieci Wi‑Fi, administrator loguje się na konto w konsoli Google, przechodzi do zakładki „Urządzenia”, a następnie do sekcji „Sieci”. Tam wybiera konkretną sieć, przewija do sekcji związanej z portalem przechwytującym i zmienia ustawienie z opcji wyłączonej na włączoną. Może też zdecydować, czy sondowane będą zarówno adresy HTTP, jak i HTTPS, czy tylko nieszyfrowane żądania HTTP.
Zmiana zapisanych ustawień automatycznie rozsyłana jest na wszystkie zarządzane urządzenia. Użytkownicy ChromeOS zaczynają wtedy widzieć jasne powiadomienia o konieczności logowania – strona portalu otwiera się w przeglądarce sama po połączeniu z Wi‑Fi. To znacząco zmniejsza liczbę zgłoszeń „brak internetu”, gdy w rzeczywistości wystarczyło kliknąć „Akceptuję” na stronie portalu.
Jak wygląda konfiguracja portalu przechwytującego w projektach WiFi4EU?
Program WiFi4EU wymusza bardzo konkretne wymagania dotyczące portalu przechwytującego. Każda instalacja zgłoszona w sprawozdaniu musi mieć własną stronę autoryzacji oraz wdrożony kod pomiarowy i element identyfikacji wizualnej. Dopiero spełnienie tych warunków – oraz zalogowanie się co najmniej 10 różnych urządzeń – pozwala uznać sieć za działającą i uruchomić wypłatę środków.
Operatorzy często używają tu systemu cnMaestro i punktów dostępowych cnPilot serii E. Konfiguracja odbywa się w dedykowanym kreatorze „Guest Access Portal”. Po zalogowaniu do cnMaestro wybiera się tę sekcję, wczytuje plik graficzny logo (często jest to połączenie znaku WiFi4EU z herbem gminy), dostosowuje tło, ustawia język na polski i włącza tryb WiFi4EU. Następnie uzupełnia się treść regulaminu i adres URL, na który ma być przekierowany użytkownik po kliknięciu w przycisk logowania.
Snippet WiFi4EU i UUID sieci
Na stronie portalu musi znaleźć się fragment kodu JavaScript, który mierzy czas wczytywania portalu i identyfikuje konkretną sieć. Standardowy snippet definiuje zmienną z czasem startu, identyfikatorem sieci oraz językiem portalu, a następnie ładuje z serwera WiFi4EU plik wifi4eu.min.js. Ten kod powinien być umieszczony tuż po znaczniku <head>, aby dane pomiarowe były prawidłowe.
W wielu gotowych rozwiązaniach – na przykład w portalu przechwytującym cnMaestro – snippet jest już zaimplementowany, a administrator musi jedynie uzyskać Network UUID od INEA na podstawie adresu URL portalu i zakresu adresów IP (zwykle podaje się 0.0.0.0/0). UUID pozwala później powiązać dane pomiarowe z konkretną instalacją zgłoszoną w systemie grantowym.
Element identyfikacji wizualnej WiFi4EU
Sam snippet JavaScript nie wystarczy, żeby instalacja spełniała wymagania WiFi4EU. Na stronie logowania musi też pojawić się specjalny baner – element identyfikacji wizualnej, który snippet wypełnia odpowiednią grafiką w zależności od języka portalu. Na stronie musi więc istnieć znacznik img z identyfikatorem wifi4eubanner, który nie jest zasłonięty innymi elementami, ma ustawioną szerokość i wysokość oraz mieści się w widocznym obszarze strony po załadowaniu.
Minimalna struktura wygląda tak: <img id=”wifi4eubanner”>. Wielkość i położenie ustawia się przez CSS. Wymagania są konkretne – jeśli widoczny obszar strony ma szerokość mniejszą niż 600 pikseli, baner musi zajmować co najmniej 90% tej szerokości. Gdy obszar ma co najmniej 600 pikseli, element powinien wypełniać minimum 50% szerokości. Tylko wtedy można mówić o poprawnym wdrożeniu identyfikacji wizualnej.
Dla projektów WiFi4EU portal przechwytujący jest poprawnie wdrożony dopiero wtedy, gdy działa snippet pomiarowy, widoczny jest baner WiFi4EU oraz co najmniej 10 różnych urządzeń zalogowało się przez ten portal.
Jakie zagrożenia wiążą się z logowaniem do portalu przechwytującego?
Logowanie do portalu przechwytującego bywa mylone z innymi ekranami logowania – zwłaszcza na smartfonach. To pole otwiera drogę dla szkodliwych aplikacji, które podszywają się pod legalne strony i próbują przejąć wrażliwe dane. Dobrym przykładem jest zagrożenie wykrywane przez firmę ESET jako Android/Spy.Agent.SI, które rozprzestrzeniało się jako fałszywa aplikacja Flash Player.
Po instalacji z zainfekowanej strony uzyskiwało uprawnienia administratora urządzenia i skanowało system w poszukiwaniu aplikacji największych banków. Gdy taką aplikację znalazło, wyświetlało użytkownikowi fałszywy ekran logowania, blokując ekran do momentu wpisania loginu i hasła. Łącząc to z przechwytywaniem SMS‑ów autoryzujących przelewy, przestępcy potrafili wyprowadzać pieniądze z kont, a użytkownik miał wrażenie, że loguje się do prawdziwego banku.
Dlatego nawet przy typowym logowaniu do portalu przechwytującego na publicznym Wi‑Fi warto zwrócić uwagę na kilka podstawowych zasad: korzystać tylko z aplikacji pobranych z oficjalnych sklepów, nie instalować niczego sugerowanego przez wyskakujące okna w przeglądarce, mieć na telefonie aktualne oprogramowanie ochronne i z dystansem podchodzić do stron logowania, które proszą o dane bankowe czy pełne dane karty płatniczej.
FAQ – najczęściej zadawane pytania
Co to jest portal przechwytujący (Captive Portal)?
To mechanizm sieciowy, który blokuje ruch użytkownika i pokazuje stronę logowania zanim urządzenie uzyska pełny dostęp do internetu. Składa się z konfiguracji punktów dostępowych, serwera HTTP i reguł na routerze lub zaporze.
Gdzie najczęściej spotykam portale przechwytujące?
W miejscach publicznych takich jak hotele, lotniska, samoloty i miejskie sieci Wi‑Fi oraz w sieciach firmowych i szkolnych. Są też używane w sieciach dla gości oraz w projektach grantowych.
Jak Android wykrywa portal przechwytujący w wersjach 5.0–11?
System wysyła krótkie nieszyfrowane sondy HTTP i sprawdza, czy odpowiedź jest przekierowaniem. Jeśli widzi przekierowanie, pokazuje powiadomienie o konieczności zalogowania.
Czym różni się wykrywanie portalu w Androidzie 11 i nowszych?
Android 11 wykorzystuje DHCP Option 114 i pobiera plik JSON z adresu API portalu zamiast zgadywać po przekierowaniach. Od Androida 12 moduł Network Stack można aktualizować osobno, co poprawia obsługę różnych portali.
Co to jest Captive Portal API i do czego służy?
To interfejs, w którym sieć udostępnia JSON z informacją o stanie portalu, adresie strony logowania i czasie sesji. Dzięki temu urządzenie od razu wie, czy i jak wyświetlić ekran logowania.
Jak skonfigurować wykrywanie portalu przechwytującego w ChromeOS?
Administrator zmienia ustawienie wykrywania portalu w konsoli administracyjnej Google w sekcji Urządzenia → Sieci dla wybranej sieci Wi‑Fi. Zmiana automatycznie trafia do zarządzanych urządzeń i wymusza automatyczne otwieranie strony logowania.
Jakie wymagania stawia program WiFi4EU dla portalu przechwytującego?
Wymaga dedykowanej strony autoryzacji, działającego snippetu pomiarowego i widocznego banera identyfikacji wizualnej oraz logowania co najmniej 10 różnych urządzeń. Dopiero spełnienie tych warunków pozwala uznać instalację za poprawną.
Jakie zagrożenia niesie logowanie przez portal przechwytujący i jak się chronić?
Ryzykiem są fałszywe strony lub aplikacje wyłudzające dane, które mogą przechwytywać loginy i SMS‑y autoryzacyjne. Należy używać aplikacji z oficjalnych sklepów, unikać instalowania czegokolwiek z wyskakujących okien i mieć aktualne oprogramowanie ochronne.
