Docker Compose networking issues on macOS with VPN active

I'm running a Docker Compose setup (db, api, worker) and can't resolve container names between services when my corporate VPN is connected. The containers start fine but service discovery fails — 'api' cannot reach 'db:5432'. I've tried restarting the Docker Desktop daemon without success. Has anyone else encountered this networking conflict between the VM bridge and a VPN tunnel?

This is one of those Docker Desktop for Mac networking behaviors that nobody documented well enough and everybody has to learn the hard way through trial and error because there isn't a single cohesive page that covers it. The root cause lives in how Docker on macOS handles its user-mode network stack versus what you get on Linux where everything runs natively in the kernel. On macOS, every container gets routed through a virtualized eth0 interface inside a lightweight Linux VM (HyperKit or VirtioFS depending on your build), and when that VM has to route traffic out of itself and into your host's networking namespace while your VPN is active at the host level, you hit an asymmetric routing condition where outbound packets are being encapsulated by the VPN tunnel but inbound response packets can't find their way back in because the NAT table entry inside Docker doesn't know about the outer VPN encapsulation layer. The symptom you described — containers reaching out to external services fine but receiving no responses, or connections hanging indefinitely at SYN/ACK — is exactly that asymmetry playing out. There are three distinct ways to approach this depending on your requirements. Option one: run a dedicated container as the network gateway and route all traffic through it using network_mode="service:vpn" in Compose; the VPN agent lives inside Docker, so there's no cross-namespace translation issue. The downside is you lose host-level VPN access for other tools on your machine while that container is running. Option two: use the --network=host flag at the service level which bypasses the bridged network stack entirely and routes directly through the host's networking namespace — this works but it's a security footgun since containers can now see all unencrypted traffic on the host, plus Docker Compose doesn't play nicely with host mode for shared networks. Option three: use Tailscale or WireGuard in sidecar fashion which uses UDP hole punching to maintain connectivity across NAT boundaries and is generally more robust than OpenVPN/Wire

VPN + Docker Desktop = routing chaos by design. Check whether your VPN is in TUN or TAP mode and if it's pushing routes that conflict with docker0. I have a 15-page thread on this from 2019 where three different approaches were tried before the workaround

help please - i have this open right now because my docker is routing everything through corporate vpn and my containers can't reach each other at all. am i supposed to use bridge mode or something else? i tried adding networks: but it didnt work. i dont really know what the problem is im just trying to get a simple redis + api stack running for dev work tomorrow before 9am. any quick fix would be amazing thx