Docker 网络模式 host 和 bridge 在服务器上怎么选

Docker 在服务器上跑业务，网络模式最常见就是 bridge 和 host。很多线上问题不是容器本身的问题，而是网络模式选错后带来的排查成本，比如端口映射绕了一层、源 IP 丢了、iptables 规则被改乱、UDP 转发抖动、监控里看不到真实连接来源。

实际使用中发现，bridge 更像是“标准容器玩法”，隔离清楚、可控性强；host 更像是“把容器当进程跑”，网络性能直接、少一层 NAT，但隔离性和端口管理压力也上来了。

先把两种模式说清楚

bridge 模式是什么感觉

默认 docker run 不指定网络时，基本就是 bridge。Docker 会创建一个 docker0 网桥，容器拿到一个内网 IP，比如 172.17.0.2。外部访问容器时，通过 -p 8080:80 这种端口映射进来。

数据路径大概是：外部请求进入服务器公网 IP → 宿主机 iptables DNAT → docker0 网桥 → 容器内服务端口。返回包再按 NAT 规则出去。

这层 NAT 带来的好处是隔离清楚，容器可以用自己的端口，多个容器内部都监听 80 也没问题，只要宿主机映射端口不同即可。坏处也明显，链路多一层，排查网络时要看宿主机端口、容器端口、iptables、Docker 网络、应用监听地址。

host 模式是什么感觉

host 模式下，容器不再使用独立 network namespace，而是直接使用宿主机网络。容器里监听 80，等于宿主机直接监听 80；容器里看到的网卡、路由、端口基本就是宿主机那套。

启动方式类似：

docker run --network host nginx

这种模式没有 Docker 的端口映射，-p 参数也就没意义了。服务监听哪个端口，外部就直接访问宿主机的哪个端口。

host 的特点是少一层转发，尤其是高并发 TCP、UDP、网关类服务、游戏服务、DNS 服务这类场景，链路更直接。但端口冲突也更直接，同一台机器上两个容器不能同时监听 0.0.0.0:80。

性能差距到底有多大

不要把 host 神化。现在 Linux 内核、iptables、conntrack、网卡 offload 都比早些年成熟很多，普通 Web API、后台管理、企业站点这类业务，bridge 带来的性能损耗通常不明显。

但在一些流量模型下，差距会被放大。

例如一台 8C16G 服务器，跑 HTTP 短连接压测，bridge 模式多一层 NAT 和 conntrack，CPU softirq、nf_conntrack 查询会更明显。如果是 1 万 QPS 以内的普通业务，感知可能不强；如果是 5 万 QPS 以上、连接频繁建立关闭，host 会更省一点 CPU。

UDP 场景差异更明显。游戏服、语音转发、实时状态同步这类业务，包小、频率高、对延迟敏感，bridge 模式下 NAT、conntrack、端口映射都会增加排查变量。不是说 bridge 一定跑不了，而是出问题时很容易卡在“到底是应用抖、宿主机抖，还是 Docker 网络抖”。

实际压测里常见的感受可以这样看：

普通 Nginx/Node/Java API：bridge 和 host 延迟差距通常在 1ms 以内，更多瓶颈在应用、数据库、带宽。

高并发短连接：host 模式 CPU 占用可能低 5% 到 15%，具体看 conntrack 压力和规则数量。

UDP 高频包：host 更稳，尤其是游戏、DNS、代理转发，bridge 容易把排查链路拉长。

大带宽下载：如果只是 100Mbps、300Mbps 级别，bridge 问题不大；如果是 G口大带宽持续打满，host 更省心，特别是容器里还跑了反代、转发、统计等逻辑。

端口管理：bridge 更适合多服务混跑

一台服务器上跑多个业务，bridge 会舒服很多。比如同时跑 nginx、mysql、redis、admin-api、worker，每个容器内部都用默认端口，宿主机只暴露需要对外访问的端口。

