Docker Containers Can't Connect - Fix the Networking Bullshit

DNS Resolution Failures - Why Everything Breaks

Most Docker networking bullshit starts with DNS. Your containers can ping 8.8.8.8 just fine but somehow "google.com doesn't exist." You get those useless "temporary failure in name resolution" errors even though your host machine works perfectly.

This has broken production for me more times than I want to count. Usually happens when Docker's DNS server gets into a fight with systemd-resolved. Ubuntu's recent versions made this worse - they switched networking stuff around and now Docker's DNS routing breaks in new and creative ways.

Docker containers are supposed to use Docker's internal DNS at 127.0.0.11. But systemd-resolved on the host sometimes forces containers to inherit the host's resolv.conf, which points to 127.0.0.53 instead. Then nothing resolves.

Had this exact thing happen with a Node API container. Could reach the database by IP but couldn't hit external APIs like Stripe. First I spent two hours thinking it was a firewall issue, checked iptables, security groups, the works. Then I thought maybe it was the Stripe API keys, wasted another hour testing different endpoints. Finally realized I should check what DNS the container was actually using - the container's /etc/resolv.conf was pointing to some random systemd bullshit instead of working DNS. Fixed it by adding explicit DNS servers to the compose file, but only after losing half a day to stupid assumptions.

The quick diagnosis:

## Check what DNS servers your container is using
docker exec container_name cat /etc/resolv.conf

## Should show 127.0.0.11, not 127.0.0.53 or random IPs
## If it shows 127.0.0.53, you've got systemd-resolved interfering

The emergency fix:

## Override DNS for immediate relief
docker run --dns=8.8.8.8 --dns=1.1.1.1 your_image

## For docker-compose, add to your service:
dns:
  - 8.8.8.8
  - 1.1.1.1

Docker's DNS docs are useless for the systemd-resolved bullshit - they mention it in one paragraph buried in 'advanced configuration' like anyone reads that far. The official Docker DNS troubleshooting guide covers jack shit about Ubuntu's networking changes. systemd-resolved conflicts are well documented on GitHub but the Docker team doesn't prioritize fixing them. Ubuntu forums are full of workarounds. This is still an active problem in 2025 - just check Reddit for the latest horror stories about containers randomly losing internet access.

Container-to-Container Communication Issues - Why Your Containers Act Like Strangers

Problem symptoms: Your containers are supposed to be on the same network but they act like they've never met. Container A tries to reach Container B using its name and gets "connection refused" or "could not resolve host".

Why this bullshit happens: Docker's default bridge network only supports IP-based communication between containers. You can't just use container names like http://api:8080 - that only works on custom bridge networks. The Docker bridge network documentation hides this shit in "advanced configuration" where nobody reads it until their containers are on fire. Stack Overflow has hundreds of questions about this. Docker Compose networking automatically creates custom networks, which is why it works there but not with docker run. The Container Network Model explains the architecture but doesn't help when you're debugging at 3AM.

Real example from production:

## I tried this first like an idiot
docker run --name db postgres
docker run --name app --link db myapp  # deprecated and I knew it but tried anyway
## Obviously didn't work, spent an hour figuring out why

## Check what network they're actually on (should have done this first)
docker network ls
docker network inspect bridge

The actual solution:

## Create a custom bridge network
docker network create --driver bridge myapp-network

## Connect both containers to it
docker run --name db --network myapp-network postgres
docker run --name app --network myapp-network myapp

## Now container "db" is resolvable from "app"

This shit is documented in the Docker networking guide, but of course it's in "advanced configuration" where you only find it after wasting half your day. Docker Labs networking tutorials have hands-on examples. Kubernetes networking concepts work similarly if you're headed that direction.

Port Mapping Issues - When Docker Says It Worked But It Fucking Didn't

Problem symptoms: You set up port mapping with -p 8080:8080 and Docker says it worked, but when you try to hit it from outside - connection refused. This is Docker networking's favorite way to waste your afternoon.

The real culprit: Your application is binding to 127.0.0.1 instead of 0.0.0.0. When an app binds to localhost inside a container, it's only accessible from within that container's network namespace. Docker can map the port all it wants, but there's nothing listening on the external interface.

