Fix Port 443 Already in Use on Windows Server

Fix "port 443 already in use" on Windows Server

Symptoms, any of which mean the same thing:

• Error: loading initial config: ... listening on :443: bind: Only one usage of each socket address is normally permitted
• EADDRINUSE: address already in use :::443
• Caddy or nginx starts, then exits about a second later
• The web server service reads as Running for a moment and then stops
• Everything worked yesterday, and the only change was a reboot or an update

Something else already owns the port. On Windows there are four usual suspects, and IIS is the first one.

---

Find out what is holding it

Get-NetTCPConnection -LocalPort 443 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess,
    @{ n = "Process"; e = { (Get-Process -Id $_.OwningProcess).ProcessName } }

Or, without PowerShell:

netstat -ano | findstr :443
tasklist /fi "pid eq <the pid>"

System (PID 4) as the owner does not mean Windows itself — it means the kernel HTTP driver, http.sys, is holding it on behalf of IIS or another service. Ask it who:

netsh http show servicestate | more
netsh http show urlacl

---

The four culprits

1. IIS — by far the most common

Windows Server enables IIS with a Default Web Site bound to port 80, and often 443, the moment the Web Server role is installed. Nothing warns you.

Stop it, and stop it coming back:

Stop-Service W3SVC
Set-Service W3SVC -StartupType Disabled

Keep the role installed if you are still using IIS for something on other ports — it only has to release 80 and 443. To free just the bindings instead, remove them from the Default Web Site in IIS Manager, or delete the site.

WinPanel's Health page detects this, offers to stop and disable IIS for you, and records the previous start mode first so a machine that genuinely used IIS can be put back.

2. A mail server that also serves HTTPS

Several mail servers bind 443 for their own web interface or for ACME. Stalwart does, by default, alongside its admin listener. If your web server dies about a second after every start and you host mail on the same box, this is almost certainly it. Whoever starts first after a reboot wins, which is why it looks intermittent.

WinPanel strips 80 and 443 out of the mail server's listeners on every boot for exactly this reason.

3. An orphaned copy of your own web server

The service was killed without a clean stop and the old process is still there, still listening. The service reads as stopped, so it looks like nothing should be holding the port. Find the PID with the command above and end it.

4. Hyper-V and WinNAT reserving port ranges

Less common, but real, and it produces the same error for ports you never chose:

netsh int ipv4 show excludedportrange protocol=tcp

If 443 falls inside a reserved range, restart the winnat service (net stop winnat then net start winnat) or exclude the port explicitly.

---

Prove it is fixed

Get-NetTCPConnection -LocalPort 443 -State Listen   # nothing
Start-Service caddy
Get-NetTCPConnection -LocalPort 443 -State Listen   # caddy, and only caddy

Then check the whole set at once — 80, 443 and your app ports:

Get-NetTCPConnection -State Listen |
  Where-Object LocalPort -in 80,443,3001 |
  Select-Object LocalPort, @{ n="Process"; e={ (Get-Process -Id $_.OwningProcess).ProcessName } }

---

Related

• Run a Node.js app as a Windows Service — the orphaned-process failure in detail
• Node.js hosting on Windows Server
• Frequently asked questions