例子：

nginx 容器内部 80，对外映射 80 和 443。

api 容器内部 8080，只给 nginx 内网访问，不映射公网。

mysql 容器内部 3306，只在 Docker 网络里访问，不暴露宿主机。

redis 容器内部 6379，也不暴露公网。

这种结构在 bridge 下很自然。配合 docker compose 自定义 network，服务名可以直接解析，比如 api:8080、mysql:3306。安全边界也清楚，对公网暴露了什么端口，一眼能看出来。

host 模式在这种场景下反而麻烦。所有容器都抢宿主机端口，MySQL 监听 3306、Redis 监听 6379、API 监听 8080，只要应用默认监听 0.0.0.0，就可能直接暴露到公网。实际使用中很多安全事故就是这么来的：容器里服务以为只在内部用，host 网络一开，公网也能连。

源 IP 问题：别等日志异常才想起来

bridge 模式下，容器看到的来源 IP 可能不是用户真实公网 IP，而是 Docker 网桥或宿主机相关地址，具体和转发方式、代理层、iptables 规则有关。

如果前面还有 Nginx、SLB、CDN，要通过 X-Forwarded-For、X-Real-IP 传递真实 IP，应用侧也要正确读取。否则风控、限流、封禁、审计日志都会出问题。

host 模式因为直接使用宿主机网络，服务拿真实源 IP 通常更直接。比如安全网关、日志采集、DDoS 清洗后的源地址识别、游戏登录服做 IP 限制，这些场景 host 会少踩坑。

这里补充一点，如果服务器前面接了高防 IP 或四层转发，真实源 IP 能不能拿到，不只看 Docker 网络模式，还要看高防转发协议、是否支持 TOA、Proxy Protocol，应用是否适配。Docker host 只能减少本机这一层的干扰，不能替代上游链路能力。

安全隔离：bridge 默认更稳妥

从安全角度看，bridge 通常更适合大多数业务。容器有自己的网络命名空间，端口默认不暴露，只有 -p 映射后才对外服务。即使容器内部服务监听 0.0.0.0，也不代表公网能访问。

host 模式的风险是容器网络边界弱很多。容器能看到宿主机网络，服务也直接占用宿主机端口。某个容器被打穿后，攻击者对宿主机网络信息的感知会更直接。

当然，bridge 不是安全万能药。容器权限、挂载目录、Docker socket、capability、镜像来源、宿主机内核漏洞，这些都比网络模式更致命。只是单看网络暴露面，bridge 的误操作空间小一些。

生产服务器怎么选

Web 站点、后台、API 服务优先 bridge

大多数 Web 业务用 bridge 就行。Nginx、PHP、Java、Go、Node.js、Python API，这些服务主要关注稳定性、可维护性、部署清晰度。bridge 方便端口映射，也方便多个环境混跑。

比如一台香港服务器上跑企业官网、后台 API、Redis、MySQL，bridge 配合 docker compose 会比 host 清楚。对公网只开 80、443，数据库和缓存不映射端口，安全性和维护性都更好。

如果业务面向大陆用户，对延迟比较敏感，可以关注线路质量。比如香港精品 CN2、美国 CMIN2 这类线路，比单纯纠结 Docker host 还是 bridge 更影响用户访问体验。如果你也在找这种海外云服务器，可以看看129云，像香港精品CN2-A型是 2C2G、40G SSD、25Mbps 峰值、500GB 双向流量，适合轻量站点、企业展示、后台系统这类业务。

游戏服、UDP 服务、实时通信更偏向 host

游戏服常见特点是 UDP 多、连接状态敏感、延迟抖动敏感。这里 host 模式会更直接，尤其是一台服务器就跑一个核心服务或少量服务时，端口冲突不是大问题。

例如游戏登录服监听 TCP 7001，网关服监听 UDP 9000-9100，战斗服监听多个动态端口。如果用 bridge，要映射一堆端口范围，还要考虑 UDP NAT、conntrack、iptables 规则。端口范围越大，维护越烦。