Had this exact problem with a Flask API. Worked fine in dev, connection refused in production. Started by restarting the container like five times thinking that would magically fix it. Then spent hours checking AWS security groups, thinking the firewall was blocking it. Tried different ports, thinking there was a conflict. Even wondered if our load balancer was broken. Finally ran netstat inside the container and saw Flask was binding to 127.0.0.1 instead of 0.0.0.0. One line change in the Flask app and it worked. The failed connection retries from our health checks ran up our AWS bill while I was debugging, because of course they did.

Check what your app is actually listening on:

docker exec container_name netstat -tulpn
## Look for 0.0.0.0:8080 not 127.0.0.1:8080

Network security considerations: Cloud platform firewalls (AWS security groups, GCP firewall rules) and local iptables rules can prevent external access to mapped ports.

Debug port mapping issues:

## Check if Docker actually mapped the port
docker port container_name

## Test from the Docker host first
curl localhost:8080

## Then test from container's perspective  
docker exec container_name curl localhost:8080

## Check what's blocking external access
sudo iptables -L -n | grep 8080

Platform differences: Docker Desktop on Windows and macOS uses virtualization layers that can affect port mapping behavior, particularly with WSL2 integration. Docker Desktop for Windows docs explain the virtualization stack. WSL2 integration guide covers the networking quirks. Host networking can provide better performance but sacrifices isolation - only use it when you've actually measured bridge networking as a bottleneck. Docker performance benchmarks show the overhead differences.

Ubuntu 24.04 Networking Changes

Ubuntu 24.04 introduced networking changes that affect Docker container internet connectivity. Common symptoms include:

• Containers can't reach external websites
• DNS resolution fails intermittently
• docker run ubuntu ping google.com fails

The diagnosis:

## Check if systemd-resolved is interfering
systemctl status systemd-resolved

## Check Docker daemon configuration
cat /etc/docker/daemon.json

## Look for DNS conflicts
docker run --rm busybox nslookup google.com

The fix that actually works:

## Edit /etc/docker/daemon.json
{
  "dns": ["8.8.8.8", "1.1.1.1"],
  "fixed-cidr": "172.17.0.0/16"
}

## Restart Docker daemon
sudo systemctl restart docker

This issue broke tons of deployments when Ubuntu 24.04 came out. Containers could reach local stuff fine but external HTTPS requests would randomly fail. I initially thought it was our CDN or some AWS outage, checked the status pages like an idiot. Then I thought maybe our container images were corrupted, rebuilt them from scratch. Tried different Ubuntu versions, different Docker versions, nothing worked. Spent a whole weekend diving into kernel logs and iptables rules before finally finding some random GitHub comment mentioning systemd-resolved conflicts. Once I knew what to look for, the fix was simple, but getting there was pure hell. The Docker docs mention it but don't explain how much it breaks everything. Ubuntu release notes buried the networking changes. Docker Forums have detailed troubleshooting threads. GitHub issues track the ongoing problems.

WSL2 and Docker Desktop Networking - Welcome to Hard Mode

Docker Desktop with WSL2 on Windows is a special kind of hell. Port forwarding just stops working randomly. Containers can't reach Windows host services. Everything breaks after Windows updates. Microsoft and Docker somehow created the most frustrating dev experience possible.

Port forwarding dies after Windows updates or when your machine sleeps. Containers can't reach SQL Server or other Windows services because WSL2 is in its own weird network space. You get random "connection refused" errors that magically fix themselves when you restart Docker Desktop.

Windows-specific debugging:

## Check WSL2 networking
wsl --list --verbose
wsl --status

## Test container to Windows host connectivity
## From inside container, Windows host is accessible via host.docker.internal
docker run --rm busybox ping host.docker.internal

The Windows workarounds:

## For reaching Windows host from container
docker run --add-host=host.docker.internal:host-gateway your_image

## For persistent port mapping issues
## Restart the whole Docker Desktop, not just restart containers

Docker Desktop networking on Windows requires additional configuration for complex networking scenarios.

