I'm running Docker and Docker Compose on Ubuntu 24.04.4 LTS. Several containers are spread across the default bridge network and a few custom networks, with some using a VPN container for their network stack. They communicate through API requests using URLs like http://HOST_IP:PORT.
This setup worked reliably for more than 18 months, including on an earlier Ubuntu installation. After changing the address of my LAN, I also changed the Ubuntu host's IP address and rebooted the machine. The containers themselves are running normally, but after updating the API URLs to use the new host IP, multiple containers can no longer reach their targets.
I'm wondering whether Docker or its bridge networking is somehow tied to the old host address, or whether there is another configuration—such as firewall rules, port publishing, network membership, or VPN routing—that needs to be updated. I'd like to diagnose and fix the issue without unnecessarily removing and redeploying everything. What should I check first, and what is the recommended way for containers on the same host to communicate?
4 Answers
For containers on the same Docker network, the host’s LAN address should not be involved. Put the services that need to communicate on a shared user-defined network and call the target by its Compose service name or container name, using the container’s listening port. For example, use http://api:8080 rather than http://HOST_IP:8080. Container IP addresses can change, so they should not be hard-coded either.
Host-published ports are mainly for access from the host or from outside Docker. If a service is only used by other containers, it usually does not need to be routed through the host at all.
Start debugging from inside the calling container. Run a shell with docker exec, then test name resolution and connectivity to the target service using its Docker name and port. Also inspect the containers and networks with docker inspect to verify that both services are attached to the expected network and that the target is actually listening on the expected interface and port.
Testing the same URL from the host is not equivalent to testing it from a container, especially when VPN-based network modes are involved.
Changing the host’s LAN IP normally does not require reinstalling Docker or changing the internal bridge networks. Check the details around the host-facing path instead: published port mappings, the application’s bind address, host firewall rules, router rules, and any VPN routing or kill-switch configuration. A service bound only to an old address, or firewall rules referring to the previous address, could prevent access through the host IP.
Using the host IP and a published port for container-to-container traffic is similar to sending traffic out through a router and back in again. It can work, but it adds unnecessary dependencies and may fail because of firewall, hairpin NAT, binding, or VPN rules. Connect directly over a shared Docker network wherever possible, and expose ports only when something outside that network needs access.
The containers are all on one Ubuntu host, but they are split between the default network, custom networks, and in a couple of cases a VPN container’s network namespace. The setup worked before the host address changed, so I’m trying to determine whether the host-facing URLs or VPN routing are the part that needs adjustment.