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 common root cause: one container was started with --network my-network, and the other with no network flag at all, so it landed on the default bridge instead. They're on two different, unconnected networks. No amount of DNS or firewall troubleshooting fixes that — they need to be on the same network.

Step 2: test DNS resolution 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 running. If it does resolve, name resolution is fine, so look at the connection itself 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 but the connection still fails or times out, check:

• Is the target app actually listening on that port, and on the right interface? A common mistake: an app bound to 127.0.0.1 inside its own container, reachable only from within that container, instead of 0.0.0.0, which other containers on the network can reach. This is an application-level bug, not a Docker networking problem — but it looks identical to "can't connect."
  Copy

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

• Is a firewall rule blocking the traffic — a host-level iptables rule or a cloud security group? Less common for container-to-container traffic on the same Docker network, but worth checking if there's custom host-level firewall configuration.

Step 4: for "can't reach the internet," 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 via 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 has working internet with intact NAT/iptables rules. A corrupted or manually-modified iptables ruleset — sometimes caused by other software on the host — is a real, if less common, cause.
• If raw IP connectivity works but DNS to the outside world fails, the problem is specifically DNS configuration. Check what DNS servers the container, and the Docker daemon's own default config, 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 connection succeed once you have a resolved IP?
4. Is the destination actually listening where you expect?

Skipping straight to firewall/iptables debugging, before confirming the basics, wastes time on the wrong part of the system. Most 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" mistake — not anything exotic at the networking layer.