Πώς να διορθώσετε το σφάλμα “Port 8080 Is Already in Use” στο Terminal σε Windows, macOS και Linux

Μέχρι τον Σεπτέμβριο του 2026, η τρέχουσα τεκμηρίωση των Node.js και Docker εξακολουθεί να περιγράφει αυτή την κατηγορία σφάλματος ως τυπική σύγκρουση δέσμευσης διεύθυνσης. Καμία επαληθευμένη αλλαγή σε αυτές τις πηγές δεν απαιτεί νέα μέθοδο αντιμετώπισης προβλημάτων. Η πρακτική αιτία παραμένει η ίδια: ένα πρόγραμμα προσπαθεί να ακούσει σε μια διεύθυνση και θύρα που ήδη κατέχει άλλη διαδικασία. Η τρέχουσα τεκμηρίωση του Node.js περιγράφει το σχετικό σφάλμα EADDRINUSE ως αποτυχημένη δέσμευση επειδή ένας άλλος διακομιστής καταλαμβάνει την τοπική διεύθυνση, ενώ το Docker τεκμηριώνει την ίδια κατάσταση ως port is already allocated ή bind: address is already in use. Η τεκμηρίωση συστημικών σφαλμάτων του Node.js και ο οδηγός αντιμετώπισης προβλημάτων σύγκρουσης θυρών του Docker αντικατοπτρίζουν και τα δύο αυτή τη συμπεριφορά μέχρι τον Σεπτέμβριο του 2026.

Η πρακτική λύση είναι επομένως διαρκής: βρείτε τη διαδικασία που ακούει στη θύρα TCP 8080, εντοπίστε τι είναι, σταματήστε την μόνο αν είναι ασφαλές να γίνει, ή ρυθμίστε τη νέα σας εφαρμογή να χρησιμοποιήσει διαφορετική θύρα. Μην ξεκινήσετε σκοτώνοντας τυχαία PID. Ένα εργαλείο βάσης δεδομένων, ένας proxy, ένα container Docker, ένας βοηθός IDE, μια υπηρεσία Java ή ένα άλλο αντίγραφο του δικού σας διακομιστή ανάπτυξης μπορεί να χρησιμοποιεί την 8080 σκόπιμα.

Τι σημαίνει πραγματικά το “port 8080 is already in use”;

Ένας διακομιστής συνήθως ζητά από το λειτουργικό σύστημα να δεσμεύσει μια υποδοχή (socket) σε μια τοπική διεύθυνση όπως 127.0.0.1:8080, 0.0.0.0:8080 ή [::]:8080. Αν ένας μη συμβατός ακροατής κατέχει ήδη αυτόν τον συνδυασμό διεύθυνσης και θύρας, ο δεύτερος διακομιστής δεν μπορεί να την διεκδικήσει. Τα frameworks εκθέτουν την αποτυχία του λειτουργικού συστήματος με διαφορετική διατύπωση: το Node.js συνήθως αναφέρει EADDRINUSE, τα frameworks Python μπορεί να εμφανίσουν OSError: [Errno 98] Address already in use, και το Docker μπορεί να αναφέρει ότι η θύρα του host είναι ήδη δεσμευμένη.

Αυτό από μόνο του δεν αποτελεί απόδειξη προβλήματος firewall ή κατεστραμμένης σύνδεσης δικτύου. Το πρώτο χρήσιμο ερώτημα είναι: ποια διαδικασία ακούει στην 8080;

Γρήγορη απάντηση: ποια εντολή πρέπει να εκτελέσετε;

Αυτές οι εντολές είναι διαγνωστικές αρχικά. Η ασφαλέστερη ακολουθία είναι: εντοπισμός → απόφαση → διακοπή ή επαναδιαμόρφωση → επαλήθευση.

Βήμα 1: Επιβεβαιώστε ότι κάτι ακούει στη θύρα 8080

Αν η εφαρμογή σας εκτυπώνει address already in use, EADDRINUSE ή port is already allocated, η σύγκρουση είναι συνήθως ήδη σαφής. Αν το μήνυμα σφάλματος είναι λιγότερο συγκεκριμένο, αναζητήστε τους τοπικούς ακροατές TCP αντί να υποθέσετε ότι η 8080 είναι το πρόβλημα.

Στα Windows, η τεκμηρίωση του netstat της Microsoft επιβεβαιώνει ότι το -a συμπεριλαμβάνει θύρες ακρόασης, το -n κρατά τις διευθύνσεις και τις θύρες αριθμητικές, και το -o προσθέτει το PID του κατόχου. Στο PowerShell, η τεκμηρίωση του Get-NetTCPConnection υποστηρίζει φιλτράρισμα ανά τοπική θύρα και κατάσταση.

