Станом на вересень 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. Інструмент бази даних, проксі, контейнер Docker, допоміжний засіб IDE, служба Java або інша копія вашого власного сервера розробки можуть використовувати 8080 навмисно.
Сервер зазвичай просить операційну систему прив’язати сокет до локальної адреси, такої як 127.0.0.1:8080, 0.0.0.0:8080 або [::]:8080. Якщо несумісний слухач вже утримує цю комбінацію адреси та порту, другий сервер не може її зайняти. Фреймворки представляють збій операційної системи різними формулюваннями: Node.js зазвичай повідомляє про EADDRINUSE, фреймворки Python можуть показувати OSError: [Errno 98] Address already in use, а Docker може повідомляти, що хост-порт вже розподілено.
Це саме по собі не є доказом проблеми з брандмауером або зламаним мережевим з’єднанням. Перше корисне запитання: який процес прослуховує порт 8080?
| Платформа | Знайти слухача | Типовий наступний крок |
|---|---|---|
| Windows PowerShell | Get-NetTCPConnection -LocalPort 8080 -State Listen | Перевірте OwningProcess, потім використайте Get-Process -Id PID |
| Windows Command Prompt | netstat -ano | findstr :8080 | Прочитайте PID у останньому стовпці |
| macOS | lsof -nP -iTCP:8080 -sTCP:LISTEN | Перевірте команду та PID перед використанням kill PID |
| Linux | ss -ltnp | grep ':8080' | Перевірте процес або використайте sudo fuser -v 8080/tcp |
| Docker | docker ps | Шукайте відображення хоста, таке як 0.0.0.0:8080->8080/tcp |
Ці команди спочатку є діагностичними. Найбезпечніша послідовність: ідентифікувати → вирішити → зупинити або переналаштувати → перевірити.
Якщо ваш додаток виводить address already in use, EADDRINUSE або port is already allocated, конфлікт зазвичай вже зрозумілий. Якщо повідомлення про помилку менш конкретне, запитайте локальні TCP-слухачі, замість того щоб припускати, що проблема в 8080.
На Windows документація netstat від Microsoft підтверджує, що -a включає порти, що прослуховуються, -n зберігає адреси та порти в числовому форматі, а -o додає PID власника. У PowerShell документація Get-NetTCPConnection від Microsoft підтримує фільтрацію за локальним портом та станом.
Get-NetTCPConnection -LocalPort 8080 -State Listen
Якщо це повертає рядок, запишіть його значення OwningProcess. Якщо нічого не повертається, перейдіть до розділу «нічого не здається власником 8080» нижче, перш ніж вбивати будь-що.
lsof ідентифікує процес та PID, пов’язані зі слухачем на порту 8080.На macOS lsof є прямим способом ідентифікувати процес, що утримує TCP-сокет, що прослуховує:
lsof -nP -iTCP:8080 -sTCP:LISTEN
Офіційний посібник lsof документує -iTCP для TCP-інтернет-сокетів та -sTCP:LISTEN для фільтрації за станом прослуховування. Вивід зазвичай включає назву команди та PID.
Наприклад, якщо команда повідомляє PID 12345, не поспішайте одразу виконувати kill -9 12345. Спершу визначте, чи це ваш старий сервер розробки, локальна служба, яка вам потрібна, чи процес, керований чимось іншим.
У Command Prompt або PowerShell ця широко підтримувана команда є простою:
netstat -ano | findstr :8080
Шукайте рядок, локальна адреса якого закінчується на :8080, а стан — LISTENING. Останній стовпець — це PID. Потім ви можете перевірити цей PID у PowerShell:
Get-Process -Id 12345
Або використайте Диспетчер завдань, якщо вам подобається графічна перевірка. Microsoft явно зазначає, що опція -o відображає PID, щоб ви могли ідентифікувати додаток. Ця перевірка важлива, оскільки на тій самій машині одночасно може працювати багато не пов’язаних процесів Java, Node, Python, контейнерів та фонових служб.
На сучасних системах Linux ss зазвичай є найбільш корисною командою для інспектування сокетів:
ss -ltnp | grep ':8080'
Сторінка посібника ss документує -l для сокетів, що прослуховують, -t для TCP, -n для числового виводу та -p для інформації про процес. Залежно від дозволів, деталі процесу можуть вимагати sudo.
Альтернативою є:
sudo fuser -v 8080/tcp
Сторінка посібника fuser документує простір імен TCP і зазначає, що інформація про процес може бути неповною, якщо у вас немає дозволу на інспектування дескрипторів іншого користувача.
Це точка прийняття рішення, яка запобігає більшості проблем, створених власними руками. Якщо PID 12345 — це покинутий копія сервера розробки, який ви мали намір перезапустити, його зупинка є розумною. Якщо це локальний зворотний проксі, корпоративний агент, спільна інтеграційна служба або контейнер, від якого залежить інший проєкт, зміна порту вашого нового додатка зазвичай є безпечнішою.
Також перевірте, чи належить процес супервізору. Служба, запущена systemd, Docker Compose, інструментом запуску завдань IDE або іншим менеджером процесів, може миттєво перезапуститися після того, як ви вб’єте її дочірній процес. У такому випадку зупиніть або переналаштуйте супервізор, замість того щоб повторно вбивати дочірній PID.
Так — якщо старий сервер все ще відкритий в іншому терміналі, яким ви керуєте, повернення до цього терміналу та натискання Ctrl+C часто є найчистішим рішенням. Це дозволяє серверу обробити свій звичайний шлях завершення роботи, замість того щоб бути примусово завершеним ззовні.
На macOS або Linux почніть зі стандартного сигналу завершення:
kill 12345
Посібник Linux kill стверджує, що за замовчуванням використовується TERM, і спеціально рекомендує його замість KILL, оскільки процес може обробити TERM і виконати очищення. Використовуйте kill -9 лише як останній засіб, коли процес, який ви перевірили як безпечний для завершення, не виходить нормально.
У Windows PowerShell Microsoft надає Stop-Process:
Stop-Process -Id 12345 -Confirm
Документація Stop-Process підтримує зупинку за PID і зазначає, що для процесів, якими ви не володієте, можуть знадобитися підвищені привілеї. Опція -Confirm корисна, коли вам потрібна додаткова перевірка перед завершенням.
/F лише після того, як ви ідентифікували PID і звичайна зупинка недостатня.Користувачі Command Prompt можуть використати:
taskkill /PID 12345
Додайте /F лише тоді, коли звичайного завершення недостатньо. Документація taskkill від Microsoft визначає /PID для вибору процесу та /F для примусового завершення.
Docker є поширеною причиною того, що розробники бачать зайнятий порт 8080, навіть коли жодне вікно додатка не здається відкритим. Виконайте:
docker ps
Шукайте у стовпці PORTS відображення, яке публікує хост-порт 8080. Поточна документація Docker з усунення несправностей явно перелічує існуючий додаток або раніше запущений контейнер як причини помилок port already allocated.
Ви можете перевірити відображення конкретного контейнера за допомогою:
docker port CONTAINER_NAME
Документація команди Docker port визначає цю команду як спосіб перелічити відображення портів контейнера. Якщо контейнер більше не потрібен, зупиніть його чисто:
docker stop CONTAINER_NAME
Docker документує, що docker stop спочатку надсилає налаштований сигнал зупинки, зазвичай SIGTERM, перш ніж перейти до примусового вбивства після періоду очікування.
Запустіть ваш додаток знову, використовуючи його звичайну команду. Якщо тепер він повідомляє про успішну прив’язку до 127.0.0.1:8080, конфлікт вирішено.
Ви також можете повторно виконати ту саму команду інспектування, яку використовували раніше. Перед запуском нового сервера запит не повинен показувати небажаних слухачів. Після запуску слухач повинен належати очікуваному процесу.
Не вбивайте його. Надайте вашому новому додатку інший порт, такий як 8081, 3000 або інший вільний порт розробки. Точний синтаксис залежить від фреймворку.
Для Flask офіційна документація сервера розробки явно рекомендує обирати інший порт, коли інша програма володіє портом за замовчуванням:
flask --app app run --port 8081
Для Django 6.1 сервер розробки приймає порт як аргумент:
python manage.py runserver 8081
Поточний навчальний посібник Django та довідка runserver документують запуск паралельних серверів розробки на окремих портах.
Для Spring Boot стандартною властивістю є server.port. Документація конфігурації Spring Boot показує server.port як налаштування порту сервера.
Пройдіться через ці перевірки, перш ніж припускати, що операційна система помиляється.
0.0.0.0:8080, 127.0.0.1:8080, [::]:8080 або адресу конкретного інтерфейсу. Уникайте занадто вузької фільтрації, щоб не пропустити фактичного слухача.TIME_WAIT — це не те саме, що процес, який активно прослуховує 8080. Спершу зосередьтеся на слухачі та процесі-власнику.Якщо помилка повертається після кожного перезавантаження або входу в систему, ймовірно, постійна служба запускається автоматично. Поширені приклади включають завдання розробки, запущене IDE, стек Docker Compose, фонову службу Java, проксі або менеджер служб ОС. Замість того, щоб розглядати кожне повторення як одноразову проблему з PID, знайдіть компонент, який запускає слухача, і змініть його конфігурацію або поведінку запуску.
Якщо конфлікт виникає лише після того, як ви повторно запускаєте та зупиняєте свій власний додаток, перевірте, чи не працює попередній екземпляр в іншому терміналі, чи не запускає ваш відлагоджувач другий процес і чи не має релодер, що стежить за файлами, батьківського та дочірнього процесів. Ключовий тест залишається тим самим: інспектувати слухача та перевірити його ідентичність.
Зазвичай ні як перший крок. Звичайне завершення роботи дає процесу шанс закрити файли, скинути буфери, зупинити дочірні завдання та чисто звільнити ресурси. Примусове завершення корисне, коли перевірений процес завис, але воно повинно бути шляхом ескалації, а не дією за замовчуванням.
Перезавантаження може очистити застарілий процес розробки, але воно також приховує причину. Якщо конфліктна служба налаштована на автоматичний запуск, порт може бути знову зайнятий одразу після перезавантаження. Ідентифікація власника 8080 є швидшою в довгостроковій перспективі.
Той самий робочий процес працює для помилок на портах 3000, 5000, 8000, 8081 та більшості інших локальних портів розробки. Номер порту змінюється; діагностика — ні.
Виправте помилку незгенерованого Prisma Client, перевіривши генератор, схему, шлях виводу, імпорти, версії, налаштування монорепозиторію та кроки збірки під час розгортання.
Виправте помилку Git «не вдалося отримати локальний сертифікат емітента», визначивши механізм довіри, встановивши правильний ланцюжок ЦС та зберігаючи перевірку SSL увімкненою.
Виправте помилки таймауту мережі MongoDB у Mongoose, визначивши тип таймауту, перевіривши доступність Atlas або TCP, виправивши URI та налаштувавши таймаути лише за необхідності.
Виправте помилку обмеженої політики виконання PowerShell, перевіривши область дії та групову політику, а потім обравши RemoteSigned, Unblock-File або тимчасовий параметр сесії.
Виправте конфлікти залежностей-партнерів npm ERESOLVE, визначивши несумісний діапазон пакетів, узгодивши версії, використовуючи npm explain та npm ls, а також розглядаючи legacy-peer-deps або force лише як контрольовані резервні варіанти.
Виправте помилки відмови у підключенні Redis на 127.0.0.1:6379, перевіривши сервер, порт, мережу Docker, redis.conf, автентифікацію та TLS.
Виправте помилки 500 у серверних компонентах Next.js, аналізуючи логи сервера, перевіряючи запити даних та змінні середовища, обробляючи помилки та перевіряючи збірку для продакшену.
Діагностуйте та виправляйте помилку CrashLoopBackOff у Kubernetes у локальному Minikube, перевіряючи стан пода, попередні логи, причини завершення роботи, проби, конфігурацію, ліміти пам’яті та стан кластера.
Виправте помилку «Docker Desktop Engine Stopped» у Windows 11, перевіривши статус Docker, оновивши та перезавантаживши WSL 2, підтвердивши віртуалізацію та використавши діагностику перед скиданням налаштувань.
Виправте помилку 'process is not defined' у Vite, замінивши використання process.env у стилі Node.js, правильно налаштувавши змінні VITE_ та перевіривши залежності.
