docker network prune 删不掉 veth 接口，因为它只清理未被引用的用户自定义网络元数据，不调用 CNI 插件，也不处理内核层 veth 设备；残留通常源于容器异常退出导致 CNI DEL 操作未执行。
docker network prune 为什么删不掉 veth 接口
因为 docker network prune 只清理「未被任何容器引用」的用户自定义网络（bridge、overlay 等），它完全不触碰默认 bridge 网络，也不管内核层面的 veth 设备。这些接口残留通常来自异常退出的容器、docker kill -9 强杀、或 containerd 没有正确回调 CNI 插件释放资源。
常见现象是：ip link show 里一堆 vethxxxxxx@if2，但 docker ps -a 和 docker network ls 都看不到对应容器或网络。
- 根本原因：CNI 插件（如
bridge）在容器销毁时负责执行DEL操作解绑并删除veth，但 containerd 或 dockerd 进程崩溃、OOM kill、或 CNI 超时失败都会导致这步跳过 -
docker network prune不调用 CNI，只是删 Docker 内存/磁盘里的网络对象记录，属于“元数据清理”，不是“设备清理” - 默认
docker0网桥上的veth更不会动——它由 Docker daemon 启动时创建，生命周期绑定 daemon 进程
containerd 场景下如何安全清理残留 veth
containerd 的容器生命周期由 ctr 或 crictl 管理，其网络释放依赖 netns 文件是否存在 + CNI DEL 执行成功。若 netns 已销毁但 veth 还挂着，说明 CNI 没收到通知或执行失败。
手动清理前先确认：该 veth 是否真无主（没被任何 netns 持有、没被 iptables/ebtables 引用、没被 tc/qdisc 绑定）：
- 查归属：
readlink /sys/class/net/vethabc123/nameif（若返回No such file，说明 netns 已消失） - 查引用：
ls -l /sys/class/net/vethabc123/master（若有输出，表示还连着网桥，不能直接删） - 查 netns 关联：
grep -l "vethabc123" /proc/*/net/ns（无结果才可删）
确认无主后，用 ip link delete vethabc123 删除。不要用 ifconfig vethxxx down && ifconfig vethxxx delete——老式 ifconfig 不支持 veth 删除。
自动化清理脚本要注意的三个坑
网上流传的 “一键清空所有闲置 veth” 脚本容易误删，关键在判断逻辑是否严谨：
- 不能只靠名字匹配
veth前缀——有些自建 CNI 或 SR-IOV 驱动也会创建 veth 开头的设备，它们有业务意义 - 不能跳过
master检查——直接删正在桥接中的 veth 会导致宿主机网络抖动甚至断连 - containerd + nerdctl 场景下，
/run/containerd/io.containerd.runtime.v2.task/k8s.io/xxx/rootfs下的 netns 可能残留，得配合nsenter -n -t PID ip link核对，否则脚本会漏判
推荐最小化检查命令组合：
ip -br link | awk '$1 ~ /^veth/ && $NF == "DOWN" {print $1}' | while read dev; do<br> [ ! -e "/sys/class/net/$dev/master" ] && ip link delete "$dev"<br>done
重启 containerd 能不能顺带清掉 veth
不能。containerd 本身不持有或管理 veth 设备，它只通过 CNI 插件间接调用。重启 containerd 后，已残留的 veth 依然挂在内核里，且没有自动回收机制。
唯一例外是：如果容器对应的 netns 文件还在 /proc/PID/ns/net 下，且你用 nsenter 进入后执行 ip link 能看到该 veth，那说明这个 netns 实际上还活着（比如进程僵死但没退出），此时应先 kill -9 PID 再删设备。
真正有效的兜底方式只有两个：手动按上述步骤删，或重启宿主机（强制释放所有 netns 和关联设备）。后者在生产环境显然不可取，所以重点还是把清理逻辑做细——尤其是 master 和 netns 的双重校验，少一步都可能让问题从“网络杂乱”升级成“业务断网”。
