Fixing Pterodactyl Wings: Pool Overlaps With Other One on This Address Space

You add a new node to Pterodactyl, get Wings running, then try to create a server. It fails. The Wings log shows something like:

Error response from daemon: Pool overlaps with other one on this address space

Or when starting an existing server after a system update:

failed to create endpoint on Docker network: Error response from daemon: 
network pterodactyl_nw already has active endpoints

Both errors point to the same class of problem: Docker tried to create an internal network with a subnet that conflicts with something already using that address range on your host machine.

---

Why This Happens

Docker creates virtual network bridges for container communication. When a Pterodactyl server starts, Wings instructs Docker to attach the container to an internal bridge network. Docker automatically assigns a subnet from a default pool.

The default pool uses the 172.16.0.0/12 range, which includes subnets like 172.17.0.0/16, 172.18.0.0/16, and so on.

If your host machine already has a network interface using one of these subnets, Docker cannot create a bridge using the same range. Common sources of conflicts:

• Your VPS provider uses 172.x.x.x for internal networking between machines
• You run a VPN on the host (WireGuard, OpenVPN) that uses overlapping subnets
• You run another Docker-based application like Nginx Proxy Manager, Portainer, or a databases container that already claimed the subnet
• The host's default gateway sits in the 172.20.0.0/16 range

---

Diagnosing the Conflict

First, look at all active network interfaces and routes on the host:

ip addr show
ip route show

Look for any addresses in the 172.16.0.0 to 172.31.255.255 range. Note which interface owns them.

List all existing Docker networks:

docker network ls
docker network inspect bridge

The inspect output shows the subnet each network uses under the IPAM.Config section.

If you see a Docker network using 172.18.0.0/16 and your VPS provider's internal management interface is also on 172.18.x.x, that is your conflict.

---

The Fix: Configure Docker's Default Address Pool

Tell Docker to use a subnet range that does not conflict with anything else on your system. Edit or create /etc/docker/daemon.json:

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

This tells Docker to allocate container bridge networks from the 10.100.0.0/16 range instead of the default 172.x.x.x range. Each bridge gets a /24 subnet from this pool, providing up to 254 usable addresses per network.

Choose a range that does not conflict with anything else:

• Your server's actual IP addresses
• Your VPC or management network
• Your VPN subnet
• Any other Docker networks from other applications

After editing daemon.json, restart Docker:

systemctl restart docker

Then restart Wings:

systemctl restart wings

---

Cleaning Up Conflicting Docker Networks

If old Docker networks exist from previous container instances and are blocking new network creation, remove them:

# List all networks
docker network ls

# Remove a specific network (only if no containers are using it)
docker network rm pterodactyl_nw

# Remove all unused networks at once
docker network prune

Wings will recreate its networks with correct configuration when servers start.

---

The Nginx Proxy Manager Conflict

A specific and common variant of this problem occurs when you run Nginx Proxy Manager on the same host as Wings. NPM creates its own Docker networks during setup. These networks have a habit of claiming subnets in the 172.20.x.x or 172.21.x.x range.

When Wings later tries to create its own network, Docker finds those subnets taken and generates the overlap error.

The fix is the same: configure daemon.json to use a non-conflicting base range. Apply the fix, then reconfigure NPM to use its own explicitly defined subnet so both applications coexist cleanly.

For NPM, modify its docker-compose.yml to specify a fixed network:

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

This gives NPM a fixed /24 that does not collide with Wings' allocations.

---

The Websocket Connection Issue From Port 443 Conflicts

A related but separate problem: Nginx Proxy Manager listens on port 443 for HTTPS traffic. Pterodactyl Wings also uses port 443 for its secure websocket connection between the node and the panel.

If NPM is running first and binding port 443, Wings fails to bind its websocket listener. The panel shows nodes as offline even though Wings is running.

Solutions:

1. Change Wings to a different port. In the Wings configuration (/etc/pterodactyl/config.yml), change api.port to a non-standard HTTPS port like 8443. Update the node allocation in the Pterodactyl panel to match.

2. Route Wings through NPM. NPM can proxy websocket connections. Create a proxy host in NPM for your node's hostname pointing to Wings' local listener. This lets NPM handle the TLS termination while passing websocket traffic through.

3. Run them on separate servers. If the configuration complexity becomes significant, Wings is better on a dedicated node machine without any other web services competing for ports.

---

Confirming the Fix

After applying the changes, try creating a server through the Pterodactyl panel. Watch the Wings log in real time:

journalctl -u wings -f

Successful server creation shows the container ID being created and the container starting. No network errors means the subnet conflict is resolved.

Check the newly created Docker network to confirm it uses your configured subnet pool:

docker network ls
docker network inspect $(docker network ls -q | head -1)

The IPAM.Config.Subnet should now show an address from your configured pool, not from the conflicting 172.x.x.x range.