Troubleshooting de red en Linux: netstat, ss, tcpdump, dig

En pocas palabras: Para diagnosticar fallas de red en Linux se usan cuatro herramientas: netstat -tulpn para ver puertos ocupados, ss (parte de iproute2, hoy versión 7.3.0) para inspeccionar sockets vía netlink, tcpdump para capturar paquetes y dig para resolver problemas de DNS.

Che, ¿te pasó que un servicio en producción deja de responder y no sabés si el problema es el puerto, el socket colgado o el DNS que tarda? Con netstat, ss, tcpdump y dig vos podés confirmar en minutos dónde está la falla real, sin tirar reinicios al azar.

El troubleshooting de red en Linux es el proceso de diagnosticar fallas de conectividad, latencia o resolución de nombres usando herramientas nativas del sistema como netstat, ss (parte de iproute2), tcpdump y dig. Estas utilidades inspeccionan sockets, capturan paquetes y consultan servidores DNS directamente desde la terminal.

¿Por qué fallan las conexiones de red en un servidor Linux en producción?

Las conexiones fallan por tres causas que se repiten en casi cualquier stack: saturación de recursos, casos no manejados que generan fallas en cascada, y acumulación de complejidad en sistemas distribuidos. Ninguna de las tres avisa con un error claro, por eso terminás mirando logs de la aplicación cuando el problema está dos capas más abajo.

Ejemplo hipotético: imaginá que subís un servicio nuevo, funciona bárbaro en staging, lo mandás a producción y a los dos días empieza a tardar cada vez más en responder, hasta que algunos clientes directamente se quedan colgados. Nadie tocó el código. Lo que cambió fue la carga, y con ella pudieron aparecer colas sin límite que ocultan el problema hasta que el proceso se queda sin memoria. Es un escenario ilustrativo, pero sirve para entender por qué conviene mirar el sistema operativo antes de sospechar del código de la aplicación.

Ahí entra el troubleshooting de red en Linux. No es magia, es mirar el sistema con las herramientas correctas antes de sospechar del código. Lo explicamos a fondo en soporte Linux para el chip Apple T1.

¿Netstat o ss: cuál conviene usar hoy para inspeccionar conexiones?

ss conviene por sobre netstat en cualquier distro moderna. El propio manual de netstat lo dice sin vueltas: “this program is mostly obsolete. Replacement for netstat is ss”. No es una opinión de blog, está en la página del manual.

La diferencia técnica es de fondo. netstat lee archivos en /proc/net/tcp, /proc/net/udp, etcétera, y los parsea línea por línea. ss consulta al kernel directo vía netlink, que es el mismo mecanismo que usa el resto de iproute2. Esa diferencia de origen de datos explica por qué la brecha de rendimiento se nota más a medida que crece la cantidad de sockets abiertos: parsear texto línea por línea rinde peor que una consulta binaria al kernel. En un servidor con pocas conexiones no vas a notar diferencia. En un servidor con miles de sockets activos (un balanceador, un proxy, una base de datos con muchos clientes) sí la vas a sentir, porque netstat tiende a volverse más lento mientras que ss sigue respondiendo rápido.

Las distribuciones modernas de Linux suelen traer ss instalado por defecto, mientras que netstat queda como paquete opcional dentro de net-tools.

Característica	netstat	ss
Origen de datos	/proc/net (lectura de archivos)	netlink (consulta directa al kernel)
Estado de mantenimiento	Obsoleto, parte de net-tools	Activo, parte de iproute2
Comportamiento con muchos sockets	Tiende a degradar el rendimiento	Se mantiene más estable
Comando típico para ver puertos	netstat -tulpn	ss -tulpn
Disponible por defecto en distros modernas	No siempre (hay que instalar net-tools)	Sí, en la mayoría de distros actuales

Criterios de decisión: cuándo usar cada una

• Si estás escribiendo un script nuevo de diagnóstico o monitoreo, usá ss: es el comando que la documentación de iproute2 y el propio manual de netstat marcan como vigente.
• Si estás en un servidor viejo donde solo está instalado net-tools, netstat sigue funcionando y te da la misma información básica de puertos y estados.
• Si el servidor tiene muchas conexiones simultáneas (un proxy, un balanceador, una base de datos concurrida), priorizá ss por el mecanismo netlink.
• Si necesitás compatibilidad con un script antiguo que ya parsea la salida de netstat, no hace falta migrarlo de urgencia: todavía funciona en la mayoría de las distros actuales.

¿Cómo detectar conflictos de puertos con netstat y ss?

Para saber qué proceso está bindeado a un puerto, el comando es netstat -tulpn o su equivalente ss -tulpn. La letra p agrega el PID y el nombre del proceso, la n evita que el comando pierda tiempo resolviendo nombres de host y puertos.

