When a container cannot reach something, the instinct is often to exec into it and curl. But most slim containers lack curl, dig, tcpdump, or even ping. A better pattern: use nsenter from the host.

Enter the container network namespace

Get the container PID:

docker inspect -f '{{.State.Pid}}' myapp

Then:

sudo nsenter -t PID -n bash

You are now in the container network namespace, but with the host binaries. tcpdump, ip, ss, dig — all work.

Capture traffic on the container veth

Docker creates a veth pair for each container — one side inside the container (eth0), the other on the host (vethXXXX) attached to the docker0 bridge.

bridge link | grep container-id-short
sudo tcpdump -i veth5a3b2c -n

Common failures

  1. DNS not resolving — check /etc/resolv.conf inside the container. Docker usually sets this to the embedded DNS server (127.0.0.11 on user-defined networks).

  2. ICMP blocked but TCP works — many container networks filter ICMP. Use tcptraceroute or hping3 instead of ping.

  3. Container can reach internet but not another container — user-defined bridge network likely not set up, or the other container is on a different network.

iptables counters

Docker injects a lot of iptables rules. To see what is matching:

sudo iptables -t nat -L -v -n
sudo iptables -L FORWARD -v -n

Watch the packet counts before and after testing to see which chain is handling traffic.