Docker “bind: address already in use”: find the process and fix cleanly

October 5, 2025 • February 3, 2026 • Read: 21 min • Views: 17

Was this helpful?

You run docker run -p 8080:80 ... or bring up a compose stack, and Docker responds with the operational equivalent of
“nope”: bind: address already in use. Suddenly you’re doing incident response on a Tuesday because a port is busy and nobody
remembers why.

This is one of those errors that looks simple until it isn’t. Sometimes it’s Nginx. Sometimes it’s a zombie container, a systemd socket,
a rootless Docker limitation, or the ghost of a process that died but left a listener behind. Let’s find the real owner, pick the least-bad fix,
and leave the host cleaner than we found it.

What the error actually means (and what it doesn’t)

When Docker “publishes” a port (for example -p 8080:80), it asks the host kernel for a listening socket on the host port
(8080 here). The kernel returns either “sure” or “no”. The “no” you’re seeing is typically EADDRINUSE: another socket already owns that
exact 4‑tuple (protocol, local address, local port).

The trick is that “already in use” is broader than “some other app is running”. It can be:

A different process listening on that port (nginx, apache, node, sshd, etc.).
A different container already published to that host port.
A system service that binds early via systemd socket activation.
Docker’s own helper (historically docker-proxy) holding the port, even if you think the container is gone.
A binding to a specific IP, blocking a later attempt to bind to 0.0.0.0 (or vice versa).
Rootless Docker limitations: binding to low ports requires extra steps.

What it is not: a firewall problem. Firewalls block traffic; they don’t prevent listening sockets from being created. If you see “address already in use”,
you’re almost always looking for a listener, a leftover proxy, or a configuration collision.

A good mental model: port publishing is a claim. Docker wants to claim the port on the host. The kernel says someone else already has the deed.
You need to find who holds it and decide whether to evict them, negotiate a new address, or move your service.

Fast diagnosis playbook

You’re under time pressure. Fine. Do the minimal checks in the right order. Don’t start “restarting Docker” like it’s an exorcism.

First: confirm the exact port, protocol, and bind address

Look at the Docker error line. Is it 0.0.0.0:80, 127.0.0.1:8080, or a specific interface IP?
TCP vs UDP matters. Two different protocols can use the same port number.

Second: identify the owning listener (the real one)

ss -ltnp for TCP, ss -lunp for UDP. This usually ends the mystery.
If you see docker-proxy, chase the container that spawned it.
If you see systemd or a “.socket” unit, you’re in socket activation land.

Third: decide the clean fix

If it’s an old container: stop/remove the container, then re-run with your intended port map.
If it’s a host service: either move the host service, move Docker’s published port, or put a proper reverse proxy in front.
If it’s systemd socket activation: stop/disable the socket unit, not just the service unit.
If it’s rootless low ports: use setcap, authbind-ish approaches, or publish higher ports and front them with a proxy.

Fourth: verify from the outside

curl locally, then from another host if possible.
Confirm you didn’t “fix” the bind while breaking routing (NAT, iptables/nftables) or IPv6 exposure.

One short joke, because you deserve it: Ports are like meeting rooms—everyone needs one urgently, nobody booked it, and somehow Finance is already inside.

Facts and historical context (so you stop arguing with the kernel)

This stuff feels arbitrary until you know a bit of history and kernel behavior. Here are concrete facts that matter when you’re debugging:

Ports are owned per protocol. TCP 443 and UDP 443 are separate claims. A busy TCP port doesn’t block UDP on the same number.
The bind target address matters. A process can bind to 127.0.0.1:8080 without blocking another process binding to 192.168.1.10:8080—but a bind to 0.0.0.0:8080 blocks all IPv4 addresses.
Linux uses SO_REUSEADDR and SO_REUSEPORT differently. They don’t mean “ignore conflicts”; they control address reuse and load distribution semantics.
TIME_WAIT is not a listening socket. It’s a connection state; it usually doesn’t prevent a new listener on that port.
Docker historically used a userland proxy (docker-proxy) for published ports. Depending on Docker version and settings, you may still see it, and it can hold ports even when networking gets weird.
iptables vs nftables transition changed failure modes. Modern distros run nftables underneath; mixing tools can make port reachability confusing, though it won’t cause EADDRINUSE by itself.
systemd socket activation can bind before your service starts. The listener belongs to the socket unit, not the daemon you think you stopped.
Rootless Docker cannot bind privileged ports by default. The kernel enforces low-port privileges; workarounds exist but should be deliberate.
IPv6 adds parallel bind behavior. A service might bind [::]:80 and also cover IPv4 via v6-mapped addresses depending on net.ipv6.bindv6only.

