127.0.0.1:49342: Adres IP hosta lokalnego, port i przewodnik debugowania

Może coś kliknąłeś. Może przewinąłeś okno terminala. Może plik dziennika przykuł twoją uwagę. Cokolwiek to było, pojawił się ciąg znaków: `127.0.0.1:49342`. Twoja przeglądarka przeskoczyła na stronę, której nie ma w internecie. Narzędzia programistyczne ją oznaczyły. Okienko logowania zamigotało i zniknęło. Nic nie było widoczne. Coś jednak nadal wydawało się nie tak.

Spokojnie, nic się nie zepsuło. Ten mały ciąg znaków to w rzeczywistości jedna z najczęstszych rzeczy, jakie zobaczysz podczas korzystania z komputera, a gdy tylko zrozumiesz jego dwie połówki, każde kolejne `127.0.0.1:` będzie brzmiało jak zwykłe zdanie. Adres IP po lewej stronie to uniwersalna pętla zwrotna, taka sama na każdym komputerze, którego dotkniesz. Port po prawej stronie to po prostu konkretny port, który system operacyjny przydzielił lokalnej usłudze, aplikacji internetowej lub innej usłudze sieciowej do krótkiej rozmowy między programami działającymi na Twoim sprzęcie. Żaden z nich nie łączy się z siecią zewnętrzną. Wszystko pozostaje na jednym pudełku przed Tobą.

Oto plan. Jedno wyjaśnienie i jeden przewodnik rozwiązywania problemów, wszystko spięte w całość. Skąd historycznie pochodzi adres. Co tak naprawdę oznacza numer portu. Dlaczego konkretnie 49342 nie jest niczym szczególnym. Kiedy widzi go użytkownik systemu Windows, a kiedy ktoś na Linuksie lub macOS. Jak wygląda sytuacja bezpieczeństwa w 2026 roku? Jak programiści kryptowalut wykorzystują ten sam schemat w środowisku programistycznym Web3 z Hardhat, Anvil, Ganache i Bitcoin Core. Przeczytaj całość od początku do końca lub przejdź od razu do sekcji, która odpowiada temu, czego szukałeś.

Czym jest 127.0.0.1: Wyjaśnienie adresu pętli zwrotnej

Zacznijmy od połowy adresu IP. Adres 127.0.0.1 jest starszy niż większość rzeczy, których używasz obecnie w internecie. W październiku 1989 roku, na długo przed powstaniem komercyjnej sieci WWW, IETF wycofał dokument RFC 1122. W sekcji 3.2.1.3 ukryta była jedna z najbardziej dosadnych zasad sieciowych, jakie kiedykolwiek spisano: „Adresy w tej formie NIE MOGĄ pojawiać się poza hostem”. System operacyjny Twojego telefonu wymusza to do dziś. Twój router domowy również. Każdy system operacyjny, który pojawił się od tamtej pory, po cichu go respektuje.

Skala ludzi zaskakuje. Ta zasada dotyczy 16 777 216 adresów. Wszystkich. Szesnaście milionów adresów jest w rezerwie, więc jeden z nich, 127.0.0.1, może niezawodnie oznaczać „tę maszynę, tutaj” w dowolnym miejscu na Ziemi. Trochę marnotrawstwa? Tak, skargi słyszano od dziesięcioleci. Globalna pula adresów IPv4 IANA spadła do zera 3 lutego 2011 r. ARIN spadł do zera 24 września 2015 r. RIPE NCC wydało swój ostateczny blok /22 25 listopada 2019 r. Projekt IETF o nazwie „draft-schoen-intarea-unicast-127” krążył wokół sugestii, że większość przestrzeni 127 mogłaby wrócić do użytku jednokierunkowego. Nikt nie chce tego ruszać. Zbyt wiele istniejącego oprogramowania zakłada, że 127 nigdy się nie zmieni.

