Yo Motherboard

Should I use Docker bridge mode or host networking for this application?

September 21, 2026 3 answers
Asked by MellowCedar42
I'm running an application in a Docker container that is exposed to Internet users and machines through HTTPS on port 443. The application also needs outbound access to the Internet and to internal systems over many different ports, including FTP, SFTP, and SSH. The Docker host is Red Hat Linux with SELinux and firewalld enabled. It has a Docker bridge interface and a physical network interface. With the default bridge network, the application can generally reach the Internet, but it cannot connect to some internal hosts located on the same subnet as the Docker host. I tried switching the container to host networking and removed the port mappings, as required by host mode. After that, the application could reach hosts on the local subnet, but other internal hosts and the Internet became unavailable, apparently because DNS or routing stopped working. I also tried configuring firewalld to forward traffic between the physical interface and the Docker bridge, but the results were not clear. What is the correct way to choose between bridge and host networking here? Can bridge mode be configured to allow the container to reach all required internal and external destinations without giving up network isolation?
bridge network DNS resolution Docker networking host network mode intranet connectivity network configuration System Operations

Answers

KiteRunner_58
Bridge mode is generally the better default because it preserves isolation and lets Docker manage NAT and DNS. Host mode removes that isolation and also means the container shares the host’s interfaces and ports, so normal port publishing no longer applies. If host mode loses Internet or DNS access, check the host’s routing table, resolver configuration, firewalld forwarding policy, and container application settings instead of assuming host mode will solve the underlying routing issue.
Reply to this answer
QuietMaple19
For several related containers, create a user-defined bridge network and attach the relevant services to it. You can still expose the public HTTPS port through a reverse proxy or explicit port mapping while allowing the application to make outbound connections. If internal hosts need to return traffic to the container, make sure they have a route back to Docker’s subnet, or configure the host firewall/NAT appropriately. A packet capture on the host and on the destination network can show whether packets are being blocked, NATed incorrectly, or simply receiving no return route.
Reply to this answer
BrightOtter7
Host networking usually isn’t necessary for this. Keep the container on a bridge network and publish only the ports that need to accept inbound connections, for example with Docker’s port mapping options. Outbound connections from a bridged container should normally work without mapping every destination port. If some same-subnet hosts are unreachable, investigate routing, firewall rules, return routes, and whether the LAN rejects traffic from Docker’s private subnet rather than switching network modes immediately.
Reply to this answer

Add your answer

Answers are reviewed before publication.

Related Discussions