Bosun vs Monitor de Actividad: por qué la herramienta de macOS no puede responder sobre puertos

Cuando algo queda pegado en un puerto, mucha gente abre primero el Monitor de Actividad. Ya está instalado, lista todos los procesos y tiene una pestaña de Red. Parece el lugar correcto.

No lo es, y el motivo es estructural, no una función que falte.

Es un visor de procesos, no de red

Sus cinco pestañas son CPU, Memoria, Energía, Disco y Red. La pestaña de Red habla de volumen, cuántos bytes y paquetes envió y recibió cada proceso. Sirve cuando quieres saber qué app se está comiendo tu conexión.

No dice nada sobre en qué puertos está escuchando un proceso. No hay columna de puerto, no puedes ordenar por puerto ni buscar uno. Así que la pregunta que realmente tienes, qué está ocupando el 3000, no tiene respuesta en esa ventana.

Puedes acercarte adivinando. Buscas el proceso node que crees que es el culpable, lo seleccionas, lo fuerzas a salir y ves si el puerto se libera. A veces funciona, y por eso la costumbre sobrevive. También significa matar procesos por corazonada, que es como la gente pierde trabajo sin guardar en un build que no pensaba detener.

El problema es la dirección

El Monitor de Actividad responde qué está haciendo este proceso. Depurar un puerto necesita lo contrario, qué proceso es dueño de este puerto. Ir hacia atrás, desde un número de puerto hasta un proceso, es justo lo que no puede hacer.

Por eso la respuesta estándar es la Terminal:

lsof -i :3000

lsof va en la dirección correcta. Parte del puerto y te entrega el proceso. Si te sientes cómodo en una terminal, ese comando más kill cubre casi todo esto, y escribimos una comparación honesta de Bosun contra lsof en vez de fingir lo contrario.

Tres cosas que ninguna de las dos te va a decir

El Monitor de Actividad y lsof comparten los mismos puntos ciegos, y suelen ser los que importan.

Cuál contenedor. Docker publica cada puerto de contenedor a través de un proceso llamado docker-proxy. El Monitor de Actividad te muestra varias filas idénticas con ese nombre. Ninguna de las dos herramientas te dice cuál de tus contenedores está detrás de cada una.

Si hay un túnel abierto. Un túnel de ngrok o de cloudflared es un camino vivo desde internet hasta tu notebook. No es un puerto escuchando en ninguna forma que lo identifique como túnel, así que es invisible en ambas. Un túnel que olvidaste cerrar es un problema de seguridad real, no solo desorden.

Qué estaba corriendo hace diez minutos. Las dos son vistas estrictamente en vivo. Si un proceso tomó un puerto y salió antes de que miraras, no queda nada que ver.

Qué hace Bosun distinto

Bosun vive en la barra de menú y parte del puerto, no del proceso. Lista todo lo que está escuchando, agrupado por número de puerto, con el proceso dueño de cada uno. Las filas de Docker muestran la imagen real del contenedor y el proyecto de Compose en vez de docker-proxy. Los túneles aparecen con su URL pública. El estado de la VPN es visible. Un historial guarda lo que estaba escuchando antes, así un puerto que apareció y se fue sigue ahí cuando vayas a buscarlo.

Terminar un proceso es explícito y no una apuesta. Bosun manda SIGTERM primero y solo escala a SIGKILL si el proceso se niega a salir, que es la misma cortesía que te da un kill normal y lo contrario de Forzar salida.

Cuál usar

El Monitor de Actividad es la herramienta correcta para CPU, memoria, energía y disco, y no va a dejar de serlo. Consérvalo para eso.

Para saber qué hay en un puerto, la respuesta es lsof si te gusta la terminal, y Bosun si prefieres tenerlo ya visible, con los contenedores y los túneles nombrados como corresponde.

Bosun requiere macOS 14 o posterior. La prueba de 14 días parte cuando lo abres, sin crear cuenta.