Docker网络模式有哪些？bridge、host与none对比

Docker 网络模式决定容器从哪里获得网络命名空间、是否经过网桥转发、端口如何暴露，以及排障时应该观察哪一层。很多访问失败并不是应用没有启动，而是容器运行时选择了不合适的网络模式：开发环境默认 bridge 足够好，性能压测可能倾向 host，安全隔离或离线任务则可能使用 none。

从容器基础学习路径看，网络模式是理解容器运行边界的重要一环。若需要把 Docker 网络与更完整的容器技术体系放在一起理解，可以结合容器技术、容器网络与Docker与容器基础继续阅读。

先理解 Docker 网络模式解决什么问题

容器默认拥有独立的网络命名空间，这意味着容器内部看到的网卡、路由表、监听端口与宿主机并不天然相同。Docker 网络模式本质上是在回答三个问题：容器是否需要独立网络栈，容器之间如何通信，外部流量怎样进入容器。

常见模式中，bridge 是默认选择，Docker 会创建虚拟网桥并把容器接入该二层网络；host 让容器直接使用宿主机网络命名空间；none 则只保留 loopback，不为容器配置对外网络。除此之外 Docker 还有 overlay、macvlan、自定义网络等能力，但在单机入门和多数本地调试中，bridge、host、none 是最需要先掌握的三类。

bridge 模式：默认、隔离、适合多数服务

bridge 模式下，Docker 会将容器连接到 docker0 或用户自定义 bridge 网络。容器获得独立 IP，容器访问外部网络通常通过宿主机 NAT 出口；外部访问容器则需要端口映射，例如把宿主机 8080 映射到容器 80。

docker run -d --name web -p 8080:80 nginx
docker inspect web --format '{{json .NetworkSettings.Networks}}'

bridge 的优势是边界清晰。容器端口不会自动暴露到宿主机，只有显式发布的端口才对外可见；同一自定义 bridge 网络中的容器可以通过容器名通信，便于本地组合多个服务。它的代价是多了一层网络转发与 NAT，排障时需要同时看容器监听、Docker 端口映射、宿主机防火墙和应用访问路径。

host 模式：少一层转发，但隔离也更弱

host 模式不会为容器创建独立网络命名空间，容器直接共享宿主机 IP、端口和路由。运行命令通常如下：

docker run --network host --name metrics-agent my-agent:latest

这种模式适合对网络路径敏感、需要直接监听宿主机端口或采集宿主机网络状态的组件，例如部分监控代理、性能压测工具和本地网络诊断工具。它的关键风险在于端口冲突与隔离减弱：容器内进程监听 80，就等同于宿主机监听 80；多个容器无法同时绑定同一端口；安全策略也不能再简单依赖容器网络边界。

none 模式：断开默认网络，只保留本地回环

none 模式不会把容器接入任何外部网络，只保留 lo。它看似少用，却在安全构建、离线计算、镜像检查、只依赖挂载文件的批处理场景中很有价值。示例：

docker run --network none --rm alpine ip addr

当任务不需要联网时，none 可以减少误访问外部服务、误拉取依赖、误上报数据的风险。缺点也很直接：容器无法访问外部 API，其他容器也无法通过网络访问它。如果应用启动阶段需要 DNS、许可证服务或配置中心，使用 none 会导致失败，需要提前把依赖改成文件注入或环境变量注入。

三种模式怎么选

对大多数应用容器，建议优先选择自定义 bridge，而不是默认 bridge。自定义 bridge 支持更好的服务名解析和网络隔离，便于把一组相关容器放在同一个通信域中。host 应作为明确的性能或网络需求选择；none 应作为明确的隔离需求选择。

排障时按路径而不是按猜测处理

当外部访问容器失败时，可以按“应用是否监听、容器端口是否正确、Docker 是否发布端口、宿主机是否放行、客户端访问地址是否正确”的顺序检查。bridge 模式下重点看 docker ps 的 PORTS 列、docker inspect 中的网络信息以及宿主机防火墙；host 模式下重点看宿主机端口是否被占用；none 模式下首先确认它是否真的应该联网。

docker ps
docker port web
ss -lntp | grep 8080

在面向 Kubernetes 学习时，也建议把 Docker 网络模式与 Pod 网络、Service 暴露方式区分开。Docker bridge 解决单机容器连接问题，而 Kubernetes 的网络模型更强调跨节点 Pod 互通、服务发现和策略治理，可延伸阅读Kubernetes实践与Kubernetes容器专题。

小结：网络模式要服务于访问路径和隔离目标

Docker 网络模式没有绝对优劣，只有是否匹配场景。bridge 适合默认服务运行与开发调试，host 适合需要共享宿主机网络的少数场景，none 适合无需联网且强调隔离的任务。真正可靠的选择方法，是先画清楚访问路径，再确认端口、DNS、安全边界和运维可观测性是否满足要求。

常见问题

Docker网络模式应该优先选 bridge 还是 host？

大多数业务容器建议优先选择自定义 bridge 网络，因为它能保留容器网络隔离、支持服务名通信，并且通过端口映射控制外部暴露范围。host 模式适合监控代理、压测工具或确实需要直接使用宿主机网络栈的场景，但要额外关注端口冲突、权限边界和主机防火墙策略。

none 网络模式是不是只适合测试？

不是。none 模式适合不需要联网的离线任务、构建隔离、镜像检查和安全敏感批处理。它的价值是减少不必要的外部访问面，但前提是应用启动不依赖 DNS、配置中心、许可证服务或外部 API，否则会因为网络不可用而启动失败。

为什么容器端口监听正常但外部仍访问失败？

需要按路径排查：先确认应用在容器内监听正确地址和端口，再看 Docker 是否发布端口、宿主机防火墙是否放行、访问方是否使用宿主机 IP 和映射端口。bridge 模式下还要检查 NAT 与端口映射，host 模式下则重点检查宿主机端口占用。