I run several Docker Compose projects locally, and Docker's automatic bridge-network allocation eventually chooses subnets that overlap with routes from my LAN or VPN, especially in the 172.16.x.x range. The problem isn't containers fighting over individual IP addresses or ports; it's that overlapping host routes break connectivity and can cause asymmetric routing. Do you rely on custom Compose networks, configure Docker's default address pools globally, or use another approach to keep separate environments isolated?
4 Answers
Docker’s built-in IPAM generally prevents conflicts between containers on its own networks. The tricky conflict is between Docker’s subnets and routes already present on the host, such as VPN or LAN ranges. Check the host routing table and choose a Docker pool that is outside every range your machine may connect to. If your VPN dynamically uses different private ranges, coordinate with whoever manages it or reserve a range that is guaranteed not to be advertised there.
Port conflicts are a separate issue from container-network subnet conflicts. Containers can listen on the same internal port as long as they are on separate networks; collisions only happen when multiple services publish the same host port. In Compose, either choose different host-side ports or avoid publishing internal-only services altogether and access them through a reverse proxy or another container on the shared network.
A practical fix is to reserve a private range for Docker that never overlaps with your home network, corporate VPNs, or other host routes. You can set Docker’s default bridge address and automatic network pool in /etc/docker/daemon.json, for example: {"bip":"10.200.0.1/24","default-address-pools":[{"base":"10.201.0.0/16","size":24}]}. The base is the larger block Docker can allocate from, while size controls the subnet assigned to each individual network. A /24 is usually plenty for a Compose project. Restart Docker after changing the file, and remove/recreate existing networks if they still use the old ranges.
For most projects, let Docker handle container IP assignment and use service names for communication instead of hardcoding addresses. Define a project-specific bridge network in Compose when you need clear isolation, and create a manually managed external network only when multiple stacks genuinely need to communicate. This avoids micromanaging individual IPs while still giving you control over which projects share a network.
That clarifies the issue: I’m not trying to assign static container addresses. The actual failure happens when an automatically selected Docker subnet overlaps with an active VPN route, so I’ll focus on reserving a safe global address pool.