EADDRINUSE после перезапуска Node.js: кто занял порт

EADDRINUSE при запуске Node.js означает, что запрошенный локальный адрес уже занят другим сервером. Найдите слушающий процесс и механизм, который им управляет, прежде чем его останавливать. После перезапуска причина может быть в старом экземпляре, дублирующем запуске или неверной конфигурации назначения, а не в самом Node.js.

Какую привязку не удалось выполнить

В справочнике ошибок Node.js EADDRINUSE относится к неудачной привязке локального сервера. Сохраните код, операцию, адрес, порт и время ошибки. Номер 3000 часто встречается в примерах, но не является обязательным условием этого отказа.

Отделите эту ситуацию от отказа соединения с удалённым сервисом. Здесь новый сервер не смог занять назначение для своей работы. Изменение DNS сайта или пароля пользователя не объясняет, кто уже использует локальный сокет.

Если приложение сообщает «запущено» до подтверждения слушания, исправьте и наблюдаемость. В документации net.Server событие listening связано с завершившейся привязкой. Запись о начале выполнения программы не равна готовности принимать соединения.

Найдите процесс, затем владельца запуска

На Linux команда просмотра ss -ltnp показывает слушающие TCP-сокеты с числовыми адресами и сведениями о процессах, если они доступны. Её параметры описаны в руководстве ss. Это наблюдение своей системы, а не команда остановки или исправления.

Сопоставьте найденные сведения с ожидаемыми адресом и портом. Затем установите назначение процесса, пользователя запуска и управляющую службу. Если сведений не хватает, попросите уполномоченного администратора дополнить наблюдение. Отсутствие имени процесса в ограниченном выводе не доказывает, что порт свободен.

На другой ОС используйте её средства просмотра слушающих сокетов и процессов. Не переносите Linux-команду как универсальную инструкцию для Windows или macOS. Сам порядок разбора остаётся прежним: назначение, процесс, владелец, основание действия.

Карта конкурирующих запусков

Следующие строки — учебные варианты для разбора, не описание действующего сервера. Таблица нужна, чтобы выбрать адресное исправление и не остановить соседний проект из-за одинакового имени исполняемого файла.

Почему завершение процесса бывает временной победой

Предположим, учебное приложение работает под менеджером процессов, а оператор запускает ещё один экземпляр вручную. Если завершить первый процесс, управляющий механизм может снова его поднять. Тогда конфликт повторится, хотя команда остановки внешне сработала.

В этом сценарии исправляется схема запуска. Договоритесь, кто единолично управляет рабочим экземпляром и как оператор выполняет перезапуск. Не добавляйте третий способ ради того, чтобы второй наконец получил порт.

Не завершайте все процессы Node.js на многопроектной машине. Совпадение исполняемого файла не подтверждает принадлежность к неисправному приложению. Для поддержки сервера подготовьте карту назначения и управляющих механизмов, а не просьбу освободить всё похожее.

Смена порта тоже требует проверки маршрута

Если конфликт вызван ошибкой распределения назначений, новый порт может быть правильным решением. Но его выбирают вместе с конфигурацией прокси, проверками доступности и ожидаемыми клиентами. Успешная привязка к произвольному свободному номеру ещё не возвращает сайт пользователю.

Зафиксируйте, какой адрес должен слушать процесс и кто вправе к нему обращаться. Не расширяйте область доступа случайно ради устранения ошибки. Особенно полезно сохранить это требование в конфигурации развёртывания, чтобы следующий выпуск не вернул старое значение.

Завершение приложения и завершение соединений

Для net.Server документация описывает асинхронный server.close: сервер перестаёт принимать новые соединения, а окончательное закрытие связано с завершением существующих. Это конкретный контракт API. HTTP-сервер и используемый фреймворк нужно проверять по их собственным правилам остановки.

Разработчик должен определить, когда приложение считается завершённым, что происходит с текущими запросами и кто запускает замену. Задержка между командами сама по себе не подтверждает ни освобождение назначения, ни целостность незавершённой работы.

Мы советуем отдельно записывать начало остановки, подтверждённое завершение и готовность нового экземпляра. Это позволит отличить конфликт запусков от долгого завершения. Не выдавайте вывод только об одном этапе за успешный полный перезапуск.

Приёмка следующего запуска

1. Сохраните точный адрес, порт, операцию и время EADDRINUSE.
2. Найдите слушающий процесс в нужном окружении.
3. Подтвердите его назначение и управляющий механизм.
4. Устраните дублирование либо согласуйте новую привязку с маршрутами.
5. В собственной тестовой среде проверьте штатный останов и новый запуск.
6. Подтвердите listening, доступность нужной функции и отсутствие повторного конфликта.
7. Закрепите один порядок запуска в инструкции эксплуатации.

Если запуск встроен в веб-приложение, его готовность и завершение входят в требования к поставке. Для доработки эксплуатации передайте таблицу владельцев и наблюдаемую последовательность. Цель — воспроизводимый перезапуск, а не разовое исчезновение EADDRINUSE после случайного завершения процесса.