Production Monitoring: Catching Network Issues Before They Kill You

The metrics that matter:

• DNS query response times (should be < 50ms)
• Container-to-container connection success rates
• External API call success rates from containers

Essential monitoring commands:

## Real-time network connections
docker exec container_name ss -tulpn

## Network interface statistics
docker exec container_name cat /proc/net/dev

## DNS resolution timing
docker exec container_name dig google.com

Most teams don't monitor container networking until it breaks in production at 3AM. Set up alerts for DNS failures and connection timeouts - they're leading indicators that your containers are about to shit the bed completely.

The reality of Docker networking: it works great in development and staging, then mysteriously breaks in production with error messages that tell you nothing useful. When containers can't talk to each other, you need a systematic debugging approach - not random configuration changes and hope.

The next section walks through the exact debugging process that finds the root cause fast when your networking is fucked and management wants answers.

The 3AM Debugging Approach

When Docker networking breaks and everyone's asking when it'll be fixed, you need a systematic way to find what's actually wrong. Not just randomly restarting containers and hoping - though let's be honest, that's usually what I try first.

This is the debugging process I eventually learned after years of flailing around. I used to just restart everything and cross my fingers, but that only works about 30% of the time. The other 70% you need actual debugging, which sucks but here we are.

First Thing: Make Sure Your Containers Aren't Just Dead

Before you waste time on network debugging, make sure your containers aren't just dead. Network issues often mask the real problem - containers crashing silently:

## Check container status - look for restarts or crashes
docker ps -a

## Check resource usage - network issues often mean retry loops eating CPU
docker stats --no-stream

## Get detailed container info including network config
docker inspect container_name | jq '.NetworkSettings'

## Check container logs for network fuckery
docker logs container_name --tail=50

Indicators of non-network issues:

• Frequent container restarts suggest application crashes
• High CPU usage may indicate connection retry loops
• Memory limits can cause crashes that appear as network failures

OK, Containers Are Alive. Now Let's See If Docker's Networking Is Fucked

Confirm Docker's network infrastructure is functioning (or find out why it's not):

## List all Docker networks
docker network ls

## Inspect the specific network your container is on
docker network inspect bridge  # or your custom network name

## Check if containers are actually connected to the expected network
docker inspect container_name | grep -A 10 \"NetworkMode\"

What to verify:

• Container is connected to the right network
• Network subnet doesn't conflict with host/VPN networks
• Network gateway is reachable from container
• No IP address conflicts between containers

Common network configuration errors:

## Container thinks it's on default bridge but it's actually on custom network
\"NetworkMode\": \"myapp-network\"  # Good
\"NetworkMode\": \"default\"        # Probably wrong if you created custom networks

## IP address conflicts (rare but happens with manual IP fuckery)
docker network inspect mynetwork | grep -A 5 \"IPv4Address\"

DNS Resolution - Where Docker Networking Goes to Die

DNS problems are the most common networking issue and will eat your whole day if you don't debug them right. I've wasted way too much time on DNS shit that turned out to be systemd-resolved conflicts. Here's how to test DNS without going insane:

## Test DNS from inside the problematic container
docker exec container_name nslookup google.com
docker exec container_name dig google.com

## Check what DNS servers the container is using
docker exec container_name cat /etc/resolv.conf

## Test resolution of container names (only works on custom networks)
docker exec container_name nslookup other_container_name

## Test Docker's internal DNS directly
docker exec container_name nslookup other_container_name 127.0.0.11

The DNS debugging that actually works:

If external DNS fails, it's probably systemd-resolved being stupid again. Check /etc/resolv.conf - if you see 127.0.0.53 instead of 127.0.0.11, that's your problem. Fix it with --dns=8.8.8.8. Though sometimes I've seen this not work either, and you have to restart the whole Docker daemon. No idea why.

If container names don't resolve, you're probably still using the default bridge network like I did for way too long. Create a custom network: docker network create mynetwork and put your containers on it. This should work immediately, but occasionally I've had to restart containers after moving them to the new network. Docker's weird like that.

