Vérifier si un port MQTT est ouvert (nc, telnet, nmap)

Pour vérifier si un port MQTT est ouvert, lancez nc -vz -w 5 broker.connectmq.com 1883 sous Linux ou macOS, ou Test-NetConnection broker.connectmq.com -Port 1883 dans PowerShell. "Succeeded" signifie qu'une connexion TCP a été acceptée ; "refused" ou "timed out" vous indique où chercher ensuite. Ce guide présente chaque outil, la signification de sa sortie et la façon de distinguer un problème de pare-feu d'un problème de broker.

Les ports à vérifier

Les numéros exacts dépendent de la configuration du broker — voir les ports MQTT expliqués. Dans les exemples, nous utilisons broker.connectmq.com, qui écoute sur 1883, 8883, 8083 et 8084.

nc (netcat) — Linux et macOS

nc -z ouvre une connexion TCP et la referme sans envoyer de données ; -v affiche le résultat et -w 5 abandonne au bout de cinq secondes.

nc -vz -w 5 broker.connectmq.com 1883

Connection to broker.connectmq.com port 1883 [tcp/ibm-mqtt] succeeded!
nc: connect to broker.connectmq.com port 1883 (tcp) failed: Connection refused
nc: connect to broker.connectmq.com port 1883 (tcp) failed: Connection timed out

Le libellé exact varie selon les variantes de netcat (macOS affiche connectx to ..., certaines versions affichent open), mais les trois résultats sont toujours les mêmes. Vérifiez tous les ports MQTT d'un coup :

for p in 1883 8883 8083 8084; do nc -vz -w 5 broker.connectmq.com "$p"; done

Pas de nc installé ? Bash peut ouvrir un socket TCP tout seul :

timeout 5 bash -c '</dev/tcp/broker.connectmq.com/1883' && echo open || echo closed

telnet

telnet est encore installé sur de nombreux serveurs et fonctionne sous Windows une fois la fonctionnalité Client Telnet activée :

telnet broker.connectmq.com 1883

Trying 203.0.113.10...
Connected to broker.connectmq.com.
Escape character is '^]'.

Connected to signifie que le port est ouvert. Appuyez sur Ctrl+] puis tapez quit pour sortir. Si vous voyez plutôt telnet: Unable to connect to remote host: Connection refused, rien n'a accepté la connexion ; une longue pause suivie de Connection timed out désigne un filtre sur le chemin. Ne tapez rien après la connexion — MQTT est un protocole binaire, et le broker fermera la connexion à l'expiration de son délai de connexion faute de paquet CONNECT valide. C'est normal.

nmap — plusieurs ports et leur état

nmap indique un état clair pour chaque port, ce qui en fait le meilleur outil pour distinguer "closed" de "filtered" :

nmap -Pn -p 1883,8883,8083,8084 broker.connectmq.com

PORT     STATE    SERVICE
1883/tcp open     mqtt
8883/tcp open     secure-mqtt
8083/tcp open     us-srv
8084/tcp filtered websnp

-Pn saute le ping préalable, que beaucoup d'hôtes cloud bloquent. La colonne SERVICE n'est qu'une supposition de nmap d'après le numéro de port, pas la preuve que MQTT tourne derrière.

PowerShell Test-NetConnection — Windows

Test-NetConnection broker.connectmq.com -Port 1883

ComputerName     : broker.connectmq.com
RemoteAddress    : 203.0.113.10
RemotePort       : 1883
TcpTestSucceeded : True

En cas d'échec, vous verrez WARNING: TCP connect to (203.0.113.10 : 1883) failed et TcpTestSucceeded : False. Utilisez -InformationLevel Quiet pour obtenir seulement True / False dans un script. Si un broker local est injoignable depuis d'autres machines, le pare-feu Windows Defender est une cause fréquente — voir MQTT et le pare-feu Windows.

Lire le résultat : pare-feu ou broker ?

Ensuite, refaites la même vérification depuis un second réseau — le partage de connexion de votre téléphone, une VM cloud, la machine d'un collègue. Si le port est ouvert depuis l'extérieur mais pas depuis votre bureau, c'est votre réseau qui le bloque (fréquent pour 1883 et 8883 sur les réseaux d'entreprise et Wi-Fi invités ; voir MQTT derrière un pare-feu d'entreprise). S'il est fermé partout, le problème vient du broker.

Sur l'hôte du broker : quelque chose écoute-t-il ?

Si vous gérez le broker vous-même et obtenez "refused", vérifiez ce qui écoute :

sudo ss -ltnp | grep -E '1883|8883'        # Linux
sudo lsof -iTCP -sTCP:LISTEN -n -P | grep -E '1883|8883'   # macOS

netstat -ano | findstr :1883

Un listener sur 127.0.0.1:1883 n'accepte que les connexions locales. Mosquitto 2.x fait cela par défaut quand aucun listener n'est configuré et journalise Starting in local only mode. Connections will only be possible from clients running on this machine. Ajoutez un listener explicite (et une authentification) pour accepter les clients distants :

listener 1883 0.0.0.0
allow_anonymous false
password_file /etc/mosquitto/passwd

Le générateur de configuration Mosquitto produit un fichier complet avec listeners TLS et WebSocket. Sous Docker, vérifiez aussi que le port est publié (-p 1883:1883).

Port ouvert, mais toujours pas de connexion ? Testez la couche suivante

Un port ouvert prouve seulement que TCP fonctionne. Deux vérifications rapides couvrent les couches supérieures :

openssl s_client -connect broker.connectmq.com:8883 -servername broker.connectmq.com </dev/null

mosquitto_pub -h broker.connectmq.com -p 1883 -t testmqtt/port-check/ping -m ok -d

Avec -d, un broker sain affiche une ligne sending CONNECT suivie de received CONNACK (0). Un CONNACK non nul signale un problème d'authentification ou de protocole — cherchez le code avec l'outil des reason codes. Si TLS reste bloqué sur 1883 ou si MQTT échoue sur 8883, vous avez inversé le port en clair et le port TLS. Les erreurs de certificat sont traitées dans tester une connexion TLS. Enfin, connectez-vous avec le client MQTT en ligne pour confirmer un aller-retour publish/subscribe complet.

Confirmer avec un vrai aller-retour MQTT

Vérifier un port prend quelques secondes et coupe le problème en deux : si TCP échoue, c'est une question de réseau, de pare-feu ou de listener ; si TCP réussit, regardez TLS, les identifiants et MQTT lui-même. Faites la vérification depuis plusieurs réseaux, lisez "refused" et "timed out" différemment, et vous saurez où chercher avant d'ouvrir le moindre fichier de log.

Questions fréquentes