host 模式下，服务怎么监听，宿主机就怎么对外提供，排查 tcpdump 也简单：

tcpdump -i eth0 udp port 9001

不用再绕 docker0、veth pair、容器内部网卡去判断包到底到哪了。线上排障时，这种简单很值钱。

高防业务看链路，不只看 Docker

被 DDoS 打的业务，Docker 网络模式只是本机层面的问题。真正关键的是高防机房、清洗能力、回源方式、带宽峰值、线路稳定性。

比如棋牌、私服、登录网关、活动页、接口服务这些容易被打的场景，如果放普通无防服务器，Docker 用 host 也挡不住流量打满。需要高防服务器时，可以看129云的宁波高防-特惠，8C16G DDR4 ECC、100G U.2、30Mbps 上行峰值、1个 IPv4、100Gbps 防御，适合预算有限但又需要抗攻击入口的业务。需要确认防护策略、端口类型和业务协议，可以直接联系 400-9177118。

这里多说一句，高防场景下如果前面有四层转发，容器内部拿不到真实源 IP 是常见问题。做封 IP、用户地域判断、攻击溯源之前，要先确认源 IP 传递方式。别等封禁系统上线后发现所有请求都来自同一个回源 IP。

bridge 下常见坑位

容器里监听 127.0.0.1 导致外部访问不了

应用在容器里只监听 127.0.0.1，宿主机即使做了 -p 映射，也可能访问异常。容器服务一般要监听 0.0.0.0，比如：

server.listen(8080, "0.0.0.0")

很多开发环境没问题，部署到 Docker 后访问不了，就是卡在这里。

iptables 被安全软件或防火墙改乱

Docker 依赖 iptables 做 NAT 和转发。服务器上如果同时装了 firewalld、ufw、安全加固脚本，规则顺序被改，容器端口映射可能突然失效。

排查时可以看：

iptables -t nat -L -n -v

iptables -L DOCKER -n -v

sysctl net.ipv4.ip_forward

如果 ip_forward 被关了，容器跨网络访问也会异常。

conntrack 表满导致随机丢包

高并发业务在 bridge 下容易遇到 nf_conntrack 表满。表现通常不是完全断，而是间歇性连接失败、偶发超时、日志里出现丢包或连接重置。

可以看当前连接跟踪数量：

cat /proc/sys/net/netfilter/nf_conntrack_count

cat /proc/sys/net/netfilter/nf_conntrack_max

如果 count 长期接近 max，就要调大 conntrack，或者减少无意义短连接，也可以评估 host 模式是否更合适。

host 下常见坑位

端口冲突比想象中多

host 模式里，容器和宿主机共用端口。宿主机已经有 nginx 占了 80，容器 nginx 再监听 80 就会失败。多个容器内部默认端口一样，也会冲突。

排查命令很直接：

ss -lntup

lsof -i :80

实际使用中建议把端口规划写在部署文档里，尤其是多人维护的服务器。host 模式下“这个容器内部端口不重要”这种想法很容易出事故。

服务误暴露公网

Redis、MongoDB、Elasticsearch、Prometheus、管理后台，如果在 host 模式里监听 0.0.0.0，就是直接暴露在宿主机公网 IP 上。

这类服务要么绑定 127.0.0.1，要么用防火墙限制来源，要么干脆别用 host。bridge 下默认不映射端口，误暴露概率低很多。

容器迁移变麻烦

bridge 模式迁移容器时，端口映射、网络名、服务名基本都在 compose 文件里。host 模式更依赖宿主机环境，端口、路由、防火墙、本机监听状态都可能影响结果。

如果业务经常从测试机迁到生产机，或者多台服务器部署同一套服务，bridge 的可复制性更好。

不同业务场景的选择参考