If DNS works sometimes but randomly shits itself, your VPN is probably fucking with Docker's routing or systemd-resolved is having another episode. I've spent hours chasing this only to find out someone connected to the corporate VPN and it broke everything. Still haven't figured out a good permanent fix for the VPN issue.

Connectivity Testing - Getting Down to the Basics

Test network connectivity systematically from inside the container:

## Test basic network interface
docker exec container_name ip addr show

## Test default gateway connectivity  
docker exec container_name ip route
docker exec container_name ping $(docker exec container_name ip route | grep default | awk '{print $3}')

## Test external connectivity by IP (bypasses DNS)
docker exec container_name ping 8.8.8.8

## Test specific service connectivity
docker exec container_name telnet target_host target_port
## or with modern containers:
docker exec container_name nc -zv target_host target_port

Port-specific testing:

## Check what ports your application is actually listening on
docker exec container_name netstat -tulpn
## Should show 0.0.0.0:port, not 127.0.0.1:port (if it shows 127.0.0.1, your app is broken)

## Test from outside the container
curl -v localhost:mapped_port

## Test from other containers on same network
docker exec other_container curl -v container_name:port

Docker Network Driver Issues - When Different Drivers Break Different Ways

Different network drivers have different failure modes. Debug by driver type:

Bridge networks (most common):

## Check bridge interface on host
ip addr show docker0
brctl show docker0  # if bridge-utils installed

## Check iptables rules (Docker modifies these)
sudo iptables -L -n | grep docker
sudo iptables -t nat -L -n | grep docker

## For custom bridge networks
docker network inspect custom_network_name | jq '.[0].IPAM'

Host networking troubleshooting:

## Container should see all host interfaces
docker run --network=host --rm busybox ip addr show

## Port conflicts become host port conflicts
netstat -tulpn | grep :port_number

Overlay networks (multi-host):

## Check overlay network status
docker network inspect overlay_network | jq '.[0].Containers'

## Verify VXLAN tunneling (advanced)
sudo tcpdump -i eth0 port 4789  # VXLAN traffic

When Host Network Configuration Fucks Everything Up

Docker networking relies on host networking being configured correctly:

## Check for IP forwarding (required for Docker)
cat /proc/sys/net/ipv4/ip_forward
## Should be 1, not 0 (if it's 0, Docker can't route shit)

## Check for Docker iptables rules
sudo iptables -L DOCKER -n
sudo iptables -t nat -L DOCKER -n

## Look for conflicting network ranges
ip route show
docker network ls --format \"table {{.Name}}	{{.Driver}}	{{.Scope}}\"

Common host configuration problems:

Corporate VPNs: VPN client routes can override Docker networks. Cisco AnyConnect documentation and OpenVPN client configurations commonly cause routing conflicts.

## Check if VPN routes conflict with Docker subnets
ip route | grep 172.17  # default Docker subnet

Cloud instance security groups: AWS/GCP/Azure firewalls block container traffic. AWS Security Groups and GCP Firewall Rules documentation explain configuration.

## This won't show in iptables but blocks external connections
## Check your cloud provider's firewall rules

systemd-resolved conflicts: Common on Ubuntu. systemd-resolved documentation explains the service behavior. Ubuntu networking guide covers Netplan integration.

## Check if systemd-resolved is interfering
systemctl status systemd-resolved
resolvectl status

## Disable if causing problems (controversial but sometimes necessary)
sudo systemctl disable systemd-resolved

Application-Level Bullshit - When Your App Is The Problem

Sometimes the issue isn't Docker networking but how your application uses the network:

## Check what your app is binding to
docker exec container_name lsof -i
## Look for 127.0.0.1:port (bad) vs 0.0.0.0:port (good)

## Check application logs for network-related errors
docker logs container_name | grep -i -E \"(connection|network|timeout|refused)\"

## Test application health endpoints
docker exec container_name curl -f localhost:8080/health || echo \"Health check failed\"

Common application networking mistakes:

• Web servers binding to localhost instead of 0.0.0.0
• Database connections using hardcoded IP addresses instead of container names
• HTTP clients not setting reasonable timeouts
• Applications not handling connection failures gracefully

