Docker网络模式怎么选才不影响性能

Docker网络模式选错，性能问题通常不是一上来就爆。更常见的情况是：压测看着还行，业务跑一段时间后，连接数上来了，iptables规则多了，conntrack表开始抖，延迟偶发尖刺，排查时又很容易把锅甩给应用、数据库或者公网线路。

实际使用中发现，Docker网络性能主要卡在三个位置：NAT、conntrack、跨主机封装。CPU不是唯一指标，包量、连接数、东西向流量比例、是否要暴露端口，都会影响选择。

先把常见网络模式的性能差异说清楚

Docker常用网络模式大概是 bridge、host、macvlan、ipvlan、overlay、none。这里不按文档顺序讲，按生产里最容易踩坑的地方讲。

bridge 是默认模式。容器通过 veth pair 接到 docker0 或自定义 bridge，再经过 iptables 做 DNAT/SNAT。它的好处是简单、隔离性够用、端口映射方便。代价是多了一层 Linux bridge、veth、iptables、conntrack。单机低并发服务基本感知不到，但高 PPS、小包、短连接密集场景会明显吃 CPU。

host 是容器直接使用宿主机 network namespace，没有 veth，没有 Docker NAT，性能最接近裸机。延迟和 PPS 表现最好，但端口隔离没了，容器里监听 0.0.0.0:80 就是宿主机 80。适合网关、代理、游戏服、音视频转发、高频短连接服务。

macvlan 是让容器像局域网里一台独立机器，有自己的 MAC 和 IP。它绕开 Docker bridge 和 NAT，性能接近 host，同时容器有独立 IP。问题是网络环境要支持，交换机端口、云厂商虚拟网络、安全组策略都可能限制多 MAC。公有云里经常不是想用就能用。

ipvlan 和 macvlan 很像，但 ipvlan 共享宿主机 MAC，容器有独立 IP。它对上游网络更友好一些，特别是 L3 模式，适合大规模容器 IP 管理。但配置复杂度比 bridge 高，排障也更偏网络工程。

overlay 多见于 Swarm、Kubernetes 跨主机网络，比如 VXLAN。它解决的是跨宿主机容器互通，不是为了极致性能。overlay 会有封装开销，MTU 也要特别注意。大包吞吐还好，小包和高连接数场景下延迟会更敏感。

none 就是不给容器网络，适合批处理、离线任务、安全沙箱，性能讨论意义不大。

性能差距大概有多大

不同内核、网卡、CPU、iptables规则数量都会影响结果，下面是常见 x86 云服务器上用 iperf3、wrk、pktgen 压出来的经验区间，不是实验室极限值。

模式 | 吞吐损耗 | 延迟增加 | CPU额外消耗 | 适合场景

host | 接近 0% | 接近 0 | 最低 | 高并发网关、游戏服、代理、转发服务

macvlan/ipvlan | 0% - 5% | 低 | 低 | 容器需要独立 IP，追求接近裸机性能

bridge | 5% - 20% | 中等 | 中等到偏高 | 普通 Web、API、后台服务

overlay | 10% - 30% | 中到高 | 偏高 | 跨主机服务发现、集群内部互通

none | 无网络开销 | 无 | 无 | 离线任务、隔离任务

这里补充一点，吞吐不是唯一指标。1Gbps 大包流量和 1Gbps 小包流量，压力完全不是一个东西。1500 MTU 下，1Gbps 大包大约 8 万多 PPS；如果是 64B 小包，理论 PPS 能到百万级。Docker bridge 下 conntrack、iptables、veth 中断处理都会被放大。

bridge不是不能用，问题通常出在高连接和端口映射

很多线上业务默认 bridge 跑了几年也没事，因为它们是长连接少、QPS 中等、请求包不小。比如普通管理后台、企业 API、CMS、低频任务队列，bridge 的损耗通常可以接受。

真正容易出问题的是短连接密集型服务。比如 HTTP 爬虫出口、API网关、下载分发、WebSocket 握手频繁、TCP代理。bridge 模式下容器访问外网要走 MASQUERADE，外部访问容器端口要走 DNAT，连接状态进入 conntrack。连接数上来后，nf_conntrack 表压力变大，CPU softirq 飙升，表现就是 RT 抖、丢包、偶发 timeout。

如果 bridge 必须用，至少要看这些指标：nf_conntrack_count、nf_conntrack_max、softirq CPU、网卡队列丢包、iptables规则数量、容器 veth 的 RX/TX dropped。很多人只看容器 CPU 和宿主机 Load Average，看不到问题根上。

实际使用中发现，自定义 bridge 通常比默认 bridge 更好管理，DNS、网段、iptables规则都清晰一些。但它不改变 NAT 和 veth 的基本路径，所以别指望换成自定义 bridge 后性能突然接近 host。

