Docker Bridge 网络冲突本质是 IP 地址空间重叠，常见于 Docker 默认网段（如 172.17.0.0/16）与宿主机内网段冲突，或自定义网络 Subnet 与 IPRange 配置不匹配；表现为网络创建失败、容器无法启动及通信异常。
Docker Bridge 网络冲突本质是 IP 地址空间重叠，常见于两种情况：一是 Docker 默认网段（如 172.17.0.0/16）与宿主机所在内网段撞车；二是自定义网络配置异常，比如 Subnet 和 IPRange 不匹配，或多个 Docker 网络彼此覆盖。问题表现通常是创建网络失败、容器无法启动、宿主机与容器/外部通信异常，甚至影响本机其他服务连通性。
查清当前 Docker 网络实际配置
别只看 docker network ls 表面结果——默认 bridge 网络可能已悄悄被改坏：
- 运行
docker network inspect bridge，重点核对IPAM.Config下的 Subnet、Gateway 和 IPRange 是否逻辑一致（例如 Subnet 是192.168.100.0/24，IPRange 却写成172.99.0.0/16就是典型错配） - 用
ip route show查看系统路由表，确认是否存在类似172.17.0.0/16 dev docker0的条目，且该网段是否和你办公网、IDC网段（如172.16.0.0/12或192.168.2.0/24）重叠 - 执行
ifconfig docker0或ip addr show docker0，验证网桥接口实际分配的 IP 是否落在 Subnet 范围内
确认宿主机真实网络环境
冲突根源往往在“人不知鬼不觉”的物理网络侧：
- 查宿主机 IP 和子网：
ip -br addr show | grep -E "(eth|ens|enp)"，记下主网卡的 IP（如172.16.251.23/24） - 检查是否已有同网段设备：比如公司内网用了
172.16.0.0/12，而 Docker 默认172.17.0.0/16正好落在其中，系统就会把发往172.17.x.x的包全扔给docker0，导致访问不了真正的172.17.3.75服务器 - 若使用虚拟机或云主机，也需确认底层网络策略是否限制了私有网段使用（部分云平台禁用
100.64.0.0/10等 CGNAT 段）
安全修改 Docker 网桥网段
不建议暴力删 docker0，推荐通过配置驱动持久生效：
- 编辑
/etc/docker/daemon.json（不存在则新建），写入明确网段，例如：
{ "bip": "10.200.0.1/24", "default-address-pools": [ {"base": "10.201.0.0/16", "size": 24} ] } - bip 固定默认 bridge 网桥的 IP 和子网；default-address-pools 控制后续自定义网络的自动分配范围，避免再撞车
- 保存后执行：
sudo systemctl restart docker，再用docker network inspect bridge验证新配置是否加载成功 - 旧容器需重建才能接入新网段；正在运行的容器可先
docker network disconnect bridge <容器名>再重新连接
临时应急与深度清理
当重启 Docker 不够快，或怀疑残留路由干扰时：
- 停服务：
sudo systemctl stop docker - 删旧网桥（仅限
docker0）：sudo ip link delete docker0（iproute2方式，无需安装额外工具） - 清理冲突路由：
sudo ip route del 172.17.0.0/16 dev docker0 2>/dev/null - 如有自定义网络残留（如
br-xxxx），可用docker network rm <NETWORK_ID>清理；不确定时加-f强制删除 - 启动 Docker 后，新配置会自动创建干净的
docker0
