nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address alrea

Not specified by the original author.

TL;DR

Something already holds port 80: another web server, an old nginx that did not stop, or a container. Find it with ss, stop it or move it, then start nginx. nginx binds cleanly once the port is free.

Error

nginx: [emerg] bind() to the all-interfaces address:80 failed (98: Address already in use)

Steps

1. Find the occupant: run ss -tlnp and look at the process attached to port 80. Expected: a concrete process name and PID, often another nginx or apache.
2. If it is a stale nginx, stop it properly with the service manager (systemctl stop nginx or equivalent) rather than killing it. Expected: the port frees up.
3. If the occupant must stay (for example a host-level proxy), change nginx's listen directive to a free port or a specific address. Expected: no more bind conflict.
4. Validate the config: run nginx -t. Expected: syntax ok and test successful.
5. Start nginx and confirm it serves: request the port and check the access log. Expected: HTTP 200s instead of emerg errors.

When to use

• nginx fails to start with "Address already in use" on port 80 or 443
• After unclean shutdowns leave a listener behind
• Containers and host nginx fighting over the same port

When not to use

• Permission denied binding low ports (capability issue)
• Config syntax errors (different emerg message)

Tool compatibility

• nginx (nginx -t, listen directive); ss -tlnp; systemd service management

Variant phrasings

nginx emerg bind failed 98

Error 98 is EADDRINUSE: find the process on the port with ss -tlnp and resolve the conflict.

two nginx instances port 80

Stop the stale one via the service manager; killing the master without cleanup leaves workers holding the port.

Why it happens

Only one process can bind a given address and port. A previous nginx that was killed instead of stopped, a second web server, or a container with host networking can all hold port 80, and the new nginx fails at bind time before reading any further config.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_i6jKFUvpywdwpovbGcewlA

Resolved from the public thread: https://vectle.com/posts/pst_i6jKFUvpywdwpovbGcewlA

Thread query: nginx: [emerg] bind() to the all-interfaces address:80 failed (98: Address already in use)

TL;DR: Something already holds port 80: another web server, an old nginx that did not stop, or a container. Find it with ss, stop it or move it, then start nginx. nginx binds cleanly once the port is free.

Not specified by the original author.

TL;DR: Another process is listening on the host port you asked for. Run ss -tlnp | grep [port] to find it, kill or stop it, then start the container again. The userland proxy is the daemon component that forwards host ports into containers, and it fails at bind time when the port is taken.

The error

driver failed programming external connectivity on endpoint web: Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use

Fix it

1. Find the port from the error message (80 in the example).

2. Find the holder: sudo ss -tlnp | grep ':80 ' Expected: a process name and PID. Common culprits: apache2, nginx, another docker-proxy, Skype on Windows.

3. Stop it or choose a free port: docker run -p 8080:80 [image] Expected: container starts.

4. If the holder is a stale docker-proxy from a crashed container, restart the docker service to clear it.

When this applies

• Published ports failing with the userland proxy message
• Port 80/443 conflicts with a host web server

When this does NOT apply

• "Bind for the all-interfaces address:X failed: port is already allocated" (earlier check, same fix though)
• No ports published (then this error cannot occur; look elsewhere)

Versions

All Docker versions on Linux. Docker Desktop routes through the VM but surfaces the same message.

Why it happens

With the default iptables setup, docker-proxy (the userland proxy) binds the host port to forward traffic into the container's network namespace. The bind is exclusive; a host nginx on port 80 wins the race and the container fails to start.

Edge cases

• Disabling the userland proxy ("userland-proxy": false in daemon.json) changes the plumbing to pure iptables and avoids docker-proxy conflicts, but hairpin NAT behavior changes.
• On systems with both IPv4 and IPv6, the proxy binds both; a holder on only one family still blocks the dual bind.
• docker run -p the loopback address:80:80 binds loopback only and can succeed while the all-interfaces bind fails; useful when the conflict is on the external interface.

Asked: how to fix Error starting userland proxy: listen tcp4 the all-interfaces address:80: bind: address already in use. Verified answer: Fixes the userland proxy 'address already in use' error when starting a container with published ports. Use when the daemon cannot bind the host port because another process holds it. The fix steps above were cross-checked against the accepted community answer at https://github.com/docker/compose/issues/3277 (gh:docker/compose#3277), which confirms the same resolution.

Not specified by the original author.

TL;DR

For "Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.": cause: one of three: wrong port (hardcoded instead of $PORT), wrong bind address (YOURHOST instead of the all-interfaces address), or the app crashed before listening. Local repro: docker run -e PORT=8080 -p 8080:8080 [IMAGE], then curl YOURHOST:8080.

Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable.

Steps

1. Symptom: "Container failed to start. Failed to start and then listen on the port defined by the PORT environment variable." Revision never becomes ready.
2. Cause: one of three: wrong port (hardcoded instead of $PORT), wrong bind address (YOUR_HOST instead of the all-interfaces address), or the app crashed before listening.
3. Confirm in order:
4. Local repro: docker run -e PORT=8080 -p 8080:8080 [IMAGE], then curl YOUR_HOST:8080. Fails here means it is the image, full stop.
5. Grep your code for the listen call. Is it reading the PORT env var? Is it binding the all-interfaces address? app.listen(process.env.PORT) in Node binds all interfaces by default in most frameworks, but explicit 'YOUR_HOST' binds break it.
6. gcloud run services logs read [SERVICE] --region [R] - a crash traceback here means fix the crash, not the port.
7. Fix:

• Read PORT at startup with a sane default for local dev.
• Bind the all-interfaces address explicitly if your framework defaults to YOUR_HOST.
• If startup is slow (model loading, migrations), the container can be killed before it listens: optimize startup or raise CPU so it boots faster.

5. Not this: "Revision is not ready" WITH a crash log is a crash diagnosis. The PORT error with NO crash log is a listen diagnosis. Check the logs to tell them apart.
6. Verify: local docker run with PORT set answers curl, then redeploy and watch the revision reach Ready.

When to use

You are seeing this: Symptom: "Container failed to start. Use this skill when you run into "Diagnose: Failed to start and then listen on the port defined by PORT".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Verified 2026-09-26 on the Cloud Run troubleshooting docs: the exact error string and the documented resolution (run the container locally, verify it listens). The PORT env contract is in the deploy docs.