Containers are fast—until they can’t talk to each other. Most “it works on my machine” issues come down to three things: wrong network, wrong DNS, or wrong ports. This guide fixes all three with a Compose-first workflow, clear driver choices, and a simple troubleshooting kit you can use every day.
How containers really talk (mental model)
A container gets a virtual Ethernet pair (veth). One end stays inside the container. The other end plugs into a Linux bridge on the host. Traffic often goes container → veth → bridge → NAT (iptables) → host NIC → internet. Docker also runs an internal DNS at 127.0.0.11. On a user-defined bridge, containers can resolve each other by service name.
Remember: make a user-defined network to get clean DNS and isolation.
Compose-first quick start
# docker-compose.yml
services:
web:
image: nginx:alpine
ports: [“8080:80”]
depends_on:
db:
condition: service_healthy
networks:
appnet:
aliases: [frontend]
healthcheck:
test: [“CMD”, “wget”, “-qO-“, “http://localhost”]
interval: 10s
retries: 5
db:
image: postgres:16-alpine
environment:
POSTGRES_PASSWORD: example
healthcheck:
test: [“CMD-SHELL”, “pg_isready -U postgres”]
interval: 10s
retries: 5
networks:
appnet:
aliases: [backend]
networks:
appnet:
driver: bridge
Bring it up:
docker compose up -d
docker compose exec web sh -lc “apk add –no-cache bind-tools curl && dig +short db && curl -I db:5432 || true”
You should see an IP for db. That proves service-name DNS works.
Don’t Miss Out: epam interview questions
Other Useful Guides: automation testing interview questions
Pick the right driver (and when)
- User-defined bridge — default for a single host. Use: dev, small prod services, clean DNS, isolation.
- Host — skips NAT; uses host network stack. Use: ultra-low latency proxies, agents. Beware port clashes.
- Overlay — multi-host via VXLAN (Swarm). Use: legacy Swarm. For new clusters, prefer Kubernetes CNI.
- Macvlan / Ipvlan — container gets an L2 presence on your LAN. Use: legacy appliances, strict IP rules. Needs switch/L2 care.
- None — no network. Use: air-gapped jobs, tight debugging.
Ports and DNAT (the common trap)
-p 8080:80 publishes host port 8080 to container port 80 with DNAT.
Fast checks on the host:
ss -lntp | grep 8080
docker ps –format ‘table {{.Names}}\t{{.Ports}}’
If the app only listens on 127.0.0.1, change it to 0.0.0.0 inside the container. If the port is busy, change the left side: 8081:80, not the app port.
Explore More: playwright interview questions
Security you will actually use
- Isolate by network. Put web and db on a private user-defined network.
- Limit egress. DB network should not reach the internet.
- Use least privilege. Avoid –network host unless you must.
- Rootless notes. Some iptables paths differ; test your flows.
Performance that matters
- NAT has a cost at high throughput. For heavy edge proxies, try host networking.
- Macvlan/Ipvlan can help on L2 paths, but profile first.
- Measure, don’t guess:
docker compose exec web sh -lc “apk add –no-cache iperf3 && iperf3 -c db -t 10 || true”
Troubleshooting cookbook (symptom → fix)
- Names don’t resolve. You’re on the default bridge. Use a user-defined one. Check: dig @127.0.0.11 db from a container.
- Connection refused from another container. App bound to 127.0.0.1. Bind to 0.0.0.0.
- Port works locally but not from the internet. Publish the port, check firewall/security groups.
- Host shows no listener. ss -lntp and docker ps to confirm mapping and PID.
- Cross-stack leakage. Separate user-defined networks for each stack; avoid the default bridge.
- Overlay is slow or flaky. MTU/VXLAN mismatch or closed ports. Open 2377/tcp, 7946/tcp+udp, 4789/udp. Tune MTU.
Helpful inspectors:
docker network ls
docker network inspect appnet
docker compose exec web ip route
Real patterns you can ship
- Sidecar proxy: Terminate TLS in a sidecar on the same network as web.
- Egress control: Route all outbound traffic through a tiny proxy container.
- Split DNS: Use aliases so internal names differ from external FQDNs.
You Might Also Like: api automation interview questions
Kubernetes mapping (one screen)
- User-defined bridge → Pod + ClusterIP Service (service-name DNS via CoreDNS).
- Published ports (-p) → NodePort/LoadBalancer/Ingress.
- Overlay multi-host → CNI plugins (Calico, Cilium, Flannel). Move to K8s when you need multi-node discovery, autoscaling, and policy.
FAQs
1. What is Docker networking and why is it important?
Docker networking enables containers to communicate with each other, external services, and the internet. Using the right driver and network type ensures reliability, security, and predictable performance.
2. How do containers communicate inside a Docker network?
A container communicates using a virtual Ethernet pair (veth) that connects to a Linux bridge. Docker’s internal DNS (127.0.0.11) resolves container names on user-defined networks.
3. Which Docker network driver should I use?
Use bridge for single-host setups, host for low-latency apps, overlay for multi-host clusters, and macvlan/ipvlan for L2-level networking. Driver choice impacts performance and isolation.
4. Why are my Docker containers unable to communicate?
Common issues include using the default bridge, incorrect port bindings, services binding to 127.0.0.1 instead of 0.0.0.0, or misconfigured DNS. Creating a user-defined network fixes most issues.
5. How can I troubleshoot Docker network issues quickly?
Use tools like docker network inspect, dig, ss, iperf, and service healthchecks to validate DNS, port mapping, routes, and connectivity.
We Also Provide Training In:
- Advanced Selenium Training
- Playwright Training
- Gen AI Training
- AWS Training
- REST API Training
- Full Stack Training
- Appium Training
- DevOps Training
- JMeter Performance Training
Author’s Bio:
Content Writer at Testleaf, specializing in SEO-driven content for test automation, software development, and cybersecurity. I turn complex technical topics into clear, engaging stories that educate, inspire, and drive digital transformation.
Ezhirkadhir Raja
Content Writer – Testleaf