Jedna rzecz, która zawsze zaskakuje nowicjuszy: pakiet dosłownie nigdy nie dociera do fizycznej karty sieciowej. Ani trochę. Pakiet skierowany do dowolnego miejsca docelowego 127.xxx zostaje przechwycony przez stos TCP/IP systemu operacyjnego na warstwie 3 i przepchnięty przez interfejs wirtualny (w Linuksie i macOS nazywa się to „lo”). Jądro nadal wykonuje prawdziwą pracę — buduje segment TCP, oblicza sumę kontrolną, przechodzi ścieżkę odbioru. To realny narzut, niezerowy. Ale żaden przełącznik w sieci LAN nigdy nie widzi tego ruchu. Żaden router go nie widzi. Żadna sieć szkieletowa go nie widzi.

Słowo „localhost” to po prostu przyjazny dla użytkownika alias odwzorowany w pliku tekstowym, który możesz otworzyć już teraz. W systemach Linux i macOS: `/etc/hosts`. W systemie Windows: `C:\Windows\System32\drivers\etc\hosts`. Program rozpoznający adresy łączy się z tym plikiem, zanim zapyta serwer DNS, dlatego `localhost` działa poprawnie na płaszczyźnie z wyłączonym Wi-Fi. IPv6 wprowadza własną wersję, `::1/128`, zdefiniowaną w dokumencie RFC 4291 w lutym 2006 roku. Klasyczny piątkowy problem: nowoczesna przeglądarka najpierw rozpoznaje `localhost` jako `::1`, ale aplikacja Pythona łączy się tylko z adresem 127.0.0.1. Różne gniazda, brak przecięcia, cicha awaria. Co tydzień ktoś gdzieś przerywa przepływ danych.

Dlaczego widzisz port 49342: Porty tymczasowe i zakresy IANA

A teraz druga połowa. Numery portów mylą ludzi bardziej niż adresy IP, i nie bez powodu. Rejestr portów nazw usług i protokołów transportowych IANA dzieli całą 16-bitową przestrzeń (od 0 do 65535) na trzy segmenty, a to, do którego segmentu trafi 49342, to już cała historia.

Port 49342 znajduje się w zakresie dynamicznym. Nic nie jest do niego „zarejestrowane” i nigdy nie będzie, ponieważ IANA odmawia przydzielania usług w tym zakresie, aby systemy operacyjne mogły swobodnie przydzielać numery portów do tymczasowego użytku. Port efemeryczny to port dynamicznie przydzielany, o który aplikacja nie prosiła, podając konkretny numer portu. System operacyjny zwrócił komunikat: „Daj mi dowolny wolny port, potrzebuję go tylko na tę sesję”. System operacyjny zwrócił 49342, aplikacja powiązała gniazdo nasłuchujące, a przepływ danych, który potrzebował krótkotrwałej kombinacji adresu i portu, otrzymał ją. Port 49342 jest często używany przez tymczasowy serwer lokalny, wykorzystujący tego typu powiązanie ad-hoc.

Domyślny zakres tymczasowy różni się w zależności od systemu operacyjnego.

W systemach Windows i macOS, 49342 znajduje się dokładnie w zakresie domyślnym. Prawie na pewno przydzielił go program alokujący system operacyjny. W systemie Linux sytuacja wygląda inaczej — 49342 znajduje się powyżej domyślnego zakresu od 32768 do 60999, więc został wybrany przez aplikację, która poprosiła jądro o `bind(('127.0.0.1', 0))` i otrzymała wszystko, co było wolne. RFC 6056, wydany przez IETF w styczniu 2011 roku, nakazuje stosom losowe wybieranie portów efemerycznych w całej przestrzeni od 1024 do 65535 ze względów bezpieczeństwa. Przewidywalne porty ułatwiają przechwytywanie przepływów. Dlatego ten sam serwer deweloperski może dziś trafić na 49342, jutro na 54871, a pojutrze na 33200.

Gdzie na Twoim komputerze wyświetla się adres 127.0.0.1:49342

Kiedy więc to się faktycznie pojawia w normalnym dniu? Lokalny serwer działający na porcie 49342 może być praktycznie wszystkim, od długiej listy kategorii narzędzi dla deweloperów, w których programiści testują aplikacje pod kątem lokalnego gniazda pętli zwrotnej. Poniższa tabela przedstawia typowe przypadki, w których porty takie jak 49342 pojawiają się w praktyce, a usługi działają i akceptują połączenia za każdym razem na określonym porcie.

