Ошибка «Address already in use» в Linux. Почему порт занят и как это исправить

Ошибка Address already in use появляется в тот момент, когда программа пытается использовать порт, который уже занят другим процессом.

Обычно проблема возникает после запуска Nginx, Apache, Docker-контейнера, Gunicorn, Node.js, PostgreSQL или собственного приложения.

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

• Что означает ошибка Address already in use
• С чего начать диагностику
• Причина №1. Другой сервис уже использует этот порт
• Причина №2. Предыдущий экземпляр приложения не завершился
• Причина №3. Запущены две одинаковые службы
• Причина №5. Docker уже опубликовал этот порт
• Причина №6. Уже работает веб-сервер
• Как быстро узнать, кто использует порт
• Где искать дополнительную информацию
• Полезный чек-лист диагностики
• Заключение

Что означает ошибка Address already in use

Любой сетевой сервис должен "занять" порт, чтобы принимать входящие подключения.

Например:

• Nginx использует порт 80 или 443;
• SSH работает на порту 22;
• PostgreSQL — на 5432;
• Redis — на 6379;
• Gunicorn часто использует 8000;
• Node.js — 3000 или любой другой свободный порт.

Если другой процесс уже слушает этот порт, операционная система запрещает запуск новой службы и возвращает сообщение:

bind(): Address already in useCopy

или

OSError: [Errno 98] Address already in useCopy

Система не позволяет двум процессам одновременно использовать один и тот же порт, иначе входящие соединения было бы невозможно правильно распределить.

С чего начать диагностику

Можно придерживаться последовательности:

1. Узнать, какой процесс использует порт.
2. Понять, почему он запущен.
3. Проверить, нужен ли этот процесс.
4. При необходимости остановить службу.
5. Только после этого запускать новое приложение.

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

Причина №1. Другой сервис уже использует этот порт

Например, вы запускаете Nginx, а Apache уже работает на порту 80.

Или пытаетесь запустить второй экземпляр Gunicorn на том же порту.

Посмотреть открытые порты можно командой:

ss -tlnpCopy

Например:

LISTEN 0      511      0.0.0.0:80      users:(("nginx",pid=1352))
LISTEN 0      511      0.0.0.0:443     users:(("nginx",pid=1352))
LISTEN 0      244      127.0.0.1:5432  users:(("postgres",pid=841))Copy

Если нужный порт уже присутствует в списке, причина найдена.

Команда ss практически всегда становится первым инструментом при диагностике подобных ошибок. Она быстрее большинства альтернатив и сразу показывает процесс, который занимает порт.

Причина №2. Предыдущий экземпляр приложения не завершился

Иногда приложение аварийно завершается, но его процесс остается работать.

Например, после остановки сервера разработки Python или Node.js кажется, что программа закрылась, но один из процессов продолжает слушать порт.

Найти процесс можно так:

lsof -i :8000Copy

Например:

COMMAND   PID USER
python   2487 userCopy

Если процесс больше не нужен, завершите его.

kill 2487Copy

После этого повторите запуск приложения.

Если процесс не завершается обычной командой, стоит сначала выяснить причину. Использовать kill -9 имеет смысл только тогда, когда другие способы уже не помогли.

Причина №3. Запущены две одинаковые службы

Иногда проблема возникает после ручного запуска приложения.

Например, Gunicorn уже работает как служба systemd, а затем его запускают еще раз вручную.

Или Node.js одновременно работает через PM2 и обычную команду:

node app.jsCopy

В результате оба процесса пытаются использовать один и тот же порт.

Проверьте список процессов.

ps aux | grep gunicornCopy

или

ps aux | grep nodeCopy

Если обнаружились два одинаковых процесса, стоит разобраться, какой из них действительно должен работать постоянно.

Причина №5. Docker уже опубликовал этот порт

При работе с Docker ошибка встречается часто.

Например:

docker run -p 80:80 nginxCopy

Если порт 80 уже используется на хосте, контейнер не сможет запуститься.

Проверьте активные контейнеры.

docker psCopy

Обратите внимание на опубликованные порты.

Например:

0.0.0.0:80->80/tcpCopy

Если этот порт уже используется контейнером, можно изменить публикацию.

Например:

docker run -p 8080:80 nginxCopy

Так контейнер будет доступен на порту 8080, не мешая другим службам.

Причина №6. Уже работает веб-сервер

На новых VDS после установки панели управления или некоторых пакетов Apache может запускаться автоматически.

Затем пользователь устанавливает Nginx и получает ошибку:

bind() to 0.0.0.0:80 failedCopy

Проверьте состояние служб.

sudo systemctl status nginxCopy

sudo systemctl status apache2Copy

или

sudo systemctl status httpdCopy

Если Apache не используется, его можно остановить.

sudo systemctl stop apache2Copy

После этого Nginx сможет занять порт.

Такую ситуацию особенно легко пропустить после установки готовых образов VPS, где часть служб уже настроена автоматически.

Как быстро узнать, кто использует порт

Через ss:

ss -tlnp | grep :8000Copy

Через lsof:

lsof -i :8000Copy

Через fuser:

fuser 8000/tcpCopy

Все три команды показывают процесс, который использует нужный порт. Если какой-то утилиты нет в системе, обычно достаточно ss, так как она входит практически во все современные дистрибутивы Linux.

Где искать дополнительную информацию

Если служба не запускается, стоит посмотреть ее журнал.

Например:

journalctl -u nginx -n 100Copy

или

journalctl -u gunicorn -n 100Copy

Также полезно проверить системный журнал.

journalctl -xeCopy

Полезный чек-лист диагностики

Если нужно быстро найти причину ошибки, выполните несколько команд подряд.

ss -tlnp
lsof -i :8000
ps aux | grep gunicorn
systemctl status nginx
journalctl -xeCopy

Для других служб достаточно заменить номер порта и название процесса.

Этот набор позволяет определить, кто использует порт, проверить состояние службы и посмотреть последние сообщения системы.

Заключение

Ошибка Address already in use означает, что выбранный порт уже используется другим процессом. Чаще всего причиной становится уже запущенная служба, оставшийся после сбоя процесс, конфликт настроек или публикация порта в Docker.