Ejemplo hipotético: supongamos que tratás de levantar un servicio en el puerto 8080 y la terminal te tira “address already in use”. Con netstat -tulpn | grep 8080 (o ss -tulpn | grep 8080) verías qué PID tiene ese puerto tomado, y de ahí al nombre del proceso hay un paso. El manual de netstat aclara algo importante: la columna PID/Program name requiere privilegios de superusuario para verse en sockets que no te pertenecen, y además advierte que esa identificación “is not trustworthy” en ciertos casos límite. Tomalo con pinzas si el proceso ya cerró pero el socket todavía no terminó de liberarse.

¿Qué significan los estados ESTABLISHED y TIME_WAIT de un socket?

ESTABLISHED significa que el socket tiene una conexión activa funcionando. TIME_WAIT significa que la conexión ya se cerró pero el socket sigue abierto un rato más para procesar paquetes tardíos que todavía andan dando vueltas por la red, según detalla el manual de netstat en su lista completa de estados TCP.

El manual también describe otros estados que vas a encontrar en el día a día: SYN_SENT y SYN_RECV durante el handshake, FIN_WAIT1 y FIN_WAIT2 durante el cierre, CLOSE_WAIT cuando el otro extremo ya cerró y tu proceso todavía no reaccionó, y LISTEN para los sockets que esperan conexiones entrantes (estos últimos no aparecen en el output salvo que uses -l o -a). Cubrimos ese tema en detalle en cómo le va a Omarchy Linux en Mac.

¿Un montón de conexiones en TIME_WAIT es un problema? No necesariamente. Es el comportamiento esperado del protocolo.

Criterios de decisión: cuándo preocuparse por TIME_WAIT

• Si el volumen de sockets en TIME_WAIT es proporcional al tráfico que el servidor maneja (muchas requests cortas, muchas conexiones que abren y cierran), es esperable y no amerita acción.
• Si el número crece de forma sostenida sin relación con el tráfico real, revisá primero la configuración de keep-alive del servidor HTTP o de la aplicación que abre las conexiones.
• Si sospechás que el problema es TIME_WAIT, confirmalo contando los sockets por estado con ss -tan o netstat -tan antes de tocar cualquier parámetro del kernel: medir primero, ajustar después.

¿Cómo capturar y leer paquetes con tcpdump?

tcpdump captura el tráfico que pasa por una interfaz de red en tiempo real, mostrando origen, destino, puerto y protocolo de cada paquete. Es la herramienta que usás cuando netstat o ss te dicen que el socket está bien pero necesitás confirmar si el paquete realmente llega al servidor.

El uso básico es tcpdump -i eth0 port 80, que filtra por interfaz y puerto. Si agregás -n evitás la resolución de nombres (más rápido), y si agregás -w archivo.pcap guardás la captura para analizarla después con un analizador de paquetes. El tema es que tcpdump requiere permisos root o la capability CAP_NET_RAW, así que en servidores compartidos no siempre vas a poder correrlo libremente.

Ejemplo hipotético: pensemos en un escenario donde un cliente dice que no puede conectar al puerto 443, pero netstat muestra el socket en LISTEN. Corrés tcpdump -i eth0 port 443 y no ves nada llegar. En ese caso, el problema no estaría en tu servidor sino antes: un firewall, un security group mal configurado, o el proveedor de red del cliente bloqueando el puerto. Ya lo cubrimos antes en entender los códigos de redirección HTTP.

¿Cómo diagnosticar latencia de DNS con dig?

dig mide cuánto tarda un servidor DNS en resolver un nombre de dominio, y ese tiempo aparece directo en la respuesta del comando bajo “Query time”. Si una app “lenta” en realidad está esperando resolución de DNS en cada request, dig te lo muestra de forma directa.

El comando básico es dig dominio.com, y si querés apuntar a un resolver específico (para comparar contra el DNS que configuraste versus uno público) usás dig @8.8.8.8 dominio.com.

Ejemplo hipotético: si al correr dig contra tu resolver configurado el “Query time” aparece notablemente más alto que al correr dig @8.8.8.8 contra el mismo dominio, eso apunta a un cuello de botella en tu resolver DNS, no en la red ni en la aplicación. Es un chequeo rápido que muchos se saltean porque asumen que la lentitud siempre es culpa del backend.

Criterios de decisión: por dónde empezar el diagnóstico

Cuando un servicio falla y no sabés por dónde arrancar, tiene sentido ir de la capa más cercana a la aplicación hacia la más cercana al cable, en este orden:

