执行 docker network rm 或 docker compose down 时，终端出现 network has active endpoints，表示这个网络仍与一个或多个容器端点保持关联。Docker为了避免正在使用的网络被直接拆除，会拒绝删除操作。
先找到仍在连接的容器，再决定停止、迁移还是断开网络。 不要一看到错误就批量删除容器，也不要手工清理Linux网桥或iptables规则，那样可能让其他项目一起断网。
先确认网络名称和错误对象
先列出网络，核对要处理的是项目自建网络还是Docker默认网络：
docker network ls
docker network inspect NETWORK_NAMECompose创建的网络名称可能带项目名前缀，例如 shop_default，不一定与compose文件中的短名称完全一致。使用 docker compose ls 和 docker compose ps -a 可以确认当前项目及其容器。
bridge、host 和 none 属于Docker内置网络，不应把它们当成普通项目网络清理。删除前必须用完整网络名或网络ID再次核对目标，避免同名项目造成误操作。
查看哪些容器仍连接在网络上
从网络检查结果中读取 Containers 字段：
docker network inspect NETWORK_NAME \
--format '{{json .Containers}}'也可以逐个列出容器名称和端点信息：
docker network inspect NETWORK_NAME \
--format '{{range $id, $c := .Containers}}{{$id}} {{$c.Name}} {{$c.IPv4Address}}{{"\n"}}{{end}}'若结果里有正在运行的数据库、反向代理或业务容器，说明网络并非残留。先确认它属于哪个Compose项目、是否仍承载流量以及有没有其他网络可用。
网络里还有容器，不等于容器异常；它只说明删除条件尚未满足。
区分运行容器与已经停止的容器
查看端点对应容器的状态和网络：
docker ps -a --filter network=NETWORK_NAME
docker inspect CONTAINER_NAME \
--format '{{.State.Status}} {{json .NetworkSettings.Networks}}'停止的容器仍可以保留网络连接，因此只执行 docker stop 不一定能删除网络。对确认废弃的容器，可以在保留日志、挂载和数据卷信息后再执行：
docker rm CONTAINER_NAME数据库容器和有命名卷的服务要先核对持久化位置。容器删除与数据卷删除是两件事，不要附带 -v，除非已经确认卷内数据不再需要。
仍在运行的容器怎样安全断开
Docker提供专门的断开命令：
docker network disconnect NETWORK_NAME CONTAINER_NAME官方文档说明，运行中的容器可以从网络断开。断开前要确认容器至少还有一条可用网络，并评估服务发现、数据库连接和对外端口是否依赖当前网络。
执行后检查：
docker inspect CONTAINER_NAME \
--format '{{json .NetworkSettings.Networks}}'
docker network inspect NETWORK_NAME--force 只应在端点状态异常、普通断开失败且已经确认业务影响时使用。强制断开不会自动修改应用配置，写死旧IP或网络别名的服务仍可能不可用。
Compose项目应优先用项目命令处理
网络由Compose创建时，先进入正确项目目录，检查最终配置和项目名称：
docker compose config --services
docker compose ps -a
docker compose down使用过 -p、COMPOSE_PROJECT_NAME 或不同目录名时，同一份compose文件可能生成不同项目名称。错误目录里执行down，可能没有处理真正占用网络的容器。
若某个容器是手工加入Compose网络的，docker compose down 不一定会替你清理它。此时应根据 docker network inspect 的结果找到该容器，再决定断开或迁移。
不要用 docker compose down -v 解决网络错误；-v 会连项目数据卷一起删除，风险与清理网络完全不对等。
处理名称相同但ID不同的残留网络
自动化部署可能反复创建项目，脚本里又只记录短名称，容易把旧网络和新网络混在一起。使用ID进行核对：
docker network ls --no-trunc
docker network inspect NETWORK_ID
docker ps -a --filter network=NETWORK_ID先确认创建时间、标签和连接容器。Compose网络一般包含项目与网络标签，可以帮助判断归属。不要根据名称相似就一次删除多个网络。
需要重新创建网络时，先记录子网、网关、驱动和选项：
docker network inspect NETWORK_NAME > network-backup.json这份输出包含内部地址和容器信息，分享前要脱敏。
为什么重启Docker后错误还在
Docker守护进程重启后会重新载入容器和网络元数据。只要容器仍存在并保持该网络配置，端点就会重新出现，因此重启Docker不是清理网络的可靠办法。
重启还会影响整台主机上的容器。生产服务器上为了处理一个项目网络而执行 systemctl restart docker，可能让无关站点短暂中断。
这类错误的根因是网络对象仍被引用，不是Docker进程卡住。 只有日志和状态明确指向守护进程异常时，才评估服务重启。
端点全部清除后再删除网络
确认 Containers 为空后执行：
docker network rm NETWORK_NAME
docker network lsDocker官方要求，删除网络前必须先断开连接在上面的容器。docker network prune 只会处理未使用网络，但它会面向整台主机扫描，不适合替代明确目标的清理命令。
在多项目服务器上，优先删除指定网络。可控运维应知道删的是哪个网络、为什么可以删，以及怎样恢复，而不是依赖一次全局prune碰运气。
建立不易残留的部署流程
为Compose项目固定 name 或项目名，避免目录改名后生成新的网络集合。部署脚本先执行 docker compose config，再按明确的项目名执行up或down，并记录失败步骤。
需要复现网络清理流程时，可以在 萤光云 创建隔离环境；需要对比不同地区Docker版本时，也可以在 LightNode 部署临时节点。测试环境不要挂载生产数据库卷，也不要复制真实密钥。
部署结束后检查孤立容器、网络与卷，但把网络、镜像和数据卷分开处置。自动清理只能针对已经证明无引用的对象，数据卷始终需要更高等级的确认。
常见问题
停止容器后为什么网络还是删不掉？
停止不会移除容器对象，它仍可能连接在网络上。确认容器已废弃后删除容器，或使用network disconnect解除连接。
可以直接使用docker network disconnect –force吗？
可以处理异常端点，但它可能立即切断业务连接。应先确认容器归属、替代网络和回滚方法，普通断开失败时再评估强制操作。
删除网络会不会删除容器数据？
单独执行network rm不会删除卷，但网络断开会影响容器间通信。不要为了清理网络附带删除卷的命令。
温馨提示
Docker网络报active endpoints是保护提示。最稳妥的顺序是确认网络、列出端点、判断容器用途、受控断开，最后删除空网络。 每一步都能回读验证，比全局清理或重启Docker更安全。