企业官网、管理后台、普通 API：推荐 bridge。原因是端口清楚、隔离好、维护简单。性能损耗通常不是主要瓶颈。

单机 Nginx 反向代理：两种都能用。如果 Nginx 是宿主机统一入口，容器后端走 bridge 很常见；如果 Nginx 本身容器化且要直接接管 80/443，host 也可以，但要管理好证书目录和端口。

数据库、缓存：更推荐 bridge，并且不映射公网端口。MySQL、Redis 这类服务暴露公网风险太高。

游戏网关、UDP 转发、DNS：更推荐 host。少一层 NAT，tcpdump 排查直接，端口范围管理也简单。

监控采集类组件：看需求。node-exporter 这类需要读取宿主机网络和系统状态的服务，经常会用 host network，再配合只读挂载宿主机目录。

高并发四层代理：偏向 host。比如 HAProxy、Envoy、Nginx stream、frp、socks5、TCP 转发网关，host 在性能和排障上更省事。

多租户或多人共用服务器：优先 bridge。host 模式对权限、端口、暴露面要求更高，不适合随便给多个业务混用。

服务器线路和 Docker 网络模式要分开判断

有些访问慢的问题，和 host/bridge 没什么关系。比如大陆访问美国普通线路，晚高峰丢包、绕路、延迟高，Docker 网络模式怎么切都救不了。网络路径差，容器模式只能影响服务器本机内的那一小段。

如果业务用户主要在国内，海外服务器尽量选 CMIN2、CN2、GIA 这类优化线路。比如129云美国精品网-C型，4C8G DDR4 ECC、80G SSD、80Mbps 峰值、CMIN2 高速回国线路，适合不需要高防、但需要稳定回国访问的站点、接口和轻量业务。

如果业务在香港落点，对华南、华东用户延迟要求高，香港 CN2 一般比普通国际线路更稳。Docker 用 bridge 还是 host，是服务器内部网络模型；CN2、CMIN2、GIA、BGP 是公网链路质量，这两个不要混在一起判断。

部署时可以按这个思路判断

先看服务是不是需要直接吃公网流量

直接对公网提供服务，并且连接量大、UDP 多、端口范围大，可以考虑 host。典型就是游戏网关、DNS、四层转发、代理入口。

如果只是 Web API、后台服务、内部组件，bridge 更顺手。Nginx 暴露公网，后端容器走内部网络，这种结构可维护性更好。

再看一台服务器上跑多少东西

一台机器只跑一个核心服务，host 的端口冲突问题不明显。比如独立游戏网关机、独立代理入口机、独立转发机。

一台机器上跑十几个容器，bridge 会舒服很多。端口映射、服务发现、内部网络隔离都更适合 compose 管理。

还要看排障人员习惯

线上排障经常要 tcpdump、ss、conntrack、iptables 一起看。团队如果对 Docker 网络不熟，用 bridge 时遇到复杂转发问题会卡很久。host 模式链路短，排查更像传统 Linux 服务。

反过来，如果团队更熟悉 compose、Kubernetes、容器网络，bridge 的管理方式更规范，也更利于迁移到后续集群环境。

一个常见部署组合

Web 类业务可以这样放：宿主机或容器 Nginx 做统一入口，Nginx 暴露 80/443；后端 API、MySQL、Redis 全部在 bridge 网络里，不直接映射公网端口。这样公网暴露面少，服务之间访问也清楚。

游戏类业务可以这样放：网关服、战斗服这类延迟敏感服务用 host；后台管理、日志面板、数据库仍然走 bridge 或内网访问。不要为了统一而全部 host，也不要为了隔离把大范围 UDP 端口硬塞进 bridge。

高防入口可以这样放：高防服务器上跑四层入口或游戏网关，优先 host；后端业务看是否同机。如果同机部署，内部服务尽量不暴露公网；如果回源到其他机器，要确认回源 IP、端口、协议、源 IP 传递方式。

