Modbus TCP Timeout oder Connection refused: Checkliste zur Fehlersuche

Kurzantwort: Finden Sie zuerst die Schicht. Connection refused heißt: Die IP-Adresse funktioniert, aber auf diesem Port lauscht nichts. Ein Connect-Timeout deutet auf Routing, eine Firewall oder einen toten Host. Steht die Verbindung und laufen danach Lesezugriffe in den Timeout, prüfen Sie Unit-ID und Framing. Eine Modbus Exception bedeutet, dass das Netzwerk in Ordnung ist.

Das Symptom lesen

Symptom	Was es ausschließt	Als Nächstes prüfen
Connection refused (Verbindung abgelehnt)	Host läuft, Route funktioniert	Portnummer, Dienst am Gerät aktiviert
Connect timeout	Noch nichts	Gleiches Subnetz? VLAN, Firewall, Stromversorgung des Geräts
Verbindung steht, Lesezugriffe laufen in den Timeout	Netzwerk und Port	Unit-ID, Modbus TCP vs. RTU-Framing, Client-Limit
Funktioniert, fällt dann in Abständen aus	Grundeinstellungen	Abfragerate, konkurrierende Clients, Wi-Fi-Qualität
Exception `83 02` und ähnliche	Den gesamten Netzwerkpfad	Adressierung. Siehe Exception Codes
Exception `0A` oder `0B`	Den Weg vom Client zum Gateway	Die serielle Seite hinter dem Gateway

Den ersten und den dritten Fall haben wir auf einem lokalen Server mit pymodbus 3.16.1 nachgestellt: Ein geschlossener Port lieferte ConnectionRefusedError, und ein Frame mit einer Protocol-ID ungleich null bekam gar keine Antwort, nur einen Client-Timeout. Schweigen sagt weniger aus als ein Fehler.

Schritt 1: Erreichen Sie den Host?

Pingen Sie ihn an, wenn das Gerät ICMP erlaubt. Viele Industriegeräte tun das nicht, ein fehlgeschlagener Ping beweist also wenig. Prüfen Sie, dass beide Seiten im selben Subnetz liegen, und achten Sie auf Gast-WLAN, das Clients oft voneinander isoliert.

Auf dem iPhone gibt es eine weitere Hürde: iOS fragt bei der ersten Verbindung nach der Berechtigung für Lokales Netzwerk. Haben Sie „Nicht erlauben“ gewählt, kann die App nichts in Ihrem LAN erreichen, bis Sie die Berechtigung unter Einstellungen einschalten.

Schritt 2: Stimmt der Port?

Der Implementation Guide reserviert TCP 502 für Modbus. Reale Geräte weichen ab. Gateways verwenden oft einen anderen Port, und an RS-485-Konvertern tauchen 8899 und 4196 auf. Geräte suchen in FieldKit prüft standardmäßig 502, 1502, 8899 und 4196 und zeigt Ihnen, welche geantwortet haben.

Eine Portnummer verrät nicht das Protokoll. Port 8899 kann ein transparenter Konverter sein, ein Modbus-TCP-Gateway oder ein Solarman-Logger, der V5 spricht.

Schritt 3: Verbunden, aber stumm

Das ist der häufigste Fall. Drei Ursachen decken das meiste ab.

Falsche Unit-ID. Hinter einem Gateway wählt die Unit-ID das serielle Gerät aus. Senden Sie eine Nummer, die kein Gerät hat, antwortet ein Gateway nach Spezifikation mit Exception 0B, andere lassen den Client in den Timeout laufen. Scannen Sie die gängigen Werte. Mehr zur Unit-ID.

Falsches Framing. Ein Konverter im transparenten Modus reicht Bytes direkt an RS-485 weiter. Eine Anfrage mit MBAP-Framing bedeutet dem Gerät auf der anderen Seite nichts, also sagt es nichts. Wechseln Sie zu RTU over TCP und versuchen Sie einen Lesezugriff. So erkennen Sie, welchen Modus Sie haben.

Zu viele Clients. Der Implementation Guide erlaubt Geräten, ihre Verbindungen zu begrenzen, und kleine Geräte lassen womöglich nur einen oder zwei zu. Schließen Sie SCADA, andere Poller und alte Sitzungen und versuchen Sie es erneut. Ein Gateway nimmt Ihre TCP-Verbindung unter Umständen an und liefert Ihnen trotzdem nichts.

Schritt 4: Es funktioniert, dann nicht mehr

Langsamer abfragen. RS-485 ist langsam. Bei 9600 Baud dauert das Lesen von 125 Registern allein auf der Leitung etwa eine Drittelsekunde, und ein Poller, der schneller abfragt, als der Bus antworten kann, baut einen Rückstau auf.
Timeout erhöhen. Ein Konverter bringt Latenz mit. Probieren Sie 2000 ms, bevor Sie einen Fehler annehmen.
Nach einem zweiten Master suchen. RTU hat keine Transaction-ID, daher können zwei Master an einer Leitung gegenseitig ihre Antworten empfangen.
Wi-Fi prüfen. Ein schwaches Signal in einem Stahlschrank sieht aus wie ein unzuverlässiges Gerät. Stellen Sie den Wert als Diagramm dar und achten Sie auf die Lücken.

Schritt 5: Mit einem funktionierenden Client vergleichen

Scheitert ein Tool und ein anderes funktioniert, liegt die Antwort im Unterschied. Notieren Sie, was jedes sendet: Unit-ID, Protocol-ID, Framing und Adresse. Zeichnen Sie den funktionierenden Frame mit Wireshark auf und fügen Sie ihn in den Frame-Decoder ein.

Quellen

Modbus Messaging on TCP/IP Implementation Guide V1.0b, Abschnitte 3 und 4
Lokale Tests am 30. Oktober 2026 mit pymodbus 3.16.1 unter Linux

FAQ

Warum verbindet sich Modbus TCP, antwortet aber nicht?

Der TCP-Port ist offen, aber auf Modbus-Ebene antwortet nichts. Übliche Ursachen sind eine falsche Unit-ID hinter einem Gateway, ein RTU-Konverter im transparenten Modus, der RTU-Frames erwartet, oder ein Gerät, das bereits die maximale Zahl an Clients bedient.

Was ist der Standard-Port von Modbus TCP?

Port 502. Der Implementation Guide reserviert ihn für Modbus, und viele Gateways und Testtools bieten auch andere Ports an, etwa 1502 oder 8899.

Heißt Connection refused, dass das Gerät ausgeschaltet ist?

Nein. Es bedeutet, dass etwas unter dieser IP-Adresse geantwortet und den Port abgelehnt hat. Der Host läuft, und der Port ist falsch oder der Dienst läuft nicht. Ein toter Host führt stattdessen zu einem Timeout.