Los puertos MQTT determinan cómo llegan tus dispositivos a un broker, si el tráfico va cifrado y si el firewall corporativo lo deja pasar siquiera. Esta guía explica los cuatro puertos que encontrarás en la práctica (1883, 8883, 8083 y 8084), cuándo usar cada uno y cómo probarlos todos en pocos minutos contra un broker real.
Respuesta corta: los cuatro puertos MQTT más comunes
MQTT es un protocolo de aplicación que funciona sobre un flujo de bytes fiable. La forma de transportar ese flujo determina el puerto (si no tienes claro por qué siempre es TCP, lee ¿MQTT usa TCP o UDP?). La IANA tiene registrado el 1883 para MQTT y el 8883 para MQTT sobre TLS. Los puertos WebSocket son una convención, no un registro, y varían según el broker; ConnectMQ usa el 8083 y el 8084.
| Puerto | Transporte | Cifrado | Clientes típicos | ¿Uso en producción? |
|---|---|---|---|---|
| 1883 | MQTT sobre TCP | No | Herramientas CLI, dispositivos de laboratorio, redes locales | Solo en redes aisladas y de confianza |
| 8883 | MQTT sobre TLS sobre TCP | Sí | Dispositivos, gateways, servicios backend | Sí, la opción por defecto |
| 8083 | MQTT sobre WebSocket (ws://) |
No | Demos en navegador, pruebas locales | Rara vez |
| 8084 | MQTT sobre WebSocket seguro (wss://) |
Sí | Navegadores, aplicaciones web móviles, redes restrictivas | Sí, para clientes web |
En ConnectMQ, ambos endpoints WebSocket usan la ruta /mqtt, así que la URL completa para el navegador es wss://broker.connectmq.com:8084/mqtt. Los puertos TLS presentan un certificado de Let's Encrypt, de confianza por defecto en casi todos los sistemas operativos y navegadores.
Puerto 1883: MQTT sin cifrar sobre TCP
El puerto 1883 transporta paquetes MQTT en bruto sin ningún cifrado. Usuarios, contraseñas y payloads cruzan la red en texto plano, legibles para cualquiera que pueda capturar el tráfico en el camino. Por eso el 1883 sirve para:
- Aprender y hacer experimentos rápidos en un servidor MQTT público gratuito.
- Un broker local dentro de una red de laboratorio aislada.
- Dispositivos muy limitados que hablan con un gateway cercano en un segmento que tú controlas.
No sirve para enviar credenciales por internet. Si ves una flota en producción usando el 1883, trátalo como un hallazgo que hay que corregir.
Puerto 8883: MQTT sobre TLS
El puerto 8883 envuelve los mismos paquetes MQTT en una sesión TLS. El cliente verifica el certificado del broker frente a una autoridad de certificación de confianza, negocia las claves y solo entonces envía el paquete CONNECT con sus credenciales. Es la opción estándar para dispositivos, gateways y servicios backend.
Lo que el 8883 exige al cliente:
- Una biblioteca TLS (mbedTLS en ESP32, OpenSSL en la mayoría de herramientas Linux, la pila de la plataforma en .NET y Java).
- Un paquete de CA de confianza para poder verificar el certificado del broker. Nunca desactives la verificación en producción.
- Un reloj razonablemente preciso, porque la validez del certificado depende de la fecha. Los dispositivos sin reloj de tiempo real deben sincronizar NTP antes de conectarse.
- Server Name Indication (SNI) configurado con el nombre de host del broker. La mayoría de bibliotecas lo hacen automáticamente cuando te conectas por nombre de host.
El coste adicional es un handshake al conectar y paquetes ligeramente más grandes. Como MQTT mantiene una única conexión de larga duración, ese handshake ocurre pocas veces, así que la sobrecarga en régimen estable es pequeña. Nuestra guía de buenas prácticas de seguridad MQTT cubre el resto de la lista de bastionado.
Puertos 8083 y 8084: MQTT sobre WebSocket
Los navegadores no pueden abrir sockets TCP en bruto, así que las aplicaciones web encapsulan MQTT dentro de tramas WebSocket. El cliente envía primero una petición HTTP de upgrade a una ruta (aquí /mqtt) y después intercambia paquetes MQTT binarios sobre la conexión actualizada.
- 8083 (
ws://) no está cifrado. Los navegadores modernos lo bloquean desde páginas servidas por HTTPS (contenido mixto), así que sirve sobre todo para pruebas locales. - 8084 (
wss://) es WebSocket sobre TLS, la única opción realista para un dashboard web en producción.
WebSocket tiene una segunda ventaja: para muchos proxies y firewalls parece tráfico HTTPS normal. Cuando la red de una fábrica o de un hotel bloquea el 8883, wss:// en el 8084 a veces pasa donde TLS en bruto no lo consigue. Consulta MQTT sobre WebSocket para ver código de navegador y advertencias sobre proxies.
Implicaciones para el firewall
Los clientes MQTT siempre inician la conexión saliente hacia el broker, y el broker devuelve los datos por esa misma conexión. Eso simplifica mucho las reglas de firewall:
- Permite TCP saliente desde las redes de dispositivos hacia el nombre de host del broker en el 8883 (y el 8084 si tienes clientes web).
- No hacen falta reglas entrantes en el lado de los dispositivos. Los dispositivos no escuchan en ningún puerto MQTT.
- Permite conexiones de larga duración. Algunos firewalls y gateways NAT descartan en silencio las sesiones TCP inactivas tras unos minutos. Configura el intervalo keep-alive de MQTT por debajo de ese timeout (60 segundos es una elección habitual) para que los paquetes PINGREQ mantengan viva la asignación.
- Evita la interceptación TLS para MQTT. Los equipos intermedios que vuelven a firmar certificados rompen la verificación en los dispositivos. Excluye el nombre de host del broker de la inspección.
- Prefiere nombres de host a listas de IP permitidas si tu firewall lo admite, porque los endpoints en la nube pueden cambiar de dirección.
Si solo consigues que abran un puerto, pide el 8883. Si ni siquiera eso es posible, pide el 8084 y conecta tus clientes por WebSocket seguro.
Prueba todos los puertos MQTT en cinco minutos
Los siguientes comandos usan broker.connectmq.com, el servidor MQTT público gratuito con acceso anónimo, pensado para pruebas y no para datos de producción. Usa un client ID y un prefijo de topic únicos, y recuerda que los topics públicos son visibles para todo el mundo.
Comprueba la accesibilidad TCP
# Linux / macOS
nc -vz broker.connectmq.com 1883
nc -vz broker.connectmq.com 8883
nc -vz broker.connectmq.com 8084
En Windows PowerShell, usa Test-NetConnection broker.connectmq.com -Port 8883 y busca TcpTestSucceeded : True.
Inspecciona el certificado TLS en el 8883
openssl s_client -connect broker.connectmq.com:8883 \
-servername broker.connectmq.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates
Deberías ver Let's Encrypt como emisor y fechas válidas. Si el emisor es el proxy de tu empresa, hay una interceptación TLS de por medio.
Publica y suscríbete en el 1883 y el 8883
# Terminal A: suscripción por TLS (mosquitto activa TLS cuando se indica una ruta de CA)
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-i ports-sub-91c2 -t "connectmq/demo/91c2/#" -v
# Terminal B: publicación por TCP sin cifrar
mosquitto_pub -h broker.connectmq.com -p 1883 -i ports-pub-91c2 \
-t "connectmq/demo/91c2/hello" -m "sent on 1883, received on 8883"
El mensaje pasa de un puerto al otro, lo que demuestra que los puertos son solo puntos de entrada al mismo broker.
Prueba WebSocket seguro en el 8084 con Node.js
// npm install mqtt
const mqtt = require("mqtt");
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId: "ports-wss-91c2",
protocolVersion: 5,
});
client.on("connect", () => {
console.log("Connected over wss on 8084");
client.subscribe("connectmq/demo/91c2/#", () => {
client.publish("connectmq/demo/91c2/wss", "hello from WebSocket");
});
});
client.on("message", (topic, payload) => {
console.log(topic, payload.toString());
client.end();
});
client.on("error", (err) => console.error("Error:", err.message));
Para TLS en bruto desde Node, cambia la URL por mqtts://broker.connectmq.com:8883.
Solución de problemas con los puertos
| Síntoma | Causa probable | Solución |
|---|---|---|
| Timeout de conexión en el 8883, el 1883 funciona | El firewall solo permite puertos comunes | Solicita salida por el 8883 o usa el 8084 |
| Falla el handshake TLS, certificado desconocido | Falta el paquete de CA o hay inspección TLS | Instala los certificados de CA y excluye el host del broker de la inspección |
| Certificado aún no válido | El reloj del dispositivo es incorrecto | Sincroniza NTP antes de conectar |
| WebSocket devuelve 404 | Ruta incorrecta | Usa /mqtt |
El navegador rechaza ws:// |
Contenido mixto en una página HTTPS | Usa wss:// en el 8084 |
| Desconexiones cada pocos minutos | Timeout de inactividad del NAT | Baja el keep-alive por debajo del timeout |
De los puertos de prueba a producción
En el servidor público te conectas de forma anónima; en un broker privado añades credenciales. Cuando creas un broker en el portal de ConnectMQ recibes un usuario, una contraseña y un client ID vinculado a esas credenciales, y se aplican los mismos cuatro puertos. Una configuración de producción típica usa el 8883 para dispositivos y gateways y el 8084 para el dashboard web, y deja el 1883 y el 8083 para depuración local. Como ConnectMQ es un broker MQTT gestionado, los certificados se renuevan por ti y no hay configuración de listeners que mantener. La guía de broker MQTT en la nube compara las opciones de alojamiento con más detalle, y el tutorial de MQTT para principiantes te guía paso a paso en tu primera conexión.
Empieza con ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y conéctate en el 8883 o el 8084 con las credenciales que genera el portal. El cliente integrado en el navegador de ConnectMQ te permite confirmar la conexión antes de tocar ningún firmware.
Preguntas frecuentes
¿Cuál es el puerto MQTT por defecto?
El puerto MQTT por defecto es el 1883 para TCP sin cifrar y el 8883 para MQTT sobre TLS. Ambos están registrados en la IANA.
¿Qué puerto MQTT debo usar en producción?
Usa el 8883 para dispositivos y servicios y el 8084 (WebSocket seguro) para navegadores. Evita el 1883 a través de internet, porque las credenciales viajan en texto plano.
¿Puedo usar MQTT en el puerto 443?
Algunos brokers ofrecen MQTT sobre WebSocket o TLS en el 443 para atravesar firewalls estrictos. broker.connectmq.com usa el 8883 y el 8084, así que pide a tu equipo de red que permita el tráfico saliente hacia esos puertos.
¿Por qué falla mi conexión WebSocket si TCP funciona?
Las causas más comunes son que falte la ruta /mqtt, usar ws:// desde una página HTTPS o un proxy que no admite upgrades a WebSocket.