Jedyny przypadek, w którym dosłownie w pasku adresu przeglądarki pojawia się `127.0.0.1:49342`? Prawie zawsze OAuth. Dokument IETF RFC 8252, zatytułowany „OAuth 2.0 dla aplikacji natywnych”, ukazał się w październiku 2017 roku i nakazuje aplikacjom natywnym korzystanie z przepływu przekierowania pętli zwrotnej, z jedną niezmienną regułą: serwer autoryzacji „MUSI zezwolić na dowolny numer portu”. Uruchom `gh auth login` lub `gcloud auth login`. Interfejs wiersza poleceń uruchamia mały serwer HTTP na losowym, efemerycznym porcie, uruchamia przeglądarkę u dostawcy tożsamości, przechwytuje wywołanie zwrotne na tym adresie pętli zwrotnej i wyłącza się. Widzisz, jak jeden z adresów localhost, taki jak 127.0.0.1:49342, miga przez może dwie sekundy, zanim zniknie. To nie błąd. To nie tracker. To nie oszustwo. To tylko bardzo krótkie uzgadnianie, całkowicie lokalne, nigdy nie docierające do sieci zewnętrznej.

Rozwiązywanie problemów z błędami i konfliktami portów 127.0.0.1:49342

Z mojego doświadczenia wynika, że problemy z localhostem występują w pięciu odmianach. Dosłownie wszystko, co zmusza do szukania o 23:00, w jakiś sposób pasuje do jednej z tych kategorii.

Port jest już używany. Węzeł krzyczy `EADDRINUSE`. Python podaje `OSError: [Errno 98] Address already in use`, ładnie i brzydko. Windows po prostu mruga `WinSock 10048` i wychodzi. Ta sama podstawowa prawda w każdym przypadku: inny proces na twoim komputerze przechwycił 49342 jako pierwszy. Twoim zadaniem jest go znaleźć, zabić i odzyskać.

• W systemie Linux: `ss -tulpn | grep :49342` lub wypróbuj starą komendę `sudo lsof -i :49342`
• Na komputerze Mac: `lsof -nP -iTCP:49342 -sTCP:LISTEN`
• W systemie Windows w programie PowerShell: `netstat -ano | findstr :49342`, następnie `tasklist /fi "PID eq "`, aby zamienić ten PID na nazwę programu

Serwer działa, nic nie może się połączyć. Natykasz się na to częściej, niż pamiętasz. IPv4 i IPv6 po cichu się z Tobą krzyżują. Twój serwer powiązał się z adresem 127.0.0.1. Twoja przeglądarka bez powodu rozpoznała `localhost` jako `::1`. To dwa różne gniazda, więc oczywiście nic się nie łączy. Napraw to, wiążąc obie rodziny jednocześnie (nasłuchiwanie na `::` zazwyczaj wychwytuje adresy mapowane na IPv4 również w większości stosów) lub po prostu wpisz 127.0.0.1 bezpośrednio w adresie URL.

Sieci VPN niszczą pętlę zwrotną. Cloudflare WARP jest zdecydowanie największym winowajcą. Cloudflare przyznaje się do tego na swojej stronie dokumentacji dotyczącej znanych ograniczeń: szczególnie na macOS, rozłączenie WARP może całkowicie usunąć trasę 127.0.0.1. Jeśli Twój lokalny host przestał działać zaraz po przełączeniu VPN, to prawie na pewno właśnie dlatego. Połącz ponownie WARP lub przywróć trasę ręcznie za pomocą `sudo ifconfig lo0 127.0.0.1 alias`. Proton VPN, Mullvad i NordVPN praktycznie nigdy tego nie powodują, cokolwiek by to nie znaczyło. Programy antywirusowe dla przedsiębiorstw i EDR to zupełnie inna historia; niektóre z nich przechwytują i przekierowują ruch pętli zwrotnej w sposób, który szybko staje się dziwny.