host模式适合追性能，但别忽略端口和安全边界

host 模式的性能优势很直接：容器和宿主机共用网络栈，少走一层 veth 和 bridge，也少走 Docker 的端口映射链路。对于高 PPS 或低延迟服务，host 经常是最省心的选择。

例如游戏网关、UDP转发、直播推流接入、TCP代理、VPN网关，这类服务对网络路径非常敏感。bridge 多出来的每一次转发、NAT、conntrack 都可能变成尖峰延迟。host 模式能把变量减少很多。

但 host 的代价也很硬。容器端口直接占用宿主机端口，多个容器不能监听同一个端口。容器内如果服务绑定了 0.0.0.0，就直接暴露到宿主机所有网卡。安全组、防火墙、应用监听地址要重新检查，不能按 bridge 模式的习惯来。

多说一句，host 模式并不等于不安全，但它减少了 Docker 网络隔离。生产里常见做法是：只给入口层、转发层、高性能网络服务用 host，业务后端继续用 bridge 或 Kubernetes CNI 网络。

macvlan和ipvlan看起来很美，云上要先确认网络限制

macvlan 性能接近 host，又能给每个容器独立 IP，听起来很适合高性能场景。但在云服务器上，经常卡在虚拟交换网络限制。很多云厂商不允许一张虚拟网卡后面出现多个 MAC，或者安全组只认主网卡 IP，导致容器能发不能收、ARP异常、跨网段不通。

ipvlan L2/L3 能绕开部分多 MAC 问题，但它对路由规划要求更高。容器 IP 从哪里来，宿主机怎么转发，上游网关是否知道回程路径，这些都要处理。没有网络团队配合时，排障成本比 bridge 高不少。

如果是自建机房、裸金属、IDC专线环境，macvlan/ipvlan 很值得考虑。特别是需要容器独立 IP、又不想走 NAT 的场景，比如多租户代理、游戏分区网关、专线接入节点。

overlay的性能问题经常被MTU放大

overlay 网络的核心问题不是“慢”，而是它多了一层封装。VXLAN 会额外增加大约 50 字节头部，如果底层 MTU 还是 1500，容器里也按 1500 发包，就可能触发分片，或者遇到 PMTUD 被防火墙挡掉后出现黑洞。

这类问题很隐蔽。小请求正常，大响应异常；内网正常，跨可用区异常；curl 偶尔卡住，业务日志只看到 timeout。最后查下来不是应用，也不是公网，而是 MTU。

overlay 场景建议把容器 MTU 调到 1450 或更低，具体看底层网络封装。Kubernetes 里也要看 CNI，比如 Flannel VXLAN、Calico IPIP、Cilium VXLAN/Geneve，各自开销不一样。云上跨主机容器互通时，MTU 是必须压测的项目。

按业务类型选，比按默认配置选靠谱

普通 Web 服务、后台 API、企业管理系统：bridge 可以用。重点不是追极限，而是稳定、隔离、端口映射清楚。单机 1Gbps 以下、QPS不夸张、连接复用做得好，bridge 的损耗通常不值得为了它改架构。

高并发入口、七层代理、四层转发、游戏接入、UDP服务：优先看 host。尤其是 UDP，bridge 下 conntrack 对 UDP 的状态维护很容易制造额外压力。host 能少很多奇怪问题。

容器需要独立 IP，且网络环境可控：看 macvlan 或 ipvlan。独立 IP 方便做访问控制、日志归属、租户隔离，也能避开 NAT。但云上要提前验证，不能等业务切过去再发现安全组不认容器 IP。

跨宿主机容器集群：overlay 或 CNI 网络是常态。性能敏感服务尽量减少跨主机东西向调用，或者把强依赖服务调度到同一节点、同一可用区。overlay 本身不是不能用，但不能拿它当裸机内网用。

离线任务、渲染、批处理：none 或受限 bridge 都可以。没必要让它们暴露网络，少一个入口也少一类风险。

宿主机网络质量会放大Docker网络模式的差异

Docker网络模式只决定容器到宿主机网络栈的路径，宿主机外面的链路质量仍然很关键。比如同样是 bridge 模式，跑在丢包 0.1% 的线路上和跑在稳定低延迟线路上，业务感知完全不一样。容器网络本身的 1ms 抖动，加上公网链路的抖动，很容易变成用户侧 5ms、20ms 的尾延迟。

购买云服务器时，如果业务是代理、下载、游戏、实时通信，不能只看 CPU 和内存。带宽峰值、线路类型、是否三网优化、是否有 DDoS 基础防护、流量计费方式都要一起看。如果你也在找这种高带宽或者低延迟的云服务器，可以看看129云，他们有中国台湾大宽带、香港大宽带-D型、美国精品网-E型这类产品，适合按业务区域和带宽需求做选择，客服热线 400-9177118 可以直接确认线路和防护细节。