Get-NetTCPConnection -LocalPort 8080 -State Listen

Αν αυτό επιστρέψει μια γραμμή, σημειώστε την τιμή OwningProcess. Αν δεν επιστρέψει τίποτα, συνεχίστε με την ενότητα «τίποτα δεν φαίνεται να κατέχει την 8080» παρακάτω πριν σκοτώσετε οτιδήποτε.

Βήμα 2: Βρείτε τη διαδικασία στο macOS

Στο macOS, το lsof είναι ένας άμεσος τρόπος για να εντοπίσετε τη διαδικασία που κρατά μια υποδοχή ακρόασης TCP:

lsof -nP -iTCP:8080 -sTCP:LISTEN

Το επίσημο εγχειρίδιο lsof τεκμηριώνει το -iTCP για υποδοχές TCP Internet και το -sTCP:LISTEN για φιλτράρισμα στην κατάσταση ακρόασης. Η έξοδος συνήθως περιλαμβάνει ένα όνομα εντολής και ένα PID.

Για παράδειγμα, αν η εντολή αναφέρει PID 12345, μην πηδήξετε αμέσως στο kill -9 12345. Πρώτα καθορίστε αν είναι ο παλιός σας διακομιστής ανάπτυξης, μια τοπική υπηρεσία που χρειάζεστε, ή μια διαδικασία που διαχειρίζεται κάτι άλλο.

Βήμα 3: Βρείτε τη διαδικασία στα Windows

Στο Command Prompt ή στο PowerShell, αυτή η ευρέως υποστηριζόμενη εντολή είναι απλή:

netstat -ano | findstr :8080

Αναζητήστε μια γραμμή του οποίου η τοπική διεύθυνση τελειώνει σε :8080 και του οποίου η κατάσταση είναι LISTENING. Η τελευταία στήλη είναι το PID. Μπορείτε στη συνέχεια να ελέγξετε αυτό το PID στο PowerShell:

Get-Process -Id 12345

Ή χρησιμοποιήστε τον Διαχειριστή Εργασιών (Task Manager) αν προτιμάτε μια γραφική επαλήθευση. Η Microsoft σημειώνει ρητά ότι η επιλογή -o εμφανίζει το PID ώστε να μπορείτε να εντοπίσετε την εφαρμογή. Αυτή η επαλήθευση είναι σημαντική επειδή το ίδιο μηχάνημα μπορεί να έχει πολλές μη σχετιζόμενες διαδικασίες Java, Node, Python, container και παρασκηνίου να εκτελούνται ταυτόχρονα.

Βήμα 4: Βρείτε τον ακροατή στο Linux

Σε σύγχρονα συστήματα Linux, το ss είναι συνήθως η πιο χρήσιμη εντολή επιθεώρησης υποδοχών:

ss -ltnp | grep ':8080'

Η σελίδα εγχειριδίου ss τεκμηριώνει το -l για υποδοχές ακρόασης, το -t για TCP, το -n για αριθμητική έξοδο και το -p για πληροφορίες διαδικασίας. Ανάλογα με τα δικαιώματα, οι λεπτομέρειες της διαδικασίας μπορεί να απαιτούν sudo.

Μια εναλλακτική είναι:

sudo fuser -v 8080/tcp

Η σελίδα εγχειριδίου fuser τεκμηριώνει τον χώρο ονομάτων TCP και σημειώνει ότι οι πληροφορίες διαδικασίας μπορεί να είναι ελλιπείς όταν δεν έχετε άδεια να επιθεωρήσετε τους περιγραφείς άλλου χρήστη.

Βήμα 5: Πρέπει να σταματήσετε τη διαδικασία ή να την κρατήσετε;

Αυτό είναι το σημείο απόφασης που αποτρέπει τα περισσότερα αυτοπαθή προβλήματα. Αν το PID 12345 είναι μια εγκαταλελειμμένη αντίγραφο του διακομιστή ανάπτυξης που σκοπεύατε να επανεκκινήσετε, η διακοπή του είναι λογική. Αν είναι ένας τοπικός αντίστροφος proxy, ένας εταιρικός πράκτορας, μια κοινή υπηρεσία ολοκλήρωσης ή ένα container στο οποίο βασίζεται ένα άλλο έργο, η αλλαγή της θύρας της νέας σας εφαρμογής είναι συνήθως πιο ασφαλής.