HSTS pamięta testy HTTPS, o których zapomniałeś. Miesiące temu testowałeś certyfikat podpisany przez siebie na `localhost`. Chrome zrobił to, co robi Chrome i zapisał nagłówek HSTS w pamięci podręcznej. Teraz każde zwykłe żądanie `http://localhost` po cichu przepisuje na https. Debugowanie jest super. Dwie minuty naprawy: otwórz `chrome://net-internals/#hsts` i usuń wpis.

Reguły zapory sieciowej. Funkcja Loopback domyślnie przechodzi przez większość zapór sieciowych. Większość. Niektóre obrazy laptopów firmowych celowo filtrują localhost w ramach ochrony przed złośliwym oprogramowaniem, a Ty odkrywasz to pod koniec długiego czwartku. Zaawansowane reguły ruchu przychodzącego Zapory systemu Windows Defender to miejsce, w którym należy to sprawdzić. W systemie Linux: `sudo ufw status verbose`. Jeśli coś naprawdę wymaga otwarcia, zezwól tylko na określony port; nie wyłączaj całej zapory sieciowej.

Jest jednak jeden nawyk, który zawsze mnie ratuje. Zanim dotknę choćby jednej reguły zapory lub trasy, uruchamiam `lsof` lub `netstat`. W połowie przypadków okazuje się, że to proces-zombie, uparcie utrzymujący port z wersji deweloperskiej, która uległa awarii dziś rano. `kill -9` dla PID. Problem znika w kilka sekund.

Konfigurowanie hosta lokalnego i serwera do użytku deweloperskiego

Kompilacja zamiast debugowania? Nabierz kilku nawyków związanych z konfiguracją serwera, a zaoszczędzisz mnóstwo popołudni. Nic z tego nie jest wymyślne. Dążymy do czegoś nudnego: niezawodnego testowania i debugowania wielu usług sieciowych i różnych usług na jednym laptopie, i to wszystko.

Zasada pierwsza, ta nudna: połącz się z `127.0.0.1`, a nie `0.0.0.0`. Nasłuchuj na `0.0.0.0`, a twój mały serwer webowy nagle reklamuje się na każdym interfejsie sieciowym, który posiadasz. To znaczy: przypadkowy gość przy sąsiednim stoliku w kawiarni go znajdzie. Powiąż się z 127.0.0.1, a tylko to, co już jest na twoim komputerze, dostanie się do sieci. `http.server` Pythona, `express.listen()` Node'a, `http.ListenAndServe` Go — wszystkie akceptują dosłowny adres IP. Po prostu go wpisz.

Zasada druga: jeśli naprawdę nie zależy ci na porcie, nie wybieraj. Przekaż port 0 do nasłuchiwacza (`server.listen(0)` w Node, `bind(('127.0.0.1', 0))` w Pythonie), a jądro zwróci wszystko, co jest wolne w tej milisekundzie. Wywołaj później `getsockname()`, aby dowiedzieć się, co faktycznie otrzymałeś i przekaż to dowolnemu komponentowi, który chce uzyskać adres URL. Zasadniczo każdy interfejs wiersza poleceń OAuth i każdy adapter debugowania, którego kiedykolwiek używałeś, robi dokładnie to samo.

Zasada trzecia: zmienne środowiskowe, a nie zakodowane na stałe porty. Pobierz `PORT` ze środowiska, domyślnie użyj czegoś sensownego, jeśli brakuje. Ten sam plik binarny uruchamia się w środowisku deweloperskim pod adresem 127.0.0.1:5173, a w środowisku produkcyjnym za pośrednictwem odwrotnego proxy pod adresem 443. Zastosuj ten sam schemat do ciągów znaków w bazie danych, kluczy API i wszystkiego innego. Dokumentacja aplikacji Twelve-Factor jest starsza niż dokumentacja niektórych Twoich kolegów, ale nadal jest to najtańszy sposób na uniknięcie przerw w działaniu.