Advanced Debugging: When Standard Tools Fail

For complex networking issues, these advanced techniques help:

## Packet capture from inside container (nuclear debugging option)
docker exec container_name tcpdump -i eth0 -w /tmp/capture.pcap
docker cp container_name:/tmp/capture.pcap .

## Network namespace debugging (requires privileged access, dangerous)
docker exec --privileged container_name nsenter -t 1 -n -p

Using dedicated network debugging containers:

## Network troubleshooting container with all tools
docker run --rm -it --network container:problematic_container \
  nicolaka/netshoot

## From netshoot container, you can run:
## nslookup, dig, curl, tcpdump, traceroute, etc.

The netshoot container is a lifesaver for debugging - wish I'd found it years ago. It's got every network tool you need. Nicolaka's networking blog has more Docker troubleshooting tips. Docker networking documentation from the official docs. Brendan Gregg's tools for performance analysis are essential for network debugging.

This systematic approach catches 95% of Docker networking issues. The key is not skipping steps - network problems often have multiple contributing factors that only become clear when you check everything in order.

This systematic approach solves most Docker networking problems, but there are still common scenarios and edge cases that trip up even experienced engineers. The next section covers the specific questions I get asked most often - the ones people Google at 3AM when their containers won't connect and they need answers fast.

The Configuration That Prevents Most Problems

Docker networking will break eventually. The question is when and how ready you are. I've spent too many weekends debugging production networking failures to keep doing reactive fixes.

Better to configure things properly up front and avoid most of the common networking problems.

Docker Daemon Configuration That Prevents Common Issues

Many networking issues can be prevented with proper Docker daemon configuration. This /etc/docker/daemon.json configuration addresses common DNS and network routing problems:

{
  "dns": ["8.8.8.8", "1.1.1.1", "8.8.4.4"],
  "dns-opts": ["ndots:2", "timeout:3"],
  "dns-search": [],
  "fixed-cidr": "172.17.0.0/16",
  "bip": "172.17.0.1/16",
  "default-address-pools": [
    {
      "base": "172.20.0.0/12",
      "size": 24
    }
  ],
  "userland-proxy": false,
  "iptables": true,
  "ip-forward": true,
  "experimental": false
}

The Docker daemon configuration documentation covers all available options, but good luck finding the important shit buried in there. Docker daemon.json reference has the complete configuration schema. Docker networking daemon configuration explains network-specific options.

Why each setting actually matters:

• dns: Use reliable external DNS servers to avoid systemd-resolved conflicts
• dns-opts: Short DNS timeout (3 seconds) for faster failure detection
• fixed-cidr: Prevents container network conflicts with corporate VPN subnets
• default-address-pools: Explicit subnet allocation prevents IP conflicts
• userland-proxy: false: Direct kernel networking improves performance
• iptables: true: Required for Docker port mapping functionality

Apply changes:

sudo systemctl restart docker
## This kills all running containers, so plan accordingly

Network Architecture Patterns That Scale

Single-Host Applications:

## docker-compose.yml that prevents common networking issues
version: '3.8'
services:
  web:
    build: .
    ports:
      - "8080:8080"
    networks:
      - app-network
    depends_on:
      - db
    environment:
      - DATABASE_URL=postgresql://db:5432/myapp
    healthcheck:
      test: ["CMD", "curl", "-f", "localhost:8080/health"]
      interval: 30s
      timeout: 10s
      retries: 3

  db:
    image: postgres:15
    networks:
      - app-network
    environment:
      - POSTGRES_DB=myapp
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 30s
      timeout: 10s
      retries: 3

networks:
  app-network:
    driver: bridge
    ipam:
      config:
        - subnet: 172.20.0.0/24

volumes:
  db_data:

Key architectural decisions:

1. Custom bridge network: Enables container name resolution
2. Explicit subnet: Prevents IP conflicts with other Docker networks
3. Health checks: Detect network-related service failures early
4. Environment variables for service URLs: Makes networking configuration explicit

Multi-Host Applications (Docker Swarm):

