Modbus Connection Refused — Causes and Fixes (2026)

You launch your SCADA client or Modbus master, enter the device IP and port, click Connect — and get back "Connection Refused." Three words that can cost an entire commissioning day if you don't know where to look.

This guide breaks down every common cause of Modbus connection failures for both TCP and RTU variants, with exact diagnostic steps and fixes. At the end, there's a section on using ModbusSimulator to reproduce the problem in a controlled environment so you can verify your fix before touching the field device.

What "Connection Refused" Actually Means at the Protocol Level

The error message differs by transport, so the starting point of your diagnosis depends on whether you're on TCP or RTU.

Modbus TCP: A TCP-Layer Rejection

Modbus TCP runs over standard TCP/IP. When your master initiates a connection, the OS sends a TCP SYN packet to the target IP on port 502. There are three possible outcomes:

• SYN-ACK back — Something is listening. The TCP handshake completes. Modbus communication can now proceed.
• RST back — "Connection Refused." The target IP is reachable, but the TCP port is closed. Nothing is listening on port 502.
• No response / timeout — The IP is unreachable, the host is offline, or a firewall is silently dropping packets (not the same as refused).

"Connection refused" is therefore a very specific signal: the IP routing works, but the application layer is not ready. That narrows your problem to the slave side — the Modbus server process, the port number, or a host-side firewall rule.

Modbus RTU: No TCP, No "Refused" — But Similar Failures

Modbus RTU runs over serial (RS-232, RS-485, RS-422). There's no TCP handshake, so you won't see a "connection refused" message in the same sense. Instead, the equivalent failures are:

• COM port won't open — The port doesn't exist, is already in use, or the driver isn't installed.
• Port opens but no response — Serial settings mismatch, wrong slave ID, physical wiring problem, or the device isn't ready.

The underlying cause in both cases is the same: master and slave can't establish a working communication channel. The rest of this guide covers each failure mode and how to fix it.

Modbus TCP: Common Causes of Connection Refused

1. Wrong Port Number

Modbus TCP is assigned TCP port 502 by IANA (Internet Assigned Numbers Authority). This is the default, and the vast majority of PLCs, remote I/O modules, drives, and gateways listen on 502 out of the box.

If your master is configured for any other port — 1502, 8502, 10502 — without explicit documentation from the device vendor saying otherwise, change it back to 502. This is the single most common mistake when setting up a new TCP connection.

Some devices do use non-standard ports, particularly embedded web servers that host Modbus on a secondary port, or Modbus TCP-to-RTU gateways that expose multiple serial ports as separate TCP ports (e.g., 502 for COM1, 503 for COM2). Always check the device datasheet.

2. Slave Application Not Running

Even if the hardware is on and the IP address is correct, the Modbus TCP server process must be running and actively listening on port 502. On a PLC, this is typically always on when the PLC is in RUN mode. But on PC-based slaves, SCADA servers, or software-defined devices, the application can crash, fail to start, or be stopped deliberately.

Check the slave side first. On a Windows machine running a Modbus slave application, open a command prompt and run:

netstat -an | findstr :502

If you see a line with 0.0.0.0:502 or the specific IP in LISTENING state, the server is up. If nothing appears, the slave process isn't running — start it before debugging anything else.

On Linux:

ss -tlnp | grep 502

3. Firewall Blocking Port 502

This is the most frequent cause when the slave is confirmed to be listening but remote clients still get "connection refused" (or a timeout). The host-based firewall on the slave machine is accepting traffic from localhost but blocking it from the network.

On Windows, check Windows Defender Firewall. Look for an inbound rule that explicitly allows TCP port 502. If no such rule exists, add one:

1. Open Windows Defender Firewall → Advanced Settings
2. Inbound Rules → New Rule
3. Port → TCP → Specific local ports: 502
4. Allow the connection → Apply to Domain, Private, Public as required

Also check for any network-layer firewalls: managed switches with ACLs, router firewall rules, or enterprise security policies that block industrial protocol ports. Port 502 is sometimes blocked by default on corporate networks for security reasons.

