The most surprising thing about Docker networking is that host mode doesn’t actually use Docker networking at all; it just hijacks the host’s network stack.
Let’s see what that looks like in practice. Imagine you have a simple web server running in a Docker container.
First, the standard bridge mode.
# Build a simple Python web server image
cat <<EOF > Dockerfile
FROM python:3.9-slim
RUN pip install Flask
COPY app.py /app/app.py
CMD ["python", "/app/app.py"]
EOF
cat <<EOF > app.py
from flask import Flask
app = Flask(__name__)
@app.route('/')
def hello_world():
return 'Hello from Docker!'
if __name__ == '__main__':
app.run(host='0.0.0.0', port=5000)
EOF
docker build -t my-web-app .
Now, run it in bridge mode:
docker run -d -p 8080:5000 --name web-app-bridge my-web-app
In this scenario, Docker creates its own private network (usually docker0 on Linux). The container gets its own IP address on this private network (e.g., 172.17.0.2). The -p 8080:5000 flag tells Docker to map port 5000 inside the container to port 8080 on your host machine. So, you’d access it via http://localhost:8080.
Now, let’s try host mode:
docker run -d --network host --name web-app-host my-web-app
Notice there’s no -p flag. When you run a container in host mode, it doesn’t get its own IP address. It shares the host’s network namespace. This means the container’s applications bind directly to the host’s network interfaces. If your app.py is listening on port 5000 (as it is), it will bind to port 5000 on your host. You’d access it via http://localhost:5000.
The fundamental problem host mode solves is isolation. When you run in bridge mode, Docker provides network isolation for your containers. Each container has its own IP address, and you explicitly control port mapping to expose services. This is the default and recommended mode for most applications because it prevents port conflicts and keeps your containers’ network environments separate from the host and from each other.
host mode, on the other hand, completely bypasses Docker’s network isolation. It’s like running the application directly on your host machine, but packaged in a container. This is useful when you need maximum network performance (no NAT overhead from Docker’s bridge) or when the application must bind to specific host interfaces or ports that are difficult to manage with port mapping (e.g., certain network monitoring tools, or applications that expect to see the host’s IP address). However, it comes at the cost of losing network isolation, meaning you can easily have port conflicts if multiple containers (or the host itself) try to use the same port.
When using host mode, the container’s view of the network is identical to the host’s. If you run ip addr inside a container in host mode, you’ll see the same interfaces and IP addresses as you would on the host machine. The container doesn’t have its own eth0 interface managed by Docker; it is the host’s eth0. This direct access means applications inside the container can bind to any port on the host that isn’t already in use, and they will appear on the host’s IP addresses.
The major trade-off is that you lose the ability to run multiple containers that need to expose the same port. If you have two containers in host mode both trying to listen on port 80, only one will succeed, and the other will fail with an "address already in use" error, just as if you were running two applications directly on the host. You also lose the ability to easily limit or inspect network traffic to/from individual containers using Docker’s networking features, as the traffic is indistinguishable from the host’s traffic.
If you’re building a complex microservice architecture, bridge mode is your default. You’ll use docker network create to build custom bridge networks for your services to communicate privately, and then use -p flags to expose only the necessary ports to the outside world. host mode is for specific, often performance-critical or low-level networking scenarios where the isolation provided by bridge mode is a hindrance rather than a benefit.
When you run a container in host mode, any network traffic originating from that container is indistinguishable from traffic originating from the host itself. This means that any firewall rules or network policies applied to the host machine will also affect the container’s network traffic, and vice-versa.