1. ¿El puerto está escuchando? Confirmalo con ss -tulpn o netstat -tulpn. Si no aparece en LISTEN, el problema es que el proceso no arrancó o escucha en otra interfaz.
2. ¿Hay una conexión establecida? Si el puerto escucha pero el cliente no logra conectar, mirá los estados con ss -tan. Un acumulado anormal de SYN_RECV o CLOSE_WAIT sugiere un problema del lado de la aplicación, no de la red.
3. ¿El paquete llega físicamente? Si los estados de socket se ven normales pero el cliente sigue sin conectar, usá tcpdump para confirmar si el tráfico entra a la interfaz. Si no entra, el problema está antes del servidor (firewall, routing, proveedor).
4. ¿Es un problema de nombre, no de red? Si la “lentitud” no es una desconexión sino una demora, probá dig antes de seguir mirando sockets o paquetes. Resolver un nombre de dominio puede ser el cuello de botella real.

¿Qué errores de arquitectura agravan los problemas de red en producción?

Tres decisiones de diseño agravan cualquier problema de red que ya tengas: colas sin límite, falta de timeouts agresivos y operaciones que no son idempotentes.

• Colas sin límite: una cola de conexiones o buffer en memoria sin tope esconde el backpressure hasta que el proceso explota con un Out-Of-Memory. No avisa antes, directamente se cae.
• Falta de timeouts: una llamada de red o a disco sin timeout explícito puede dejar colgado todo el pool de workers si la dependencia del otro lado no responde.
• Operaciones no idempotentes: los paquetes de red se pierden y los clientes reintentan. Si una operación que modifica datos no es segura para ejecutarse dos veces, un simple reintento de red te duplica registros.

Errores comunes al hacer troubleshooting de red en Linux

• Confundir LISTEN con una conexión activa: ver un socket en LISTEN solo te dice que el proceso espera conexiones, no que algo esté conectado. Para ver conexiones reales hay que mirar los estados ESTABLISHED.
• No usar la opción -n: correr netstat o ss sin -n hace que el comando intente resolver cada IP a nombre de host, lo que puede tardar un montón si el DNS está lento (justo el problema que estás tratando de diagnosticar).
• Asumir que TIME_WAIT es un bug: es parte normal del cierre de TCP. El problema real aparece cuando el volumen es anormalmente alto para el tráfico esperado.
• Correr tcpdump sin filtro: capturar todo el tráfico de una interfaz sin especificar puerto ni host genera un volumen de datos imposible de leer a mano.

Preguntas Frecuentes

¿Cómo saber qué proceso está ocupando un puerto en Linux?

Corré netstat -tulpn o ss -tulpn y filtrá por el número de puerto con grep. La columna PID/Program name muestra el proceso responsable, aunque necesitás privilegios de root para ver procesos que no te pertenecen. Tema relacionado: los cortes de costos que podés aplicar en Azure.

¿Cuál es la diferencia entre netstat y ss?

netstat lee información de archivos en /proc/net y está marcado como obsoleto en su propio manual. ss consulta al kernel vía netlink, es parte de iproute2 y tiende a responder mejor con muchas conexiones activas.

¿Cómo uso tcpdump para capturar tráfico de red?

El comando básico es tcpdump -i interfaz port puerto, por ejemplo tcpdump -i eth0 port 443. Agregá -n para evitar resolución de nombres y -w archivo.pcap si querés guardar la captura para analizarla después.

¿Qué significa TIME_WAIT en una conexión TCP?

TIME_WAIT es el estado de un socket que ya cerró su conexión pero sigue abierto un tiempo para procesar paquetes de red que llegan tarde. Es comportamiento normal del protocolo, no un error.

¿Cómo diagnostico lentitud de DNS con dig?

Corré dig dominio.com y mirá el valor “Query time” en la respuesta. Si querés comparar contra un resolver público, usá dig @8.8.8.8 dominio.com y contrastá los tiempos.

Conclusión

El troubleshooting de red en Linux no requiere herramientas exóticas. Con ss para sockets, tcpdump para paquetes y dig para DNS, cubrís la mayoría de los incidentes de conectividad que vas a enfrentar en un servidor en producción. netstat todavía funciona en la mayoría de las distros, pero el propio manual lo marca como obsoleto, así que si estás armando scripts nuevos de diagnóstico, escribilos directo con ss.

Lo que de verdad cambia el resultado de un incidente no es qué comando corrés primero, sino si tu arquitectura ya tiene colas acotadas, timeouts configurados y operaciones idempotentes antes de que el problema de red aparezca. Esas tres cosas no las arregla ningún comando de diagnóstico, se definen en el diseño.

Fuentes

• netstat(8) – Linux manual page
• iproute2 – Wikipedia
• Linux Networking Troubleshooting: Netstat, SS, TCPDump, and Dig in Action – dev.to