4. Wrong IP Address

Simple, but worth stating: verify you have the right IP. Devices in the field get reassigned, subnets change during network upgrades, and someone inevitably mis-types an octet in a commissioning sheet.

Test IP reachability first with a ping:

ping 192.168.1.100

If ping succeeds, the IP is correct and the host is up — the problem is TCP layer (port/firewall). If ping fails, you have an IP or routing problem to solve before Modbus is even relevant.

Then test the TCP port specifically:

telnet 192.168.1.100 502

A blank screen means connected (port open). "Could not open connection" or "Connection refused" confirms port 502 is closed at that IP.

If telnet is not available on your Windows machine, enable it via: Control Panel → Programs → Turn Windows features on or off → Telnet Client. Alternatively, use PowerShell:

Test-NetConnection -ComputerName 192.168.1.100 -Port 502

5. Slave Listening on a Specific Interface Only

Some Modbus slave software binds to a specific network interface rather than 0.0.0.0 (all interfaces). If the slave is bound to 127.0.0.1 (loopback only), external connections will be refused even if port 502 is technically in use. Check the slave application's binding configuration and set it to bind to the correct interface IP or to all interfaces.

6. Too Many Simultaneous Connections

Many PLCs and embedded devices limit the number of concurrent Modbus TCP connections — often 4, 8, or 16 connections maximum. If those slots are exhausted by other masters (other SCADA clients, HMIs, data loggers), a new connection attempt will be refused at the TCP level. Check how many clients are currently connected to the device and close any unused connections.

Modbus RTU: Common Causes of Connection Failures

1. Wrong COM Port

On a Windows PC, the USB-to-RS485 adapter or serial port must map to the COM port number configured in your master software. COM port assignments can change when you plug into a different USB port or after a driver update.

Open Device Manager → Ports (COM & LPT) to see the current COM port number assigned to your adapter. Match this exactly in your master software. If the port number keeps changing, assign a fixed COM port number in the device driver properties.

2. Serial Parameter Mismatch

All devices on a Modbus RTU network must use exactly the same serial communication parameters. One wrong setting and you get nothing:

Parameter	Common Values	Notes
Baud rate	9600, 19200, 38400, 115200	Must match exactly — 9600 vs 19200 gives garbage or silence
Data bits	8 (RTU), 7 (ASCII)	Always 8 for Modbus RTU
Parity	None, Even, Odd	Even parity is the Modbus specification default; many devices default to None
Stop bits	1, 2	1 stop bit when parity is used; 2 stop bits when parity is None (per spec, but not always enforced)

The most common default across industrial devices is 9600 8N1 (9600 baud, 8 data bits, no parity, 1 stop bit). But always verify against the specific device manual — especially for drives and energy meters, which often use different defaults.

3. Wrong Slave ID

Modbus RTU uses a single-byte slave address field (1–247). If you send a request to slave ID 1 and the device is configured for slave ID 5, the device will silently ignore the message. You won't get an exception code — just silence, followed by a timeout on the master side.

Check the device's DIP switches, rotary switches, or configuration menu for its assigned slave ID. If unknown, use an address scan: send requests to slave IDs 1 through 247 in sequence (with a short timeout) and watch for any response. ModbusSimulator's address scanner automates this.

4. RS-485 Wiring Problems

RS-485 uses a differential pair (two wires) for half-duplex communication. Wiring errors are among the most common field problems.

Swapped A/B polarity: RS-485 labels vary by manufacturer — some call the positive wire A, others call it B. The Modbus specification defines A as the negative wire (D−) and B as the positive wire (D+), but many industrial device manufacturers reverse this. If communication doesn't work, try swapping the two wires. This is a valid first-step field fix.

Missing termination resistors: For RS-485 networks longer than approximately 10–15 meters, 120-ohm termination resistors should be placed at both physical ends of the bus. Without termination, signal reflections cause data corruption, especially at higher baud rates. Many PLCs and RS-485 converters have a built-in switchable termination resistor — enable it at the two endpoints only.

