ss vs netstat: qué comando de puertos usar en Linux

Usa ss — es el estándar actual en cualquier distribución Linux moderna, y netstat allí es legado. En Ubuntu, Fedora y Debian, el binario de netstat ahora llega solo con el paquete opcional net-tools, mientras que ss forma parte de iproute2 y está instalado en todas partes. ss además es más rápido en servidores con carga porque lee las estadísticas de sockets directamente del kernel en lugar de recorrer _proc_ archivo por archivo. La trampa es la sintaxis: -tulpn no significa lo mismo en ambos, así que esta guía te da la tabla de equivalencias exacta, los comandos que valen la pena memorizar y las respuestas a las preguntas que aparecen en pleno incidente a las 2 de la mañana.

¿Está netstat obsoleto?

En Linux, en la práctica sí. El paquete net-tools — que contiene netstat, ifconfig y route — lleva años sin seguir las funciones modernas del kernel y ya no viene instalado por defecto en ninguna distribución importante. Sigue existiendo, sigue funcionando, y no hay nada que desinstalar, pero las funciones nuevas llegan solo a iproute2 (el paquete detrás de ss e ip).

Tres consecuencias prácticas:

No está en las instalaciones recientes. Un Ubuntu 24.04 o un servidor Fedora recién instalado no tiene netstat hasta que instales net-tools a mano. Por eso tanta gente busca el equivalente de netstat — el binario simplemente no está.
Sin información de sockets moderna. netstat es anterior a funciones como TCP fast open, estadísticas de sockets a nivel de subflujo y la atribución de sockets por cgroup. ss las reporta de forma nativa.
La excepción de Windows. En Windows, netstat está vivo y coleando — netstat -ano sigue siendo la forma estándar de mapear un PID a un puerto en escucha allí. La historia de obsolescencia es solo de Linux.

¿Qué es el comando ss en Linux?

ss significa "socket statistics". Vuelca la visión del kernel de cada socket TCP, UDP y Unix: estado, direcciones, puertos, procesos, temporizadores y profundidades de cola. La forma de caballo de batalla es:

# Todo lo que está en escucha, con el proceso dueño
sudo ss -tulpn

Opción por opción, se lee: TCP (-t), UDP (-u), solo sockets en escucha (-l), mostrar procesos (-p), salida numérica — sin consultas DNS (-n). El sudo importa para -p: sin root ves los puertos pero no obtienes nombres de proceso para sockets que no son tuyos.

Otros dos one-liners que cubren la mayor parte del trabajo:

# Todas las conexiones establecidas hacia/desde el puerto 443, con procesos
sudo ss -tnp 'sport = :443 or dport = :443'

# Tabla resumen: cuántos sockets hay en cada estado
ss -s

Esa sintaxis de filtrado es una mejora real frente al enfoque de netstat de "grep y reza" — corre dentro del kernel, así que es exacta y no un emparejamiento de texto.

¿Cómo saber qué proceso está usando un puerto?

Es la razón número uno para recurrir a cualquiera de las dos herramientas. Con ss:

sudo ss -ltnp 'sport = :8080'

Salida de ejemplo en una máquina con un servidor de desarrollo:

State   Recv-Q  Send-Q  Local Address:Port  Peer Address:Port  Process
LISTEN  0       511     *:8080              *:*               users:(("node",pid=214113,fd=18))

El campo users:(...) te da el nombre del proceso y el PID directamente — sin segundo comando. Si el puerto está ocupado pero no aparece ningún proceso, normalmente estás viendo un socket retenido por otro namespace de red (un contenedor). Desde el host, ejecuta sudo ss -ltnp y busca el puerto con la columna de proceso vacía; luego cruza con docker ps o entra al namespace del contenedor con nsenter.

¿Prefieres una herramienta dedicada? sudo lsof -i :8080 -sTCP:LISTEN hace el mismo trabajo y funciona igual en macOS y la mayoría de los BSD, por eso sobrevive en los runbooks. En Linux, eso sí, ss ya está instalado.

¿Cuáles son las diferencias entre ss y netstat?

Mismo trabajo, distinta fontanería: netstat raspa _proc/net/tcp_ en espacio de usuario, mientras que ss usa netlink para preguntarle al kernel directamente — por eso ss responde en milisegundos en un servidor con 50 mil sockets abiertos y netstat no. En el día a día, la diferencia son las opciones. Aquí está la equivalencia que vale la pena pegar en el monitor:

Quieres	netstat	ss
Puertos TCP en escucha + proceso	`netstat -tlpn`	`ss -tlpn`
Todas las conexiones TCP + UDP	`netstat -tulpna`	`ss -tulpna`
Tabla de enrutamiento	`netstat -r`	`ip route`
Estadísticas de interfaces	`netstat -i`	`ip -s link`
Resumen de sockets del kernel	—	`ss -s`
Filtrar por puerto en el kernel	—	`ss -tnp 'sport = :22'`

Fíjate en que las dos primeras filas son idénticas: por suerte, las opciones cortas de ss coinciden con las de netstat en los casos comunes, así que la memoria muscular sobrevive en su mayoría al cambio. Las filas de abajo son donde netstat no tiene respuesta — el trabajo de enrutado e interfaces pasó al comando ip, y el resumen y el filtro solo existen en ss.

¿Cuándo conviene seguir usando netstat?

Dos casos honestos. Primero, portabilidad: en un parque mixto de Linux, AIX o BSD antiguos, netstat es la única sintaxis presente en todas partes. Segundo, continuidad de memoria muscular en runbooks viejos — si el runbook dice netstat -tlpn y la máquina tiene net-tools instalado, sigue funcionando sin problemas.

Para todo lo demás, ss por defecto, y actualiza el runbook. Un compañero útil cuando estés reescribiendo esos runbooks en un servidor es el memo de journalctl, que encaja de natural con las comprobaciones de puertos cuando diagnostcas un servicio que no arranca: /en/blog/2026-09-02/journalctl-cheat-sheet.

¿Por qué no encuentra el comando ss?

Porque o estás en una distribución muy vieja (de la era pre-2007, antes de que iproute2 fuera estándar) o — mucho más probable — no estás en Linux. ss no es un comando de macOS; macOS trae lsof y netstat pero ningún ss. Con los BSD, casi igual. En Windows, usa netstat -ano o el Get-NetTCPConnection de PowerShell.

Si de verdad estás en Linux y ss no aparece, instala iproute2:

sudo apt install iproute2    # Debian/Ubuntu
sudo dnf install iproute2    # Fedora/RHEL

La respuesta de 30 segundos

ss antes que netstat en Linux, siempre: viene preinstalado, es más rápido y puede filtrar dentro del kernel. netstat -tlpn se convierte en ss -tlpn, la caza de procesos pasa a ser sudo ss -ltnp 'sport = :PUERTO', y las tablas de enrutado son territorio de ip route. Deja netstat para los scripts multiplataforma y la memoria muscular vieja; deja esta página para las equivalencias.