What do bridge and host mean in Docker? I only realized what port mapping actually mapped to when I installed Home Assistant

incident started with a question from my cousin. He followed my Docker introduction installed containers on Synology. After installing qBittorrent, it could go to the background, but when it was Home Assistant's turn, it got stuck: in the tutorial, the network section was set to host and had no ports to enter. He stared at the screen and asked me, 'If you don't fill in the ports, where will you enter the management page later?' I couldn't answer smoothly at the time. Last year the night I installed Home Assistant in Feiniu, I copied the host exactly as ordered by the official order, without even thinking about why. This time, I was stumped by the question. I dug through all six running containers on the NAS and checked them one by one, finally breaking down these two modes.

bridge: The container lives in a duplex and has to pass through a gatekeeper to enter and exit

bridge is Docker's default mode; 90% of containers can be chosen with a closed eye. What it does can be understood like this: Docker quietly installed a virtual switch in your NAS system, named docker0, managing a dedicated network segment by default 172.17.0.0/16. Each time you start a container, it's like creating a small compartment with a unique address in the building. qBittorrent might be 172.17.0.2, Jellyfin is 172.17.0.3, one person per room, and they don't disturb each other.

trouble lies in getting in and out. Containers need to download torrents and scrape posters; when traffic leaves the building, the NAT gatekeeper at the door changes its business card—rewriting the source address from 172.17.0.2 to NAS's own 192.168.31.10, so the external server knows who to reply to. Conversely, if you try to access the QBittorrent backend from your computer browser, the traffic will get confused when it reaches the NAS building: there are many compartments inside, and the security guard doesn't know which one you're looking for. Port mapping is designed for this. A numbered window is opened on the NAS exterior wall: the computer accesses "NAS IP: 8080," and the gatekeeper transfers traffic to 172.17.0.2 8080 according to the registration form. This registration rule at the bottom is an address translation record.

so the about installing qBittorrent emphasized "fill in the NAS port in the left column, fill in the container port in the right column"—the left side is the window number, the right side is the door number in the compartment—two different things. On the left, you can freely modify high-level port anti-scanning; on the right, the container is written as fixed internally—just copy it directly.

host: The container is directly installed in the NAS itself, saving the need for exterior walls and windows

host mode is much wilder. Containers are no longer spaced apart; they move directly into the NAS unit, using the NAS IP, NAS network card, and NAS port table. When you visit '192.168.31.10:8123,' you just knock on the Home Assistant's door—no doorkeeper, no registration form, no transfer. The option in Synology Container Manager is written in a fancy way called "Use the same network as the Docker host," which is it.

there's a detail that's easy to miss: in host mode, the port mapping field is filled in blankly, and the interface either turns gray or is simply ignored. The first time I troubled HA port conflicts, I was fiddling with the mapping table for a long time, but later realized they didn't take this path at all—container listening 8123 is taken over by the NAS 8123, and you can tap the NAS IP plus 8123 from any device on the local area network, going directly.

How can

instantly tell which type of running container is used? The interface is clear: Synology Container Manager has a network section for container details, and the Feiniu Docker container detail page is also labeled. The lazy method is to deduce from the phenomenon: the mapping table shows registration records, which is 80% of the bridge; If the mapping bar is empty and the NAS IP is filled in, it can still enter the admin page mostly host. The method I gave my cousin was this simple method. He dug up the empty mapping table he had when installing HA, and immediately understood why there was no port to fill in.

Why does Home Assistant specifically call out hosts: Broadcast calls can't get past the gatekeeper

the official installation command says 'host' is dead, not just randomly selected. One of Home Assistant's skills is automatic detection: Chromecast on the local network, sensors in ESPHome firmware, AirPlay-enabled speakers—all found through mDNS, a "courtyard call"—shout to port 5353 at multicast address 224.0.0.251, the device responds, and the device registers it. I have written about this shouting mechanism before, its flaw is that broadcasts only exist within the same Layer 2 network.

The problem with the

