Cómo saber qué programa está usando un puerto en Linux y solucionar conflictos de red paso a paso

Uno de los problemas más comunes al administrar Linux es intentar levantar un servicio y recibir un error como “Address already in use”, “port is already allocated” o “failed to bind”. Eso significa que otro proceso ya está usando el puerto, que el servicio está escuchando en una dirección distinta, que Docker publicó el puerto, que systemd activó un socket o que el firewall no permite el tráfico esperado.

La buena noticia es que Linux ofrece herramientas muy precisas para diagnosticarlo. ss permite inspeccionar sockets y mostrar procesos asociados; lsof lista archivos abiertos, incluidos sockets de red; fuser identifica procesos que usan archivos o sockets; y systemctl ayuda a controlar servicios administrados por systemd.

1. Qué significa que un puerto esté ocupado

Un puerto es un punto lógico de comunicación. Por ejemplo, HTTP suele usar el puerto 80, HTTPS el 443, SSH el 22, PostgreSQL el 5432, MySQL/MariaDB el 3306 y Redis el 6379. Cuando un programa “escucha” en un puerto, queda esperando conexiones entrantes.

En condiciones normales, dos servicios no pueden escuchar al mismo tiempo en la misma combinación de IP + puerto + protocolo. Por eso, si Nginx ya escucha en 0.0.0.0:80, Apache no podrá iniciar en el mismo puerto. La familia de manuales de Linux documenta errores como EADDRINUSE cuando se intenta usar una dirección o puerto que ya está ocupado.

2. Comando principal: ss para ver puertos y procesos

El comando ss es una de las herramientas más útiles para investigar sockets en Linux. Su manual indica que se usa para mostrar estadísticas de sockets, y la opción -p permite mostrar el proceso que usa cada socket.

sudo ss -ltnp

Lectura rápida del comando:

3. Buscar un puerto específico con ss

Si quieres saber quién usa el puerto 80, 443, 3000, 5432 o cualquier otro, filtra por puerto. Para TCP:

sudo ss -ltnp '( sport = :80 )'
sudo ss -ltnp '( sport = :443 )'
sudo ss -ltnp '( sport = :3000 )'

Para UDP, usa -u:

sudo ss -lunp '( sport = :53 )'
sudo ss -lunp '( sport = :123 )'

Un ejemplo de salida puede verse así:

State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      511          0.0.0.0:80        0.0.0.0:*     users:(("nginx",pid=1245,fd=6))

Esto indica que nginx, con PID 1245, está escuchando en el puerto 80 para todas las interfaces IPv4.

4. Usar lsof para identificar el programa del puerto

lsof significa “list open files”. En Linux, los sockets de red también se tratan como archivos abiertos, por lo que lsof permite encontrar procesos que tienen abierto un puerto. Su manual documenta que lista archivos abiertos e incluye archivos de red como sockets de Internet.

sudo lsof -nP -iTCP:80 -sTCP:LISTEN
sudo lsof -nP -iTCP:443 -sTCP:LISTEN
sudo lsof -nP -iTCP:5432 -sTCP:LISTEN

Para UDP:

sudo lsof -nP -iUDP:53

lsof suele mostrar columnas útiles como COMMAND, PID, USER, FD, TYPE, DEVICE, SIZE/OFF, NODE y NAME. Es ideal cuando necesitas saber no solo el puerto, sino también el usuario que ejecuta el proceso.

5. Usar fuser cuando necesitas solo el PID

fuser identifica procesos que usan archivos o sockets. Su manual indica que puede trabajar con espacios de nombres como tcp y udp, lo que lo hace práctico para descubrir rápidamente qué PID está usando un puerto.

sudo fuser -v 80/tcp
sudo fuser -v 443/tcp
sudo fuser -v 53/udp

6. Confirmar qué es realmente el proceso

