Bug: HTTP Toolkit fails to start – Port 45456 reported as in use, but it isn’t

[friedensfurz]

Environment

• OS: Windows 11 Enterprise multi-session
• Version: 24H2 (Build 26100.7840)
• HTTP Toolkit version: 1.24.4 (installed via winget)

---

Issue Description

After a fresh installation of HTTP Toolkit, the application fails to start and shows the following error:

Server crashed with 'Error: listen EADDRINUSE: address already in use 127.0.0.1:45456'

However, the port does not appear to actually be in use.

---

What I Tried

1. Fresh install via:

   winget install httptoolkit
   

2. Checked whether the port is in use:

   netstat -ano | findstr :45456
   

   → No results returned.

3. Rebooted the system.

4. Reinstalled HTTP Toolkit.

5. Ran as Administrator.

The error persists after all of the above.

---

Expected Behavior

If the port is truly in use, it should appear in netstat.
If it is not in use, HTTP Toolkit should start normally.

---

Observations

• No process is bound to 127.0.0.1:45456.
• The error happens immediately on launch.
• This occurs even on a clean install.

---

My thoughts

• Could this be related to Windows 11 24H2 networking changes?
• Is HTTP Toolkit reserving the port via some internal mechanism?
• Could this be related to excluded port ranges (netsh interface ipv4 show excludedportrange protocol=tcp)?

I’m happy to provide additional logs if needed.

last-run.log

[pimterry]

What does it show if you run:

netsh interface ipv4 show excludedportrange protocol=tcp

My best guess would be that this is caused by WSL or similar: https://httptoolkit.com/docs/guides/troubleshooting/#http-toolkit-conflicts-with-hyper-v

[friedensfurz]

It doesnt seem to be a WSL issue though...

PS C:\Users\USER> netsh interface ipv4 show excludedportrange protocol=tcp

Portausschlussbereiche für das Protokoll "tcp"

Startport      Endport
----------    --------
      5357        5357
     50000       50059     *

* - Verwaltete Portausschlüsse.```

[pimterry]

Hmm, yes that port exclusion doesn't relate to this at all, so the WSL issue looks unlikely.

What happens if you try to listen on this port manually some other way? For example if you have Node installed you can run npx http-server -p 45456 or with Python python -m http.server 45456.

Do those work? If so then HTTP Toolkit is doing something wrong and we can dig into that in more depth. If not, then something really is using that port on your machine, and you'll need to hunt that down somehow. Sharing the full output from netstat might have some clues.