很多人第一次深入 Docker 网络时，都会被同一个问题拦住：Docker 默认使用哪种网络驱动？标准答案是 bridge，但如果你只记住了这个答案，接下来的防火墙配置、端口映射、容器断网排查依然会让你一头雾水。因为 bridge 之所以能"开箱即用"，靠的不是 docker0 这个虚拟网桥本身，而是 Docker 启动时悄悄写入 iptables 的那几十条规则。这篇文章我会以防火墙为视角，把默认驱动的原理、iptables 的交互方式、常见冲突场景和排障思路完整讲一遍。适合被容器端口映射困惑过的开发者、被 firewalld 重启搞崩过网络的运维，以及想给 Docker 做安全加固的同学。
1. 默认驱动是 bridge：结论背后的四层原因
1.1 五种驱动里，只有 bridge 做到了零配置和好隔离
Docker 一共有 bridge、host、none、overlay、macvlan 五种常用网络驱动（ipvlan 和第三方插件这里先不展开）。官方把 bridge 定为默认，不是因为别的驱动不好，而是因为只有它同时满足了"零配置、能隔离、可互通、可映射端口"这四个条件。我们先看一张对比表，心里有个全局印象：
| 驱动 | 隔离性 | 外部访问方式 | 上手难度 | 典型场景 |
|---|---|---|---|---|
| bridge | 容器隔离在虚拟网桥内 | 通过端口映射访问 | 低 | 单机多容器部署（默认） |
| host | 无隔离，共享宿主机网络栈 | 直接占用宿主机端口 | 低 | 对网络延迟极其敏感的场景 |
| none | 完全隔离 | 无外部网络 | 低 | 离线任务、只需要回环的场景 |
| overlay | 跨主机虚拟网络 | 通过网关和端口暴露 | 高 | Swarm 或跨主机集群 |
| macvlan | 容器直接使用物理网段 | 在局域网内分配独立 IP | 中 | 容器需要像独立主机一样接入局域网 |
host 驱动其实网络性能最好，因为容器直接复用宿主机网络栈，没有 NAT 转换，也没有虚拟网桥的转发开销。但它的问题也很致命：隔离性几乎为零。容器里不小心监听 0.0.0.0:3306，和宿主机自己跑了个数据库没有任何区别，安全上很难接受。none 驱动适合不需要网络的离线任务，但通用性太差。overlay 和 macvlan 不是不好，而是依赖条件偏多：overlay 需要一套键值存储来做网络元数据同步，macvlan 得先和网管协调好 IP 段和 VLAN，在单机开发环境里纯属杀鸡用牛刀。所以 Docker 把 bridge 定为默认，并不是一个随意的决定。
1.2 docker0 是一台虚拟交换机，不是一张网卡
很多人画 Docker 网络拓扑时，会把 docker0 画成一张"虚拟网卡"，这个理解不能说完全错，但会误导你对数据流向的判断。docker0 本质是一个 Linux bridge，也就是一台运行在宿主机内核里的虚拟二层交换机。宿主机上每个默认 bridge 网络的容器，都有一对 veth 虚拟网线：一头是容器里的 eth0，另一头插在 docker0 这个虚拟交换机上。容器和容器之间、容器和宿主机之间，都通过这台交换机交换数据帧，整个过程不出宿主机，物理网卡根本不参与。
默认 docker0 的网段是 172.17.0.0/16，网关就是 docker0 自己的地址 172.17.0.1。如果你用 docker network create 创建自定义 bridge 网络，Docker 会分配另一个网段，比如 172.18.0.0/16。这个网段信息在防火墙规划时特别重要，后面讲冲突排查时会反复用到。你可以用 ip addr show docker0 和 brctl show 直接查看网桥信息，这是排查一切网络问题的第一步。
这里再强调一个容易忽略的点：bridge 是二层设备，它本身不关心 IP、不关心端口。真正决定"容器能不能去外网、宿主机 8080 端口怎么转发到容器 80"的，是内核里的路由表和 iptables 规则。可以这样类比：docker0 是十字路口，路由表决定该往哪个方向走，iptables 是站在路口的交警，决定放行还是拦截。而 Docker 的灵性之处在于，它启动时会自动把交警安排好，不需要你手动插一句嘴。
1.3 默认 bridge 与自定义 bridge：同一套转发逻辑
如果你用 docker run 不指定 --network，容器进的是 docker0；用 docker-compose 且不写 networks 字段，默认也会为整个 compose 项目创建一个自定义 bridge 网络。两者最大的区别是：自定义 bridge 网络自带 DNS 解析，容器之间可以通过服务名互相访问，而默认 docker0 只能靠 IP。但在 iptables 层面，它们的表现几乎一样——都走 FORWARD 链、都拥有一条独立的 MASQUERADE 规则。所以后面讲的所有排查方法，对默认和自定义 bridge 网络一样适用。
还有一点，Docker 会在 nat 表和 filter 表里为每个 bridge 网络各维护一套规则。如果你机器上既有 docker0 又有多个自定义网络，执行 iptables -t nat -L POSTROUTING -n 会看到好几条 MASQUERADE，别觉得奇怪，每条对应一个网桥网络。搞清楚这个前提，就不会在遇到多条相似规则时手忙脚乱。
2. iptables 接管网络的五个关键位置
2.1 Docker 动了 filter 和 nat 两张表
默认情况下，Docker daemon 启动时并不会去碰你的 INPUT 链，它重点维护的是 filter 表和 nat 表。具体来说，它会在 filter 表的 FORWARD 链上挂两条子链，并在 nat 表的关键位置写入跳转规则，整套体系可以拆成下面几类：
- filter 表 FORWARD 链：策略设置为 DROP（新版本 Docker 会这样做），然后在链首插入跳转到 DOCKER-USER 和 DOCKER 链的规则
- filter 表 DOCKER 链：放行转发到容器 IP 的流量，每条端口映射对应相关放行规则
- filter 表 DOCKER-USER 链：专门留给用户自定义规则，Docker 重启不会清空
- nat 表 PREROUTING 链：跳转到 DOCKER 链，处理外部进来的 DNAT
- nat 表 OUTPUT 链：跳转到 DOCKER 链，处理宿主机本机访问容器映射端口的流量
- nat 表 POSTROUTING 链：写入 MASQUERADE 规则，实现源地址伪装
- nat 表 DOCKER 链：具体的 DNAT 规则，每一条端口映射对应一条
从整体看，Docker 的 iptables 逻辑可以概括成一句话：进来先 DNAT，转发先检查 DOCKER-USER，再检查 DOCKER，出去统一 MASQUERADE。理解这句话，比背下任何一条具体规则都重要。
2.2 外部流量访问容器映射端口的完整路径
假设你执行 docker run -p 8080:80 -d nginx，宿主机公网 IP 是 203.0.113.10，容器 IP 是 172.17.0.2。外部客户端访问 http://203.0.113.10:8080 时，数据包在内核里的旅程是这样的：
- 数据包进入宿主机物理网卡，首先经过 nat 表 PREROUTING 链
- PREROUTING 里的规则跳转到 DOCKER 链，DOCKER 链中的 DNAT 规则把目标地址 203.0.113.10:8080 改写为 172.17.0.2:80
- DNAT 完成后，内核查路由表，发现目标 172.17.0.2 走 docker0
- 数据包进入 filter 表 FORWARD 链，先检查 DOCKER-USER 链（用户规则放行后），再进入 DOCKER 链，DOCKER 链里有对应 ACCEPT 规则
- 数据包从 docker0 发出，POSTROUTING 链对来自 172.17.0.0/16 且目标不是 172.17.0.0/16 的流量做 MASQUERADE，源地址被伪装成 172.17.0.1
- 容器的响应包按 conntrack 记录原路返回，NAT 逆转换把源地址从 172.17.0.2:80 还原成 203.0.113.10:8080
注意第 4 步，FORWARD 链的策略虽然是 DROP，但这不影响正常流量，因为 DOCKER 链里有针对容器 IP 的 ACCEPT。这也是为什么很多人把 FORWARD 策略改成 DROP 后，容器端口映射依然能用的原因——Docker 早已把放行规则写好了。
2.3 容器访问外网的完整路径
容器向外部发起连接时，路径是反向的：数据包从容器 eth0 发出，到 docker0，内核查路由表发现目标不在本机直连网段，于是走默认路由转发到物理网卡。这一步能走通有一个先决条件：net.ipv4.ip_forward=1，也就是内核允许转发。Docker 启动时如果发现这个值是 0，会主动把它改成 1。
数据包进入 FORWARD 链时，Docker 在 DOCKER 链里同样准备了放行规则：来自容器网段且属于新连接或已建立连接的数据包会被 ACCEPT。然后到 POSTROUTING，MASQUERADE 规则把源地址 172.17.0.x 伪装成宿主机出口 IP，外部服务器看到的就是宿主机 IP 在访问。响应包回来时，根据 conntrack 表逆转换成容器的源地址。整个链路里，最容易被防火墙搞坏的不是 NAT 规则，而是 FORWARD 链上对 DOCKER 链的引用——一旦 FORWARD 链被清空或策略被改动，转发就断了。
2.4 规则的生命周期：只在特定时机重建
理解规则的生命周期，是排查"重启防火墙后容器断网"的关键。Docker 只在 daemon 启动时、以及创建或删除网络、启动或停止容器时，对 iptables 做增量更新。它不会定期检查规则是否还在。因此，如果某个外部工具在 Docker 启动之后把 iptables 规则清空了（firewalld 重启、ufw reload、手动 iptables -F），Docker 完全无感知，直到你手动 systemctl restart docker，它才会重新把整套规则补齐。这个"无感知"特性，是后面所有坑的根源。
3. 防火墙与 Docker 冲突的三个真实场景
3.1 场景一：重启 firewalld 后容器集体断网
这是我在生产环境里遇到频率最高的故障。某次例行维护，同事在宿主机上执行了 systemctl restart firewalld，随后监控立刻报警：业务容器的健康检查失败。上去一看，容器进程都活着，docker ps 完全正常，但容器内经 curl 访问外部接口全部超时，宿主机访问容器映射端口也不通。
刚开始容易怀疑是应用挂了，但容器日志里一片安静。用 iptables -t nat -L POSTROUTING -n -v 一看，Docker 写的 MASQUERADE 规则不见了；再看 iptables -L FORWARD -n，DOCKER 链的引用也没了。原因很清楚：firewalld 重启时会重新加载自己的规则集，把 filter 表和 nat 表里非自己管理的规则清掉，Docker 写入的规则被一锅端。这个问题在 Docker 以传统 iptables 方式管理规则时尤其典型，社区里相关的求助帖非常多。
解决办法分两个层次。故障现场最直接的是 systemctl restart docker，让 daemon 重新生成规则；但那台机器上跑着几十个容器，重启 Docker 意味着所有容器网络栈重建，业务中断时间不可控。所以后来我养成了个习惯：重启 firewalld 之前，先备份一份 iptables 状态；如果发现 Docker 规则丢了，用 iptables-restore 快速恢复，而不是盲目重启 Docker。对于个人开发机，直接重启 Docker 是省事的；对于生产环境，一定要在维护窗口里操作，或者提前规划好 firewalld 与 Docker 的共存方案。
3.2 场景二：ufw 把 FORWARD 策略改成 DROP 导致端口映射失效
如果你用的是 ufw，问题往往是另一种形态。ufw 默认会把 filter 表 FORWARD 链的策略设为 DROP，而 Docker 端口映射的流量必须经过 FORWARD 链。当 ufw enable 之后，外部过来的访问包走到 FORWARD 链，策略是 DROP，直接被丢进黑洞，表现为端口映射不通。
这类问题的排查思路是：iptables -L FORWARD -n 看到策略是 DROP 且 DOCKER 链没有被引用或不在生效位置，基本可以确定是 ufw 干的。修复办法有两个层次：临时做法是把 /etc/default/ufw 里的 DEFAULT_FORWARD_POLICY 从 DROP 改成 ACCEPT，然后 ufw reload；长期做法是在 ufw 里显式放行 docker0 网段相关的转发流量。注意，改 DEFAULT_FORWARD_POLICY 会影响所有转发流量，如果你还有别的用途依赖 FORWARD 链做限制，得想清楚再改。这种"策略级"问题比"规则级"问题更隐蔽，因为它不需要任何规则冲突，只要默认策略是 DROP，一切转发就都断了。
3.3 场景三：规则写在 DOCKER 链里，Docker 一重启就消失
有些同学想给容器端口加白名单，图省事直接 iptables -I DOCKER 1 -p tcp --dport 80 -s 某个IP -j ACCEPT。当时测是通的，效果也符合预期。但某天维护时重启了 Docker，白名单规则没了，所有来源 IP 又能访问容器了。原因在于 DOCKER 链是 Docker 自己维护的"私有领地"，每次 daemon 启动、网络重建时都会 flush 后重建，用户写进去的规则对 Docker 来说只是临时寄生，随时可能被清掉。
正确的落点只能是 DOCKER-USER 链。这条链从名字就能看出来，是 Docker 专门留给用户的自定义区域。它在 FORWARD 链里的调用顺序排在所有 Docker 自动规则之前，也就是说，你在 DOCKER-USER 里的 DROP 或 REJECT 优先于 DOCKER 链的 ACCEPT 生效，而且 Docker 重启不会清空它。它唯一的缺点是文档里着墨不多，很多人压根不知道这条链的存在。
3.4 场景四：在 INPUT 链上限制容器端口为什么无效
还有一个经常让人困惑的误区：有人习惯用 iptables -I INPUT -p tcp --dport 8080 -j DROP 来限制容器映射端口，然后发现完全拦不住。这是因为容器端口映射的入站流量走的是 PREROUTING → FORWARD → POSTROUTING 这条转发路径，根本不经过 INPUT 链。INPUT 链只管发给宿主机本机的数据包。数据包到达宿主机后，目标地址被 DNAT 成容器 IP，内核把它判定为"需要转发"而不是"本机接收"，所以它只会经过 FORWARD 链。想限制容器端口映射，正确的位置是 DOCKER-USER 链，而不是 INPUT 链。这个误区几乎是周期性的，每隔一段时间就会有人在社区里重新问一遍。
4. DOCKER-USER 链的正确用法：从限制到固化
4.1 为什么自定义规则必须写进 DOCKER-USER
DOCKER-USER 链是 Docker 1.13 之后引入的，目的就是解决"用户规则和 Docker 自动规则互相踩踏"的问题。它在 FORWARD 链里的位置非常靠前，大致逻辑是：进入 FORWARD → 先检查 DOCKER-USER → 如果没有明确匹配，再按顺序检查 DOCKER 链。由于 DOCKER 链最后总是放行容器相关流量，所以你想做的拦截动作必须在 DOCKER-USER 里完成，而且要保证规则顺序正确。
DOCKER-USER 还有一个天然优势：不受 Docker daemon 重启影响。你可以放心地把规则固化在这条链里，即使 docker stop、docker start、网络重建，规则依然在。若想临时清空自定义规则，直接 iptables -F DOCKER-USER 即可，完全不影响 Docker 自身的规则。最稳的持久化方案，是把 DOCKER-USER 的规则写进 iptables 的配置文件，配合 iptables-persistent 或系统开机脚本自动恢复。
4.2 白名单实例：只允许特定 IP 访问某个容器端口
假设宿主机上用 -p 8080:80 跑了一个服务，需求是只允许 192.168.1.100 这个内网地址访问，其他来源全部拒绝。推荐的分步命令如下：
iptables -F DOCKER-USER iptables -A DOCKER-USER -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -A DOCKER-USER -p tcp --dport 80 -s 192.168.1.100 -j ACCEPT iptables -A DOCKER-USER -p tcp --dport 80 -j DROP第一条先清空，保证不残留之前测试的规则；第二条放行所有已建立连接的回程包，避免你已连上的会话被突然掐断；第三条放行白名单 IP 到容器 80 端口的新连接；第四条拒绝其余所有来源。
这里有个非常容易踩的坑：DOCKER-USER 链在 FORWARD 链中执行时，DNAT 已经在 PREROUTING 阶段完成了，所以你在 DOCKER-USER 链里看到的 --dport 是容器端口 80，不是宿主机端口 8080。如果习惯性地写 --dport 8080，规则永远匹配不上。想按宿主机端口限制的话，要用 conntrack 模块匹配原始目标端口：
iptables -A DOCKER-USER -p tcp -m conntrack --ctorigdstport 8080 -j DROP这个细节在官方文档里着墨不多，但实际配置时几乎每个人都会错一次。
4.3 注意规则顺序：先放行已建立连接，再做拦截
顺序问题单独拿出来说，是因为它太容易被忽略。如果你上来就先插一条 DROP 规则，那么容器返回给客户端的响应包也会被这条规则拦住，表现就是"连接完全建立不起来"。所以我每次都会把 RELATED,ESTABLISHED 的 ACCEPT 放在最前面。同理，如果白名单不是一个 IP 而是一个网段，也可以写 -s 192.168.1.0/24，原理完全一样。
自定义规则的匹配顺序可以用 iptables -L DOCKER-USER -n --line-numbers 查看。规则从上往下逐条匹配，匹配到 ACCEPT 就放行，匹配到 DROP 就丢弃，都不匹配就返回 FORWARD 继续走 DOCKER 链。理解了这一点，你就明白为什么"先放行特定来源、再拒绝全部"是唯一正确的解法。另外，如果只写了白名单 ACCEPT 而漏掉最后的 DROP，白名单之外的数据包会从 DOCKER-USER 链返回 FORWARD，继续往下走到 DOCKER 链，最终还是被放行——白名单形同虚设。
4.4 让规则在重启后依然存在
只敲命令不持久化，是很多人第二次踩坑的原因。Linux 发行版重启后 iptables 规则默认不会保留，你需要自己保存。常见做法有三种：
- 安装 iptables-persistent，把规则保存到 /etc/iptables/rules.v4，开机时由服务自动加载
- 把 iptables-restore 写进 systemd 的 oneshot 服务，指定开机执行
- 如果你用的是 firewalld，可以用 firewall-cmd --permanent 声明 rich rule，把等价规则纳入 firewalld 管理
我个人的习惯是配合配置管理工具来做，因为规则文件本身可版本化，新机器初始化时直接复用。但如果只是维护一两台机器，iptables-persistent 就足够了。
5. 排障自查清单与我的几点心得
5.1 一张表从症状定位检查点
为了省时间，我整理了一张自查表，每次容器网络出问题都按这个顺序查：
| 症状 | 优先检查项 | 关键命令 |
|---|---|---|
| 容器无法访问外网 | 路由转发是否开启、FORWARD 链、MASQUERADE 规则是否存在 | sysctl net.ipv4.ip_forward |
| 外部无法访问映射端口 | DNAT 规则、FORWARD 链策略、外部安全组 | iptables -t nat -L DOCKER -n |
| 映射端口只对部分来源开放 | DOCKER-USER 规则顺序 | iptables -L DOCKER-USER -n --line-numbers |
| 重启防火墙后端口不通 | Docker 规则是否被清掉 | iptables -L FORWARD -n |
| 宿主机本机访问映射端口不通 | nat 表 OUTPUT 链跳转 | iptables -t nat -L OUTPUT -n |
这张表不能解决所有问题，但能帮你把排查范围从"整个网络"缩小到"某条链"，剩下的事情就是打印那条链的具体规则，逐条对比预期行为。
5.2 三个容易误判的细节
第一个误判是"容器内 curl 127.0.0.1 通了，就说明网络没问题"。容器里的 127.0.0.1 是容器自己的回环地址，和宿主机、外部访问完全是两回事。判断端口映射是否生效，应该从外部或至少从宿主机访问映射端口，而不是在容器里自测。
第二个误判是把"iptables 规则存在"等同于"iptables 规则生效"。规则存在只说明链里有条目，但 FORWARD 链是否真的跳转到 DOCKER-USER 和 DOCKER 链、策略是 ACCEPT 还是 DROP、流量是否走了预期路径，这些都要结合数据包计数来验证。iptables -L 的输出里每个规则前面都有 pkts 和 bytes 计数，如果一条规则长期为 0，说明流量根本没经过它，问题多半在更前面的链路，比如外部安全组或路由。
第三个误判是改完规则不测回程流量。防火墙规则永远要考虑双向：你放行了请求，不一定放行了响应。这也是我一再强调在 DOCKER-USER 里优先 ACCEPT RELATED,ESTABLISHED 的原因。很多白名单配置"看上去对了，实际一测不通"，问题几乎都出在这里。
5.3 关于安全边界的实话
最后说点不太会写在官方文档里的经验。Docker 的端口映射 -p 8080:80 默认绑定在 0.0.0.0，意味着宿主机上任何一个网卡 IP 都能访问这个端口，暴露面相当大。如果只是想让本机访问，用 -p 127.0.0.1:8080:80 只在回环地址上监听；如果一定要暴露给外部，务必配合 DOCKER-USER 白名单和外部安全组的双重限制。我见过不少服务被扫描爆破的案例，根因都是"外部安全组放开了端口、宿主机防火墙没管、容器又恰好有漏洞"，三层防线全裸奔。端口映射越少越好，白名单越窄越好，规则持久化越早做越好，这三点做到，Docker 服务踩坑的概率会小很多。每次在防火墙相关问题上折腾一轮之后，我的体感都是：理解 iptables 的交互方式，比记住任何一条命令都值钱。
