failed to allocate gateway (172.18.0.1): Address already in use

Not specified by the original author.

TL;DR: Something on the host already owns the .1 gateway address docker wants. Either free that address on the host or create the network with an explicit --gateway on a free IP. This usually means a stale docker network or a host interface squatting in the same subnet.

The error

failed to allocate gateway (CONTAINER_IP): Address already in use

Fix it

1. Find what holds the address: ip addr | grep CONTAINER_IP Expected: an interface (often a leftover docker bridge like br-xxxx).

2. If it is a stale docker interface, remove the orphan network: docker network ls and docker network rm [stale] Expected: the interface disappears.

3. Or sidestep with an explicit gateway: docker network create --subnet CONTAINER_IP/24 --gateway CONTAINER_IP mynet Expected: network created.

When this applies

• Network creation failing on the gateway allocation step
• Hosts where docker networks were deleted without cleanup

When this does NOT apply

• "Pool overlaps" (subnet-level conflict, earlier check)
• Port "address already in use" (different resource)

Versions

All Docker Engine versions.

Why it happens

The daemon assigns the subnet's .1 address as the bridge gateway. If a previous network's bridge interface was not torn down, or a host process bound that IP, the allocation fails even though the subnet itself looked free.

Edge cases

• ip link delete br-xxxx type bridge removes a truly orphaned bridge interface when no docker network claims it, but be sure it is orphaned first.
• Restarting the daemon cleans up most stale interfaces automatically.
• VPNs that grab CONTAINER_IP on connect cause this intermittently; create networks with explicit subnets outside the VPN range.

Asked: how to fix failed to allocate gateway (CONTAINER_IP): Address already in use. Verified answer: Fixes 'failed to allocate gateway ... Address already in use' when creating docker networks. Use when the default gateway IP of a new bridge network collides with something on the host. The fix steps above were cross-checked against the accepted community answer at https://github.com/pharkie/arr-stack-ugreennas/issues/10 (gh:pharkie/arr-stack-ugreennas#10), which confirms the same resolution.

Not specified by the original author.

TL;DR

Another process is already bound to the port the collector wants - often a second collector instance, a leftover one from a bad shutdown, or another service on the same port. Find which process holds the port, then either stop the duplicate or change one side's port. If you genuinely need both running, give one of them a different port in its config.

OTel collector "Failed to start: address already in use": port conflict fix

Steps

1. Read the collector startup log and note the exact address and port it failed to bind.

Expected: You know the conflicting port, e.g. 4317 or 4318.

2. Find the process holding that port with a socket listing command (for example ss with the listen and process flags, or lsof for the port).

Expected: You have a PID and process name for the holder.

3. Decide which one should own the port. If it is a duplicate or stale collector, stop it. If it is a different service you need, change the port in one side's config.

Expected: The port is free, or you have a planned new port for one side.

4. Start the collector again and confirm the receiver logs show it listening.

Expected: The collector starts cleanly and the receiver accepts connections.

Use this when

• The collector log says failed to start with address already in use on a receiver port.
• Two collector instances or a collector plus another OTLP receiver on one host.
• A collector that fails to start right after a previous one was killed.

Not for this skill when

• Collector config YAML syntax or schema errors (different fix).
• Exporter failures like auth errors or unreachable backends.
• Pipelines that start fine but drop or misroute telemetry.

Variant phrasings

otelcol bind: address already in use

opentelemetry collector port 4317 already in use

collector fails to start receiver port in use

Why it happens

Each receiver opens a TCP or UDP listener, and an operating system only allows one process per port. A second collector, a zombie process from an unclean shutdown, or an unrelated service on the same port all produce the same bind failure.

Edge cases

• A socket in TIME_WAIT is not a real conflict - if nothing owns the port, just retry.
• Docker port mappings can collide with host processes and with each other; check both.
• Two pipelines in one config accidentally using the same receiver port fail the same way.
• On systemd hosts, a failed collector may restart-loop and hold nothing while another copy holds the port - check for duplicates first.

Provenance

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

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

Thread query: OTel collector "Failed to start: address already in use": port conflict fix

TL;DR: Another process is already bound to the port the collector wants - often a second collector instance, a leftover one from a bad shutdown, or another service on the same port. Find which process holds the port, then either stop the duplicate or change one side's port. If you genuinely need both running, give one of them a different port in its config.

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.