Missing bias resistors: When no device on the bus is transmitting, the differential pair floats. A floating bus can pick up noise and cause false start bits. Bias resistors (typically 560 ohms, pull-up on B, pull-down on A) keep the bus in a defined idle state. Some RS-485 converters include these by default.

Ground reference: RS-485 requires a common signal ground between all devices on the bus. A three-wire connection (A, B, and GND) is correct. Without the common ground, the common-mode voltage can exceed the RS-485 receiver's input range (±7V typically), causing intermittent errors or no communication.

Cable type: Use shielded twisted-pair cable (e.g., Belden 3105A or equivalent). Ground the shield at one point only to avoid creating a ground loop. In environments with heavy electrical noise (near VFDs, servo drives, contactors), shielded cable is not optional.

5. COM Port Already in Use

Windows will refuse to open a COM port that is already held open by another application. Close any other serial terminal, Modbus tool, or driver software that might have the port open. If no application appears to be using it, check for ghost device drivers or virtual COM port software running in the background.

Diagnostic Workflow: Step by Step

For Modbus TCP

1. Ping the slave IP. If ping fails, fix IP/routing before anything else.
2. Test port 502 with telnet or Test-NetConnection. If refused, nothing is listening — go to step 3. If it connects, go to step 5.
3. Check that the slave application is running (netstat -an | findstr :502 on Windows). If not running, start it.
4. Check the firewall. Temporarily disable the host firewall and test again. If it now connects, add the inbound port 502 rule and re-enable the firewall.
5. Capture with Wireshark. On the master machine, filter on tcp.port == 502. You should see a SYN packet out and a SYN-ACK back. If you see SYN and RST, port is closed. If you see SYN and nothing, the IP is unreachable or traffic is being dropped upstream.
6. Check connection count on the slave device. If at the maximum, close unused connections.

For Modbus RTU

1. Verify the COM port exists in Device Manager and the number matches your master software.
2. Check serial parameters against the device manual: baud rate, parity, data bits, stop bits.
3. Confirm slave ID from the device's physical configuration (DIP switches, display menu).
4. Check A/B wiring. If unsure, try swapping the two wires.
5. Run a Modbus address scan to discover which slave IDs respond, which confirms the physical layer and serial settings are working.
6. Enable raw communication logging in your master software. Confirm TX frames are being sent. If TX is present but RX is empty, the device isn't responding — wiring or slave ID. If TX is absent, the COM port isn't opening correctly.
7. Check RS-485 termination and bias if the bus has multiple devices or long cable runs.

For a broader set of Modbus errors beyond connection failures, see the Modbus troubleshooting guide.

Fix Checklists

Modbus TCP Connection Refused — Fix Checklist

Check	Action
IP address correct?	Verify from device label, config menu, or network scan
Device reachable?	Run ping <ip>
Port correct?	Default is 502; check device manual for exceptions
Port listening?	Run netstat -an | findstr :502 on slave host
Slave application running?	Check process list or service status on slave host
Host firewall rule?	Add inbound TCP allow rule for port 502
Network firewall?	Confirm no ACL or security policy blocking port 502
Connection limit reached?	Check active connection count on slave; close unused ones
Slave bound to correct interface?	Ensure slave binds to 0.0.0.0 or the correct NIC IP

Modbus RTU Connection Failed — Fix Checklist

Check	Action
COM port exists?	Verify in Device Manager → Ports (COM & LPT)
COM port number correct?	Match exactly in master software
Port not in use?	Close all other applications using the COM port
Baud rate matches?	Check device manual; try 9600 as a baseline
Parity and stop bits match?	Try N81 (None, 8, 1) and E81 (Even, 8, 1) as the two most common
Slave ID correct?	Check DIP switches or device display; run address scan if unknown
A/B polarity correct?	Swap wires if no response after confirming settings
Termination installed?	Add 120-ohm resistors at both ends of RS-485 bus for runs over 10m
Common ground connected?	Connect signal GND between master and slave
Cable quality?	Use shielded twisted-pair; check for breaks or short circuits

