Prüfen, ob ein MQTT-Port offen ist (nc, telnet, nmap)

Um zu prüfen, ob ein MQTT-Port offen ist, führst du unter Linux oder macOS nc -vz -w 5 broker.connectmq.com 1883 aus oder in PowerShell Test-NetConnection broker.connectmq.com -Port 1883. "Succeeded" heißt, eine TCP-Verbindung wurde angenommen; "refused" oder "timed out" sagt dir, wo du als Nächstes suchen musst. Dieser Guide zeigt jedes Tool, was seine Ausgabe bedeutet und wie du ein Firewall-Problem von einem Broker-Problem unterscheidest.

Die zu prüfenden Ports

Die genauen Nummern hängen von der Broker-Konfiguration ab – siehe MQTT-Ports erklärt. In den Beispielen nutzen wir broker.connectmq.com, das auf 1883, 8883, 8083 und 8084 lauscht.

nc (netcat) – Linux und macOS

nc -z öffnet eine TCP-Verbindung und schließt sie, ohne Daten zu senden; -v gibt das Ergebnis aus und -w 5 gibt nach fünf Sekunden auf.

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

Der genaue Wortlaut variiert zwischen netcat-Varianten (macOS schreibt connectx to ..., manche Builds open), aber die drei Ergebnisse sind immer dieselben. Alle MQTT-Ports auf einmal prüfen:

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

Kein nc installiert? Bash kann selbst einen TCP-Socket öffnen:

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

telnet

telnet ist auf vielen Servern noch installiert und funktioniert unter Windows, sobald das Feature Telnet-Client aktiviert ist:

telnet broker.connectmq.com 1883

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

Connected to heißt, der Port ist offen. Mit Ctrl+] und quit beendest du die Sitzung. Siehst du stattdessen telnet: Unable to connect to remote host: Connection refused, hat nichts die Verbindung angenommen; eine lange Pause mit anschließendem Connection timed out deutet auf einen Filter dazwischen hin. Tippe nach dem Verbinden nichts ein – MQTT ist ein Binärprotokoll, und der Broker schließt die Verbindung, wenn sein Connect-Timeout ohne gültiges CONNECT-Paket abläuft. Das ist normal.

nmap – mehrere Ports und ihr Zustand

nmap meldet für jeden Port einen eindeutigen Zustand und ist damit das beste Tool, um "closed" von "filtered" zu unterscheiden:

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 überspringt den Ping-Check, den viele Cloud-Hosts blockieren. Die Spalte SERVICE ist nur nmaps Vermutung anhand der Portnummer, kein Beweis, dass dort MQTT läuft.

PowerShell Test-NetConnection – Windows

Test-NetConnection broker.connectmq.com -Port 1883

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

Bei einem Fehler siehst du WARNING: TCP connect to (203.0.113.10 : 1883) failed und TcpTestSucceeded : False. Mit -InformationLevel Quiet bekommst du für Skripte nur True / False. Ist ein lokaler Broker von anderen Rechnern aus nicht erreichbar, ist die Windows-Defender-Firewall eine häufige Ursache – siehe MQTT und die Windows-Firewall.

Das Ergebnis lesen: Firewall oder Broker?

Führe danach denselben Check aus einem zweiten Netz aus – Hotspot des Handys, eine Cloud-VM, der Rechner einer Kollegin. Ist der Port von außen offen, aber nicht aus deinem Büro, blockiert dein Netz ihn (häufig bei 1883 und 8883 in Firmen- und Gast-WLANs; siehe MQTT hinter einer Firmen-Firewall). Ist er überall geschlossen, liegt das Problem beim Broker.

Auf dem Broker-Host: Lauscht überhaupt etwas?

Betreibst du den Broker selbst und siehst "refused", prüfe, was lauscht:

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

netstat -ano | findstr :1883

Ein Listener auf 127.0.0.1:1883 nimmt nur lokale Verbindungen an. Mosquitto 2.x macht das standardmäßig, wenn kein Listener konfiguriert ist, und loggt Starting in local only mode. Connections will only be possible from clients running on this machine. Füge einen expliziten Listener (und Authentifizierung) hinzu, um entfernte Clients anzunehmen:

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

Der Mosquitto-Konfigurationsgenerator erstellt eine vollständige Datei mit TLS- und WebSocket-Listenern. Prüfe in Docker zusätzlich, ob der Port veröffentlicht ist (-p 1883:1883).

Port offen, aber keine Verbindung? Die nächste Schicht testen

Ein offener Port beweist nur, dass TCP funktioniert. Zwei schnelle Checks decken die Schichten darüber ab:

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

Mit -d zeigt ein gesunder Broker eine Zeile sending CONNECT, gefolgt von received CONNACK (0). Ein CONNACK ungleich null ist ein Authentifizierungs- oder Protokollproblem – schlage den Code im Reason-Codes-Tool nach. Hängt TLS auf 1883 oder scheitert MQTT auf 8883, hast du Klartext- und TLS-Port verwechselt. Zertifikatsfehler behandelt eine TLS-Verbindung testen. Verbinde dich zum Schluss mit dem Online-MQTT-Client, um einen vollständigen Publish/Subscribe-Round-Trip zu bestätigen.

Mit einem echten MQTT-Round-Trip bestätigen

Ein Port-Check dauert Sekunden und teilt das Problem in zwei Hälften: Scheitert TCP, liegt es an Netzwerk, Firewall oder Listener; klappt TCP, schau dir TLS, Zugangsdaten und MQTT selbst an. Prüfe aus mehr als einem Netz, lies "refused" und "timed out" unterschiedlich – und du weißt, wo du suchen musst, bevor du auch nur eine Logdatei öffnest.

Häufig gestellte Fragen