How to Find Which Process Is Listening on a Port in Linux

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

Команды предназначены для Linux с iproute2. Для TCP выполните:

Для UDP используется отдельная выборка:

Сервис, привязанный к петлевому адресу, рассчитан на локальные подключения. Привязка ко всем интерфейсам имеет другой смысл, но не делает порт автоматически доступным через внешний firewall или облачные правила. Отдельно различайте IPv4 и IPv6.

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

Если речь идёт о HTTPS, можно сократить TCP-вывод фильтром:

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

Вывод относится к сетевому пространству, в котором выполняется команда. Приложение внутри контейнера и публикация порта на хосте — разные уровни. Отсутствие процесса в ожидаемом месте не доказывает отсутствие сервиса во всей системе.

Не запускайте новый слушатель для «проверки», если порт уже нужен рабочему приложению. Сначала составьте цепочку: внешний адрес, правила доступа, порт хоста, прокси или контейнер, порт приложения. На каждом шаге должен быть понятен владелец настройки.

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

У UDP нет такого же установления соединения, как у TCP. Наличие локального UDP-сокета нужно сопоставлять с протоколом приложения и реальным ответом, а не проверять только попыткой TCP-подключения к тому же номеру порта. Пустая TCP-выборка в таком случае ожидаема.

An application reports that a port is in use, or a service is running but cannot be connected to. Start with local sockets. This check reveals whether a listener exists on the server and which address it is bound to. It does not replace checks for routing, firewalls, or external accessibility.

The commands are intended for Linux with iproute2. For TCP, run:

For UDP, use a separate query:

A service bound to a loopback address is intended for local connections. Binding to all interfaces has a different meaning but does not automatically make the port accessible through an external firewall or cloud rules. Distinguish between IPv4 and IPv6 separately.

For example, an application listens on a local port behind a reverse proxy. Such a setup can be entirely correct: the client does not need to connect directly to the application. The error would be changing the binding to external solely to fix a single failed test.

If the issue involves HTTPS, you can shorten the TCP output with a filter:

If no listener is found, check the configuration and service logs. If an unexpected process is detected, first determine its purpose. The same port may be part of a shared architecture, and stopping the process could affect multiple sites.

The output relates to the network namespace where the command is executed. An application running inside a container and port publishing on the host are different layers. The absence of a process in the expected location does not prove the absence of the service across the entire system.

Do not start a new listener for a "test" if the port is already required by a production application. First, map the chain: external address, access rules, host port, proxy or container, application port. At each step, the owner of the configuration must be clear.

Save the protocol, local address, port, process, and observation time. Then compare them with the expected connection scheme. After fixing the issue, check both the local socket and a standard request from the appropriate side of the network. Success at one level does not guarantee success at others: an open TCP port does not necessarily mean a working site, and unavailability from the internet does not always indicate a stopped process.

UDP does not have the same connection establishment as TCP. The presence of a local UDP socket must be compared with the application protocol and the actual response, not just verified by attempting a TCP connection to the same port number. An empty TCP response in this case is expected.