How do you stop Docker networks clashing with your LAN or VPN subnet?

Put a default-address-pools entry in /etc/docker/daemon.json that hands out subnets from a private range nothing else on your network uses, restart the daemon, and recreate your networks. That one change fixes both symptoms that bring people here: a new stack that cuts off a VPN or a remote LAN, and the error all predefined address pools have been fully subnetted. Both come from the same built-in list in Docker Engine Engine, which holds 31 networks and spends its last sixteen inside 192.168.0.0/16.

Two answers circulate, and both are half right#

The first answer is "Docker uses 172.17.0.0/16, so just move it with bip". bip moves only the default bridge, docker0. Every compose project creates its own _default network, and those come from a separate list, the default address pools. Changing bip leaves all of them where they were.

The second answer is "Docker already avoids subnets that are in use, so a clash cannot be Docker's fault". Docker's networking overview says it "attempts to avoid address prefixes already in use on the host", and the source shows exactly how far that attempt goes. Before taking a subnet automatically, the daemon reads two things: the nameservers in /etc/resolv.conf, and the on-link routes in the host's main routing table. That protects the LAN your server is plugged into. It does not protect anything the host reaches through a gateway, anything in another routing table, or anything that appears after the network was created. Those are exactly the places a VPN puts its routes.

The default pools, in numbers#

The list is hardcoded in Moby's ipamutils package, and it is identical in Engine 28.1.1 and in the current release, docker-v29.9.1 (14 October 2026):

Docker takes the first free subnet in that order. docker0 normally takes 172.17.0.0/16, so your first fourteen compose projects land on 172.18 to 172.31. The fifteenth project gets 192.168.0.0/20, which covers 192.168.0.0 to 192.168.15.255, the range most home routers use. The thirty-first project fails with all predefined address pools have been fully subnetted.

Each network is far larger than it needs to be. A typical self-hosted stack has two to five containers on a network built for 65,534. That waste is why the pool runs out at 31 networks and not at a few thousand.

We saw the whole sequence on one server running 39 compose projects. Thirty of its networks filled the built-in list exactly, 172.18 to 172.31 and all sixteen 192.168 /20 blocks. The other nine, and docker0, sat in 10.201.x.0/24, the pool its daemon.json now sets. A network keeps the subnet it was created with, which is why the two ranges sit side by side on one host.

What Docker checks, measured#

We tested each case on Docker Engine 28.1.1 by adding a route for the next free subnet, then creating a network and reading the subnet it got. Every route and test network was removed afterwards.

Then we tried both orders, because a VPN that connects after boot is the common case:

• Docker network first, VPN route second. Adding the gateway route failed with RTNETLINK answers: File exists, and ip route get sent the VPN's address range into the Docker bridge. The tunnel shows as connected, and nothing behind it answers.
• VPN route first, Docker network second. Docker created the network on the same subnet. The bridge route was added beside the existing one, but the host kept sending that range to the gateway, so the containers' own subnet was the part that stopped working from the host.

Either way, the first route wins and the other side breaks quietly. No error appears in docker compose up.

Who actually gets hurt#

On a server whose LAN is directly attached, the on-link check means Docker skips the LAN itself. The clashes come from networks one hop further away:

• A site-to-site VPN or a VPN server whose remote LAN, or whose tunnel subnet, falls inside a Docker network. If the tunnel comes up after the stack, its route is refused with File exists and replies to those clients go into the bridge. Headscale vs wg-easy covers the two common VPN servers.
• Tailscale subnet routes. Routes in table 52 are invisible to Docker's check, so a stack started later can claim an advertised subnet.
• A second VLAN or office LAN reached through your router, such as a camera network on 192.168.10.0/24.
• A laptop running Docker, where a work VPN that routes 192.168 ranges connects long after the Docker networks were allocated.

If you reach the server through an overlay network, Remote access without port forwarding covers the setups this applies to.

The fix: one pool, sized on purpose#

Choose a block inside 10.0.0.0/8 that none of your LANs, VPNs or cloud networks use, and write it to /etc/docker/daemon.json:

{
  "default-address-pools": [
    {"base": "10.201.0.0/16", "size": 24}
  ]
}

base is the block Docker allocates from. size is the prefix length of each network it creates, not the size of the pool, and this is where tutorials go wrong. The number of networks is 2 to the power of (size minus the base prefix length):

The last row is a configuration that circulates in tutorials, paired with "bip": "192.168.90.1/24". The bridge works, the first compose project works, and the second one fails with the same "fully subnetted" error the change was meant to prevent.

Avoid two other ranges. 172.240.0.0/16, which another widely shared fix recommends, is outside 172.16.0.0/12, so it is not private address space under RFC 1918. While a Docker network holds it, traffic to the real hosts in that range goes into the bridge. And if you use Swarm, its overlay networks have their own default pool, 10.0.0.0/8 split into /24 networks, so carve your local pool from a part of 10/8 you are certain Swarm is not using.

With no bip set, docker0 takes the first subnet of the new pool. On our test server it came up as 10.201.0.1/24. Anything that hardcodes 172.17.0.1, such as a host service bound to that address, has to change with it. Reaching a host service from a container covers the host-gateway name that follows the bridge for you.

Applying it: restart, then recreate#

default-address-pools is not one of the options the daemon reloads on SIGHUP, so it needs a full restart:

sudo systemctl restart docker

Docker's live restore documentation is plain about the cost: "By default, when the Docker daemon terminates, it shuts down running containers." Containers with a restart policy come back afterwards. Plan it as downtime.

The restart does not move anything. Every existing network keeps its old subnet until it is deleted and created again. For each compose project:

cd /srv/stacks/immich
docker compose down     # removes the containers and the project's networks
docker compose up -d    # recreates them from the new pool

docker compose down removes networks defined in the compose file and "the default network, if one is used", and leaves named volumes alone unless you add -v. "Networks and volumes defined as external are never removed", so the shared proxy network in Docker Compose conventions survives every project's down. Stop every stack attached to it, run docker network rm proxy and docker network create proxy, then bring the stacks back.

Check the result with:

for n in $(docker network ls -q --filter driver=bridge); do
  docker network inspect -f '{{.Name}} {{range .IPAM.Config}}{{.Subnet}}{{end}}' "$n"
done

If you hit "fully subnetted" right now#

Free networks first, then fix the pool. docker network prune removes networks "not referenced by any containers". On a self-hosting box that usually means networks left by renamed or deleted projects. It also removes the networks of stacks that are currently stopped, which is harmless because docker compose up recreates them, and an unused external network, which is not harmless if your stacks expect it. Look at docker network ls before you prune. Pruning buys a few slots. The pool change is what makes the error go away for good.

Pinning a subnet for one stack#

Compose can set a network's subnet directly:

networks:
  default:
    ipam:
      config:
        - subnet: 10.250.3.0/24

Use this only when something needs to know the subnet in advance, such as a trusted-proxies setting in an app behind a reverse proxy (Reverse proxy and TLS covers why that matters). Our test showed that an explicit subnet skips Docker's route check entirely, so a pinned subnet that overlaps your LAN is accepted without a warning. Keep pinned subnets outside the automatic pool, or the stack fails with Pool overlaps with other one on this address space on any host where Docker has already handed that subnet to another network.

When this answer stops applying#

• IPv6. Docker's route check only reads on-link routes for IPv4. If you enable IPv6 on your networks, choose the IPv6 pool yourself.
• Docker Desktop on macOS and Windows. Containers run inside a virtual machine with its own networking. Nothing here was tested there.
• Podman and rootless Docker. Both use different network back ends. Nothing here was measured on either, and Docker vs Podman covers how they differ.
• Swarm overlay networks. They use the global pool described above, not the local one this guide changes.

What to do next#

Write the pool into daemon.json before you need it. It is far easier on a new server than after forty networks exist. List the subnets your VPN and remote LANs use, alongside the plan in DNS for self-hosters, and pick a Docker range that misses all of them. If you are building the server now, Your first self-hosted server lists the other decisions that are hard to undo later.