WinError 10013 and EACCES on Windows: The Port Isn't in Use, It's Reserved

"An attempt was made to access a socket in a way forbidden by its access permissions" usually means the port isn't in use at all: Windows has reserved it. Run netsh interface ipv4 show excludedportrange protocol=tcp and if your port falls inside one of the listed ranges, that's your answer. Pick a port outside them, or reserve the port for yourself so nothing else can take it.

It shows up under different names depending on what you were starting:

Error: listen EACCES: permission denied 0.0.0.0:5000
 
PermissionError: [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions
 
Error response from daemon: ports are not available: exposing port TCP 0.0.0.0:54327 -> 127.0.0.1:0: listen tcp 0.0.0.0:54327: bind: An attempt was made to access a socket in a way forbidden by its access permissions.

The first is Node, the second Python (I hit it with python -m http.server; any Python server that binds the port gets the same PermissionError), and the third is Docker Desktop, as reported in a Supabase CLI issue. Microsoft's error reference lists it as WSAEACCES, 10013: "Permission denied."

The confusing part is what happens next. You look for the process using the port, and there isn't one.

How I tested it

I reproduced this on my own Windows 11 machine, which has WSL2 and Docker Desktop installed, using Node 22.22 and Python 3.11. I tried to listen on ports inside and outside the reserved ranges, on 0.0.0.0, 127.0.0.1 and ::, and checked each one with netstat and PowerShell's Get-NetTCPConnection. Everything below ran from a normal, non-administrator terminal unless I say otherwise.

Step 1: check whether Windows has reserved the port

netsh interface ipv4 show excludedportrange protocol=tcp

You don't need an administrator terminal for this. Here's what it printed on my machine:

Protocol tcp Port Exclusion Ranges
 
Start Port    End Port
----------    --------
      5000        5000
     50000       50059     *
     58217       58316
     59786       59885
     59886       59985
     63002       63101
 
* - Administered port exclusions.

Every port in those ranges is off limits to normal programs. Port 5000, Flask's default, was reserved here on its own. I tried to listen on 5000, 58250 and 63050, all inside listed ranges, and both Node and Python failed every time, on every address:

node 0.0.0.0 58250   -> listen EACCES: permission denied 0.0.0.0:58250
node 127.0.0.1 58250 -> listen EACCES: permission denied 127.0.0.1:58250
node :: 58250        -> listen EACCES: permission denied :::58250
python 58250         -> [WinError 10013] An attempt was made to access a socket in a way forbidden by its access permissions

Ports 5001 and 50010 bound without a problem. Port 50010 is inside a listed range, but that range has an asterisk, which matters for the fix below.

Run the same command with ipv6 in place of ipv4 if your server listens on ::. On my machine both lists were identical.

Why netstat shows nothing on the port

This is what sends people around in circles. A reservation isn't a socket, so the usual tools for finding which process is using a port have nothing to show:

> netstat -ano | findstr :58250
(nothing)
 
> Get-NetTCPConnection -LocalPort 58250
No MSFT_NetTCPConnection objects found with property 'LocalPort' equal to '58250'.

The port is free in the sense that nothing is using it, and blocked in the sense that Windows won't let you have it. There's no process to stop.

One exception worth knowing: on my machine, port 5000 did show up in netstat, owned by PID 4. PID 4 is the Windows System process, not a program you can kill. Something listening as PID 4 on a web-style port is usually HTTP.sys, Windows' built-in web server driver, and you can see which program registered it with:

netsh http show servicestate view=requestq

Mine listed HTTP://LOCALHOST:5000/ registered by another process. So port 5000 was blocked twice over: reserved, and held through HTTP.sys. Moving off 5000 was the only sensible fix.

Where the reserved ranges come from

Windows hands out temporary "ephemeral" ports for outgoing connections from its dynamic range, which Microsoft documents as 49152 to 65535 by default. Windows networking components can also exclude blocks of ports for their own use. The ones developers run into are the Hyper-V and WinNAT networking behind WSL2 and Docker Desktop. The top Docker for Windows issue on this, filed in January 2019, is titled "Docker-for-Windows & Hyper-V excluding but not using important port", and a WSL issue shows reserved blocks running from port 2164 to 10895, right across common development ports.

The ranges aren't fixed. People in those threads describe ports that worked one day and failed the next after a reboot or an update, with no change on their side.

I can't tell you which component reserved each range on my machine, and netsh doesn't say. What matters is whether your port is on the list.

Fix 1: use a port outside the ranges (no admin needed)

This is the fastest fix and the one I'd try first. Pick a port that isn't inside any listed range and start your server there:

flask run --port 5001
python -m uvicorn main:app --port 8001
npx vite --port 5174
docker run -p 5001:80 your-image

For Docker, only the host side of -p host:container has to change. The app inside the container can keep its port.

Most frameworks fall back to 3000, 5000, 5173, 8000 and 8080, so if one of those is inside a reserved range, set the port in your config file rather than on the command line, so the next person on the team doesn't hit it too.

Fix 2: reserve the port for yourself (admin)

If you need that exact port, because a teammate's setup, an OAuth redirect URL or a mobile app expects it, claim it before Windows does. In an administrator terminal:

net stop winnat
netsh int ipv4 add excludedportrange protocol=tcp startport=5000 numberofports=1
net start winnat

Replace 5000 with your port. Stopping WinNAT first releases the reservations it made (the same effect Fix 3 relies on), so your port is free to claim. Stopping it briefly interrupts WSL2 and Docker networking, so close those first.

It looks backwards to reserve the port you want to use, but Microsoft's documentation on reserved ranges explains why it works: a reserved range keeps the port from being handed out at random, and "only a program or process that specifically requests a port that is in the reserved range can use the port." Your dev server asks for the port by number, so it's allowed in. Hyper-V can't take it any more.

I saw this on my own machine. Ranges you add yourself show an asterisk, as "administered port exclusions." My 50000–50059 range was one of those, and port 50010 inside it bound normally from Node and Python. The ranges without an asterisk refused every bind.

I didn't run these three commands while testing for this post, because they restart the networking WSL and Docker rely on. Everything else in this post I ran myself.

Fix 3: restart WinNAT (admin, temporary)

The most-repeated quick fix in the Docker, WSL and Supabase issue threads is:

net stop winnat
net start winnat

A commenter in the WSL thread reports it shrinks the exclusion list only temporarily, because WinNAT reserves ports again. Treat it as a way to get unblocked today, then use Fix 1 or 2 so it doesn't come back.

Fix 4: check the dynamic port range wasn't moved

netsh int ipv4 show dynamicport tcp

The default is a start port of 49152 and 16384 ports, which keeps temporary ports well clear of 3000, 5000 and 8080. If yours starts much lower, that's worth fixing: the reserved blocks in the WSL report, from 2164 to 10895, sat far below the default start. A widely shared answer in the Docker issue puts the range back to the default from an administrator terminal:

netsh int ipv4 set dynamic tcp start=49152 num=16384
netsh int ipv6 set dynamic tcp start=49152 num=16384

Mine was already at the default, which is why most of my reserved blocks sat above 49152. Port 5000 was the odd one out.

If the error is EADDRINUSE instead, the port really is taken

EADDRINUSE is a different problem, and this time there is a process to find. Here's what I got with one test server already listening on port 5002:

node   -> listen EADDRINUSE: address already in use 0.0.0.0:5002
python -> [WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted

Find who owns it, then stop it if it's yours:

netstat -ano | findstr :5002

Get-NetTCPConnection -LocalPort 5002 -State Listen | Select-Object LocalAddress, OwningProcess
Get-Process -Id <PID>
Stop-Process -Id <PID>

Check what the process is before you stop it. A PID can belong to a database, a sync client or another project, not the dev server you forgot about. I got tired of the netstat → tasklist → guesswork routine and built ZeroPort, a small Windows app that lists every listening port with the program behind it and checks the process is still the same one before stopping it. It won't show a reserved range, though. Nothing is listening there, which is the whole point of this post.

The quiet one: no error, but the wrong app answers

This one isn't an error at all, and it surprised me. With a test server holding 0.0.0.0:5002, a second server on the same port started without complaint when it used a different address:

Microsoft's socket binding rules match: with default options and the same user account, a bind to a specific address succeeds even while another socket holds the wildcard address on that port.

In practice, an old dev server you forgot about keeps running, the new one starts fine on a slightly different address, and localhost in the browser goes to whichever one Windows picks. If your changes aren't showing up and the terminal says the server started, run netstat -ano | findstr :PORT. Two PIDs on one port is the answer.

Quick reference

Windows has its own ways of breaking developer tools that work fine elsewhere: Claude Code refusing to start in Git Bash, and npm, pip, git and curl each trusting certificates differently behind a corporate proxy. Getting development environments working cleanly on locked-down Windows machines is a lot of the work I do — see recent projects.