A reliability paraphrased idea (because I won’t pretend I’m quoting perfectly): paraphrased idea: hope is not a strategy — attributed to Edsger W. Dijkstra in operations circles.
The point stands: prove what owns the port before you change anything.

Hands-on tasks: commands, outputs, and decisions

These are practical tasks you can run on a Linux host. Each one includes: the command, a plausible output snippet, what it means, and the decision you make.
Do them in order when you’re uncertain; cherry-pick when you’re confident.

Task 1: Reproduce the exact bind target Docker is trying to claim

cr0x@server:~$ docker run --rm -p 8080:80 nginx:alpine
docker: Error response from daemon: driver failed programming external connectivity on endpoint inspiring_morse (8f4c9b5b1b6a): Bind for 0.0.0.0:8080 failed: port is already allocated.

Meaning: Docker tried to bind TCP port 8080 on all IPv4 interfaces (0.0.0.0) and failed because the port is already owned.

Decision: Stop guessing and find the current owner of TCP/8080.

Task 2: Identify the listening process with `ss` (fast, modern)

cr0x@server:~$ sudo ss -ltnp 'sport = :8080'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8080      0.0.0.0:*    users:(("node",pid=2147,fd=23))

Meaning: PID 2147 (node) owns the listener on TCP/8080 across all IPv4 interfaces.

Decision: Decide whether that Node service should move, be stopped, or be fronted by a reverse proxy while Docker uses another port.

Task 3: Show the full listener table to catch “wrong port” assumptions

cr0x@server:~$ sudo ss -ltnp
State  Recv-Q Send-Q Local Address:Port   Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:22          0.0.0.0:*     users:(("sshd",pid=892,fd=3))
LISTEN 0      4096   127.0.0.1:5432      0.0.0.0:*     users:(("postgres",pid=1011,fd=6))
LISTEN 0      4096   0.0.0.0:8080        0.0.0.0:*     users:(("node",pid=2147,fd=23))
LISTEN 0      4096   [::]:80             [::]:*        users:(("nginx",pid=1320,fd=7))

Meaning: You have a mix of loopback-only and public listeners; also notice IPv6 [::]:80.

Decision: If Docker is trying to publish 80, check IPv6 listeners too. If it’s 8080, the Node service is the conflict.

Task 4: Use `lsof` when you need filesystem and command-line context

cr0x@server:~$ sudo lsof -nP -iTCP:8080 -sTCP:LISTEN
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    2147 app   23u  IPv4  56123      0t0  TCP *:8080 (LISTEN)

Meaning: Confirms the listener and user account, useful for figuring out how it starts (systemd unit? cron? PM2?).

Decision: If it’s a “mystery service,” you now have a PID and user to trace.

Task 5: Trace the PID to a systemd unit (the “who started this?” question)

cr0x@server:~$ ps -p 2147 -o pid,ppid,user,cmd
  PID  PPID USER     CMD
 2147     1 app      node /opt/api/server.js

cr0x@server:~$ systemctl status 2147
● api.service - Internal API
     Loaded: loaded (/etc/systemd/system/api.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2026-01-01 09:13:22 UTC; 1d 2h ago
   Main PID: 2147 (node)

Meaning: The listener is a managed service, not a random terminal.

Decision: Coordinate the change: either update api.service to move ports, or publish Docker on another port.

Task 6: Check if Docker itself already published that port (container conflict)

cr0x@server:~$ docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Ports}}'
NAMES            IMAGE            PORTS
web              nginx:alpine     0.0.0.0:8080->80/tcp, [::]:8080->80/tcp
postgres         postgres:16      127.0.0.1:5432->5432/tcp

Meaning: Another container already owns host port 8080 and maps it to container port 80.

Decision: Don’t start a second service on the same host port. Pick a new host port, or stop/replace the existing container.

Task 7: Find which compose project owns the port (when containers have polite names)

cr0x@server:~$ docker inspect -f '{{.Name}} {{range $p, $conf := .NetworkSettings.Ports}}{{$p}}={{(index $conf 0).HostIp}}:{{(index $conf 0).HostPort}} {{end}}' web
/web 80/tcp=0.0.0.0:8080

Meaning: Confirms exactly which container and mapping claimed the host port.

