真正导致容器断网的主因是网桥子网与宿主机局域网ip段重叠，引发内核路由表混乱；mac冲突极少单独引发突发脱网，90%以上所谓mac冲突实为子网重叠，应优先通过修改daemon.json的default-address-pools避开冲突网段并清理网络残留来解决。
MAC地址冲突在 Docker Compose 场景中极少单独引发“突发脱网”，真正导致容器断网的主因通常是 网桥子网与宿主机局域网IP段重叠，进而触发内核路由表混乱或ARP响应异常——此时系统可能误将容器流量导向物理网关，或丢弃本该发往容器的包，现象上表现为“突然无法访问”“SSH中断”“服务失联”。MAC冲突本身多见于极端复用场景（如反复快速重建同名网络+未清理残留），但常被误判为根源。
确认是否真为MAC冲突而非子网重叠
先别急着改MAC，90%以上所谓“MAC冲突脱网”实际是子网撞车。快速验证：
- 运行
ip route，检查是否存在两条指向不同接口的相同目标网段（例如同时有172.18.0.0/16 via docker0和172.18.0.0/16 via eth0） - 执行
ip addr show，看docker0和物理网卡（如ens33）是否都在 172.x.x.x 或 10.x.x.x 等私有网段内 - 查容器日志：
docker logs，若出现network is unreachable或no route to host，基本可排除MAC问题，属路由层面失效
优先解决子网重叠（根本解法）
修改 Docker 默认地址池，让自动生成的网桥彻底避开宿主机网段：
- 编辑
/etc/docker/daemon.json，加入（示例避开 172.16.0.0/12）：{"default-address-pools": [{"base": "192.168.200.0/24", "size": 24}]} - 停掉所有 compose 项目：
docker-compose down -v - 删掉旧网桥：
docker network prune（或手动docker network rm） - 重启 Docker：
systemctl restart docker - 重新启动 compose：
docker-compose up -d，新网桥将从 192.168.200.0/24 起分配
若确需干预MAC（极少数情况）
仅当确认同一宿主机存在多个 bridge 网络且 MAC 随机重复（可通过 docker network inspect | grep Mac 查看），才考虑显式指定：
- 在
docker-compose.yml的 networks 段中添加driver_opts：networks:<br> app-net:<br> driver: bridge<br> driver_opts:<br> com.docker.network.bridge.enable_icc: "true"<br> com.docker.network.bridge.host_binding_ipv4: "0.0.0.0"
- 更彻底的方式：为每个自定义网络指定唯一
mac_address（需配合静态 IP）：services:<br> web:<br> networks:<br> app-net:<br> ipv4_address: 192.168.200.10<br> mac_address: 02:42:c0:a8:c8:0a
预防性加固措施
避免每次部署都踩坑：
- 所有
docker-compose.yml必须显式声明networks，禁用默认桥接；不写network_mode: bridge - 为每个项目分配固定、隔离的 CIDR（如
192.168.201.0/24、192.168.202.0/24），并在ipam.config中锁定 - 上线前执行预检脚本：
ip route | grep -E '^(10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.|192\.168\.)' | wc -l，若结果 > 1，说明存在潜在冲突
