You’re here because you’ve already tried everything. Your Docker containers are completely unreachable when Cloudflare Warp is active. You get Connection reset, timeouts, or just plain silence.
Disconnecting Warp makes it all work, but that’s not a fix—it’s a surrender. You’ve probably already scoured forums, tried adding exclusion rules that didn’t stick, and are about to give up.
Stop. You’ve found the right page. This is the actual solution.
The Core Problem: A Network Hijack
Let’s get straight to it. This isn’t a bug; it’s a feature. Your Cloudflare Warp client is likely managed by your organization, which uses an “Include” policy for its VPN tunnel. This means Warp is configured to forcefully grab all traffic going to a specific list of IP addresses. The problem? Docker’s default network (172.17.0.0/16) is on that list.
Every time you run vagrant up or docker-compose up, the traffic from your machine to your container is being hijacked and routed through the VPN tunnel, where it disappears into the void. This is why you get timeouts and connection errors. Because this is a centrally-managed policy, local commands to add exclusions are often ignored.
Step 1: Confirm the Diagnosis on Your Machine
Before you change any files, you can prove this is your issue in under 10 seconds. Open your terminal and run the warp-cli settings command, filtering it with grep to find Docker’s default IP range.
warp-cli settings | grep '172.17.0.0/16'
If the conflict exists, you will see that IP address in the output. If the command returns a result like the one below, you have 100% confirmed the problem and can proceed to the fix.
(network policy) Include mode, with hosts/ips: ... 172.17.0.0/16 ...
Note: this reserved address range, among others, is “Used for local communications within a private network”, as you can see in this Wikipedia article.
Step 2: Apply the Permanent Fix
The only reliable solution is to move Docker to a network that Warp doesn’t care about. You do this by changing Docker’s default bridge IP. It’s a one-time configuration change that permanently solves the issue.
1. Stop the Docker Daemon
Close Docker Desktop or run the appropriate command to stop the service.
# On Linux (example) sudo systemctl stop docker
2. Locate and Edit daemon.json
This is Docker’s main configuration file. If it doesn’t exist, create it.
- macOS:
~/.docker/daemon.json - Windows:
%USERPROFILE%\.docker\daemon.json - Linux:
/etc/docker/daemon.json
3. Set a New Bridge IP (bip)
Open the daemon.json file and add the following. We are telling Docker to use a new IP range that is highly unlikely to be included in your Warp policy.
{
"bip": "192.168.220.1/24"
}
If the file already has other settings, just add the "bip" key-value pair, making sure to keep the JSON format valid (add a comma after the preceding line if necessary).
4. Restart Docker
That’s it. Restart the Docker service. Your Docker networks will now be created in the 192.168.220.x range, which flies under Warp’s radar.
Note: similarly to the note above, this reserved address range, among others, is “Used for local communications within a private network”, as you can see in this Wikipedia article.
You can now run vagrant up or any other Docker command with Cloudflare Warp active. No more disconnects, no more workarounds. Now you can get back to what you were actually trying to do.
If you’re diving deep into Docker networking—especially custom bridges, IP conflicts, or daemon configuration—you’ll benefit from Docker Deep Dive by Nigel Poulton. It’s a clear, hands-on guide trusted by DevOps engineers and developers worldwide. Learn more on Amazon.
Once your Docker containers are reachable again, you might want to set up proper debugging. I’ve written a complete guide on configuring PHP debugging in Docker with Vim and Xdebug , including path mapping and Xdebug settings.