Decision: If you intended a replacement deployment, do a controlled swap (blue/green or stop-then-start) instead of fighting the kernel.

Task 8: If `docker-proxy` is listening, map it back to a container

cr0x@server:~$ sudo ss -ltnp 'sport = :8080'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8080      0.0.0.0:*    users:(("docker-proxy",pid=3012,fd=4))

cr0x@server:~$ ps -p 3012 -o pid,cmd
  PID CMD
 3012 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8080 -container-ip 172.17.0.3 -container-port 80

Meaning: Docker’s proxy is holding the host port and forwarding to a container IP. The container may or may not still exist.

Decision: Check Docker state next; if the container is gone but the proxy remains, treat it as a Docker/networking bug and clean up safely.

Task 9: Correlate container IPs to a container (when you only have `172.17.0.3`)

cr0x@server:~$ docker network inspect bridge -f '{{range .Containers}}{{.Name}} {{.IPv4Address}}{{"\n"}}{{end}}'
web 172.17.0.3/16
postgres 172.17.0.4/16

Meaning: The proxy is forwarding to web.

Decision: If you’re trying to start another “web,” you need an intentional rollout plan or a different host port.

Task 10: If it’s systemd socket activation, stop the socket unit (not just the service)

cr0x@server:~$ sudo ss -ltnp 'sport = :80'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:80        0.0.0.0:*    users:(("systemd",pid=1,fd=49))

cr0x@server:~$ systemctl list-sockets | grep -E '(:80|http)'
web.socket   0      4096   0.0.0.0:80   0.0.0.0:*    LISTENING

cr0x@server:~$ sudo systemctl stop web.socket
cr0x@server:~$ sudo systemctl disable web.socket
Removed "/etc/systemd/system/sockets.target.wants/web.socket".

Meaning: PID 1 (systemd) owns port 80 through a socket unit. Stopping the service won’t free the port; stopping the socket will.

Decision: Disable the socket if Docker needs the port. If the socket is needed for a host daemon, don’t fight it—publish Docker elsewhere.

Task 11: Confirm IPv6 is part of the conflict

cr0x@server:~$ sudo ss -ltnp | grep ':80 '
LISTEN 0      4096   [::]:80      [::]:*    users:(("nginx",pid=1320,fd=7))

Meaning: Something is listening on IPv6 port 80. Depending on sysctls and the application, that may also cover IPv4.

Decision: If Docker tries to bind 0.0.0.0:80 and fails, stop/relocate the IPv6 listener or explicitly bind services to distinct addresses.

Task 12: Use `curl` to confirm what’s currently serving the port

cr0x@server:~$ curl -sS -D- http://127.0.0.1:8080/ -o /dev/null
HTTP/1.1 200 OK
Server: Express
Content-Type: text/html; charset=utf-8
Connection: keep-alive

Meaning: Port 8080 is not “mysteriously allocated”; it’s actively serving an Express app.

Decision: You’re not freeing this port without impacting someone. Plan a controlled move or a reverse proxy.

Task 13: When you suspect a stale container, list stopped containers and remove the right one

cr0x@server:~$ docker ps -a --filter "status=exited" --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'
NAMES          STATUS                    PORTS
web_old        Exited (137) 2 hours ago  0.0.0.0:8080->80/tcp

cr0x@server:~$ docker rm web_old
web_old

Meaning: Even exited containers can leave behind confusing state in humans. The port mapping should be gone once the container is removed,
but verify with ss.

Decision: If the port is still held after removal, you’re looking at a proxy or daemon issue—keep digging, don’t randomly reboot.

Task 14: Verify Docker isn’t stuck with an orphaned proxy (rare, but real)

cr0x@server:~$ docker ps --filter "publish=8080"
CONTAINER ID   IMAGE     COMMAND   CREATED   STATUS    PORTS     NAMES

cr0x@server:~$ sudo ss -ltnp 'sport = :8080'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   0.0.0.0:8080      0.0.0.0:*    users:(("docker-proxy",pid=3012,fd=4))

Meaning: No running container claims 8080, but docker-proxy still does. That’s inconsistent state.

Decision: Prefer a targeted fix: restart Docker to reconcile port forwards, but do it intentionally (drain traffic, warn stakeholders, know the blast radius).

Task 15: Restart Docker the safe way (when you must)

cr0x@server:~$ sudo systemctl status docker --no-pager
● docker.service - Docker Application Container Engine
     Active: active (running) since Thu 2026-01-01 08:11:09 UTC; 1d 3h ago

