La comprobación rápida es nc -zv host puerto: "succeeded" significa que el puerto está abierto, "refused" significa que la máquina respondió pero nadie escucha, y el silencio total casi siempre significa que un firewall descarta el paquete. Son tres fallos distintos con tres soluciones distintas. Este es el árbol de decisión para distinguirlos, no otra lista de cinco herramientas que hacen el mismo handshake.
1. ¿El puerto está realmente abierto?
$ clai comprueba si el puerto 8099 está abierto en 127.0.0.1→ nc -zv 127.0.0.1 8099Connection to 127.0.0.1 8099 port [tcp/*] succeeded!-z solo prueba la conexión sin enviar datos, -v imprime el resultado. Es la respuesta más corta posible.
2. Puerto cerrado — y esa es una respuesta concreta
$ clai comprueba el puerto 8098→ nc -zv 127.0.0.1 8098nc: connect to 127.0.0.1 port 8098 (tcp) failed: Connection refused"Connection refused" significa que la máquina es alcanzable y rechazó la conexión activamente — nadie escucha en ese puerto. Es buena noticia: la red funciona, el problema es el servicio.
3. Distinguir el rechazo del silencio
$ clai comprueba los puertos 8098 y 8099 y muestra el motivo→ nmap --reason -p 8099,8098 127.0.0.1PORT STATE SERVICE REASON8098/tcp closed unknown conn-refused8099/tcp open unknown syn-ackLa columna REASON es el diagnóstico real. syn-ack es abierto. conn-refused es que nadie escucha. no-response significa que el paquete desapareció — casi siempre un firewall. Es el único lugar donde las tres causas se distinguen por separado.
4. Mirar desde el otro lado: quién escucha
$ clai muestra qué proceso está escuchando en el puerto 8099→ ss -tlnp | grep 8099LISTEN 0 5 0.0.0.0:8099 0.0.0.0:* users:(("python3",pid=2411411,fd=3))0.0.0.0:8099 significa todas las interfaces. Si dijera 127.0.0.1:8099, el servicio solo respondería en local, y una comprobación remota fallaría aunque el servicio esté perfectamente sano. Esa es la tercera causa, y solo se ve desde aquí.
5. Sin nc ni nmap instalados
$ clai comprueba el puerto sin instalar herramientas extra→ timeout 2 bash -c 'echo > /dev/tcp/127.0.0.1/8099' && echo "open" || echo "closed"openbash puede abrir una conexión TCP en bruto a través del pseudodispositivo /dev/tcp. Funciona en un contenedor pelado sin nc ni nmap. timeout es obligatorio — sin él, un puerto filtrado te hace esperar el timeout del propio kernel.
6. Comprobar varios puertos de un host remoto a la vez
$ clai comprueba los puertos 22, 80 y 443 en example.com→ nmap -Pn -p 22,80,443 example.com-Pn se salta la comprobación de ping. Muchos hosts no responden a ICMP, y sin este flag nmap decide que el host está caído y ni siquiera escanea los puertos.
Trampas
- "Connection refused" y "timeout" son diagnósticos distintos. Refused significa que el paquete llegó a la máquina. El silencio significa firewall o pérdida de paquetes. No trates uno como el otro.
- Escanear hosts que no son tuyos puede ser ilegal. Apunta nmap a tu propia infraestructura, no a la de otros.
- UDP no se comprueba así. No hay handshake para UDP, así que
nc -zucasi siempre dice "succeeded". Necesitasnmap -sUy paciencia.
Preguntas relacionadas
El puerto está abierto pero la app no responde. Está escuchando el proceso equivocado, o es demasiado lento para responder. Revisa la salida de ss -tlnp y los logs del servicio.
¿Cómo compruebo un puerto desde Windows? Test-NetConnection -Port 443 example.com en PowerShell.
¿Por qué ya no se recomienda telnet? Hace lo mismo, pero casi nunca está instalado, mientras que nc y /dev/tcp están disponibles casi en todas partes.
Ver también
- Matar el proceso que ocupa el puerto 8080
- Triaje de red en lenguaje llano: conexiones, puertos, DNS
- El proceso que no quiere morir
Deja de memorizar flags de nc y nmap: describe el problema y CliAI escribe el comando. Instálalo en una línea.