Zasada czwarta: HTTPS na localhost nie jest już problemem. Zarówno Chrome, jak i Firefox przyznają status bezpiecznego kontekstu `localhost` i `127.0.0.1` dla większości funkcji, nawet bez prawdziwego certyfikatu. Wybredna biblioteka nadal odmawia certyfikatu podpisanego przez siebie? Użyj `mkcert`, wciąż najmniej irytującego lokalnego urzędu certyfikacji. Wbudowane narzędzia, takie jak `http.server` w Pythonie i moduł `net` w Node, pozwalają na skonfigurowanie serwera lokalnego w zaledwie pięciu linijkach kodu podczas lokalnego tworzenia aplikacji, co pozwala programistom testować aplikację internetową pod realistycznym obciążeniem, wykorzystując te same skrypty do testów integracyjnych, gdzie usługi komunikują się przez pętlę zwrotną.

Ostatnia i tak naprawdę najważniejsza zasada. Produkcja nie jest lokalna. Kropka. Twój komputer lokalny stanowi granicę zaufania; kontener produkcyjny nią nie jest. Nigdy nie zostawiaj punktów końcowych debugowania działających pod adresem 127.0.0.1 w kontenerze produkcyjnym, ponieważ inne procesy w tym samym kontenerze docierają do nich pierwszego dnia, a po wystąpieniu błędu w środowisku wykonawczym atakujący również się do nich wkrada. Używaj ruchu lokalnego tylko tam, gdzie faktycznie należy, w środowiskach programistycznych i nigdzie indziej, a w dniu, w którym jakiekolwiek wewnętrzne API korzystające z portu zostanie przeniesione do środowiska współdzielonego lub produkcyjnego, natychmiast wprowadź przed nim prawdziwe uwierzytelnianie. Żadnego „naprawimy to po uruchomieniu”. Tak było w poprzedniej firmie.

Bezpieczne korzystanie z portu 49342: bezpieczeństwo adresu pętli zwrotnej

Localhost wydaje się prywatny. I przeważnie taki jest. Aż nagle przestaje taki być.

Oto haczyk, z którym w końcu każdy się spotyka. Zewnętrzni atakujący nie mogą bezpośrednio wybrać numeru 127.0.0.1, to prawda. Ale z pewnością mogą oszukać Twoją przeglądarkę lub jakąś aplikację na Twoim komputerze, której już ufasz, aby wykonała połączenie w ich imieniu. Cała ta klasa ataków nazywa się ponownym wiązaniem DNS. Działa on na serwerach localhost od czasów, gdy większość osób czytających ten tekst nie pisała jeszcze kodu.

Przykładem, do którego wciąż odwołują się osoby związane z kryptowalutami, jest atak na MyEtherWallet z 24 kwietnia 2018 roku. Atakujący przejęli kontrolę BGP na Route 53 Amazona, przekierowali DNS dla myetherwallet.com i podali klon phishingowy, który działał wystarczająco długo, by wykraść około 215 ETH (około 152 000 do 160 000 dolarów, w zależności od znacznika czasu, według raportów The Register i Internet Society). Wiem, że nie było to włamanie do lokalnego hosta. Ale to był punkt zwrotny, w którym społeczność kryptowalut przestała udawać, że model źródłowy przeglądarki stanowi realną granicę bezpieczeństwa. Każdy lokalny most portfela, dyskretnie nasłuchujący na porcie pętli zwrotnej, nagle stał się odsłonięty.

Odpowiedź Chrome pojawiła się jako Private Network Access, pierwotnie nazywana CORS-RFC1918 w wersjach roboczych. Od marca 2024 roku przeglądarka uruchamia preflight CORS z wartością `Access-Control-Request-Private-Network: true`, zanim jakakolwiek publiczna witryna uzyska dostęp do adresu prywatnego lub adresu pętli zwrotnej. Usługa lokalna musi odpowiedzieć wartością `Access-Control-Allow-Private-Network: true`, aby zatwierdzić. Pełne egzekwowanie obowiązuje w wersjach Chrome od 123 do 130. Jeśli więc wysyłasz serwer deweloperski pod adres 127.0.0.1:49342, oczekując, że strona publiczna dotrze do niego podczas testów integracyjnych, ustaw ten nagłówek. W przeciwnym razie żądanie po prostu zniknie.