Ελέγξτε επίσης αν η διαδικασία ανήκει σε έναν επόπτη (supervisor). Μια υπηρεσία που εκκινείται από το systemd, το Docker Compose, έναν εκτελεστή εργασιών IDE ή έναν άλλο διαχειριστή διαδικασιών μπορεί να επανεκκινείται αμέσως μετά τη δολοφονία της θυγατρικής της διαδικασίας. Σε αυτή την περίπτωση, σταματήστε ή επαναδιαμορφώστε τον επόπτη αντί να σκοτώνετε επανειλημμένα το θυγατρικό PID.

Μπορείτε απλώς να χρησιμοποιήσετε το Ctrl+C;

Ναι—αν ο παλιός διακομιστής είναι ακόμα ανοιχτός σε άλλο τερματικό που ελέγχετε, η επιστροφή σε αυτό το τερματικό και η πίεση του Ctrl+C είναι συχνά η πιο καθαρή λύση. Επιτρέπει στον διακομιστή να χειριστεί τη φυσιολογική του διαδικασία τερματισμού αντί να τερματιστεί από έξω.

Βήμα 6: Σταματήστε τη συγκρουόμενη διαδικασία με ασφάλεια

Στο macOS ή Linux, ξεκινήστε με το προεπιλεγμένο σήμα τερματισμού:

kill 12345

Το εγχειρίδιο kill του Linux δηλώνει ότι η προεπιλογή είναι το TERM και το συνιστά ρητά έναντι του KILL επειδή μια διαδικασία μπορεί να χειριστεί το TERM και να εκτελέσει καθαρισμό. Χρησιμοποιήστε το kill -9 μόνο ως έσχατη λύση όταν μια διαδικασία που έχετε επαληθεύσει ότι είναι ασφαλής για τερματισμό δεν θα βγει φυσιολογικά.

Στο Windows PowerShell, η Microsoft παρέχει το Stop-Process:

Stop-Process -Id 12345 -Confirm

Η τεκμηρίωση του Stop-Process υποστηρίζει τη διακοπή ανά PID και σημειώνει ότι μπορεί να απαιτούνται αυξημένα δικαιώματα για διαδικασίες που δεν κατέχετε. Η επιλογή -Confirm είναι χρήσιμη όταν θέλετε έναν επιπλέον έλεγχο πριν τον τερματισμό.

Οι χρήστες του Command Prompt μπορούν να χρησιμοποιήσουν:

taskkill /PID 12345

Προσθέστε /F μόνο όταν ένας φυσιολογικός τερματισμός δεν είναι αρκετός. Η τεκμηρίωση του taskkill της Microsoft ορίζει το /PID για την επιλογή της διαδικασίας και το /F για αναγκαστικό τερματισμό.

Βήμα 7: Ελέγξτε το Docker πριν κατηγορήσετε μια φυσιολογική διαδικασία host

Το Docker είναι ένας κοινός λόγος για τον οποίο οι προγραμματιστές βλέπουν την θύρα 8080 κατειλημμένη ακόμα και όταν δεν φαίνεται να είναι ανοιχτό κάποιο παράθυρο εφαρμογής. Εκτελέστε:

docker ps

Κοιτάξτε στη στήλη PORTS για μια αντιστοίχιση που δημοσιεύει την θύρα host 8080. Η τρέχουσα τεκμηρίωση αντιμετώπισης προβλημάτων του Docker αναφέρει ρητά μια υπάρχουσα εφαρμογή ή ένα προηγούμενο εκτελούμενο container ως αιτίες σφαλμάτων port already allocated.

Μπορείτε να επιθεωρήσετε τις αντιστοιχίσεις ενός συγκεκριμένου container με:

docker port CONTAINER_NAME

Η τεκμηρίωση της εντολής port του Docker ορίζει αυτή την εντολή ως έναν τρόπο για την απαρίθμηση των αντιστοιχίσεων θυρών ενός container. Αν το container δεν χρειάζεται πλέον, σταματήστε το καθαρά:

docker stop CONTAINER_NAME

Το Docker τεκμηριώνει ότι το docker stop στέλνει πρώτα το ρυθμισμένο σήμα διακοπής, συνήθως SIGTERM, πριν καταφύγει σε αναγκαστική δολοφονία μετά την περίοδο χάριτος.

Βήμα 8: Επανεκκινήστε την εφαρμογή και επαληθεύστε ότι η 8080 είναι ελεύθερη