Encontrar el PID no basta. Antes de detener algo, identifica su ruta, argumentos, usuario, servicio systemd y logs. Esto evita apagar una base de datos, un proxy, una aplicación crítica o un contenedor en producción.

PID=1245

ps -fp "$PID"
readlink -f /proc/"$PID"/exe
tr '\0' ' ' < /proc/"$PID"/cmdline; echo
ls -l /proc/"$PID"/cwd

También puedes intentar encontrar la unidad systemd asociada:

systemctl status "$PID"
systemctl status nginx
systemctl status apache2
systemctl status postgresql

systemctl es la herramienta para controlar el administrador de servicios systemd, incluyendo acciones como iniciar, detener o reiniciar unidades.

7. Solución 1: detener el servicio que ocupa el puerto

Si confirmas que el servicio no debe estar activo, deténlo con systemctl. Por ejemplo, si Apache ocupa el puerto 80 y quieres usar Nginx:

sudo systemctl stop apache2
sudo systemctl disable apache2

sudo systemctl start nginx
sudo systemctl status nginx

En distribuciones tipo RHEL, Rocky, AlmaLinux o Fedora, el servicio puede llamarse httpd en lugar de apache2:

sudo systemctl stop httpd
sudo systemctl disable httpd

8. Solución 2: cambiar el puerto del nuevo servicio

Si el servicio actual debe seguir funcionando, cambia el puerto del nuevo servicio. Por ejemplo, puedes dejar Nginx en 80 y mover una aplicación Node.js, Python, Go o Java al puerto 3001, 8080 o 9000.

sudo ss -ltnp '( sport = :8080 )'

Si no hay salida, probablemente el puerto no está en escucha. Luego configura la aplicación para usar ese puerto y reinicia su servicio.

9. Solución 3: revisar Docker y contenedores

Muchos conflictos de puerto en Linux vienen de Docker. Cuando publicas un puerto con -p o mediante ports: en Docker Compose, Docker lo expone en el host. La documentación oficial explica que publicar puertos puede hacer que el servicio esté disponible desde fuera del host, y que puedes limitarlo enlazando el puerto a una IP concreta, como 127.0.0.1.

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"
docker port nombre_contenedor

Ejemplo de conflicto típico en Docker Compose:

services:
  app:
    image: mi-app
    ports:
      - "80:80"   # Conflicto si Nginx o Apache ya usa el puerto 80

Solución: publica otro puerto del host:

services:
  app:
    image: mi-app
    ports:
      - "8080:80"  # Host 8080 → contenedor 80

Después aplica cambios:

docker compose down
docker compose up -d
docker ps --format "table {{.Names}}\t{{.Ports}}"

10. Solución 4: revisar si el servicio escucha solo en localhost

Un error frecuente es creer que un servicio está “caído” porque no responde desde otra PC, cuando en realidad está escuchando solo en 127.0.0.1. Eso permite conexiones locales, pero no desde la red.

127.0.0.1:3000   → solo local
0.0.0.0:3000     → todas las interfaces IPv4
192.168.1.10:3000 → solo esa IP del servidor
[::]:3000        → IPv6, según configuración del sistema

Docker también documenta esta diferencia: al publicar un puerto puedes enlazarlo a 127.0.0.1 para que quede local, o a una IP específica para aceptar tráfico por una interfaz concreta.

11. Solución 5: revisar firewall y reglas de red

Que un puerto esté en escucha no significa que sea accesible desde la red. Puede estar bloqueado por firewalld, nftables, iptables, UFW, reglas cloud, security groups o un router. firewalld permite administrar zonas, servicios y puertos; su documentación describe zonas como niveles de confianza y permite gestionar servicios o puertos por protocolo.

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all
sudo firewall-cmd --list-ports
sudo firewall-cmd --list-services

Para abrir un puerto de forma permanente con firewalld:

sudo firewall-cmd --permanent --add-port=8080/tcp
sudo firewall-cmd --reload
sudo firewall-cmd --list-ports

