Docker Networking Basics

Docker networking allows containers to communicate with each other, access external services and expose applications to users. Instead of treating every container as an isolated process, Docker provides virtual networks that determine how containers discover and reach one another.

Understanding Docker networking is essential when running web applications, databases, APIs and supporting services together. Once the basic networking model is clear, concepts such as service names, container ports, published ports and network drivers become much easier to understand.

What Is Docker Networking?

Docker networking is the system Docker uses to connect containers and control how network traffic moves between containers, the host machine and external networks. Each container can have its own network interface and IP address while Docker manages the virtual network infrastructure connecting them.

Why Docker Networking Matters

• Allow containers to communicate with each other.
• Connect application containers to databases and caches.
• Expose containerized services to the host machine.
• Control which containers can communicate.
• Connect containers to external networks.
• Separate different application environments.

How Container Networking Works

When Docker starts a container, it can attach the container to one or more Docker networks. Docker creates the necessary virtual networking interfaces and manages communication between containers connected to the same network.

Application Container
        |
        v
Docker Network
        |
        +------> API Container
        |
        +------> Database Container
        |
        +------> Cache Container

The Default Bridge Network

Docker provides a default bridge network for containers when no other network is specified. Containers attached to this network can communicate through Docker's networking system, although user-defined bridge networks provide better service discovery and isolation for most applications.

docker network ls

docker network inspect bridge

User-Defined Bridge Networks

A user-defined bridge network is usually a better choice for applications that contain multiple containers. Docker provides automatic DNS-based service discovery on user-defined networks, allowing containers to communicate using container or service names instead of manually managing IP addresses.

docker network create app-network

docker run -d   --name database   --network app-network   postgres

Container Names and DNS

Containers connected to the same user-defined Docker network can generally reach each other using container names as hostnames. This is especially useful for applications that connect to databases, APIs or caches because the application does not need to know the container's current IP address.

Database container:
database

Application connection:
postgresql://database:5432/app

Container IP Addresses

Docker assigns IP addresses to containers on their connected networks. However, container IP addresses should generally not be treated as permanent identifiers because they can change when containers are recreated. Network names and service names are usually more reliable for application configuration.

Docker Network Drivers

Docker supports several network drivers designed for different networking scenarios. The most appropriate driver depends on whether containers run on one host, across multiple Docker hosts or in a specialized environment.

Bridge Networking

Bridge networking is the most common Docker networking model for applications running on a single host. Containers connected to the same bridge network can communicate through the virtual network created by Docker.

Host Networking

Host networking removes much of the network isolation between the container and the Docker host by allowing the container to use the host's network stack. This can reduce networking overhead in certain scenarios but also reduces isolation and changes how ports are handled.

docker run --network host nginx

None Networking

The none network driver disables normal container networking. It can be useful when a container does not require network access or when networking is intentionally configured manually.

docker run --network none alpine

Container Ports vs Published Ports

One of the most important Docker networking concepts is the difference between a container port and a published host port. A service may listen on port 3000 inside a container without being directly accessible from the host or the public network.

Publishing a Port

The -p option publishes a container port through the Docker host. The host port appears before the container port in the mapping.

docker run -d   --name web   -p 8080:80   nginx

In this example, Nginx listens on port 80 inside the container while port 8080 on the host forwards traffic to that container port. A request to the host on port 8080 can therefore reach the Nginx process.

Exposing vs Publishing Ports

The EXPOSE instruction in a Dockerfile documents the ports that an application is expected to use. It does not publish those ports to the host. Publishing is performed when a container is started or when ports are configured through Docker Compose.

FROM nginx

EXPOSE 80

Container-to-Container Communication

Containers on the same Docker network normally communicate directly using the destination container's service or container name and the port where the application listens inside that container. Host port publishing is not required for communication between containers on the same network.

Web container
    |
    | database:5432
    v
Database container

Docker Compose Networking

Docker Compose simplifies networking for applications containing multiple services. Compose can create a network for the application and connect services to it automatically. Service names can then be used as hostnames between containers.

services:
  web:
    image: nginx
    ports:
      - "8080:80"

  api:
    image: my-api

  database:
    image: postgres

In this example, the services can communicate through the Compose network. The web service is accessible from the host through port 8080, while the API and database do not need published ports simply to communicate with other services.

Custom Compose Networks

Compose also allows applications to define custom networks. This is useful when different groups of services should have separate communication boundaries.

services:
  frontend:
    image: my-frontend
    networks:
      - frontend

  api:
    image: my-api
    networks:
      - frontend
      - backend

  database:
    image: postgres
    networks:
      - backend

networks:
  frontend:
  backend:

Here the API can communicate with both the frontend and database networks, while the database is isolated from services that are connected only to the frontend network.

Network Isolation

Docker networks can be used to limit which services can communicate with each other. Separating frontend, backend and database services into appropriate networks can reduce unnecessary connectivity and make the application's architecture easier to understand.

External Networks

Docker Compose can connect services to an existing Docker network instead of creating a new application-specific network. This is useful when multiple Compose projects need to communicate or when a reverse proxy is shared between several applications.

networks:
  shared-network:
    external: true

DNS and Service Discovery

Docker's internal DNS allows services on compatible networks to locate one another by name. This avoids coupling applications to dynamically assigned IP addresses and makes container replacement much easier during deployments.

Common Networking Architecture

A typical web application might contain a frontend or reverse proxy, an API service and a database. The public-facing service usually publishes a host port, while internal services communicate over private Docker networks.

Internet
   |
   v
Reverse Proxy :443
   |
   v
API Container :3000
   |
   v
Database Container :5432

Testing Container Connectivity

When containers cannot communicate, testing connectivity from inside the container can help determine whether the problem is related to DNS resolution, network membership, ports or the application itself.

docker exec -it web sh

ping database

getent hosts database

A successful DNS lookup confirms that the hostname can be resolved, but it does not necessarily mean that the target application is accepting connections. The destination port and application process must also be checked.

Useful Docker Network Commands

Troubleshooting Docker Networking

• Verify that both containers are attached to the expected network.
• Check the service or container hostname.
• Confirm that the application is listening on the expected internal port.
• Inspect published host ports when accessing a service externally.
• Use docker network inspect to examine network membership.
• Test DNS resolution from inside the container.
• Check application logs for connection errors.

Common Mistakes

• Using localhost to connect from one container to another.
• Confusing host ports with container ports.
• Hardcoding container IP addresses.
• Publishing every internal service to the host.
• Assuming EXPOSE publishes a port.
• Putting unrelated services on the same network.

Best Practices

• Use user-defined networks for multi-container applications.
• Use service names instead of container IP addresses.
• Publish only ports that external clients actually need.
• Keep databases and internal services on private networks.
• Separate services into networks when isolation is useful.
• Document important port mappings.
• Use HTTPS and appropriate network security controls for production traffic.
• Inspect network configuration when troubleshooting connectivity problems.

Frequently Asked Questions

Helpful Docker Networking Tools

A Docker Compose Generator helps create multi-service configurations with networks and port mappings, a Docker Compose Formatter keeps Compose files consistently formatted, a Port Number Lookup helps identify common service ports, an HTTP Port Reference provides a quick reference for web-related ports, and a Ping Command Builder helps construct connectivity testing commands.

Conclusion

Docker networking provides the foundation for communication between containers, the host system and external services. The most important concepts are Docker networks, service discovery, container ports, published ports and network isolation. For most multi-container applications, user-defined networks and service names provide a simple and reliable foundation. By publishing only necessary ports, separating internal services and understanding how Docker handles container-to-container communication, developers can build containerized systems that are easier to operate, troubleshoot and secure.