Using ModbusSimulator to Reproduce and Test the Fix

One of the most effective ways to diagnose a Modbus connection problem is to eliminate variables by substituting ModbusSimulator for either the master or the slave. This lets you confirm whether the problem lives in your master software, your slave device, or the network between them.

Scenario 1: Your Master Can't Connect to the Real Device

Start ModbusSimulator in Slave mode on the same machine running your master software. Configure it to listen on TCP port 502 (or whatever port your device uses). Now connect your master to 127.0.0.1:502.

If the master connects to the simulator but not to the real device, the master configuration is correct — the problem is in the real device's network settings, firewall, or application. If the master fails to connect even to the local simulator, the problem is in the master software or its connection configuration.

Scenario 2: You Need to Test a New Master Configuration Before Going to Site

Run ModbusSimulator as a TCP or RTU slave, populate registers with representative values, and test your SCADA or PLC master configuration against it. This lets you validate register addresses, function codes, byte ordering, and scaling factors in the office before the field device is available.

Scenario 3: Verifying RS-485 Hardware After Wiring Changes

On a dedicated test bench, run ModbusSimulator as an RTU slave over a USB-to-RS485 adapter. Connect your field wiring to a second adapter and use another Modbus master tool. If communication works on the test bench but not in the field, the problem is in the field wiring or environment (noise, termination, cable run).

ModbusSimulator's communication logger shows every raw TX and RX frame in hex, making it straightforward to confirm whether the correct bytes are being sent and received. For more on RTU simulation, see the Modbus RTU simulator guide. For TCP simulation, see Modbus TCP simulator.

Frequently Asked Questions

What does "Modbus connection refused" mean?

For Modbus TCP, it's a TCP-layer signal meaning the target host is reachable at the IP level but the TCP port (typically 502) is closed — nothing is listening. The remote OS sent back a RST packet in response to the connection attempt. For Modbus RTU, the equivalent is the COM port failing to open, because it doesn't exist, is already held by another process, or the driver is missing.

What port does Modbus TCP use?

TCP port 502, IANA-registered for Modbus. Most devices use this by default. Some gateways allow configuration of a different port; check the vendor documentation before assuming a non-standard port.

How do I check if a Modbus slave is listening on port 502?

On Windows (at the slave machine): netstat -an | findstr :502. A result showing LISTENING confirms the server is up. From the master side: telnet <ip> 502 or Test-NetConnection -ComputerName <ip> -Port 502 in PowerShell.

Why does Modbus TCP work locally but not from a remote client?

Almost always a firewall issue. The slave application is listening, but the host firewall blocks inbound TCP connections on port 502 from external IP addresses. Add an explicit inbound allow rule for TCP 502 on the slave host.

What serial settings must match for Modbus RTU?

Baud rate, data bits (8 for RTU), parity (None/Even/Odd), and stop bits. Every device on the bus must use identical settings. The most common default is 9600 8N1, but verify against the device datasheet.

What is the difference between connection refused and connection timeout?

"Connection refused" means the host is reachable and actively sent back a rejection (RST). "Connection timeout" means no response — the IP is unreachable, the host is offline, or a firewall is silently dropping packets. Refused is actually easier to diagnose; it confirms your IP routing is working.

Can I test Modbus TCP without physical hardware?

Yes. ModbusSimulator runs as a Modbus TCP slave, listening on port 502. Connect your master software to 127.0.0.1:502 to test configuration, register mapping, and data parsing without any hardware present.

How do I fix RS-485 wiring causing Modbus RTU failures?

Check A/B polarity (swap wires if unsure), add 120-ohm termination resistors at both ends of the bus for runs over 10 meters, connect a common signal ground between all devices, and use shielded twisted-pair cable. Bias resistors on the converter prevent the bus from floating when idle.