How would you debug a container that can't reach another container or the internet?

Step 1: confirm both containers are actually on the same network

docker network inspect my-network
# check the "Containers" section -- are BOTH containers actually listed here?

A surprisingly common root cause: one container was started with --network my-network, and the other was started with no network flag at all, silently landing on the default bridge instead (see that question). They're simply on two different, unconnected networks. No amount of DNS or firewall troubleshooting will fix that — they need to actually be attached to the same network.

Step 2: test DNS resolution specifically, before testing the actual connection

docker exec web nslookup api
# or, if nslookup isn't available in a minimal image:
docker exec web getent hosts api

If the name doesn't resolve to an IP at all, the problem is at the networking/DNS layer (likely Step 1's issue, or the target container isn't actually running). If it does resolve to an IP, the problem is further along — the name resolution is fine, so investigate the actual connection next.

Step 3: test actual connectivity to the resolved IP/port

docker exec web curl -v http://api:3000/health
docker exec web nc -zv api 3000        # just check if the port is open, without a full HTTP request

If DNS resolves correctly but the connection itself fails or times out, check:

• Is the target application actually listening on that port, and on the right interface? A common mistake: an application bound to 127.0.0.1 inside its own container (only reachable from within that same container) instead of 0.0.0.0 (reachable from other containers on the network). This is an application-level configuration issue, not a Docker networking problem at all, but it manifests identically as "can't connect."

docker exec api netstat -tlnp
# Confirm it's listening on 0.0.0.0:3000, not just 127.0.0.1:3000

• Is there a firewall rule (host-level iptables, or a cloud security group) blocking the traffic — less common for pure container-to-container traffic on the same Docker network, but worth checking if the setup involves any custom host-level firewall configuration.

Step 4: for "can't reach the internet" specifically, check the host and DNS layers

docker exec my-container ping 8.8.8.8       # test raw IP connectivity, bypassing DNS entirely
docker exec my-container cat /etc/resolv.conf   # check what DNS server the container is configured to use
docker exec my-container nslookup google.com     # test actual DNS resolution to the outside world

• If raw IP connectivity (ping 8.8.8.8) fails, the problem is likely at the host or NAT level. Check that the container's network mode isn't accidentally none, and that the host itself has working internet connectivity with intact NAT/iptables rules. A corrupted or manually-modified iptables ruleset — sometimes caused by other software on the host interfering with Docker's own rules — is a real, though less common, cause here.
• If raw IP connectivity works but DNS resolution to the outside world fails, the problem is specifically in DNS configuration — check what DNS servers the container (and the Docker daemon's own default DNS configuration) are actually using.

The general debugging discipline

Work outward in layers, confirming each one before assuming the next is the problem: (1) are both containers on the same network at all, (2) does name resolution work, (3) does the actual connection succeed once you have a resolved IP, (4) is the destination truly listening where you expect. Skipping straight to complex firewall/iptables debugging without first confirming the basics — same network, actually listening on the right interface — wastes significant time debugging the wrong part of the system. The overwhelming majority of real-world "container can't reach container" issues turn out to be Step 1 or the "listening on 127.0.0.1 instead of 0.0.0.0" application-level mistake, not anything exotic at the networking layer itself.