ERR_CONNECTION_REFUSED: What It Means and How to Fix It

ERR_CONNECTION_REFUSED is Chrome's name for one precise network event: your machine asked a server to open a TCP connection, and the other end answered with an explicit no. In TCP terms, defined in RFC 9293, the connection attempt was answered with a reset instead of an acceptance. That distinguishes it from its sibling errors: a refusal is an answer, while a timeout is silence, and the difference is diagnostic gold. In the recorded lab behind this article, connecting to a loopback port with nothing listening failed in 3 milliseconds with the explicit code ECONNREFUSED; a timeout, by contrast, burns its full deadline hearing nothing.

Only a few things produce that explicit no. Nothing is listening on the port you asked for, because the service is down, crashed, or bound to a different address. A firewall along the path is configured to actively reject the connection rather than silently drop it. Or the address your machine resolved is simply the wrong place, pointing at a host that has no such service, which is common right after DNS changes.

The refusal itself carries no HTML, no status code, and no explanation; the server-side software never saw the request at all. That is why the browser can only tell you the connection was refused, per Chrome's connection-error help, and why fixing it means finding out which machine said no and why, rather than staring at the error page.

Thirty seconds of triage halves the search space. Open two or three unrelated sites. If everything is refused, the cause is on your side: a proxy setting pointing at a dead intermediary, a security suite whose filtering component crashed, a broken DNS answer for everything, or, on a managed network, policy. If exactly one site is refused, the cause is that site's side or specific to the path between you: their server is down, their DNS points at the wrong address, or something between you and them rejects that destination.

Two refinements sharpen the split. Try the failing site from another network, most easily a phone on mobile data: refused there too means the site itself is down for everyone, and third-party down-detector pages will usually agree. And try another browser: Chromium browsers share the operating system's proxy configuration, so a leftover proxy entry refuses connections identically in Chrome and Edge, while Firefox, with its own independent settings, sails through. That exact pattern, everything refused in one browser family and fine elsewhere, points at connection settings rather than at any website.

One special address deserves its own section below: when the refused site is localhost or 127.0.0.1, you are not debugging the internet at all, you are debugging your own machine, and the checklist is different.

Work down this list in order; each step is cheap and each result narrows the cause. First, confirm it is not simply the site being down: test from a second network or a status checker, because no client-side setting fixes a server that is off. Second, check the operating system's proxy settings. A dead or leftover proxy is the classic everything-refused cause, since every request goes to an intermediary that no longer exists; the fix is removing the manual proxy and setup script, exactly as covered in the proxy and firewall guide. Third, flush stale DNS. If a site recently moved servers, your machine can keep connecting to the old address whose machine rightly refuses: ipconfig /flushdns on Windows or a router restart clears it, and switching the resolver is the durable version of the fix.

Fourth, disable browser extensions, especially anything that filters, redirects, or secures traffic, and retry in a clean profile. Fifth, look at your security suite: web-protection modules interpose themselves as local intermediaries, and a half-crashed one refuses everything the browser sends it. Temporarily disabling the module, or reinstalling the suite, isolates that in minutes.

What does not belong on the list: hammering reload, which changes nothing about a refusal, and clearing cookies, which lives one layer above the socket that got refused. The error happens before HTTP exists, so HTTP-level cleanup cannot touch it.

ERR_CONNECTION_REFUSED on 127.0.0.1 or localhost is the most self-contained version of the error, and the lab reduces it to one sentence: the moment a listener existed on the previously refused port, the identical connect succeeded. Everything on this checklist is a variation of "nothing is listening where you are knocking".

The dev server is not running, exited on a compile error, or is still starting. The port is wrong: the app moved to 3001 because 3000 was busy, and the browser tab still says 3000. The bind address does not match the hostname: a server bound to a container-internal address or a specific interface will refuse connections to 127.0.0.1, and there is a subtler split between localhost resolving to the IPv6 loopback while the server listens only on the IPv4 one, or the reverse. Inside containers, the port simply is not published to the host. And an HTTPS URL pointed at a plain-HTTP dev port, or vice versa, produces refusals and protocol errors that look identical from the browser.

The two commands that settle it: ask the OS who is listening, with netstat -ano | findstr :3000 on Windows or lsof -i :3000 elsewhere, and probe the socket directly with curl:

curl -v http://127.0.0.1:3000/
*   Trying 127.0.0.1:3000...
* connect to 127.0.0.1 port 3000 failed: Connection refused

If netstat shows nothing on the port, start or fix the server. If it shows a listener on a different address or port, correct whichever side is wrong. That is the entire debugging loop.

When traffic is configured to flow through a proxy, a refusal has two possible authors, and fixing the wrong one wastes an afternoon. Either the proxy itself refused your connection, or the proxy connected fine and the destination refused the proxy. The error page looks the same; the wire does not.

Test the hops separately. First, verify the proxy endpoint is alive and answering with the proxy checker, which separates "my intermediary is down" from everything else in one step. If the proxy is healthy, run the same request through it verbosely with curl's proxy flag and read where the failure lands: a refusal during the initial connection to the proxy address means the proxy hop, while an error after the tunnel is established means the destination side. Port and scheme mistakes cluster on the first hop, because sending HTTP proxy syntax to a SOCKS port gets rejected at the door; the proxy-port guide maps which ports speak which protocol.

Two proxy-specific causes round it out. Credentials: some gateways close unauthenticated connections outright rather than answering 407, which presents as a refusal. And provider-side changes: a retired gateway hostname or a rotated port refuses everything until the client configuration catches up with the provider's current documentation, so confirm the endpoint against the dashboard rather than memory before debugging deeper.

From the operator's chair, ERR_CONNECTION_REFUSED reports are good news wearing a scary name: refusals are explicit, immediate, and usually one configuration line away from the fix. The causes rank cleanly.

The service is not running: it crashed, failed to start after a deploy, or a health-checkless restart left nothing bound. The bind address is wrong: a server listening on the loopback interface serves itself perfectly and refuses the internet, the classic works-on-the-box failure; listening on all interfaces, or the correct public one, fixes it. The port disagrees with the client: TLS traffic aimed at the plain port, or a load balancer forwarding to a backend port nobody listens on. And the firewall layer: a rule that rejects a port answers exactly this error, and here the distinction between reject and drop matters operationally, because a reject rule produces instant, explicit refusals while a drop rule produces timeouts. Your users' error message tells you which rule they are hitting.

The diagnostic sequence mirrors the developer one, run from the server itself: check the process is alive, check what address and port it actually bound, then probe locally and from outside. A local success paired with an outside refusal isolates the firewall or the load balancer in one contrast. Refusals in this situation are also invisible to the application logs, because the kernel answered before the application existed in the conversation; absence of log lines is itself the clue.

Chrome's connection errors form a family, and telling the members apart is most of the diagnosis. The recorded lab makes the contrast concrete: the refused connect failed explicitly in 3 milliseconds, while silence burns the whole deadline before the client gives up.

The refusal is the friendliest of the three, because it is fast and definite: you know the address was reachable and you know the port was closed to you. Use that. If a request that used to be refused starts timing out instead, a firewall changed from rejecting to dropping; if a refusal appears where pages loaded yesterday, a service died or a port moved. For the wider picture of how requests travel and where intermediaries sit in the chain, the proxy fundamentals guide walks the full path hop by hop.