cr0x@server:~$ sudo systemctl restart docker
cr0x@server:~$ sudo ss -ltnp 'sport = :8080'
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process

Meaning: The listener is gone, implying the proxy was orphaned and a daemon restart cleaned it up.

Decision: Immediately re-deploy the container with the intended port mapping, then validate traffic paths. Also: open a ticket to understand why Docker drifted.

Task 16: Diagnose rootless Docker bind failures (looks similar, different cause)

cr0x@server:~$ docker context show
rootless

cr0x@server:~$ docker run --rm -p 80:8080 nginx:alpine
docker: Error response from daemon: driver failed programming external connectivity on endpoint hopeful_bardeen: Error starting userland proxy: listen tcp4 0.0.0.0:80: bind: permission denied.

Meaning: This one is not “already in use”; it’s “permission denied,” but operators often misread it as “a port problem.”
Rootless mode can’t bind privileged ports (<1024) without help.

Decision: Either publish a high port (e.g., 8080) and front it with a privileged proxy, or configure a deliberate capability-based solution.

Second short joke, then back to work: Restarting Docker to fix a port conflict is like rebooting the office to find your stapler. It works, but you’ll make enemies.

Pick the clean fix: a decision tree

“Fix cleanly” is not “kill -9 and move on.” A clean fix is one where you understand ownership, impact, and recurrence. Use this decision tree.

1) Is the port owned by a host service you actually need?

Yes, and it must stay on that port: Do not publish Docker on the same port. Publish on a different host port and use a reverse proxy (or load balancer) to route.
Yes, but it can move: Change the host service configuration and deploy in a controlled window. Update monitoring and firewall rules.
No, it’s unexpected: Trace who started it (PID → parent → unit file or container) and remove it properly.

2) Is the port owned by another container?

It’s the same service (replacement deployment): Do a controlled swap. With Compose, that might mean stopping the old service before starting the new one, or using different published ports for blue/green.
It’s a different service: Negotiate ports. Don’t build an undocumented “whoever starts first wins” system.

3) Is the owner systemd via a socket unit?

Yes: Stop/disable the .socket unit, or change it to listen on a different address/port. Stopping the .service unit alone is theater.

4) Is it a stale Docker networking artifact?

Likely: Validate Docker’s view (docker ps, docker network inspect) against the kernel’s view (ss). If they disagree, restart Docker in a controlled way.

5) Do you actually need to bind on `0.0.0.0`?

Publishing on all interfaces is convenient and often wrong. If a service is only meant for local access (metrics, admin UIs),
bind to 127.0.0.1 or a specific management interface and keep it off the public internet.

Three corporate mini-stories (pain, learning, paperwork)

Mini-story 1: The incident caused by a wrong assumption

A team inherited a “simple” host: one VM, Docker installed, a handful of containers, and a reverse proxy. The runbook said the application lived on port 8080.
So the on-call assumed 8080 was the app port. Reasonable. Wrong.

During a routine update, they deployed a new container with -p 8080:80 and hit “port already allocated.” They did what people do when the clock is ticking:
they picked another port (8081), updated the reverse proxy, and called it done. Traffic recovered.

Two hours later, a different alert fired: internal callbacks were failing. Some upstream system had a hardcoded dependency on http://host:8080.
That dependency existed because months earlier someone bypassed the reverse proxy “temporarily,” and “temporary” became infrastructure.

The wrong assumption wasn’t about Docker. It was about ownership and interface contracts. Port 8080 wasn’t “the app.” It was “the contract that other teams coded against.”
Once they realized that, the fix was boring: put the reverse proxy back on 8080, move the internal service to a non-conflicting port, and document the contract.

The follow-up action was the real win: they added a listener inventory check to deployments. If port ownership changes, the deploy fails loudly before production does.

Mini-story 2: The optimization that backfired

Another org decided to “optimize” host networking. They wanted fewer moving parts, so they switched some latency-sensitive services to --network host.
That eliminates NAT and can reduce overhead. It also removes the safety rails.

The first month went fine. Then a developer shipped a sidecar with a default port of 9090, also on host networking.
On one node, 9090 was already used by a metrics exporter. On another, it wasn’t. So the rollout succeeded “sometimes.”

The failure mode was nasty: the container would start on nodes where the port was free, and fail elsewhere with “bind: address already in use.”
Or worse, the sidecar would start first and steal the port, and the exporter would fail. Same port, two services, non-deterministic start order.

