Modbus TCP timeout or connection refused: a troubleshooting checklist

Read the symptom

Symptom	What it rules out	Check next
Connection refused	Host is alive, route works	Port number, service enabled on the device
Connect timeout	Nothing, yet	Same subnet? VLAN, firewall, device power
Connects, reads time out	Network and port	Unit ID, Modbus TCP vs RTU framing, client limit
Works, then fails at intervals	Basic settings	Polling rate, competing clients, Wi-Fi quality
Exception 83 02 and friends	The whole network path	Addressing. See exception codes
Exception 0A or 0B	Client to gateway path	The serial side behind the gateway

We reproduced the first and the third on a local pymodbus 3.16.1 server: a closed port returned ConnectionRefusedError, and a frame with a non-zero Protocol ID got no reply at all, only a client timeout. Silence tells you less than an error does.

Step 1: can you reach the host?

Ping it if the device allows ICMP. Many industrial devices don’t, so a failed ping proves little. Check that both ends are on the same subnet, and watch for guest Wi-Fi, which often isolates clients from each other.

On iPhone there’s one more gate: iOS asks for Local Network permission on the first connection. If you tapped Don’t Allow, the app can’t reach anything on your LAN until you turn it on under Settings.

Step 2: is the port right?

The implementation guide reserves TCP 502 for Modbus. Real devices vary. Gateways often use another port, and 8899 and 4196 turn up on RS-485 converters. FieldKit’s Find devices checks 502, 1502, 8899 and 4196 by default and tells you which ones answered.

A port number doesn’t tell you the protocol. Port 8899 may be a transparent converter, a Modbus TCP gateway, or a Solarman logger speaking V5.

Step 3: connected but silent

This is the most common case. Three causes cover most of it.

Wrong Unit ID. Behind a gateway, the Unit ID selects the serial device. If you send a number no device has, a spec-following gateway answers exception 0B, and others let the client time out. Scan the common values. More on the Unit ID.

Wrong framing. A converter in transparent mode passes bytes straight to RS-485. An MBAP-framed request means nothing to the device on the other side, so it says nothing. Switch to RTU over TCP and try one read. How to tell which one you have.

Too many clients. The implementation guide lets devices cap their connections, and small devices may allow only one or two. Close SCADA, other pollers and old sessions, then try again. A gateway may accept your TCP connection and still give you nothing.

Step 4: it works, then it doesn’t

• Lower the polling rate. RS-485 is slow. At 9600 baud a read of 125 registers takes about a third of a second on the wire alone, and a poller that fires faster than the bus can answer builds a backlog.
• Raise the timeout. A converter adds latency. Try 2000 ms before you assume a fault.
• Look for a second master. RTU has no transaction ID, so two masters on one line can receive each other’s answers.
• Check the Wi-Fi. A weak signal in a steel cabinet looks like a flaky device. Chart the value and look at the gaps.

Step 5: compare with a known good client

If one tool fails and another works, the difference is your answer. Note what each one sends: Unit ID, Protocol ID, framing and address. Capture the working frame with Wireshark and paste it into the frame decoder.

Sources

• Modbus Messaging on TCP/IP Implementation Guide V1.0b, sections 3 and 4
• Local tests on 30 October 2026 with pymodbus 3.16.1 on Linux