bridge model lies here. The container lives in a small compartment at segment 172.17. Its group broadcast packet must pass through the NAT gatekeeper first, while NAT does one-on-one postcard forwarding. Faced with the broadcast package "shouted to the whole courtyard," it has no corresponding registration rules, so the package is left locked up in the building. The result was that HA installed in bridge could open web pages, but the device found the list empty, and Chromecast couldn't find any of it. The official requirement to use 'host' means HA can stand in the yard and shout, with their voice echoing throughout the entire home network. Similarly, Feiniu monitoring kits, which need to detect LAN cameras, run at the system layer for the same reason.

an exception by the way. There are online tutorials teaching you how to set up an avahi reflector in Bridge, package multicast between two network segments, and transfer back and forth. In theory, this can save mDNS. I haven't tried this route myself, and the official documentation doesn't support or recommend this approach—every extra layer means another mistake. For home use, if you really need HA, hosting directly is the easiest solution—don't take the long route for the sake of 'a unified bridge for all containers.'

my six containers at home were checked one by one: only one was used host

the reasoning is explained, then present the actual items. I've listed all six containers running on Feiniu, making the patterns clear at a glance:

five bridges out of six, that's enough to say something. There is only one criterion for judgment: does this container need to actively discover other devices in the local area network? If you don't need it, web services, downloaders, library and music library, bridge plus port mapping, just follow the rules; If needed, use home automation hubs and mDNS-dependent discovery services—host directly, don't compete with yourself. the words 'image,' container, and mount the Docker skin. These two network models are the backbone. Once the bones are clear, containers have a backbone.

host three costs, be aware before choosing

host wasn't a bargain for free. The first is port conflicts. In bridge mode, each container has its own small building. Both qBittorrent and calibre-web want to use the 8080 but can coexist peacefully, each living in their own compartment, except the window numbers on the exterior walls are different; In host mode, all containers are packed into the NAS itself, and there's only one port table. If two containers compete for the same port, the last one won't start up. Before installing, check who is occupying the port. SSH you can enter with a command see it, so don't wait for the container to restart repeatedly before reacting.

second is the safe account. The NAT gatekeeper at the bridge casually acts as a security guard, and from outside you can only see the window you open; In host mode, the entire wall of a container faces the home local area network, and every port the container listens on is directly attached to the NAS IP. For example, qBittorrent has a BT listening port. Hosting is like exposing the production port to the open. For lazy people like me who have to copy parameters to rebuild container upgrades, having to build up the adds an extra layer of isolation and peace of mind.

third is the pitfall of maintaining habits. The host container has no port parameters to copy. The 'port mapping' mentioned in the five-step upgrade in 1118 naturally doesn't work on it. It's missing this from the parameter copying list, so it's easy to overlook it during rebuild. Conversely, when switching ports in a bridge container, you don't need to change the container; you just rebuild the mapping rules and it's much more flexible.

Conclusion: How to choose, and a third party who is used less often

Four-line scenario matching: To find LAN devices (home automation, screen casting), select host; For webpage management (downloader, audio-visual library), choose bridge plus mapping; You need to look at the real client IP (for example, AdGuard Home logging, reverse proxy source to check the source). Choose the host. Bridge's NAT will change all sources to the NAS itself; If you're unsure, just default to bridge; if something goes wrong, then consider hosting.

there's also Macvlan, which is easy to mention: it sends a formal IP to the container within the home LAN, such as 192.168.31.88, which looks like a standalone device from the router device list. Sounds beautiful, but there are plenty of pitfalls in home scenarios. Even the setup with the router is troublesome. Beginners shouldn't try it proactively—just know this mode is enough. Of the six containers on my NAS, after five years it's just Home Assistant as one host, and the rest are just proper bridges. This setup hasn't caused any network-level trouble so far. When it comes to choosing a mode, it can be summed up in one sentence: let containers obediently serve as web pages, lock them in the building; He had to let it call out to its mates in the yard and release it.