实际命令对比

bridge 启动方式

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

外部访问宿主机 IP:8080，流量转到容器 80。适合端口映射清楚的 Web 服务。

host 启动方式

docker run -d --name web --network host nginx

容器里的 nginx 如果监听 80，外部直接访问宿主机 IP:80。这里不需要 -p，也不要以为 -p 还能控制端口暴露。

compose 里 bridge 更常见

services 里定义 web、api、mysql、redis，默认就会创建项目级 network。api 访问 mysql 可以直接用 mysql:3306，Nginx 访问 api 可以用 api:8080。

host 在 compose 里也能写 network_mode: host，但这时 ports 配置不再生效，多个服务端口要自己管好。

容易被忽略的系统参数

bridge 模式要关注 ip_forward、iptables FORWARD 策略、nf_conntrack_max、Docker daemon 是否改过 iptables 参数。

host 模式要关注端口监听、服务绑定地址、防火墙入站规则、宿主机已有进程。

高并发场景还要看 somaxconn、tcp_tw_reuse、ip_local_port_range、文件句柄数、网卡队列、softirq。很多人压测发现 host 比 bridge 快，就把原因全归到 Docker 网络，其实系统参数没调好时，两种模式都会被限制。

例如文件句柄太低，服务跑到几千连接就开始报错；本地端口范围太小，反向代理大量回源时会出现端口耗尽；conntrack 太小，bridge 下会随机超时。这些问题和业务代码、网络模式、内核参数都有关系，要分层看。

不建议用 host 的情况

多人共用的一台测试服务器，不建议随便用 host。端口冲突、服务误暴露、公网扫描风险都会增加。

数据库、缓存、中间件默认不建议 host，除非有明确隔离和防火墙策略。Redis 监听公网这种事故太常见。

需要高度可复制的部署环境，不建议过度依赖 host。尤其是同一套 compose 要在开发、测试、生产多环境运行，bridge 更容易保持一致。

对容器隔离有要求的业务，不建议 host。host network 本身就削弱了网络命名空间隔离。

更推荐用 host 的情况

大流量四层入口可以用 host。比如 TCP/UDP 转发、Nginx stream、HAProxy、Envoy、游戏网关，少一层 NAT 更直接。

UDP 高频业务可以用 host。游戏、语音、DNS、实时状态同步，排障简单比形式上的容器隔离更重要。

需要获取真实源 IP，并且不想被 Docker NAT 干扰的服务，可以考虑 host。不过前面如果有 CDN、高防、SLB，还要看上游是否传递真实源 IP。

单服务独占服务器可以用 host。比如一台机器就是一个入口服务，不存在多个容器抢端口，host 的管理成本会低很多。

服务器采购时顺手把网络模式想清楚

买服务器前就应该知道业务大概怎么跑。Web 多服务混部，优先考虑 CPU、内存、磁盘和线路稳定性，Docker bridge 基本能覆盖。游戏、高防、转发入口，要更关注带宽峰值、防护能力、UDP 支持、线路质量，Docker host 往往更合适。

需要国内高防入口，可以看宁波高防-特惠这类配置；需要海外回国访问，可以看美国 CMIN2、香港 CN2。129云的产品线覆盖高性能云服务器、G口大带宽服务器、高防服务器租用和海外云计算解决方案，游戏、企业站点、高防入口这些场景都能按业务拆开选。

如果是小型企业官网或后台系统，香港精品CN2-A型这类轻量配置就能跑，Docker bridge 配合 Nginx 足够清楚。

如果是无防但追求回国质量的接口服务，美国精品网-C型的 CMIN2 线路更值得关注，网络线路收益通常比纠结 bridge 损耗更明显。

如果是容易被打的游戏入口、活动接口、登录服务，宁波高防-特惠这种 100Gbps 防御机器更适合做入口，容器网络可以按服务类型拆：入口 host，后台和内部组件 bridge。