iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
“Connection refused” means a connection attempt was rejected or found no listener at the address the client contacted. It does not, by itself, identify the cause. The main possibilities are that no service is listening there, the service is listening on a different address or port, or a firewall or other policy is actively rejecting the attempt.
What “connection refused” tells you
For a TCP stream socket, the Linux man-pages project defines ECONNREFUSED this way: “A connect() on a stream socket found no one listening on the remote address.” (Linux connect(2) manual.) That describes the connection attempt’s outcome, not a definitive diagnosis of the system or rule that caused it.
A TCP service needs to bind to a local address and port and enter a listening state before it can accept incoming connections. The client must target an address and port where that listener is reachable. A service may be running yet unavailable at the client’s chosen endpoint.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →The three main causes
1. Nothing is listening at the contacted endpoint
The client may have reached the intended server, but no process is listening at the destination address and port. The service may be stopped, may have failed to start, or may not have created its listener. Check the service’s status and startup logs, then verify whether a listening socket exists at the expected endpoint.
#1 Best Overall
2. The service is listening somewhere else
A running service can still refuse a client that targets the wrong port or address. Compare the destination the client actually uses with the service’s configured bind address and listening port. Pay particular attention to services bound only to loopback: a listener available to the server itself may not accept connections addressed to another interface.
Confirm the hostname’s resolved address, the port, and the protocol the client is using. If the client runs in a container or on another host, verify the endpoint from that client’s environment; the server’s own view may not be the same.
3. A firewall or policy actively rejects the attempt
A host firewall, network firewall, or other policy can reject a connection. But the displayed phrase alone does not prove that a firewall is responsible. Linux documents local firewall-rule failures under EACCES or EPERM in some circumstances, and the error presented to an application can depend on the rule, network path, operating system, and client library. Check relevant policy and logs after verifying the client’s destination and the server’s listener. (Linux connect(2) manual; POSIX connect().)
Free tools Windows power users keep installed
One-click scans. No signup required.
How to distinguish the causes
- Establish the client’s actual target. Record the hostname or IP address, resolved destination, port, protocol, and whether the client is local, remote, or containerized. Do not assume the endpoint in a configuration file is the endpoint the client ultimately contacts.
- Check the server process and listening socket. Confirm that the service is running and that a process is listening on the expected port. Use the tools and service-management interface for the server’s operating system; the diagnostic commands and firewall steps differ by platform.
- Compare destination and bind address. Check that the listener’s address and port match the client’s destination and that the listener is bound to an interface reachable from that client. A loopback-only bind or a different port can explain a refusal even when the service is healthy.
- Review firewall and policy evidence. Once the endpoint and listener line up, inspect applicable host and network rules and logs for an explicit rejection. The error text does not name the device or rule involved.
- Check the exact error and context. POSIX distinguishes
ECONNREFUSEDfromETIMEDOUT,ENETUNREACH, andEHOSTUNREACH. A timeout or unreachable error is a different signal, though intermediaries can affect what an application reports. (POSIXconnect().)
A less common Linux case: a full listener queue
Linux documents that a connection request arriving when a listening queue is full may result in ECONNREFUSED. If the protocol supports retransmission, the request may instead be ignored and a later retry may succeed. This is a possible backlog or load condition, not evidence that every busy service immediately refuses connections. (Linux listen(2) manual.)
If the connection uses a local UNIX-domain socket
A local UNIX-domain socket is a separate interprocess-communication case, not a TCP connection. Check that the configured pathname identifies a socket and that a process is listening there. Linux documents that connecting to a pathname with no listening socket can also produce a refused-connection error. (Linux connect(2) manual.)
Platform and prevalence limits
The detailed error behavior described here is grounded in Linux and POSIX documentation. Windows, macOS, Linux distributions, containers, proxies, firewalls, and cloud platforms can differ in diagnostics and error mapping, so use the documentation for the system you are troubleshooting. The cited manuals do not establish how often each cause occurs; the error alone is not a basis for ranking them.
Quick Recap
Rank #4
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
