Modbus Connection Refused (ECONNREFUSED / Error 111): Complete Diagnostic & Troubleshooting Guide
Few errors in industrial automation are as frustrating during field commissioning as Connection Refused (ECONNREFUSED / Error 111 / Winsock 10061). You can successfully ping the PLC or gateway IP address, but the moment your SCADA, HMI, Python script, or Modbus master client attempts to establish a TCP session on port 502, the socket instantly crashes.
Unlike a timeout where the network hangs in silence, a Connection Refused error is an explicit rejection: the target device is awake and processing packets, but actively refusing your TCP handshake. In this guide, we break down why Modbus TCP connections are refused and walk through step-by-step diagnostic commands to restore communications quickly.
What Happens on the Wire: TCP Handshake Anatomy
To understand why an ECONNREFUSED error occurs, consider the standard Transmission Control Protocol (TCP) three-way handshake:
- SYN: The client (your SCADA or polling tool) sends a synchronization packet to the target IP address on port 502.
- Normal Response (SYN-ACK): If a Modbus TCP daemon or PLC server block is listening on port 502, the target replies with a SYN-ACK packet, completing connection setup.
- Refusal Response (RST / ACK): If the destination OS receives the SYN packet on port 502 but no listening socket is bound to that port, the destination TCP stack immediately returns an RST (Reset) packet.
Key Difference: Timeout vs. Connection Refused
Connection Refused (RST): Returns within 5–20 milliseconds. The physical cable is intact, IP routing works, and the target machine received your packet. The problem is purely at the application / port layer.
Timeout (No Response): Returns after 1000–5000 milliseconds. Packets are dropped by a firewall, routing is broken, or the physical controller is powered off.
Top 5 Causes of Modbus TCP Connection Refused
1. Modbus Server Process or Ladder Logic Block is Inactive
In modern PLCs (e.g., Siemens S7-1200 / S7-1500), Modbus TCP server functionality does not run automatically in the background. It must be explicitly programmed as an MB_SERVER function block in OB1 or a cyclic interrupt routine. If the PLC is placed in STOP mode, or if the enable bit (EN) on the communication block is low, the PLC closes the listener socket and responds with TCP RST to all incoming connection attempts.
2. PLC Concurrent Socket Exhaustion
Industrial PLCs are embedded controllers with constrained memory and TCP stacks. Most PLCs support between 2 and 8 concurrent TCP connections. When:
- Multiple operators open local HMI panels,
- A central SCADA polls tags continuously,
- An engineer connects via programming software (TIA Portal, EcoStruxure, SoMachine),
- Automated data logging scripts fail to close sockets properly in exception handlers,
the PLC exhausts its socket table. When an additional client attempts to connect, the PLC kernel refuses the handshake until an existing connection times out (keepalive) or disconnects.
3. Port Number Mismatch (Default 502 vs Custom Port)
Standard Modbus TCP uses port 502. However, when multiple Modbus services run on the same industrial PC or virtual machine, secondary slaves often listen on ports 503, 1502, or 5020. If your client defaults to port 502 while the slave application binds to port 5020, every connection attempt to 502 will be refused.
4. IP Binding Configuration (127.0.0.1 vs 0.0.0.0)
When testing Modbus servers or gateways hosted on Linux or Windows PCs, server software often binds to localhost (127.0.0.1) by default instead of all interfaces (0.0.0.0). While testing works on the local machine, any remote client on the local network attempting to connect will receive an ECONNREFUSED response.
5. Firewall or Security Software Blocking Port 502
Corporate IT firewalls, managed industrial switches with Access Control Lists (ACLs), or Windows Defender Firewall can reject unauthorized traffic. Some firewalls actively send TCP RST packets instead of silently dropping packets, resulting in an immediate connection refused error.
Step-by-Step Diagnostic Workflow
Step 1: Test Port 502 Reachability from Command Line
Before opening SCADA configuration software, test the socket directly using native command-line utilities:
On Windows (PowerShell):
Test-NetConnection -ComputerName 192.168.1.100 -Port 502Look at TcpTestSucceeded: if False, the port is closed or refused.
On Linux / macOS:
nc -zv -w 3 192.168.1.100 502If output returns Connection refused, the host is live but port 502 is not listening.
Step 2: Check Listening Ports on the Target Host
If you have terminal access to the host machine running the Modbus server or gateway, check which ports are actively listening:
netstat -tulpn | grep 502
# or using modern ss:
ss -tulpn | grep 502
Verify that the address column shows 0.0.0.0:502 or :::502 (listening on all interfaces), rather than 127.0.0.1:502.
Step 3: Capture the Handshake in Wireshark
Filter Wireshark with:
tcp.port == 502 && ip.addr == 192.168.1.100
If you observe [SYN] from your PC followed immediately by [RST, ACK] from the destination IP, your connection is confirmed refused by the target device.
Using ModbusSimulator to Isolate Hardware vs Software Faults
When diagnosing a field issue, the fastest way to find the fault is isolation: is the problem in your SCADA / master software, or in the target PLC / physical network?
With ModbusSimulator, you can spin up a fully compliant virtual Modbus TCP slave on your laptop in seconds:
- Launch ModbusSimulator and select Modbus TCP Slave.
- Configure listening port to 502 and bind to your local IP address.
- Point your SCADA system, HMI, or diagnostic client to
127.0.0.1or your local IP. - If communication succeeds with the simulator, your client driver and tag mappings are proven functional. The connection refused error is confirmed to be on the physical PLC side (stopped CPU, disabled communication block, or exhausted sockets).
Troubleshoot Modbus TCP Systems Without Hardware
Simulate Modbus TCP and RTU devices on Windows. Test connection limits, inject communication errors, and validate SCADA tags before field commissioning.
Download ModbusSimulator (30-Day Free Trial)Summary Checklist: How to Fix Modbus Connection Refused
- Check PLC Run Mode: Ensure the controller CPU is in RUN mode and the communication function block (e.g.,
MB_SERVER) is executing cyclically. - Audit Active Sockets: Power cycle the PLC or close orphaned client sessions to clear exhausted socket tables.
- Confirm Port Number: Verify both master and slave use port 502 (or match custom port numbers).
- Bind to 0.0.0.0: Configure PC-based Modbus servers to listen on all network interfaces.
- Add Firewall Exception: Open inbound TCP port 502 in Windows Defender and corporate edge firewalls.
- Cross-Check with ModbusSimulator: Validate client software against a local software slave before replacing hardware.
Frequently Asked Questions
What does 'Modbus Connection Refused' (ECONNREFUSED) mean?
In TCP networking, 'Connection Refused' (POSIX errno 111 ECONNREFUSED or Windows Winsock WSAECONNREFUSED 10061) occurs when a client sends a TCP SYN packet to the target IP address on port 502, but the target operating system immediately replies with a TCP RST (Reset) packet. This confirms the destination machine is reachable on the network, but no listening process or Modbus server is accepting connections on port 502.
How is 'Connection Refused' different from 'Modbus Timeout Error'?
A Connection Refused error returns almost instantly (within milliseconds) because the target host actively responds with a TCP RST packet rejecting the connection. In contrast, a Modbus Timeout error occurs when the client transmits a request and waits in silence with zero response until the timeout expires (e.g., 2000 ms), typically caused by an offline IP address, dropped packets, or an unplugged Ethernet cable.
Why do PLCs refuse Modbus TCP connections when already communicating?
Industrial PLCs (such as Siemens S7-1200, Schneider M221, Delta DVP) have strict hardware limits on simultaneous TCP sockets (often 4 to 8 concurrent clients). If SCADA systems, HMIs, programming laptops, or unclosed script connections consume all available sockets, the PLC TCP stack will reject subsequent incoming connection attempts with a TCP RST until an existing socket closes.
How can I verify if port 502 is open and listening?
On Linux or macOS, run 'nc -zv
How does ModbusSimulator help isolate connection refused issues?
ModbusSimulator allows you to run a virtual Modbus TCP server on your local machine or a designated IP. By redirecting your SCADA or master software to the simulator, you can verify whether your client configuration is correct. If your client connects successfully to ModbusSimulator but fails against the field PLC, the root cause is isolated to physical PLC configuration, firewall rules, or socket exhaustion.
Can port 502 be blocked by local administrative firewalls?
Yes. Corporate endpoint firewalls and Windows Defender frequently block inbound and outbound connections on non-standard ports. Port 502 is a privileged IANA port. Adding an explicit inbound TCP rule for port 502 in Windows Advanced Firewall or running your server under proper network binding permissions resolves local blocking.