Actualizado el 22 de octubre de 2026.
Si una aplicación dice que el puerto está ocupado, busca primero quién está escuchando en él. En Linux, ss permite filtrar el número exacto y mostrar el proceso asociado. Para el puerto TCP 8080:
sudo ss -ltnp 'sport = :8080'-l muestra sockets en escucha, -t selecciona TCP, -n conserva direcciones y puertos numéricos y -p añade los procesos. El filtro sport selecciona el puerto local. La página de manual de ss documenta estas opciones y su lenguaje de filtros.
Cómo leer el resultado
En la columna de dirección local verás la dirección y el puerto. Un servicio ligado a 127.0.0.1:8080 escucha en el bucle local IPv4; uno en 0.0.0.0:8080, en todas las direcciones IPv4 del espacio de red correspondiente. Que escuche en todas no implica que sea accesible desde Internet: el cortafuegos y los routers también intervienen.
La información de proceso puede incluir el nombre, el PID y el descriptor del socket. Sin privilegios suficientes, es posible ver el puerto pero no el proceso de otro usuario. Utiliza sudo solo si estás autorizado a administrar ese equipo.
UDP y conexiones ya establecidas
Para buscar un socket UDP local en el puerto 5353:
sudo ss -lunp 'sport = :5353'UDP no tiene el mismo establecimiento de conexión que TCP; no esperes encontrar siempre la palabra LISTEN. Si lo que buscas es una conexión TCP saliente hacia el puerto 443, cambia de enfoque:
sudo ss -tnp 'dport = :443'Este segundo comando busca el puerto del extremo remoto. No responde a «quién ocupa mi puerto 443», sino a «qué conexiones TCP van a un puerto 443 remoto».
Por qué evitar grep sobre el número del puerto
La receta antigua usaba netstat y una búsqueda de :22. Esa cadena también puede aparecer dentro de :2222. El filtro numérico de ss evita esa ambigüedad y elimina la necesidad de interpretar coincidencias de texto.
Si no aparece nada, comprueba el protocolo, el momento de la consulta y el espacio de red. Un proceso dentro de un contenedor puede escuchar en una red distinta de la del host. También puede haber un puerto publicado mediante reglas de red sin un proceso de aplicación escuchando directamente en ese mismo puerto del host.
Antes de detener el proceso
Identifica qué servicio lo ha iniciado y qué depende de él. Matar un PID al azar puede interrumpir usuarios o provocar que un supervisor lo arranque de nuevo. Para resolver un conflicto, cambia el puerto de una de las aplicaciones o detén el servicio correcto por su mecanismo habitual.
Estos comandos son de consulta: no cierran sockets ni matan procesos. Si compartes el resultado para pedir ayuda, elimina direcciones internas, nombres de usuario y cualquier dato que no sea necesario para explicar el problema.
Comentarios