Qué es un puerto y por qué tu app necesita uno

Publicado el 2026-09-12 por frfrand

Una IP encuentra la máquina; el puerto encuentra el programa. Qué son los 65535 puertos, por qué los de abajo de 1024 son especiales y cómo se diagnostica un "address already in use".

Una máquina tiene una dirección IP. Pero en esa máquina corren muchos programas a la vez: un servidor web, una base de datos, SSH, tu aplicación.

Si llega un paquete a esa IP, ¿para cuál de todos es?

Para eso existe el puerto. La IP encuentra la máquina; el puerto encuentra el programa dentro de ella. La combinación de las dos cosas se llama socket, y es lo que identifica de forma única a una conversación en la red.

65535 puertas por dirección

El número de puerto se guarda en 16 bits, así que van del 1 al 65535. Es un montón: ninguna máquina normal usa más de unas decenas.

Se dividen en tres tramos por convención:

• 1 a 1023: los puertos "bien conocidos". Necesitan privilegios de root para que un programa se ponga a escuchar en ellos.
• 1024 a 49151: registrados. Acá viven la mayoría de las bases de datos y servicios.
• 49152 a 65535: efímeros. Son los que el sistema le asigna automáticamente a tu lado de la conversación cuando abrís una conexión saliente.

Ese último punto explica algo que confunde: cuando tu navegador se conecta al puerto 443 de un servidor, tu propia máquina usa un puerto al azar del rango alto. Por eso podés tener veinte pestañas abiertas contra el mismo sitio sin que se mezclen.

Los que conviene saber de memoria

22 SSH 25 SMTP (correo saliente) 53 DNS 80 HTTP 443 HTTPS 3306 MySQL 5432 PostgreSQL 6379 Redis

Son convenciones, no reglas. Nada te impide correr tu web en el 8080 o mover SSH al 2222.

Y una aclaración que vale la pena: mover SSH del 22 al 2222 no te hace más seguro. Los escáneres automáticos prueban todos los puertos igual. Lo que sí hace es dejarte el log de autenticación mucho más limpio, porque el ruido de fondo de bots desaparece. Es higiene, no seguridad.

Por qué tu app corre en el 3000 y no en el 80

Porque para escuchar en un puerto menor a 1024 hace falta ser root, y no querés que tu aplicación corra como root.

La solución estándar es poner un proxy inverso adelante: nginx escucha en el 443 (arranca como root, abre el puerto y después baja de privilegios) y le pasa las peticiones a tu app en localhost:3000.

Tu app nunca queda expuesta a Internet. Sólo nginx lo está.

Address already in use

El error más común con puertos, y el más fácil de resolver una vez que sabés el comando:

$ ss -tulpn | grep :3000 tcp LISTEN 0 511 *:3000 users:(("node",pid=8412))

Ahí tenés el culpable con su PID. Las banderas son fáciles de recordar: t de TCP, u de UDP, l de listening, p de proceso, n de números (sin resolver nombres).

Casi siempre es una instancia vieja de tu propia aplicación que no terminó de morir. kill 8412 y seguís.

Si el comando no muestra el proceso, probá con sudo: sin privilegios no ves los procesos de otros usuarios.

Escuchar en 0.0.0.0 o en 127.0.0.1

Esta distinción es chica de escribir y enorme en consecuencias.

127.0.0.1:5432 solo acepta conexiones desde la propia máquina 0.0.0.0:5432 acepta conexiones desde cualquier lado

Si tu base de datos escucha en 0.0.0.0 y el firewall no la tapa, está abierta a Internet. Es una de las formas más comunes de exponer datos sin darse cuenta.

La regla: todo lo que no necesite entrar desde afuera, que escuche en 127.0.0.1. Y si necesitás conectarte desde tu máquina, no abras el puerto: hacé un túnel SSH.

En ArduMaker los puertos están cerrados por defecto y se abren declarándolos, justamente para que esta decisión sea explícita y no un descuido.