En sistemas con UFW, puedes revisar reglas así:

sudo ufw status verbose
sudo ufw allow 8080/tcp

12. Solución 6: revisar logs del servicio

Si el servicio no arranca, no basta con revisar puertos. Los logs suelen indicar si el problema es configuración, permisos, certificado, usuario, archivo inexistente, conflicto de puerto o error de dependencias.

sudo journalctl -u nginx --no-pager -n 100
sudo journalctl -u apache2 --no-pager -n 100
sudo journalctl -u postgresql --no-pager -n 100
sudo journalctl -xe

También revisa la configuración antes de reiniciar servicios críticos:

sudo nginx -t
sudo apachectl configtest
sudo sshd -t

13. Caso práctico: Nginx no inicia porque el puerto 80 está ocupado

Escenario: instalas Nginx, intentas iniciarlo y falla. El puerto 80 ya está ocupado por Apache.

# 1. Ver quién usa el puerto 80
sudo ss -ltnp '( sport = :80 )'

# 2. Confirmar proceso

sudo lsof -nP -iTCP:80 -sTCP:LISTEN

# 3. Revisar estado de Apache

sudo systemctl status apache2

# 4. Detener Apache si no se usará

sudo systemctl stop apache2
sudo systemctl disable apache2

# 5. Validar Nginx e iniciar

sudo nginx -t
sudo systemctl start nginx
sudo systemctl status nginx

# 6. Confirmar escucha

sudo ss -ltnp '( sport = :80 )'

14. Caso práctico: una aplicación en Docker no puede usar el puerto 3000

Escenario: ejecutas una aplicación en Docker y aparece un mensaje indicando que el puerto ya está asignado.

# Ver proceso del host
sudo ss -ltnp '( sport = :3000 )'

# Ver contenedores que publican puertos

docker ps --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

# Ver puerto de un contenedor específico

docker port mi-contenedor

Soluciones posibles:

15. Caso práctico: kubectl port-forward falla por puerto local ocupado

En Kubernetes, kubectl port-forward usa un puerto local de tu máquina para conectarse a un Pod o Service. Si ese puerto local ya está ocupado, fallará. La documentación de Kubernetes indica que, si no necesitas un puerto local específico, puedes dejar que kubectl elija uno automáticamente para evitar conflictos.

kubectl port-forward service/mi-servicio 8080:80

O dejar que Kubernetes asigne el puerto local:

kubectl port-forward service/mi-servicio :80

16. Diferenciar puerto abierto, puerto escuchando y puerto accesible

Estos tres conceptos suelen confundirse:

curl -I http://192.168.1.10:8080
nc -vz 192.168.1.10 8080

17. Cuándo usar kill y cuándo no

Usar kill puede resolver el síntoma, pero no siempre resuelve la causa. Si un servicio está gestionado por systemd, Docker o Kubernetes, el proceso puede reiniciarse automáticamente. En esos casos, detén la unidad, contenedor o recurso correcto.

# Servicio systemd
sudo systemctl stop nginx

# Contenedor Docker

docker stop mi-contenedor

# Proceso manual, con señal ordenada

sudo kill -TERM 1245

# Último recurso

sudo kill -KILL 1245

18. Checklist rápido para solucionar conflictos de puerto

19. Errores comunes

20. Preguntas clave

Recomendamos

En resumen

Para saber qué programa está usando un puerto en Linux, empieza con ss, confirma con lsof o fuser, revisa el PID, identifica el servicio y valida logs antes de detener nada. La mayoría de conflictos se resuelve con una de cuatro acciones: detener el servicio correcto, cambiar el puerto, ajustar Docker o corregir la IP/firewall.

La clave profesional es mirar el problema completo: puerto, protocolo, IP de escucha, proceso, usuario, servicio systemd, contenedor, firewall y conectividad real desde otra máquina. Así evitas soluciones peligrosas como matar procesos críticos o abrir puertos innecesarios.