Docker的bridge和host是什么意思？端口映射到底映射了啥，装Home Assistant那次我才分清

事情起因是表弟的一句提问。他照着我那篇Docker入门往群晖上装容器，qBittorrent装完能进后台，轮到Home Assistant就卡住了：教程里网络那一栏选的是host，没有端口可填，他盯着屏幕问我，这玩意不填端口，等会儿从哪儿进管理页？我当时也答不顺溜。去年我往飞牛里装Home Assistant那晚，是照着官方命令原样抄的host，压根没琢磨为什么。这回被问住了，我把NAS上跑的六个容器挨个翻出来对账，总算把这两种模式掰开揉碎了。

bridge：容器住的是楼中楼，进出都得过门卫

bridge是Docker的默认模式，九成容器闭眼选它就行。它干的事可以这样理解：Docker在你NAS的系统里悄悄装了一台虚拟交换机，名字就叫docker0，管着一个独立网段，默认172.17.0.0/16。每启动一个容器，就相当于在这栋楼里隔出一个带独立门牌的小隔间，qBittorrent可能是172.17.0.2，Jellyfin是172.17.0.3，一人一间，互不打扰。

麻烦在进出。容器要下载种子、要刮削海报，流量出楼时会被门口的NAT门卫换张名片——把源地址从172.17.0.2改写成NAS自己的192.168.31.10，外面的服务器才知道回信寄给谁。反过来，你想从电脑浏览器进qBittorrent的网页后台，流量到了NAS这栋楼就抓瞎了：楼里有一堆隔间，门卫不知道你找哪间。端口映射就是给这个准备的，在NAS外墙上开一扇带编号的窗：电脑访问「NAS的IP:8080」，门卫按登记表把流量转进172.17.0.2的8080，这条登记规则在底层就是一条地址转换记录。

所以装qBittorrent那篇里强调的「左列填NAS端口、右列填容器端口」，左边是外墙窗户的编号，右边是隔间里的门牌，两码事。左边可以随便改高位端口防扫描，右边是容器内部写死的，照抄就行。

host：容器直接住进NAS本人，外墙窗户都省了

host模式就野得多。容器不再隔小间，直接搬进NAS本人这套房子里住，用NAS的IP、NAS的网卡、NAS的端口表。你访问「192.168.31.10:8123」，就是直接敲Home Assistant的门，中间没有门卫、没有登记表、没有任何转手。群晖Container Manager里那个选项写得文绉绉，叫「使用与Docker主机相同的网络」，就是它。

有个细节容易踩：host模式下端口映射那一栏填了也是白填，界面要么灰掉要么直接忽略。我第一次给HA排查端口冲突时，还在映射表里折腾半天，后来才反应过来人家根本不走这条路——容器监听8123，NAS的8123就被它占了，你从局域网任何设备敲NAS的IP加8123，直达。

怎么一眼判断一个在跑的容器用的哪种？界面能看：群晖Container Manager点进容器详情有网络一栏，飞牛Docker的容器详情页也标着。懒办法是从现象反推：映射表里挂着登记记录的，八成bridge；映射栏空着、填NAS的IP却能进管理页的，多半host。我给表弟的就是这个土办法，他翻出自己装HA时那张空映射表，当场就明白了为什么没端口可填。

为什么Home Assistant点名要host：广播喊话过不了门卫

官方安装命令里写死了host，不是随手一选。Home Assistant吃饭的本事之一是自动发现：局域网里的Chromecast、ESPHome固件的传感器、支持AirPlay的音箱，它都是靠mDNS这种「院里喊话」找到的——往组播地址224.0.0.251的5353端口喊一嗓子，设备应答，登记入册。这套喊话机制我之前专门写过，它的命门是广播只活在同一个二层网络里。

bridge模式的问题就出在这。容器住的是172.17段的小隔间，它喊出去的组播包要先过NAT门卫，而NAT干的是一对一转寄明信片的活，面对「喊给全院听」的广播包，它没有对应的登记规则，包就闷在楼里了。结果就是HA装在bridge里能打开网页，但设备发现列表空空荡荡，Chromecast一个都搜不到。官方让用host，就是让HA直接站在院里喊，嗓门能传遍整个家庭网络。同理，飞牛监控套件这种需要发现局域网摄像头的东西，跑在系统层也一个道理。

顺带交代个例外。网上有教程教你在bridge里配avahi反射器，把组播包在两个网段之间来回搬运，理论上能救mDNS。我自己没折腾过这条路，官方文档对这玩法也不支持不推荐，多一层中转多一个出错点。家用场景真到需要HA的那步，直接host是最省心的解，别为了「全容器统一bridge」的洁癖绕远路。

我家六个容器挨个对账：就一个用host

道理讲完，上实物。我把飞牛上跑的六个容器全列出来，模式一目了然：

六个里五个bridge，够说明问题了。判断标准就一条：这个容器需不需要主动去发现局域网里的其他设备。不需要的，网页服务、下载器、书库音乐库，bridge加端口映射，规规矩矩；需要的，家庭自动化中枢、依赖mDNS的发现类服务，直接host，别跟自己较劲。镜像、容器、挂载那三个词是Docker的皮，这两种网络模式才算骨，骨分清了，容器排障就有主心骨。

host的三个代价，选之前心里要有数

host不是白捡的便宜。头一个是端口打架。bridge模式下每个容器有独立小楼，qBittorrent和calibre-web都想用8080也相安无事，各住各的隔间，只是外墙窗户编号别重；host模式下所有容器挤在NAS本人这套房子里，端口表只有一张，两个容器抢同一个端口，后启动的那个直接起不来。装之前先查一眼端口被谁占了，SSH进去一条命令就能看，别等容器反复重启才反应过来。

第二个是安全账。bridge的NAT门卫顺手当了保安，外面只能看见你开的那扇窗；host模式的容器是整面墙都朝家庭局域网敞开，容器监听的每一个端口都直接挂在NAS的IP上。比如qBittorrent这种带着BT监听端口的，走host等于把做种端口也摊在明面上，我家这种容器升级还要抄参数重建的懒人，多一层隔离心里踏实。

第三个是维护习惯的坑。host容器没有端口参数可抄，1118那篇升级五步里的「抄端口映射」对它天然无效，抄参数清单里少了这项，重建时漏想就抓瞎。反过来bridge容器换端口不用动容器，改条映射规则重建一下就完事，灵活得多。

收尾：怎么选，以及一个用得少的第三者

四行情景对号：要发现局域网设备（家庭自动化、投屏类）选host；只是网页管理（下载器、影音书库）选bridge加映射；要看真实客户端IP的（比如AdGuard Home记日志、反代看来源）选host，bridge的NAT会把来源全改成NAS自己；拿不准的，默认bridge，出问题再想host。

还有个macvlan，提一嘴就够：它给容器在家庭局域网里发一个正式IP，比如192.168.31.88，从路由器设备列表看就像台独立设备。听着美，家用场景坑不少，跟路由器握手配置都麻烦，新手别主动碰，知道有这号模式就行。我NAS上那六个容器，五年下来就Home Assistant一个host，剩下的规规矩矩bridge，这套配置到现在没出过网络层面的幺蛾子。选模式这事，一句话收束：让容器老老实实当个网页的，锁楼里；要让它在院里喊话找伙伴的，放出来。