Ξεκινήστε ξανά την εφαρμογή σας χρησιμοποιώντας την κανονική της εντολή. Αν τώρα αναφέρει επιτυχημένη δέσμευση στο 127.0.0.1:8080, η σύγκρουση έχει επιλυθεί.

Μπορείτε επίσης να επαναλάβετε την ίδια εντολή επιθεώρησης που χρησιμοποιήσατε νωρίτερα. Πριν ξεκινήσετε τον νέο διακομιστή, το ερώτημα δεν πρέπει να δείχνει ανεπιθύμητο ακροατή. Μετά την εκκίνηση, ο ακροατής πρέπει να ανήκει στη διαδικασία που περιμένετε.

Τι γίνεται αν η διαδικασία που χρησιμοποιεί την 8080 πρέπει να παραμείνει σε λειτουργία;

Μην τη σκοτώσετε. Δώστε στη νέα σας εφαρμογή μια διαφορετική θύρα όπως την 8081, 3000 ή άλλη ελεύθερη θύρα ανάπτυξης. Η ακριβής σύνταξη εξαρτάται από το framework.

Για το Flask, η επίσημη τεκμηρίωση διακομιστή ανάπτυξης συνιστά ρητά την επιλογή διαφορετικής θύρας όταν ένα άλλο πρόγραμμα κατέχει την προεπιλεγμένη θύρα:

flask --app app run --port 8081

Για το Django 6.1, ο διακομιστής ανάπτυξης δέχεται τη θύρα ως όρισμα:

python manage.py runserver 8081

Το τρέχον tutorial του Django και η αναφορά runserver τεκμηριώνουν την εκτέλεση ταυτόχρονων διακομιστών ανάπτυξης σε ξεχωριστές θύρες.

Για το Spring Boot, η τυπική ιδιότητα είναι η server.port. Η τεκμηρίωση διαμόρφωσης του Spring Boot δείχνει την server.port ως ρύθμιση θύρας διακομιστή.

Τι γίνεται αν καμία εντολή δεν δείχνει διαδικασία στην θύρα 8080;

Εξετάστε αυτούς τους ελέγχους πριν υποθέσετε ότι το λειτουργικό σύστημα κάνει λάθος.

• Ελέγξτε τόσο IPv4 όσο και IPv6. Μια υπηρεσία μπορεί να ακούει στο 0.0.0.0:8080, 127.0.0.1:8080, [::]:8080 ή σε μια συγκεκριμένη διεύθυνση διεπαφής. Αποφύγετε το πολύ στενό φιλτράρισμα ώστε να μην χάσετε τον πραγματικό ακροατή.
• Εκτελέστε την επιθεώρηση με επαρκή δικαιώματα. Τα εργαλεία Linux μπορεί να παραλείπουν λεπτομέρειες διαδικασίας για υποδοχές που ανήκουν σε άλλους χρήστες. Τα Windows μπορεί επίσης να απαιτούν ανύψωση δικαιωμάτων για ορισμένες λειτουργίες διαδικασιών.
• Ελέγξτε containers και εικονικοποιημένα περιβάλλοντα. Το Docker Desktop, το WSL, οι εικονικές μηχανές και τα εργαλεία τοπικού Kubernetes μπορούν να κάνουν την πηγή λιγότερο προφανή από μια διαδικασία τερματικού προσκηνίου.
• Αναζητήστε έναν βρόχο αυτόματης επανεκκίνησης. Αν το PID αλλάζει αμέσως μετά τον τερματισμό του, ένας επόπτης πιθανώς επανεκκινεί την υπηρεσία.
• Διαχωρίστε το LISTEN από το TIME_WAIT. Μια σύνδεση TCP σε TIME_WAIT δεν είναι το ίδιο πράγμα με μια διαδικασία που ακούει ενεργά στην 8080. Εστιάστε πρώτα σε έναν ακροατή και τη διαδικασία κατόχου.
• Επιβεβαιώστε την ακριβή διεύθυνση δέσμευσης. Ένα σφάλμα που αναφέρει μόνο «8080» μπορεί να κρύβει αν η εφαρμογή προσπαθεί να δεσμεύσει το localhost, κάθε διεπαφή, IPv4 ή IPv6.

Γιατί η θύρα 8080 συνεχίζει να γίνεται απασχολημένη ξανά;