The “optimization” wasn’t inherently bad, but it required discipline they didn’t have: explicit port allocation, node-level validation, and a policy against default ports.
They rolled back host networking for most services and kept it only where it was justified—and documented the allowed ports per node.

Mini-story 3: The boring but correct practice that saved the day

A payments-adjacent platform ran multiple Docker hosts with strict change management. Nothing exciting. They also kept a simple habit:
every host had a nightly job that captured a snapshot of listening sockets and mapped them to unit names and containers.

One morning, a host started rejecting a deployment with the familiar port bind error. The on-call pulled last night’s snapshot and compared it to “now.”
Port 443 had a new listener owned by a systemd socket unit that wasn’t part of the baseline. That narrowed the search from “anything on the host” to “recent system changes.”

The culprit was a package update that enabled a default socket unit for a bundled web UI. The service itself wasn’t even running yet—systemd was holding the port preemptively.
Without the snapshot, they would have chased Docker networking and iptables for an hour.

The fix was trivial: disable the unexpected socket unit, rerun the deployment, and add a package pin until they could re-home the UI.
The practice was boring and effective: know what’s listening, and know when it changes.

Common mistakes: symptoms → root cause → fix

These are the patterns that show up repeatedly in production. The symptoms often look identical. The fixes are not.

1) Symptom: Docker says “port is already allocated” but you can’t find a process

Root cause: The listener is on IPv6 only ([::]:PORT) or bound to a specific IP you didn’t check, or it’s held by docker-proxy.
Fix: Use ss -ltnp without filtering first, then check both IPv4 and IPv6. If it’s docker-proxy, map it to a container via its command line or network inspect.

2) Symptom: You stopped the service but the port is still busy

Root cause: systemd socket activation. The .socket unit owns the port, not the daemon process you stopped.
Fix: Stop/disable the socket unit: systemctl stop something.socket and systemctl disable something.socket.

3) Symptom: Compose deploy works on one host, fails on another

Root cause: Hidden port consumers differ between hosts (metrics exporters, local dev services, distro defaults).
Fix: Standardize baseline listeners and check them in CI/CD preflight. Or stop publishing fixed ports per host and put services behind a reverse proxy.

4) Symptom: You “fixed” the bind by changing to a random high port, then downstream systems fail

Root cause: Port number was part of a contract (hardcoded clients, firewall rules, allowlists, monitoring checks).
Fix: Restore the contract port and move the conflicting service instead. If you must change the contract, coordinate and version it like an API.

5) Symptom: Docker publishes on IPv4, but service is only reachable on localhost (or vice versa)

Root cause: Binding mismatch: host binds to 127.0.0.1 while clients expect external access, or service inside container only listens on 127.0.0.1 instead of 0.0.0.0.
Fix: Align binding layers. For containers, ensure the process listens on 0.0.0.0 inside the container. For host publishing, use the right host IP in -p (e.g., -p 127.0.0.1:8080:80).

6) Symptom: After removing a container, the port stays allocated

Root cause: Orphaned docker-proxy or stuck daemon state.
Fix: Confirm no container publishes the port. If none do, restart Docker in a controlled manner and re-check listeners. If it persists, investigate lingering processes and Docker logs.

7) Symptom: “bind: permission denied” while trying to publish port 80 in rootless Docker

Root cause: Privileged port restriction in rootless mode.
Fix: Publish a high port and front with a privileged reverse proxy, or implement a capability-based approach deliberately (and document it).

8) Symptom: You can’t bind to 0.0.0.0:PORT, but binding to 127.0.0.1:PORT works

Root cause: Something already owns the wildcard bind (0.0.0.0) on that port, or your service is trying to claim wildcard while another service is bound to a specific address with exclusive flags.
Fix: Inspect listeners with addresses. Decide whether you want the port on all interfaces; bind explicitly to the required IP, or move the conflicting service.

Checklists / step-by-step plan

Checklist A: When you just need Docker to start (without making it someone else’s problem)

Read the error line. Note protocol, address, and port (0.0.0.0:PORT vs 127.0.0.1:PORT).
Run sudo ss -ltnp 'sport = :PORT' (or UDP equivalent) and identify PID/process.
If it’s a container: docker ps and locate the port mapping; stop/remove the correct container.
If it’s a host service: find the unit with systemctl status PID; decide move vs stop.
If it’s systemd socket: stop/disable the .socket unit.
Re-run your Docker start with an explicit bind address if appropriate (loopback-only for internal tools).
Verify with curl locally and from a peer host if the service is meant to be external.

