Jakie są typowe porty serwera localhost?
Opublikowano 13 maja 2026
Serwer localhost zwykle działa dobrze, dopóki dwie usługi nie zechcą używać tego samego portu, przeglądarka nie wyświetli komunikatu o odrzuceniu połączenia albo framework po cichu nie uruchomi się na numerze, którego się nie spodziewałeś. Właśnie wtedy to pytanie bardzo szybko staje się praktyczne: jakie są typowe porty używane przez serwery localhost i do czego służą? Krótka odpowiedź jest taka, że kilka numerów portów pojawia się wciąż na nowo, ponieważ odpowiadają standardowym protokołom, popularnym narzędziom deweloperskim lub domyślnym ustawieniom frameworków. Gdy poznasz ten schemat, rozwiązywanie problemów staje się znacznie spokojniejsze.
Do czego faktycznie służą porty localhost
Port to punkt końcowy, na którym usługa nasłuchuje w obrębie hosta. Na localhost ten host to Twój własny komputer, zwykle adresowany jako 127.0.0.1 lub localhost. Adres IP mówi ruchowi, do której maszyny ma dotrzeć. Port mówi mu, która usługa na tej maszynie powinna odpowiedzieć.
Jeśli uruchamiasz aplikację webową na localhost:3000, Twoja przeglądarka łączy się z Twoim własnym komputerem i żąda usługi nasłuchującej na porcie 3000. Jeśli PostgreSQL działa na localhost:5432, Twoja aplikacja wysyła tam zamiast tego ruch do bazy danych. Ta sama maszyna, inne drzwi.
To ma znaczenie, ponieważ lokalne stosy deweloperskie są często zatłoczone. Serwer deweloperski frontendu, API, baza danych, Redis, narzędzie do testowania poczty i dashboard metryk mogą działać na jednym laptopie. Zachowują porządek, używając różnych portów.
Typowe porty serwera localhost i ich zastosowania
Niektóre porty są oficjalnymi standardami. Inne stały się powszechne, ponieważ popularne narzędzia wybrały je lata temu i ten zwyczaj pozostał. Oba typy pojawiają się w rzeczywistej pracy programistycznej.
Port 80
Port 80 jest domyślny dla HTTP. Jeśli otwierasz zwykłą stronę internetową bez podania portu, przeglądarka zakłada 80. Na localhost jest to mniej powszechne w codziennym tworzeniu aplikacji, ponieważ powiązanie z niskimi portami może wymagać podwyższonych uprawnień w niektórych systemach, a deweloperzy często wolą nie uruchamiać edytora, terminala i stosu webowego jako root. Rozsądny wybór.
Mimo to port 80 pojawia się w lokalnych konfiguracjach reverse proxy, środowiskach opartych na Dockerze i testach, które muszą dokładniej odtwarzać zachowanie produkcyjne.
Port 443
Port 443 jest domyślny dla HTTPS. Jeśli testujesz SSL lokalnie, jest to standardowy cel. W wielu konfiguracjach lokalne proxy lub serwer webowy kończy HTTPS na 443 i przekazuje ruch do aplikacji działającej na innym porcie, takim jak 3000 lub 8000.
Jest to przydatne, gdy musisz testować bezpieczne cookies, callbacki OAuth, service workery lub cokolwiek, co zachowuje się inaczej w HTTPS.
Port 3000
Port 3000 to jeden z najbardziej znajomych portów localhost dla web developerów. Jest powszechnie używany przez aplikacje Node.js i frameworki frontendowe. Narzędzia oparte na React, Next.js w trybie deweloperskim i wiele aplikacji Express domyślnie działa właśnie tutaj.
Jeśli na komputerze deweloperskim zawsze jest otwarta karta przeglądarki z localhost:3000, nie jest to nic niezwykłego. Zwykle oznacza to, że działa aplikacja frontendowa lub lekki serwer webowy.
Port 5000
Port 5000 jest często używany przez frameworki webowe Pythona, szczególnie Flask, oraz przez różne lekkie lokalne API. To także częsty port zapasowy, gdy inny preferowany port jest zajęty.
Często zobaczysz go w prototypach backendu, narzędziach wewnętrznych lub szybkich usługach proof of concept, gdzie celem jest szybkość, a nie formalności.
Port 5173
Port 5173 stał się powszechny, ponieważ Vite używa go jako domyślnego portu serwera deweloperskiego. Nowoczesne projekty frontendowe zbudowane przy użyciu Vite często startują tutaj, chyba że port jest zajęty.
To dobry przykład tego, jak nowsze narzędzia tworzą nowe normalne zachowania. Oficjalny protokół nie nadał 5173 specjalnego znaczenia dla lokalnego developmentu. Zrobiło to narzędzie.
Port 8000
Port 8000 to klasyczny port lokalnego developmentu. Często używa go wbudowany prosty serwer HTTP Pythona. Django powszechnie używa 8000 podczas developmentu. Pojawia się tu także wiele ogólnych serwerów aplikacyjnych i wewnętrznych interfejsów administracyjnych.
Jest popularny częściowo dlatego, że łatwo go zapamiętać i rzadko wymaga specjalnej obsługi ze strony systemu operacyjnego.
Port 8080
Port 8080 to jeden z najszerzej używanych alternatywnych portów HTTP. Jeśli port 80 jest standardowymi drzwiami frontowymi, 8080 jest bocznymi drzwiami, które wszyscy znają. Często używają go serwery aplikacyjne Java, usługi proxy, lokalne dashboardy i testowe aplikacje webowe.
Jest także powszechny w środowiskach konteneryzowanych i lokalnych konfiguracjach reverse proxy.
Port 8081 i pobliskie porty
Porty takie jak 8081, 8082 i 8888 są często używane, gdy 8080 jest już zajęty albo gdy kilka interfejsów webowych musi działać obok siebie. Nie ma tu żadnej głębokiej magii. To głównie praktyczna numeracja.
Zobaczysz to w workflow agencji i SaaS, gdzie kilka aplikacji, paneli administracyjnych i środowisk podglądowych działa jednocześnie.
Port 27017
Port 27017 jest domyślny dla MongoDB. Jeśli Twoja aplikacja łączy się z lokalną instancją MongoDB, prawdopodobnie używany jest ten port, chyba że celowo go zmieniłeś.
Ponieważ jest to port bazy danych, nie należy go lekkomyślnie wystawiać poza localhost, chyba że masz bardzo świadomie zaprojektowaną politykę sieciową i dostępu.
Port 3306
Port 3306 jest domyślny dla MySQL i MariaDB. To jeden z najbardziej rozpoznawalnych portów baz danych w hostingu i operacjach aplikacyjnych.
Lokalne aplikacje zbudowane z użyciem PHP, Laravel, WordPress i wielu niestandardowych systemów biznesowych często wskazują na localhost:3306 podczas developmentu lub w instalacjach na pojedynczym serwerze.
Port 5432
Port 5432 jest domyślny dla PostgreSQL. Jeśli Twój stos używa Django, Rails, nowoczesnych backendów SaaS lub aplikacji intensywnie korzystających z analityki, ten port pojawia się często.
W porównaniu z portami webowymi porty baz danych są mniej widoczne w przeglądarce, ale to właśnie tam często znajduje się rzeczywisty stan aplikacji. Jeśli ten port jest zablokowany, aplikacja może się uruchomić, ale i tak zawiedzie we wszystkich interesujących miejscach.
Port 6379
Port 6379 domyślnie należy do Redis. Redis jest używany do cache'owania, kolejek, sesji, ograniczania szybkości i wzorców pub/sub.
W lokalnym developmentcie Redis często działa cicho w tle, aż coś się zepsuje i nagle staje się głównym bohaterem. To normalne.
Port 9200
Port 9200 jest powszechnie kojarzony z interfejsami HTTP API Elasticsearch lub OpenSearch. Często używają go aplikacje intensywnie korzystające z wyszukiwania, narzędzia observability i pipeline'y logów.
Ponieważ te usługi mogą być zasobożerne, lokalny proces nasłuchujący tutaj może wyjaśniać, dlaczego maszyna deweloperska jest mniej radosna niż zwykle.
Dlaczego te porty stały się powszechne
Niektóre z tych numerów są przypisane przez konwencję lub organizacje standaryzacyjne. HTTP na 80, HTTPS na 443, MySQL na 3306, PostgreSQL na 5432 - to stabilne ustawienia domyślne, ponieważ interoperacyjność ma znaczenie.
Inne stały się powszechne, ponieważ frameworki potrzebowały rozsądnych ustawie ń domyślnych, a deweloperzy wolą nie wpisywać codziennie dodatkowych flag. W ten sposób 3000, 5000, 8000 i 5173 stały się znajome. To nie są uniwersalne prawa. To przyzwyczajenia, które przerodziły się w oczekiwania.
To rozróżnienie ma znaczenie przy rozwiązywaniu problemów. Jeśli PostgreSQL nie działa na 5432, ktoś prawdopodobnie to zmienił. Jeśli aplikacja frontendowa nie działa na 3000, może to po prostu oznaczać, że inny proces był tam pierwszy.
Co się dzieje, gdy porty są w konflikcie
Konflikt portów oznacza, że jeden proces już nasłuchuje na porcie, a inny próbuje użyć tego samego. Druga usługa nie może się powiązać albo automatycznie wybiera inny port.
Dlatego projekt, który zwykle działa na 3000, może nagle uruchomić się na 3001. Logi opowiadają teraz tę samą historię: coś innego już zajmowało 3000. Na obciążonej stacji roboczej może to być inny serwer deweloperski, pozostawiony kontener albo osierocony proces po awarii.
Praktyczne rozwiązanie jest proste. Sprawdź, który proces zajmuje ten port, zatrzymaj go, jeśli nie powinien działać, albo skonfiguruj jedną z usług tak, aby używała innego portu. W zarządzanych środowiskach hostingowych i stagingowych dobre monitorowanie pomaga wychwycić to szybciej, zanim zamieni się to w wątek wsparcia pełen zgadywania.
Kiedy warto zmienić domyślny port
Zmiana domyślnego portu jest przydatna, gdy kilka podobnych usług musi działać razem, gdy wymaga tego lokalna polityka bezpieczeństwa albo gdy potrzebujesz, by Twoja konfiguracja deweloperska odzwierciedlała określony wzorzec wdrożenia.
Może to także pomóc uniknąć kolizji w Dockerze, lokalnych klastrach Kubernetes i współdzielonych maszynach deweloperskich. Minusem jest przewidywalność. Ustawienia domyślne są łatwiejsze do zapamiętania dla zespołów, łatwiejsze do udokumentowania i często wygodniejsze dla narzędzi. Niestandardowe porty dają elastyczność, ale tworzą też jeszcze jedną rzecz, o której można zapomnieć sześć tygodni później.
W przypadku zespołów najlepsze podejście jest zwykle nudne i spójne. Zachowuj standardowe porty tam, gdzie ma to sens. Zmieniaj je tylko wtedy, gdy istnieje ku temu wyraźny powód operacyjny.
Bezpieczeństwo i porty localhost
Usługa nasłuchująca na localhost jest zwykle osiągalna tylko z tej samej maszyny. To zmniejsza ryzyko, ale go nie eliminuje. Złośliwe oprogramowanie, lokalne ataki z poziomu przeglądarki lub nieostrożne przekierowanie portów nadal mogą powodować problemy.
Bezpieczniejszą praktyką jest powiązanie wrażliwych usług, takich jak bazy danych i pamięci podręczne, z 127.0.0.1, chyba że zdalny dostęp jest naprawdę wymagany. Jeśli potrzebny jest zdalny dostęp, dodaj odpowiednie reguły zapory, uwierzytelnianie, szyfrowanie tam, gdzie to właściwe, oraz monitorowanie. Spokojne systemy to zwykle te, które nie zostały przypadkowo pozostawione otwarte.
Praktyczny sposób patrzenia na porty localhost
Jeśli chcesz mieć szybki model myślowy, potraktuj porty jako trzy grupy. Porty 80 i 443 to standardy webowe. Porty takie jak 3000, 5000, 5173, 8000 i 8080 to typowe porty aplikacji i serwerów deweloperskich. Porty takie jak 3306, 5432, 6379 i 27017 to specyficzne dla usług porty backendowe dla baz danych i cache.
Samo to pomaga w zaskakująco dużej liczbie przypadków rozwiązywania problemów. Jeśli localhost:3000 nie działa, pomyśl o serwerze aplikacji. Jeśli localhost:5432 nie działa, pomyśl o bazie danych. Jeśli localhost:443 zachowuje się dziwnie, pomyśl o TLS, reverse proxy, certyfikacie lub lokalnej konfiguracji HTTPS.
W przypadku firm obsługujących coś więcej niż zabawkowy stos dobra dyscyplina infrastrukturalna ma znaczenie nawet w developmentcie i stagingu. To jeden z powodów, dla których dostawcy tacy jak kodu.cloud przywiązują wagę do zarządzanego wsparcia, monitorowania i przewidywalnych środowisk. Problemy są mniejsze, gdy mapa portów jest zrozumiała, zanim pojawi się ruch.
Przydatna myśl na koniec jest taka: typowe porty localhost mniej polegają na zapamiętywaniu numerów, a bardziej na rozpoznawaniu wzorców usług. Gdy już wiesz, które porty zwykle należą do serwerów webowych, frameworków aplikacyjnych, baz danych i cache, możesz diagnozować lokalne problemy znacznie szybciej i z mniejszą paniką.
Andres Saar Inżynier ds. obsługi klienta