举个实际场景：香港大宽带-D型是 16C、16G DDR4 ECC、220G SSD、500Mbps峰值、2TB单向流量，适合香港方向的下载分发、海外业务入口、轻量代理节点。美国精品网-E型是 16C、16G、200G SSD、175Mbps峰值、三网精品，适合面向大陆访问的美国节点。中国台湾大宽带有 1-2Gbps 峰值，适合大带宽测试、边缘分发，但要注意“不保证大陆网络访问”这个条件，别拿它承诺大陆用户体验。

压测时别只看iperf3吞吐

iperf3 能看带宽，但看不全容器网络问题。很多 Docker 网络瓶颈不是纯吞吐，而是连接跟踪、短连接创建、包转发路径、CPU softirq。

压 Web 服务时，建议同时跑 wrk 或 hey，看 P50、P95、P99 延迟。只看平均延迟没意义，网络问题多数体现在 P99。压 TCP/UDP 转发时，可以用 pktgen、trafgen 或真实业务回放，看 PPS 和丢包。压跨主机 overlay 时，要专门测 MTU、大包、小包、长连接、短连接。

监控上至少要看这些命令输出：ss -s、conntrack -S、cat /proc/sys/net/netfilter/nf_conntrack_count、sar -n DEV、sar -n TCP,ETCP、mpstat -P ALL、ethtool -S 网卡名。容器内看不出来时，就回到宿主机看，因为瓶颈多半在宿主机网络栈。

bridge模式下常见调优

bridge 不是一调就能变 host，但可以避免一些明显坑。

nf_conntrack_max 要按连接规模调大，默认值在高并发场景经常不够。hashsize 也要匹配，否则表很大但查找效率不理想。短连接很多时，要关注 TIME_WAIT、端口耗尽和 conntrack timeout。

iptables规则不要无限堆。Docker、Kubernetes、服务网格、主机安全软件都可能写规则，链路变长后每个包都要匹配。规则多到一定程度，性能下降非常直接。nftables 在新系统上更好管理，但迁移前要确认 Docker 版本和发行版兼容。

应用侧能复用连接就复用连接。HTTP keep-alive、连接池、gRPC 长连接，比单纯调内核参数更有效。网络模式只是路径，连接模型才是压力来源。

host模式下的检查项

host 模式部署前要把端口表列清楚，特别是一台机器跑多个容器时。Nginx、Envoy、游戏进程、exporter、sidecar 都可能抢端口。容器重启后端口冲突，Docker 不一定给出很友好的错误。

监听地址要明确。能绑定内网 IP 就别绑定 0.0.0.0，能只监听 127.0.0.1 的管理端口就不要暴露到公网网卡。安全组、firewalld、iptables INPUT 链都要按宿主机维度配置。

日志归属也要处理。bridge 模式下可以通过容器 IP 区分来源，host 模式里容器共享宿主机 IP，日志里要加容器名、实例 ID、业务标签，不然后面排障会很痛苦。

Kubernetes里不要把Docker经验直接照搬

Kubernetes 里 Pod 网络通常由 CNI 接管，Docker 的 bridge 概念不一定直接对应。Calico、Cilium、Flannel、Canal 的路径差异很大。Calico BGP 直路由和 Flannel VXLAN 的性能表现就不是一个级别；Cilium eBPF 绕过部分 iptables 后，在大规模 Service 场景下会比传统 kube-proxy iptables 模式稳很多。

如果 Pod 是性能敏感入口，可以考虑 hostNetwork: true，但它带来的端口冲突、安全边界问题和 Docker host 模式类似。DaemonSet 部署网关、日志采集、节点代理时比较常见，普通业务 Pod 不建议随手开。

Service 访问路径也要看。ClusterIP、NodePort、LoadBalancer、Ingress，每层都可能带来 NAT 或转发。高性能入口服务最好压测真实链路，而不是只压 Pod IP。

比较稳的选择方式

低到中等流量业务，直接 bridge 或默认 CNI，优先保证可维护性。不要为了理论上 5% 的性能差距，把网络搞到团队没人敢碰。

高 PPS、低延迟、短连接密集，优先 host。性能收益明显，排障路径短，但端口和安全要管住。

需要独立 IP，且网络环境允许，考虑 macvlan/ipvlan。上云前先开测试机验证 ARP、回程路由、安全组、抓包结果。

跨主机集群用 overlay 或 CNI 时，把 MTU、P99延迟、东西向流量比例放进压测。服务之间调用频繁，就尽量减少跨节点绕行。

如果一台机器上既有入口转发，又有普通业务容器，常见做法是入口容器用 host，业务容器用 bridge 或 CNI 网络。入口层负责接流量，后端服务走内网连接，性能和隔离都比较容易控制。