version: '3.8'
services:
  web:
    image: myapp:latest
    ports:
      - "8080:8080"
    networks:
      - frontend
      - backend
    deploy:
      replicas: 3
      placement:
        constraints:
          - node.role==worker

  api:
    image: myapi:latest
    networks:
      - backend
    deploy:
      replicas: 2

  db:
    image: postgres:15
    networks:
      - backend
    deploy:
      placement:
        constraints:
          - node.role==manager
    volumes:
      - db_data:/var/lib/postgresql/data

networks:
  frontend:
    driver: overlay
    attachable: true
  backend:
    driver: overlay
    internal: true  # No external access

volumes:
  db_data:

Multi-host networking principles:

1. Overlay networks for cross-host communication
2. Network segmentation: Frontend and backend networks
3. Internal networks: Database network has no internet access
4. Service discovery: Works automatically with overlay networks

Application-Level Network Resilience

Your application must handle network failures gracefully. Docker networking will fail eventually - design for it.

Connection Configuration Best Practices:

Web Applications:

// Node.js example - bind to all interfaces, not just localhost
const express = require('express');
const app = express();

// Wrong: Only accessible from inside container
// app.listen(3000, '127.0.0.1');

// Right: Accessible from other containers and host
app.listen(3000, '0.0.0.0', () => {
    console.log('Server listening on all interfaces');
});

// Database connection with retries and proper timeouts
const { Pool } = require('pg');
const pool = new Pool({
    host: process.env.DATABASE_HOST || 'db',
    port: process.env.DATABASE_PORT || 5432,
    user: process.env.DATABASE_USER || 'postgres',
    password: process.env.DATABASE_PASSWORD,
    database: process.env.DATABASE_NAME || 'myapp',
    
    // Critical: Network failure resilience
    connectionTimeoutMillis: 5000,
    idleTimeoutMillis: 30000,
    max: 10,
    
    // Retry on connection failure
    retryAttempts: 3,
    retryDelay: 1000,
});

HTTP Client Configuration:

## Python example - HTTP client with proper timeouts and retries
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

def create_http_client():
    session = requests.Session()
    
    # Retry strategy for network failures
    retry_strategy = Retry(
        total=3,
        status_forcelist=[429, 500, 502, 503, 504],
        backoff_factor=1,
        allowed_methods=["HEAD", "GET", "OPTIONS"]
    )
    
    adapter = HTTPAdapter(
        max_retries=retry_strategy,
        pool_connections=10,
        pool_maxsize=10
    )
    
    session.mount("http://", adapter)
    session.mount("https://", adapter)
    
    return session

## Use environment variables for service URLs
client = create_http_client()
api_base_url = os.environ.get('API_BASE_URL', 'http://api:8080')

try:
    response = client.get(f'{api_base_url}/data', timeout=(5, 30))
    response.raise_for_status()
except requests.exceptions.RequestException as e:
    logger.error(f"Network request failed: {e}")
    # Handle gracefully - return cached data, show error message, etc.

Container Image Network Optimization

Build images that work reliably in networked environments:

## Dockerfile network best practices
FROM node:18-alpine

## Install network debugging tools in development
RUN apk add --no-cache \
    curl \
    dnsutils \
    netcat-openbsd

## Create non-root user for security
RUN addgroup -g 1001 -S nodejs && \
    adduser -S nextjs -u 1001

WORKDIR /app

## Copy and install dependencies
COPY package*.json ./
RUN npm ci --only=production && npm cache clean --force

## Copy application code
COPY --chown=nextjs:nodejs . .

USER nextjs

## Bind to all interfaces, not just localhost
EXPOSE 3000
ENV HOST=0.0.0.0
ENV PORT=3000

## Health check that tests network connectivity
HEALTHCHECK --interval=30s --timeout=10s --start-period=40s --retries=3 \
  CMD curl -f localhost:8080/health || exit 1

CMD ["npm", "start"]

Image networking principles:

1. Bind to 0.0.0.0: Makes service accessible from other containers
2. Include debugging tools: Essential for troubleshooting production issues
3. Health checks: Detect network-related failures early
4. Non-root user: Security best practice that doesn't affect networking
5. Explicit port exposure: Documents network interface

