127.0.0.162893

That message shows up in editors far more than anywhere else. A debugger tried to attach to a process on your own machine, found nothing listening, and gave up. The port varies between sessions, but 62893 appears often enough that people search for it specifically.

Why a debugger needs a port at all

Node exposes an inspector protocol over WebSocket. Start a script with --inspect and the runtime opens a socket on loopback, then waits for a client. Your editor is that client. It connects, sets breakpoints, reads variables, and steps through code across that connection. No socket, no debugging.

By default the inspector claims 9229. Editors that spawn their own sessions frequently ask the operating system for a free port instead, which is how you end up staring at a five-digit number nobody chose. Anything above 49151 is drawn from the dynamic pool, the same pool that produces unexplained listeners on 57573 and other high numbers you never configured.

Launch or attach, and why it matters

Most refused-connection errors on this port come from attaching too early. The editor fires its request, the runtime has not finished binding, and TCP answers with a flat refusal. Adding a short delay, or switching to launch mode, removes the race entirely.

The usual suspects

• The application crashed during startup, so nothing ever bound the port
• Auto attach is enabled and grabbed a different port than the one in your config
• A previous debug session is still holding the socket from a process you thought had exited
• The code runs inside a container while the editor runs on the host, and loopback means two different things in those two places
• Security software silently blocked the local connection

Checking the inspector by hand

Node’s inspector exposes a small JSON endpoint. Visit http://127.0.0.1:62893/json/list in a browser while the process runs and you should get a description of the debuggable target, including a WebSocket URL. An empty response or a refusal means the inspector is not up, and no amount of editor configuration will change that.

When the port changes every run

Pin it. Set an explicit --inspect=62893 flag and put the same number in your config. Fixed ports make debugging repeatable, which is exactly why some tools always claim the same one — an interface server that reliably answers on port 7860 is easy to bookmark, while a random ephemeral socket like 49342 never is.

Loopback is doing you a favour here

Binding the inspector to 127.0.0.1 means nothing outside your machine can attach to your running process. That is a real protection, because a debugger connection allows arbitrary code execution inside the target. If you ever need to debug across machines, do it through an SSH tunnel rather than exposing the inspector to the network. The reasoning behind that isolation is covered in the walkthrough of the loopback interface.

Exposing it deliberately means binding to 0.0.0.0 and letting your LAN reach the port, which drags router configuration into the mix. Devices then need to be on the same segment, defined by the subnet mask in use, and reachable through whatever gateway your network runs, often the familiar 192.168.1.1 panel. Giving the debug host a fixed address helps too, and pinning a machine to 192.168.1.2 is the simplest way to do it.

FAQ