Cuando algo no funciona en la red, la pregunta no es “¿hay red?” sino “¿en qué capa falla?”. La conectividad es una pila: resolución DNS, routing IP, TCP handshake, protocolo de aplicación. Cada herramienta de diagnóstico opera en una capa distinta, y confundirlas lleva a conclusiones equivocadas. Usar ping para diagnosticar un servicio web caído, o curl para diagnosticar pérdida de paquetes intermitente, son errores habituales que hacen perder tiempo.
ping envía paquetes ICMP Echo Request y espera ICMP Echo Reply. Es la comprobación más básica de alcanzabilidad IP, pero tiene un límite fundamental: ICMP no es TCP. Que ping falle no dice nada sobre si el puerto 443 responde. Muchos firewalls en producción bloquean ICMP deliberadamente —especialmente en servicios cloud— y muchos hosts están configurados para no responder a pings aunque estén perfectamente operativos. El único escenario donde ping falla y eso significa algo definitivo es cuando el problema está en la capa IP antes del filtrado. Úsalo para confirmar que llegas al host, no para confirmar que el servicio funciona. El flag -c limita el número de paquetes enviados; sin él, ping en Linux corre indefinidamente hasta que lo interrumpes.
traceroute envía paquetes con TTL incremental (1, 2, 3…) para que cada router en el camino responda con un ICMP Time Exceeded, revelando así el path completo y la latencia a cada salto. Los asteriscos (* * *) en un hop no necesariamente indican un problema: ese router simplemente no responde a los paquetes de diagnóstico. Lo que sí es significativo es un aumento brusco de latencia entre dos hops consecutivos o un path que cambia inesperadamente.
mtr combina ping y traceroute en una vista interactiva que se actualiza continuamente. Su ventaja real es que acumula estadísticas —paquetes enviados, pérdida porcentual, latencia media, jitter— durante un período de tiempo, lo que permite detectar pérdida de paquetes intermitente que un traceroute puntual nunca capturaría. Es la herramienta correcta cuando el problema es “la conexión va lenta o se corta a ratos”.
dig es el cliente DNS de referencia. Habla directamente con resolvers y muestra la respuesta completa: flags, TTL, registros adicionales. host es una alternativa más simple para uso rápido, pero dig es lo que necesitas cuando tienes que entender qué está devolviendo exactamente un resolver o por qué la resolución falla.
curl -v es donde pasas de la capa IP a la capa de aplicación. Muestra el handshake TLS, los headers HTTP completos, el código de respuesta y el cuerpo. Si ping llega pero el servicio no responde, curl -v te dirá si es un problema de certificado, de redirección, de autenticación o del propio servidor.
nmap y tcpdump son el siguiente nivel: nmap para verificar qué puertos están abiertos sin necesidad de tener un cliente para ese protocolo, y tcpdump para capturar tráfico real cuando necesitas ver exactamente qué bytes se están intercambiando. Si mezclas estas herramientas sin autorización sobre sistemas ajenos, te metes en problemas legales; úsalas solo sobre infraestructura que administras.
# Escenario: el servicio web en api.ejemplo.com no responde desde un servidor de aplicación. # Vamos capa por capa. # 1. ¿Llegamos a nivel IP? Cuatro pings y salir. ping -c 4 api.ejemplo.com # 2. ¿Cómo es el path? ¿Hay un hop con latencia anómala? traceroute api.ejemplo.com # 3. ¿Hay pérdida de paquetes intermitente? mtr en modo no-interactivo, # 100 ciclos, para tener una muestra estadística sólida. mtr --report --report-cycles 100 api.ejemplo.com # 4. ¿Resuelve bien el DNS desde esta máquina? dig api.ejemplo.com A # Comparar contra el resolver público de Google para saber si el problema # es el resolver local o la zona DNS en sí. dig @8.8.8.8 api.ejemplo.com A # Output mínimo cuando solo necesitas la IP, sin el formato completo. dig +short api.ejemplo.com A # Verificar registros MX por si el problema afecta también al correo. dig api.ejemplo.com MX # 5. ¿El puerto está abierto? nmap contra los puertos relevantes. # -p especifica puertos; sin -p nmap escanea los 1000 más comunes. nmap -p 80,443 api.ejemplo.com # 6. ¿Qué pasa a nivel HTTP/TLS? -v muestra todo: resolución DNS, # conexión TCP, handshake TLS, headers de request y response. curl -v https://api.ejemplo.com/health # Solo los headers de respuesta, sin descargar el cuerpo. # Útil para verificar redirects, cabeceras de seguridad, etc. curl -I https://api.ejemplo.com/health # 7. Si el problema parece estar en la capa TCP y quieres ver # los paquetes reales. -n evita resolución DNS inversa en cada paquete # (mucho más rápido). -i especifica la interfaz. # Requiere root o el capability CAP_NET_RAW. tcpdump -i eth0 -n port 443 and host api.ejemplo.com
La secuencia importa. ping confirma IP, traceroute/mtr mapean el path y detectan pérdida, dig aísla problemas de resolución, nmap verifica que el puerto esté escuchando, curl -v diagnostica la capa de aplicación, y tcpdump captura el tráfico real cuando todo lo demás es ambiguo.
Fíjate en el paso 3: mtr --report --report-cycles 100 en lugar del modo interactivo por defecto. En modo interactivo, mtr corre hasta que lo interrumpes; --report lo hace terminar y escribir el resultado en stdout, lo que permite guardarlo en un archivo o incluirlo en un ticket de soporte. Cien ciclos dan suficiente muestra para que el porcentaje de pérdida sea estadísticamente significativo; con los diez por defecto, una pérdida del 1% podría no aparecer.
El paso 4 usa dos queries dig con intención: primero contra el resolver configurado en /etc/resolv.conf de la máquina (que puede ser el DNS corporativo, un resolver local, o systemd-resolved), luego contra 8.8.8.8 directamente. Si la primera falla y la segunda funciona, el problema está en el resolver local o en la propagación de la zona. Si ambas fallan, el registro DNS simplemente no existe o está mal configurado en el servidor autoritativo.
En el paso 6, -v de curl es ruidoso pero preciso: verás líneas como * SSL certificate verify ok. o * SSL: certificate subject name 'otro.ejemplo.com' does not match target host name 'api.ejemplo.com', que te dan el diagnóstico exacto sin tener que interpretar un código de error genérico.
tcpdump en el paso 7 tiene -n por una razón de rendimiento: sin él, tcpdump intenta resolver en DNS inverso cada IP que ve, lo cual en un stream de tráfico activo añade latencia y contamina la captura con queries DNS propias. El filtro port 443 and host api.ejemplo.com limita la captura solo al tráfico relevante; sin filtro en una interfaz con carga, el buffer de captura se llena y empiezas a perder paquetes.
Un detalle sobre nmap: la salida filtered en un puerto no significa que el servicio esté caído, significa que hay un firewall descartando los paquetes de prueba sin responder. closed significa que el host responde activamente con TCP RST —el servicio no está escuchando, pero la máquina sí está accesible. open confirma que hay algo escuchando. La diferencia entre filtered y closed te dice si el problema es de firewall o de proceso.
[Ubuntu]: En Ubuntu con systemd-resolved activo, dig puede devolver respuestas distintas a las que obtiene el sistema porque las aplicaciones usan el stub resolver en 127.0.0.53, no el DNS configurado en /etc/resolv.conf directamente. Usa resolvectl query api.ejemplo.com para ver exactamente qué resuelve el sistema.
N° 80