Monitoring and Alerting for Network Health

Set up monitoring before you have problems:

Docker Compose monitoring stack:

version: '3.8'
services:
  cadvisor:
    image: gcr.io/cadvisor/cadvisor:latest
    ports:
      - "8080:8080"
    volumes:
      - /:/rootfs:ro
      - /var/run:/var/run:ro
      - /sys:/sys:ro
      - /var/lib/docker/:/var/lib/docker:ro
    
  prometheus:
    image: prom/prometheus:latest
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - '--config.file=/etc/prometheus/prometheus.yml'
      - '--storage.tsdb.path=/prometheus'
      - '--web.console.libraries=/etc/prometheus/console_libraries'
      - '--web.console.templates=/etc/prometheus/consoles'

  grafana:
    image: grafana/grafana:latest
    ports:
      - "3000:3000"
    volumes:
      - grafana_data:/var/lib/grafana
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=admin

volumes:
  prometheus_data:
  grafana_data:

Essential network metrics to monitor:

• Container network interface errors
• DNS resolution time and failure rate
• Inter-service connection success rate
• External API response times
• Port exhaustion on host

Grafana looks nice but half the dashboards are broken by default. Spent a weekend setting up monitoring and ended up with more alert noise than actual value. Start with simple alerts that matter - not dozens of metrics that spam your Slack at 3AM. Also watch your CloudWatch costs with monitoring, it adds up fast. Grafana dashboards has pre-built options for Docker. Prometheus configuration guide explains metric collection setup. Docker monitoring best practices from Sematext covers what actually matters. cAdvisor documentation explains container metrics.

Prometheus configuration for Docker network monitoring:

## prometheus.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: 'cadvisor'
    static_configs:
      - targets: ['cadvisor:8080']

  - job_name: 'docker-containers'
    docker_sd_configs:
      - host: unix:///var/run/docker.sock

## Alert rules for network issues
rule_files:
  - "network_alerts.yml"

Network alert rules:

## network_alerts.yml
groups:
  - name: docker_network
    rules:
      - alert: ContainerNetworkDown
        expr: up{job="docker-containers"} == 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "Container network is down"
      
      - alert: HighNetworkLatency
        expr: container_network_receive_packets_total{name!=""} > 1000
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "High network traffic on container"

Environment-Specific Network Configuration

Development Environment:

## .env.development
DATABASE_HOST=localhost
API_BASE_URL=http://localhost:8080
REDIS_HOST=localhost

## Use host networking for easier debugging
docker run --network=host myapp

Staging Environment:

## .env.staging  
DATABASE_HOST=db
API_BASE_URL=http://api:8080
REDIS_HOST=redis

## Use custom networks that mirror production
docker network create --driver bridge staging-network

Production Environment:

## .env.production
DATABASE_HOST=db.production.local
API_BASE_URL=https://api.production.com
REDIS_HOST=redis-cluster

## Use overlay networks for multi-host deployments
docker network create --driver overlay production-network

Network configuration management:

• Use environment variables for all service URLs
• Never hardcode IP addresses in application code
• Use DNS names consistently across environments
• Test network configurations in staging that match production

You can't prevent all Docker network issues - the networking stack is too complex. But you can make failures visible and debuggable. Apps that handle network failures gracefully with clear error messages are way easier to maintain than ones that fail silently.

Document your network setup. When production breaks at 3AM and you're trying to remember how containers connect, you'll be glad you wrote it down. Docker networking documentation provides good examples. Architecture decision records help track networking choices.

Docker networking works fine until it doesn't. When it breaks, the error messages usually tell you nothing useful. The difference between experienced and junior engineers is debugging systematically instead of randomly changing stuff until it works. Docker troubleshooting documentation covers the basics. Container networking troubleshooting from Kubernetes docs applies to Docker too.

This covers the debugging process and configuration that actually work in production. Use the systematic approach, configure things properly up front, and set up monitoring before problems hit. Production readiness checklist includes networking security considerations. Docker in production guide covers deployment best practices.