删除容器后残留veth接口是因CNI DEL操作失败，docker rm不负责清理网络设备；需先验证veth无主（查netns、桥接、nameif），再用ip link delete安全删除。
删除容器后残留 veth 接口，是因为 Docker 或 containerd 没有成功调用 CNI 插件执行网络释放（DEL 操作），导致内核层的虚拟以太网设备未被清理。这不是 docker rm 的缺陷，而是异常退出场景下的常见副作用——比如 docker kill -9、OOM kill、daemon 崩溃或 CNI 超时失败。
为什么 docker rm 不删 veth
Docker 的 rm 命令只负责清理容器元数据和 rootfs，网络设备的销毁依赖于 CNI 插件回调。若容器进程已消失但 netns 文件残留、或 CNI DEL 调用失败，veth 就会“悬空”挂在宿主机上。此时 docker network prune 也无效，因为它只删未被引用的网络对象，不碰内核设备。
确认 veth 是否真无主
不能直接删，先验证归属和依赖：
- 查 netns 关联：
grep -l "vethabc123" /proc/*/net/ns—— 无输出才说明没进程持有该网络命名空间 - 查桥接状态：
ls -l /sys/class/net/vethabc123/master—— 若有输出（如指向 docker0 或 br-xxxx），表示仍连在网桥上，需先解绑 - 查 netns 文件是否存在：
readlink /sys/class/net/vethabc123/nameif 2>/dev/null—— 返回 “No such file” 表示对应 netns 已销毁
安全删除残留 veth 的方法
确认无主后，用标准网络工具操作：
- 用
ip link delete vethxxx直接删除（推荐，内核级清理） - 不要用
ifconfig vethxxx down && ifconfig vethxxx delete—— 旧版 ifconfig 不支持 veth 删除，会报错 - 若该 veth 还挂在网桥上，先执行
ip link set vethxxx nomaster解除绑定，再删
containerd 环境下的额外注意点
使用 nerdctl 或原生 ctr 时，残留可能更隐蔽：
- 检查
/run/containerd/io.containerd.runtime.v2.task/下是否残留 netns 文件 - 用
nsenter -n -t $PID ip link进入疑似容器的 netns，确认 veth 是否仍在其中 - 若 netns 已销毁但 veth 仍在，且无 master、无 grep 匹配，则可安全删除
