Docker升级后自定义网络“消失”本质是新版对网络JSON元数据校验更严格，需检查/var/lib/docker/network/files/下文件完整性，修复或重建网络并避开宿主机网段冲突。
升级 Docker 版本后，自定义网络（尤其是通过 docker network create 创建的 bridge 网络）突然“消失”或容器启动报 network not found，本质不是配置被删除，而是新版 Docker 对网络元数据的加载机制或兼容性校验变严格了——特别是当原有网络依赖已损坏的 JSON 文件、IPAM 配置冲突、或子网与宿主机当前网络重叠时。
确认网络是否真的丢失
执行 docker network ls，若列表中没有你的自定义网络名，不代表它彻底消失。Docker 的网络定义实际存储在 /var/lib/docker/network/files/ 下的 JSON 文件中。重启后若该目录下文件损坏或格式异常（比如含非法字符、空字段、不兼容的 IPAM 结构），Docker daemon 会跳过加载，导致“看不见”。
- 检查文件完整性：
ls -l /var/lib/docker/network/files/，看是否有对应网络 ID 的 .json 文件 - 用
cat查看内容，重点确认Subnet、Gateway字段是否合法（如"172.20.0.0/16"格式正确，不能是"172.20.0.0/255.255.0.0"） - 对比旧版备份（如有）：若升级前导出过
docker network inspect mynet > mynet.json，可比对结构差异
修复损坏的网络定义文件
如果发现 JSON 文件存在语法错误或字段缺失（例如缺少 IPAM 或 Driver），不要手动编辑——Docker 不接受非标准格式。稳妥做法是重建网络，并复用原配置。
- 记录原网络关键参数：运行
docker network inspect mynet（若还能查到），或从历史命令、compose 文件、运维文档中找回--subnet、--gateway、--ip-range - 删除残留痕迹（谨慎）：
rm -f /var/lib/docker/network/files/*.json（仅当确认无其他有效网络且已备份） - 重建网络：
docker network create --subnet=172.20.0.0/16 --gateway=172.20.0.1 mynet - 重启容器时显式指定网络：
docker run --network mynet ...，避免依赖隐式默认行为
规避新版兼容性陷阱
Docker 24.x+ 对 bridge 网络的子网合法性校验更严，例如禁止使用 /32 单地址子网、拒绝与宿主机路由表冲突的网段（如宿主机有 192.168.1.0/24，你却创建 192.168.1.0/24 的 Docker 网络）。
- 检查宿主机路由：
ip route show | grep -E "(172\.|192\.168\.|10\.)"，避开已使用的私有网段 - 避免使用老旧 IPAM 插件配置：新版默认使用内置 IPAM，若旧网络 JSON 中含
"IPAM": {"Config": [{"Driver": "default"}]}，应简化为"IPAM": {"Config": [{"Subnet": "...", "Gateway": "..."}]} - 升级后首次启动，加
--debug启动 Docker daemon：sudo dockerd --debug，观察日志中是否有failed to load network及具体原因
预防下次升级出问题
版本升级不该成为网络故障的触发器。关键在把网络配置“代码化”和“可重现”。
- 所有自定义网络创建命令，统一写入部署脚本或 CI/CD 流水线，而非仅靠人工执行
- 用 Docker Compose 时，在
docker-compose.yml顶层声明networks:并指定driver_opts和子网，Compose 会自动处理兼容性 - 定期导出网络配置：
docker network inspect mynet | jq '.[0] | {Name, Driver, Subnet, Gateway}' > networks-backup.json - 升级前停用非必要容器，执行
docker system prune -a --volumes清理潜在干扰项（注意备份数据卷）