Kilka luk CVE w Electronie z 2025 roku zasługuje na omówienie, skoro już o tym mowa. CVE-2025-10585 to błąd powodujący pomyłkę typu V8, dodany do katalogu znanych luk wykorzystywanych przez CISA 23 września 2025 roku. CVE-2025-55305 to obejście integralności kodu, które manipuluje migawkami sterty V8, ujawnione mniej więcej w tym samym czasie. Electron opakowuje Chromium, a na Twoim laptopie jest mnóstwo aplikacji Electron (Slack, VS Code, Discord, Notion, Teams i prawdopodobnie więcej). Wiele z nich udostępnia usługi lokalne w pętli zwrotnej. Łata szybko. I proszę, nigdy nie twórz punktu końcowego RPC na 127.0.0.1 bez tokena uwierzytelniającego, jeśli ten punkt końcowy może odczytywać klucze, podpisywać transakcje lub w jakikolwiek sposób manipulować pieniędzmi.

Jak twórcy kryptowalut wykorzystują localhost w Hardhat, Anvil i Ganache

Web3 dev to w zasadzie niekończący się ciąg odniesień do adresów sieciowych 127.0.0.1 — niezależnie od tego, czy skupiasz się na wdrażaniu kontraktów, testowaniu protokołów, czy po prostu codziennym tworzeniu stron internetowych w oparciu o lokalny łańcuch. Na Twoim laptopie działa teraz mały klaster węzłów lokalnych na localhost (nawet jeśli zapomniałeś o połowie z nich). Każdy z nich ma własne reguły dotyczące serwerów i portów. Każdy z nich udostępnia klientom odrębną kombinację adresu IP i portu, zazwyczaj korzystając z konkretnego portu domyślnie ustawionego przez narzędzie.

Krótka ściągawka. Sieć Hardhat Network od Nomic Foundation domyślnie wybiera `http://127.0.0.1:8545` z identyfikatorem łańcucha 31337. Anvil firmy Foundry deklaruje ten sam adres i port, konfigurowalny za pomocą `--port` na wypadek, gdyby dwa pakiety testowe były otwarte i ze sobą kolidowały. Interfejs graficzny Ganache pobiera `127.0.0.1:7545` z identyfikatorem sieci 5777, chociaż jego odpowiednik w interfejsie CLI ma identyfikator 8545, podobnie jak Hardhat. Tryb regtest w Bitcoin Core uruchamia JSON-RPC na `127.0.0.1:18443` — zmiana ta faktycznie pojawiła się w wersji 0.16 poprzez żądanie ściągnięcia nr 10825, po tym, jak ktoś zauważył konflikt z adresem 18332 w sieci testowej.

MetaMask łączy się dosłownie z każdym z nich. Dodaj niestandardową sieć z lokalnym adresem URL RPC i gotowe. Adres IP 127.0.0.1 działa jak cienki mostek między interfejsem użytkownika portfela w przeglądarce a symulowanym blockchainem, który w danej chwili działa na Twoim laptopie. Kiedy widzisz `127.0.0.1:` w śladzie stosu Web3, prawie zawsze jest to jedna z dwóch rzeczy: adapter debugera IDE atakujący węzeł lub sam węzeł uruchamia punkt końcowy WebSocket na losowym porcie tuż obok swojego stałego RPC.

Integracje płatności powtarzają ten schemat. Budujesz płatność kryptowalutową wspieraną przez Plisio? Ostatecznie uruchamiasz SDK lokalnie na małym nasłuchiwaczu Flask lub Express na `127.0.0.1:3000/plisio/callback`. Webhook bramy nigdy nie może dotrzeć bezpośrednio do Twojego laptopa z publicznego internetu, więc lokalne testy używają tunelu (ngrok, Cloudflare Tunnel, Tailscale Funnel) do ujawnienia portu. Jest to konkretny port na konkretnym numerze portu, który Ty, jako sprzedawca, wybierasz i kontrolujesz. Zestawy SDK Plisio dla PHP, Pythona, Laravela i Node.js zawierają pomocnika `verifyCallbackData`, który ponownie oblicza HMAC-SHA1 ładunku na podstawie tajnego klucza sklepu. Sprawdzanie jest przeprowadzane dla każdego wywołania zwrotnego, gdy trafia ono do lokalnego nasłuchiwacza. Ten sam adres pętli zwrotnej, to samo zadanie, dołączony prawdziwy podpis.

