---
title: Container Networking
description: Overview of Docker container networking modes and practical networking patterns
tags:
  - containers
  - docker
  - networking
category: containers
created: 2026-03-14
updated: 2026-03-14
---

# Container Networking

## Introduction

Container networking determines how workloads talk to each other, the host, and the rest of the network. In Docker environments, understanding bridge networks, published ports, and special drivers is essential for secure and predictable service deployment.

## Purpose

This document explains how container networking works so you can:

- Choose the right network mode for a workload
- Avoid unnecessary host exposure
- Troubleshoot service discovery and connectivity problems
- Design cleaner multi-service stacks

## Architecture Overview

Docker commonly uses these networking approaches:

- Default bridge: basic isolated network for containers on one host
- User-defined bridge: preferred for most application stacks because it adds built-in DNS and cleaner isolation
- Host network: container shares the host network namespace
- Macvlan or ipvlan: container appears directly on the physical network
- Overlay: multi-host networking for orchestrated environments such as Swarm

## Network Modes

### User-defined bridge

This is the normal choice for single-host multi-container applications. Containers on the same network can resolve each other by service or container name.

Example:

```bash
docker network create app-net
docker run -d --name db --network app-net postgres:16
docker run -d --name app --network app-net ghcr.io/example/app:1.2.3
```

### Published ports

Publishing a port maps traffic from the host into the container:

```bash
docker run -d -p 8080:80 nginx:stable
```

This exposes a service through the host IP and should be limited to the ports you actually need.

### Host networking

Host networking removes network namespace isolation. It can be useful for performance-sensitive agents or software that depends on broadcast-heavy behavior, but it increases the chance of port conflicts and broad host exposure.

### Macvlan or ipvlan

These drivers give a container its own presence on the LAN. They can be useful for software that needs direct network identity, but they also bypass some of the simplicity and isolation of bridge networking.

## Configuration Example

Compose network example:

```yaml
services:
  reverse-proxy:
    image: caddy:2
    ports:
      - "80:80"
      - "443:443"
    networks:
      - edge

  app:
    image: ghcr.io/example/app:1.2.3
    networks:
      - edge
      - backend

  db:
    image: postgres:16
    networks:
      - backend

networks:
  edge:
  backend:
    internal: true
```

In this pattern, the database is not reachable directly from the host or external clients.

## Troubleshooting Tips

### Container can reach the internet but not another container

- Verify both containers are attached to the same user-defined network
- Use container or service names rather than host loopback addresses

### Service is reachable internally but not from another host

- Confirm the port is published on the host
- Check host firewall rules and upstream routing

### Random connectivity issues after custom network changes

- Inspect network configuration with `docker network inspect <name>`
- Check for overlapping subnets between Docker networks and the physical LAN
- Restart affected containers after major network topology changes

## Best Practices

- Use user-defined bridge networks instead of the legacy default bridge where possible
- Publish only reverse proxy or explicitly required service ports
- Keep databases and internal backends on private internal networks
- Avoid `network_mode: host` unless there is a clear technical reason
- Document custom subnets to avoid conflicts with VPN and LAN address plans

## References

- [Docker: Bridge network driver](https://docs.docker.com/network/drivers/bridge/)
- [Docker: Networking overview](https://docs.docker.com/engine/network/)
- [Docker: Published ports](https://docs.docker.com/get-started/docker-concepts/running-containers/publishing-ports/)