Αν το σφάλμα επιστρέφει μετά από κάθε επανεκκίνηση ή σύνδεση, μια μόνιμη υπηρεσία πιθανώς ξεκινά αυτόματα. Κοινά παραδείγματα περιλαμβάνουν μια εργασία ανάπτυξης που εκτελείται από IDE, μια στοίβα Docker Compose, μια υπηρεσία Java παρασκηνίου, έναν proxy ή έναν διαχειριστή υπηρεσιών του λειτουργικού συστήματος. Αντί να αντιμετωπίζετε κάθε υποτροπή ως ένα μεμονωμένο πρόβλημα PID, βρείτε το στοιχείο που εκκινεί τον ακροατή και αλλάξτε τη διαμόρφωση ή τη συμπεριφορά εκκίνησης του.

Αν η σύγκρουση συμβαίνει μόνο αφού ξεκινήσετε και σταματήσετε επανειλημμένα τη δική σας εφαρμογή, ελέγξτε αν μια προηγούμενη περίπτωση εκτελείται ακόμα σε άλλο τερματικό, αν ο debugger σας εκκινεί μια δεύτερη διαδικασία και αν ένας επαναφορτωτής παρακολούθησης αρχείων έχει γονική και θυγατρική διαδικασία. Η βασική δοκιμή παραμένει η ίδια: επιθεωρήστε τον ακροατή και επαληθεύστε την ταυτότητά του.

Πρέπει να χρησιμοποιήσετε kill -9, taskkill /F ή να επανεκκινήσετε τον υπολογιστή;

Συνήθως όχι ως πρώτο βήμα. Ένας φυσιολογικός τερματισμός δίνει σε μια διαδικασία την ευκαιρία να κλείσει αρχεία, να εκκαθαρίσει buffers, να σταματήσει θυγατρικές εργασίες και να απελευθερώσει πόρους καθαρά. Ο αναγκαστικός τερματισμός είναι χρήσιμος όταν μια επαληθευμένη διαδικασία έχει κολλήσει, αλλά θα πρέπει να είναι η κλιμακωτή διαδρομή και όχι η προεπιλογή.

Μια επανεκκίνηση μπορεί να καθαρίσει μια παλιά διαδικασία ανάπτυξης, αλλά κρύβει επίσης την αιτία. Αν η συγκρουόμενη υπηρεσία είναι ρυθμισμένη να ξεκινά αυτόματα, η θύρα μπορεί να είναι ξανά κατειλημμένη αμέσως μετά την επανεκκίνηση. Ο εντοπισμός του κατόχου της 8080 είναι μακροπρόθεσμα πιο γρήγορος.

Μια αξιόπιστη ακολουθία αντιμετώπισης προβλημάτων

1. Διαβάστε το ακριβές σφάλμα και επιβεβαιώστε ότι είναι σύγκρουση δέσμευσης διεύθυνσης/θύρας.
2. Ερωτήστε την θύρα 8080 για μια διαδικασία ακρόασης.
3. Καταγράψτε το PID και εντοπίστε το όνομα της διαδικασίας.
4. Αποφασίστε αν αυτή η διαδικασία πρέπει να παραμείνει σε λειτουργία.
5. Αν είναι μια παρωχημένη διαδικασία, σταματήστε την κομψά.
6. Αν διαχειρίζεται από το Docker ή έναν άλλο επόπτη, σταματήστε ή επαναδιαμορφώστε τον διαχειριστή.
7. Αν η διαδικασία είναι νόμιμη, ρυθμίστε τη νέα σας εφαρμογή να χρησιμοποιήσει άλλη ελεύθερη θύρα.
8. Επανεκκινήστε την εφαρμογή και επαληθεύστε ότι η αναμενόμενη διαδικασία κατέχει τώρα την επιλεγμένη θύρα.

Η ίδια ροή εργασίας λειτουργεί για σφάλματα στις θύρες 3000, 5000, 8000, 8081 και στις περισσότερες άλλες τοπικές θύρες ανάπτυξης. Ο αριθμός της θύρας αλλάζει· η διάγνωση όχι.

Κύριες αναφορές

• Node.js: συστημικά σφάλματα και EADDRINUSE
• Microsoft Learn: netstat
• Microsoft Learn: Get-NetTCPConnection
• Microsoft Learn: Stop-Process
• Εγχειρίδιο έργου lsof
• Σελίδα εγχειριδίου ss του Linux
• Docker: αντιμετώπιση προβλημάτων θύρας ήδη δεσμευμένης
• Διακομιστής ανάπτυξης Flask: διεύθυνση ήδη σε χρήση
• Αναφορά runserver του Django 6.1