Chromium Network Errors
Connection Refused
ERR_CONNECTION_REFUSEDReviewed for reference consistency: August 11, 2026
The target server actively rejected the connection attempt.
What ERR_CONNECTION_REFUSED Means
The ERR_CONNECTION_REFUSED error on the Chromium Network Errors indicates connection refused — the target server actively rejected the connection attempt.. This typically occurs due to localhost port binding mismatch (e.g., a docker container listening on 127.0.0.1 instead of 0.0.0.0, blocking external access)..
This error is most commonly encountered by developers connecting to localhost environments (127.0.0.1) during development. In production, it serves as a critical alert indicating that the web server daemon is stopped, severely misconfigured, or bound to the wrong network interface. It is classified as a Layer 4 (Transport Layer) failure. When the browser dispatches a TCP SYN packet to initiate a connection, the target server or firewall instantly responds with a TCP RST (Reset) packet. This signifies an active, deliberate rejection, meaning the machine is online but refusing to talk on that port.
How to fix ERR_CONNECTION_REFUSED
General informational guidance, not professional advice. Commands can affect your system or data — back up first and proceed at your own risk. FixerCode is an independent reference, not affiliated with any vendor mentioned.
Verify listening port
Use network socket tools to verify that your backend application is actively listening on the expected port and bound to the correct IP address.
ss -tlnpCheck interface binding
Inspect your web server configuration files (like Nginx or Apache) to ensure the server binds to 0.0.0.0 if you need to access it from a different machine.
grep -i 'listen' /etc/nginx/nginx.confAnalyze service logs
If the service is supposed to be running, check the systemd journal logs to see if it crashed immediately upon startup.
journalctl -u nginx.service -n 50 --no-pager
Technical Background
At the transport layer (Layer 4 of the OSI model), all standard web traffic relies on the Transmission Control Protocol (TCP). A TCP connection must be established before any HTTP data can be exchanged, beginning with a strict three-way handshake: the client sends a SYN (Synchronize) packet, the server replies with a SYN-ACK (Synchronize-Acknowledge), and the client finishes with an ACK.
When a Chromium-based browser encounters an ERR_CONNECTION_REFUSED, it indicates a failure at the very first step of this handshake. The browser successfully dispatched the initial SYN packet to the target IP address and port, but instead of receiving the expected SYN-ACK confirming readiness, it received an RST (Reset) packet.
A TCP RST packet is a deliberate, active response from the remote operating system. It explicitly informs the client that there is no service currently listening on the requested port, or that a firewall rule has been specifically configured to reject the connection rather than silently dropping the packet.
Because this rejection happens at the TCP layer, the browser never gets the chance to send the actual HTTP request headers. Therefore, this is purely a network-level issue and cannot be fixed by altering HTTP headers, clearing browser cookies, or changing application-level logic.
Common Causes
- Localhost port binding mismatch (e.g., a Docker container listening on 127.0.0.1 instead of 0.0.0.0, blocking external access).
- The primary web server service (such as Nginx, Apache, or a Node.js process) has crashed, stopped, or is in a failed restart loop.
- A strict firewall rule (using iptables or a hardware appliance) is explicitly configured to REJECT incoming TCP traffic on ports 80 or 443.
- The backend application is attempting to bind to a privileged port (under 1024) without sufficient root or administrator permissions.
Typical Scenarios
- Local machine port mapping issues when running applications inside isolated Docker containers.
- A backend API process (like Express or Django) crashed silently due to an unhandled exception or memory leak.
- A network administrator deployed a firewall rule that drops packets using the REJECT target instead of the DROP target.
- An application configuration error where the server is instructed to listen on a port that is already in use by another process.
What to Know
If you are a software developer seeing this on a local environment, immediately check if your development server is actually running, hasn't crashed, and is bound to the correct port (0.0.0.0 instead of 127.0.0.1 if using Docker). For system administrators dealing with production servers, this usually indicates the primary web server daemon is down or a recent firewall deployment is actively rejecting HTTP/HTTPS traffic.
Frequently Asked Questions
Common questions about Chromium ERR_CONNECTION_REFUSED error
ERR_CONNECTION_REFUSED means the target server or firewall actively rejected the request by instantly sending a TCP Reset (RST) packet. The connection was declined immediately. ERR_CONNECTION_TIMED_OUT, on the other hand, means the server never responded at all, forcing the browser to eventually give up waiting.
Yes, absolutely. If your local firewall (like Windows Defender Firewall) or a third-party antivirus suite is strictly configured, it might actively intercept and reject outgoing connections to certain untrusted ports or development domains, resulting directly in this error.
Docker containers have their own isolated network namespaces. If your application inside the container binds to 127.0.0.1 (localhost), it is only accessible from inside that specific container. To fix this, you must configure your application to bind to 0.0.0.0 so it can accept traffic routed from your host machine.
No. If your internet connection was entirely down, you would typically see an error like ERR_INTERNET_DISCONNECTED or a DNS resolution failure. Connection Refused specifically means you reached the destination network successfully, but the specific port you asked for was actively closed.
Related Error Codes
Related Errors From Other Categories
Similar error codes documented across different platforms and systems
Process Killed — the process was terminated by a SIGKILL signal
Signal 11 (SIGSEGV) memory fault or Errno 11 (EAGAIN / EWOULDBLOCK) resource unavailable
Exit code 139 — a segmentation fault (SIGSEGV, signal 11) killed the process
Input/output error EIO — a read or write operation could not complete