Fix: "port 443 is taken by …" on macOS, Linux and Windows

Piperace tried to grab the default HTTPS port for your .local sites and something else already had it. Here's what that means and how to free up 443 on macOS, Linux, and Windows.

You don't have to fix this. Piperace falls back to :8443 automatically — https://myapp.local:8443 works exactly the same as https://myapp.local, it's just one port number longer. Read on only if you want the clean, port-less URL.

What's actually happening

When the local HTTPS proxy starts, it tries to bind port 443 so browsing to https://myapp.local just works, with no port to remember. If another process already owns 443, Piperace can't have it — so it binds :8443 instead and shows a warning naming the process that got there first, e.g. nginx (pid 496) or piperace-tray (pid 425).

That name comes from asking the OS who's listening on 443 (lsof/ss under the hood). If Piperace can't identify the owner — most often on Windows, or when the other process runs as a different user — the warning just says "another process."

One subtlety worth knowing: on macOS, an unprivileged wildcard bind to :443 can appear to succeed right next to another process's more specific 127.0.0.1:443 bind — but the kernel routes loopback connections to the more specific socket, so the other process wins silently. Piperace checks for this by actually round-tripping a connection through the port it thinks it owns, so the warning is trustworthy: if you see it, something really is intercepting 443, even if a naive check would say the bind worked.

🍎macOS

Find out who's holding the port (Piperace already tells you in the warning, but to check yourself):

# name + PID of whatever owns 443
sudo lsof -nP -iTCP:443 -sTCP:LISTEN

It's another Piperace instance (e.g. a second piperace-tray, or a stray piperace local in a terminal) — quit it from the menu-bar icon, or:
pkill -f piperace-tray
It's a dev proxy or container (nginx, Caddy, Docker publishing 443, Apache, etc.) — stop that service, e.g.:
brew services stop nginx # or docker stop <container>

Then relaunch Piperace. macOS doesn't require sudo for Piperace to bind 443 — once the port is free, it grabs it on the next start automatically.

🐧Linux

There are two different reasons Piperace ends up on :8443 on Linux, and they need different fixes.

Something else owns 443

Root-owned listeners are invisible to an unprivileged lsof/ss, so check with sudo:

sudo ss -ltnp 'sport = :443'
# or
sudo lsof -nP -iTCP:443 -sTCP:LISTEN

Stop whatever shows up — usually a system nginx/Apache, or a container runtime publishing 443:

sudo systemctl stop nginx

Piperace itself isn't allowed to bind <1024

If nothing else owns 443 and the warning still doesn't name a process, Linux is simply refusing an unprivileged process a port below 1024. Grant Piperace that one capability, once:

sudo setcap cap_net_bind_service=+ep $(command -v piperace)

Either way, restart Piperace afterwards so it re-probes 443.

🪟Windows

Find the PID listening on 443 in PowerShell:

netstat -ano | findstr :443

Then resolve the PID to a process name:

Get-Process -Id <pid>
# or
tasklist /FI "PID eq <pid>"

The usual suspects on Windows: IIS (World Wide Web Publishing Service), Docker Desktop, a VPN client, or another Piperace already running in the system tray.

IIS — stop it from an elevated PowerShell:
Stop-Service W3SVC
or turn it off entirely via Turn Windows features on or off → Internet Information Services.
Another Piperace — quit it from the system tray icon.
Anything else — as a last resort:
taskkill /PID <pid> /F

Relaunch Piperace once the port is free.

Bottom line: this is a cosmetic fix, not a functional one — your .local sites, tunnels, and Inspect all work identically on :8443. Free up 443 only if you want URLs without a port number in them.

← Back to blog