Oddal się na chwilę. Ten sam schemat jest właściwie wszędzie: płatności, OAuth, usługi sieciowe Web3 używane w procesie rozwoju – wszystkie wyglądają tak samo od wewnątrz – serwer na porcie 49342 lub innym porcie dynamicznym, rzeczywiste połączenia na określonym porcie i cały czas działają na localhost.

Szybkie sprawdzanie hosta lokalnego i portów dla dowolnego systemu operacyjnego

Krótka ściągawka. Trzymaj ją otwartą w zakładce terminala. Sięgniesz po nią częściej, niż myślisz.

Wyobraź sobie komputer z Linuksem, dowolną dystrybucję. `sudo ss -tulpn | grep :49342` odpowiada na pytanie „kto jest na 49342”. Pomiń ten grep, a otrzymasz wszystkie otwarte gniazda nasłuchujące komputera. Ciekawi Cię dynamiczny pułap portów jądra? `cat /proc/sys/net/ipv4/ip_local_port_range`. Jeśli chcesz tylko dowodu na to, że pętla zwrotna działa, `ip addr show lo` pokaże Ci to. I hej — jeśli `lo` zniknie z wyników, to masz znacznie większy problem niż port.

Mac działa podobnie, tylko z innymi narzędziami, ponieważ jest częścią świata BSD. `lsof -nP -iTCP:49342 -sTCP:LISTEN` wyświetla proces oczekujący na porcie. Usuń dwukropek i liczbę, a otrzymasz listę wszystkich nasłuchujących. Dodaj prefiks sudo, jeśli potrzebujesz wglądu w gniazda innych użytkowników. Zakres efemeryczny znajduje się w `sysctl net.inet.ip.portrange.first net.inet.ip.portrange.hifirst`. Pętla zwrotna nazywa się tutaj `lo0` (nie `lo`), a ta mała dziwaczna nazwa wychwytuje użytkowników dokładnie raz, zanim przyswoją ją na zawsze. Sprawdź za pomocą `ifconfig lo0`.

Windows całkowicie odwraca dialekt. Uruchom PowerShella jako administrator. `netstat -ano | findstr :49342` zwraca PID. Wrzuć to do `tasklist /fi "PID eq "`, aby przetłumaczyć numer na nazwę aplikacji. Zakres dynamiczny? `netsh int ipv4 show dynamicport tcp`. Trzeba przesunąć zakres w dół, ponieważ uparta starsza aplikacja wymaga czegoś na niższym poziomie? `netsh int ipv4 set dynamic tcp start=49152 num=16384` przesuwa go.

Zapamiętaj je, a problemy z lokalnym hostem skrócą się do pięciu minut, a może nawet szybciej. Spróbuj kiedyś tego: uruchom `lsof -nP -iTCP -sTCP:LISTEN | grep 127.0.0.1` na swoim działającym laptopie. Przewijana lista jest zawsze dłuższa, niż się spodziewasz. Karty w tle przeglądarki. Kilka serwerów języka edytora, często więcej niż jeden. Wewnętrzny DNS Dockera. Mostki Electron IPC ze Slacka, Discorda, Linear i innych używanych przez Ciebie urządzeń. Jakiś demon telemetrii systemu operacyjnego, o istnieniu którego nie miałeś pojęcia. Plus sześć lub siedem serwerów deweloperskich z dzisiejszego poranka, których na pewno zapomniałeś wyłączyć. Ten poziom szumów jest normalny. Tak właśnie brzmi działające środowisko deweloperskie.

Simon Chartan

A journalist with a strong technical background and a passion for decentralized finance. With degrees in MBA and Master of Engineering in Data Science, the author combines analytical expertise with a clear, engaging writing style. At Plisio, they cover topics such as cryptocurrency, blockchain, DeFi, and digital finance—helping readers make sense of a rapidly evolving fintech landscape.