Od rujna 2026., trenutna dokumentacija za Node.js i Docker i dalje opisuje ovu vrstu greške kao standardni sukob pri vezanju adrese; nema provjerene promjene u tim izvorima koja zahtijeva novu metodu rješavanja problema. Praktični uzrok ostaje isti: program pokušava slušati na adresi i portu koje već posjeduje drugi proces. Trenutna dokumentacija za Node.js opisuje povezanu grešku EADDRINUSE kao neuspjelo vezanje jer drugi server zauzima lokalnu adresu, a Docker dokumentira isto stanje kao port is already allocated ili bind: address is already in use. Dokumentacija sustavskih grešaka Node.js-a i Dockerov vodič za rješavanje sukoba portova oba odražavaju ovo ponašanje od rujna 2026.
Praktično rješenje je stoga trajno: pronađite proces koji sluša na TCP portu 8080, identificirajte što je, zaustavite ga samo ako je sigurno zaustaviti ga, ili konfigurirajte svoju novu aplikaciju da koristi drugi port. Nemojte početi ubijanjem nasumičnih PID-ova. Alat za bazu podataka, proxy, Dockerov kontejner, pomoćnik IDE-a, Java usluga ili druga kopija vašeg vlastitog razvojnog servera mogu namjerno koristiti 8080.
Server obično traži od operativnog sustava da veže utičnicu (socket) na lokalnu adresu poput 127.0.0.1:8080, 0.0.0.0:8080 ili [::]:8080. Ako nekompatibilni slušatelj već drži tu kombinaciju adrese i porta, drugi server ne može je preuzeti. Okviri (frameworks) izlažu grešku operativnog sustava različitim riječima: Node.js obično prijavljuje EADDRINUSE, Python okviri mogu prikazati OSError: [Errno 98] Address already in use, a Docker može prijaviti da je host port već dodijeljen.
To samo po sebi nije dokaz problema s vatrozidom ili pokvarene mrežne veze. Prvo korisno pitanje je: koji proces sluša na 8080?
| Platforma | Pronađite slušatelja | Tipičan sljedeći korak |
|---|---|---|
| Windows PowerShell | Get-NetTCPConnection -LocalPort 8080 -State Listen | Provjerite OwningProcess, zatim koristite Get-Process -Id PID |
| Windows Command Prompt | netstat -ano | findstr :8080 | Pročitajte PID u zadnjem stupcu |
| macOS | lsof -nP -iTCP:8080 -sTCP:LISTEN | Provjerite naredbu i PID prije korištenja kill PID |
| Linux | ss -ltnp | grep ':8080' | Provjerite proces, ili koristite sudo fuser -v 8080/tcp |
| Docker | docker ps | Potražite mapiranje hosta poput 0.0.0.0:8080->8080/tcp |
Ove su naredbe prvenstveno dijagnostičke. Najsigurniji slijed je: identificiraj → odluči → zaustavi ili prekonfiguriraj → provjeri.
Ako vaša aplikacija ispisuje address already in use, EADDRINUSE ili port is already allocated, sukob je obično već jasan. Ako je poruka o grešci manje specifična, upitajte lokalne TCP slušatelje umjesto da pretpostavljate da je 8080 problem.
Na Windowsima, Microsoftova dokumentacija za netstat potvrđuje da -a uključuje portove koji slušaju, -n zadržava adrese i portove numeričkim, a -o dodaje PID vlasnika. U PowerShellu, Microsoftova dokumentacija za Get-NetTCPConnection podržava filtriranje po lokalnom portu i stanju.
Get-NetTCPConnection -LocalPort 8080 -State Listen
Ako to vrati redak, zabilježite njegovu vrijednost OwningProcess. Ako ne vrati ništa, nastavite s donjim odjeljkom “ništa ne čini da posjeduje 8080” prije nego što ubijete bilo što.
lsof identificira proces i PID povezan sa slušateljem na portu 8080.Na macOSu, lsof je izravan način za identifikaciju procesa koji drži TCP utičnicu koja sluša:
lsof -nP -iTCP:8080 -sTCP:LISTEN
Službeni priručnik za lsof dokumentira -iTCP za TCP Internet utičnice i -sTCP:LISTEN za filtriranje u stanje slušanja. Izlaz obično uključuje naziv naredbe i PID.
Na primjer, ako naredba prijavi PID 12345, nemojte odmah prijeći na kill -9 12345. Prvo utvrdite je li to vaš stari razvojni server, lokalna usluga koju trebate, ili proces kojim upravlja nešto drugo.
U Command Promptu ili PowerShellu, ova široko podržana naredba je jednostavna:
netstat -ano | findstr :8080
Potražite redak čija lokalna adresa završava s :8080 i čije je stanje LISTENING. Zadnji stupac je PID. Zatim možete pregledati taj PID u PowerShellu:
Get-Process -Id 12345
Ili koristite Upravitelj zadataka ako preferirate grafičku provjeru. Microsoft izričito napominje da opcija -o prikazuje PID kako biste mogli identificirati aplikaciju. Ova provjera je važna jer isto računalo može imati mnogo nepovezanih Java, Node, Python, kontejnerskih i pozadinskih procesa koji rade istovremeno.
Na modernim Linux sustavima, ss je obično najkorisnija naredba za pregled utičnica:
ss -ltnp | grep ':8080'
Priručnik za ss dokumentira -l za utičnice koje slušaju, -t za TCP, -n za numerički izlaz i -p za informacije o procesu. Ovisno o dopuštenjima, detalji o procesu mogu zahtijevati sudo.
Alternativa je:
sudo fuser -v 8080/tcp
Priručnik za fuser dokumentira TCP imenski prostor i napominje da informacije o procesu mogu biti nepotpune kada nemate dopuštenje za pregled deskriptora drugog korisnika.
Ovo je točka odluke koja sprječava većinu samonanesenih problema. Ako je PID 12345 napuštena kopija razvojnog servera koji ste namjeravali ponovno pokrenuti, zaustavljanje je razumno. Ako je to lokalni obrnuti proxy, korporativni agent, zajednička integracijska usluga ili kontejner od kojeg ovisi drugi projekt, promjena porta vaše nove aplikacije obično je sigurnija.
Također provjerite pripada li proces nadzorniku (supervisoru). Usluga koju je pokrenuo systemd, Docker Compose, pokretač zadataka IDE-a ili drugi upravitelj procesa može se odmah ponovno pokrenuti nakon što ubijete njegov podproces. U tom slučaju, zaustavite ili prekonfigurirajte nadzornika umjesto da ponovno ubijate PID podprocesa.
Da – ako je stari server i dalje otvoren u drugom terminalu kojim vi upravljate, vraćanje u taj terminal i pritiskanje Ctrl+C često je najčišće rješenje. To omogućuje serveru da obradi svoj normalni put gašenja umjesto da bude prisilno prekinut izvana.
Na macOSu ili Linuxu, počnite s zadanim signalom za završetak:
kill 12345
Linux priručnik za kill navodi da je zadani signal TERM i izričito ga preporučuje umjesto KILL jer proces može obraditi TERM i izvršiti čišćenje. Koristite kill -9 samo kao krajnje sredstvo kada proces za koji ste provjerili da je sigurno zaustaviti ga neće normalno izaći.
U Windows PowerShellu, Microsoft pruža Stop-Process:
Stop-Process -Id 12345 -Confirm
Dokumentacija za Stop-Process podržava zaustavljanje po PID-u i napominje da mogu biti potrebna povišena prava za procese koje ne posjedujete. Opcija -Confirm korisna je kada želite dodatnu provjeru prije završetka.
/F samo nakon što identificirate PID i normalno zaustavljanje nije dovoljno.Korisnici Command Prompta mogu koristiti:
taskkill /PID 12345
Dodajte /F samo kada normalni završetak nije dovoljan. Microsoftova dokumentacija za taskkill definira /PID za odabir procesa i /F za prisilni završetak.
Docker je čest razlog zašto programeri vide port 8080 zauzetim čak i kada se ne čini da je otvoren nijedan prozor aplikacije. Pokrenite:
docker ps
Potražite u stupcu PORTS mapiranje koje objavljuje host port 8080. Dockerova trenutna dokumentacija za rješavanje problema izričito navodi postojeću aplikaciju ili prethodno pokrenuti kontejner kao uzroke grešaka port already allocated.
Možete pregledati mapiranja specifičnog kontejnera s:
docker port NAZIV_KONTEJNERA
Dokumentacija za Docker port naredbu definira ovu naredbu kao način za navođenje mapiranja portova kontejnera. Ako kontejner više nije potreban, zaustavite ga uredno:
docker stop NAZIV_KONTEJNERA
Docker dokumentira da docker stop prvo šalje konfigurirani signal za zaustavljanje, obično SIGTERM, prije nego što prijeđe na prisilno ubijanje nakon razdoblja milosti.
Ponovno pokrenite svoju aplikaciju koristeći svoju normalnu naredbu. Ako sada prijavi uspješno vezanje na 127.0.0.1:8080, sukob je riješen.
Također možete ponovno pokrenuti istu naredbu za pregled koju ste koristili ranije. Prije pokretanja novog servera, upit ne bi trebao pokazati neželjenog slušatelja. Nakon pokretanja, slušatelj bi trebao pripadati procesu koji očekujete.
Nemojte ga ubiti. Dajte svojoj novoj aplikaciji drugi port poput 8081, 3000 ili drugog slobodnog razvojnog porta. Točna sintaksa ovisi o okviru (frameworku).
Za Flask, službena dokumentacija razvojnog servera izričito preporučuje odabir drugog porta kada drugi program posjeduje zadani port:
flask --app app run --port 8081
Za Django 6.1, razvojni server prihvaća port kao argument:
python manage.py runserver 8081
Djangoov trenutni tutorijal i runserver referenca dokumentiraju pokretanje istodobnih razvojnih servera na odvojenim portovima.
Za Spring Boot, standardno svojstvo je server.port. Dokumentacija za konfiguraciju Spring Boot-a pokazuje server.port kao postavku porta servera.
Prođite kroz ove provjere prije nego što pretpostavite da je operativni sustav pogrešan.
0.0.0.0:8080, 127.0.0.1:8080, [::]:8080 ili adresi specifičnog sučelja. Izbjegavajte filtriranje tako usko da propustite stvarnog slušatelja.TIME_WAIT nije isto što i proces koji aktivno sluša na 8080. Prvo se fokusirajte na slušatelja i procesa vlasnika.Ako se greška vraća nakon svakog ponovnog pokretanja ili prijave, vjerojatno se trajna usluga automatski pokreće. Uobičajeni primjeri uključuju razvojni zadatak pokrenut iz IDE-a, Docker Compose stack, pozadinsku Java uslugu, proxy ili upravitelja usluga OS-a. Umjesto da svako ponavljanje tretirate kao jednokratni problem s PID-om, pronađite komponentu koja pokreće slušatelja i promijenite njegovu konfiguraciju ili ponašanje pri pokretanju.
Ako se sukob događa samo nakon što vi ponovno pokrećete i zaustavljate svoju vlastitu aplikaciju, provjerite je li ranija instanca i dalje pokrenuta u drugom terminalu, pokreće li vaš debugger drugi proces i ima li ponovni učitavač koji prati datoteke roditeljski i podproces. Ključni test ostaje isti: pregledajte slušatelja i provjerite njegov identitet.
Obično ne kao prvi korak. Normalno gašenje daje procesu priliku da zatvori datoteke, isprazni međuspremnike, zaustavi podzadatke i uredno oslobodi resurse. Prisilni prekid koristan je kada je provjereni proces zaglavljen, ali to bi trebao biti put eskalacije, a ne zadano stanje.
Ponovno pokretanje može očistiti zastarjeli razvojni proces, ali također skriva uzrok. Ako je sukobljena usluga konfigurirana da se automatski pokreće, port može biti ponovno zauzet odmah nakon ponovnog pokretanja. Identificiranje vlasnika 8080 dugoročno je brže.
Isti tijek rada funkcionira za greške na portovima 3000, 5000, 8000, 8081 i većini drugih lokalnih razvojnih portova. Broj porta se mijenja; dijagnoza ne.
Ispravite Tailwind CSS stilove koji se ne ažuriraju u Vite Reactu provjerom postavki Tailwind v4, CSS uvoza, otkrivanja izvora, dinamičkih klasa, HMR-a i zastarjelih predmemorija.
Ispravite ModuleNotFoundError u Pythonu 3 za pip na Windowsima, macOS-u i Linuxu pomoću ensurepipa, OS paketa, virtualnih okruženja i provjera interpretera.
Ispravite GitHub SSH Permission Denied (publickey) provjerom hosta, aktivnog SSH ključa, GitHub računa, SSO autorizacije, udaljenog URL-a i pristupa portu 22.
Sigurno ispravite Git push koji ne omogućuje brzo premotavanje. Zaštitite lokalni rad, dohvatite udaljene commitove, odaberite spajanje ili rebase, riješite sukobe i pushajte bez gubitka promjena.
Ispravite greške Nginx 502 Bad Gateway s Node.js uzvodno provjerom porta aplikacije, NGINX logova, proxy_pass adrese, umrežavanja kontejnera, vremenskih ograničenja i ponovnog učitavanja.
Ispravljena je greška "Tip 'null' nije moguće dodijeliti tipu" u TypeScriptu s tipovima unija, sužavanjem, zadanim vrijednostima i sigurnim tvrdnjama pod strictNullChecks.
Ispravite pogrešku da Prisma Client nije generiran provjerom generatora, sheme, izlazne putanje, uvoza, verzija, monorepo postavki i koraka izgradnje pri implementaciji.
Ispravite Node.js ERR_MODULE_NOT_FOUND u ESM-u provjerom putanja uvoza, ekstenzija datoteka, instalacije paketa, izvoza, ESM načina rada i čistih instalacija.
Riješite Gitovu grešku 'nemoguće dobiti lokalni certifikat izdavatelja' identificiranjem pozadine povjerenja, instaliranjem ispravnog lanca CA i održavanjem omogućene SSL verifikacije.
Riješite greške mrežnog isteka vremena MongoDB u Mongooseu identificiranjem vrste isteka, testiranjem dostupnosti Atlasa ili TCP-a, ispravljanjem URI-ja i podešavanjem vremena isteka samo kada je opravdano.