Checklist B: Clean fix for production (the one you can explain later)

Inventory current listeners: capture ss -ltnp output before changes.
Identify ownership: map PID to unit/container and document it in the change ticket.
Define the contract port: which clients depend on it? Is it in firewall rules, allowlists, monitoring, or DNS?
Pick a strategy:
- Move the container’s published port.
- Move the host service port.
- Introduce a reverse proxy and keep the external port stable.
- Bind services to distinct interfaces (public vs management).
Deploy with a rollback plan: “If X fails, restore Y listener and revert config Z.” Not optional.
Post-change validation: listener exists, app responds, monitoring passes, and no new unexpected listeners appeared.
Prevent recurrence: add a preflight port check in CI/CD or host provisioning.

Checklist C: Compose-specific plan (ports are policy, not decoration)

Locate the mapping in docker-compose.yml under ports:.
Check for duplicates across services (common copy/paste failure).
Ensure your target ports aren’t used by other stacks on the same host.
If you need multiple instances of the same stack, don’t reuse the same host ports. Parameterize them.
Consider removing published ports entirely for internal-only services and connect via Docker networks instead.

FAQ

1) Why does Docker say “port is already allocated” instead of showing the process?

Docker is reporting the kernel error from the bind attempt. The kernel doesn’t supply “friendly ownership details” in that syscall response.
Use ss or lsof to identify the owning PID.

2) I ran `netstat` and it showed nothing, but Docker still fails. Why?

You may be checking the wrong protocol (UDP vs TCP), the wrong address family (IPv4 vs IPv6), or filtering incorrectly.
Also, some netstat builds don’t show process ownership without root. Prefer ss -ltnp with sudo.

3) Can two containers publish the same host port if they bind to different IPs?

Yes, if you explicitly publish to different host IPs, for example:
one binds 127.0.0.1:8080 and another binds 192.168.1.10:8080.
If either binds to 0.0.0.0:8080, it blocks all IPv4 addresses for that port.

4) Is it safe to just restart Docker to fix this?

Sometimes it clears orphaned proxies or reconciles state. It also interrupts running containers and can drop connections.
In production, treat it like a service restart with a change window. If you can fix the actual owner process instead, do that.

5) What if the port is held by `systemd` (PID 1)?

That’s usually a .socket unit. Stop and disable the socket unit. Stopping the related service isn’t enough because systemd keeps the listening socket open.

6) What about `TIME_WAIT`—could that cause “address already in use”?

Not for a typical listening bind. TIME_WAIT is about recently closed connections.
The usual “address already in use” in Docker port publishing is a real listener, not connection churn.

7) I’m using rootless Docker and can’t publish port 80. Is that the same issue?

No. That’s usually “permission denied” due to privileged port binding rules. The clean fix is to publish a high port and front it with a reverse proxy,
or explicitly configure a capability-based approach (and own the security implications).

8) Why does Compose sometimes fail during rolling updates with port conflicts?

Compose doesn’t do rolling updates the way orchestrators do. If you try to run “old” and “new” containers simultaneously with the same published ports,
the second one can’t bind. Use different ports for blue/green, or stop the old container before starting the new.

9) How do I avoid this forever?

You don’t. But you can reduce surprises:
keep a port allocation doc per host (or per environment), use reverse proxies for stable external ports, and add a preflight check that fails deployments
when required ports are already owned.

10) Does Kubernetes NodePort cause the same “address already in use” problem?

It can, but the ownership shifts: kube-proxy and node-level listeners can reserve ports. The diagnostic method is the same: check listeners with ss,
then map the owner back to the orchestrator component.

Conclusion: next steps that won’t wake you up at 3 AM

“bind: address already in use” is the kernel doing its job. Your job is to stop treating it like a random Docker tantrum.
Identify the listener with ss, map it to a unit or container, and choose a fix that respects contracts and blast radius.

Practical next steps:

Add a deployment preflight that checks required host ports with ss and fails fast.
Stop publishing everything on 0.0.0.0 by default. Bind internal tools to loopback.
Document which service “owns” each externally relevant port, and treat changes like API changes.
If systemd socket units are in play, audit them—ports can be reserved even when “the service is stopped.”
When Docker state and kernel state disagree, restart Docker only as a controlled operation, not as superstition.