可通过 readlink /sys/class/net/vethxxx/master 确认 veth 是否挂载于 docker0，再结合 stat 查创建时间与 docker ps -a 历史容器比对归属；安全删除需先 ip link set vethxxx master none 解绑，再 ip link delete。
怎么确认残留的 veth 接口属于哪个容器？
容器删了但 veth 还挂在 docker0 上，本质是命名空间被销毁后，宿主机端的 veth 设备没自动清理——linux 不会主动回收已断开连接的 veth pair 一端。直接 ip link delete 可能失败（报错 Device or Resource busy），因为内核仍认为它连着某个（已消失的）网络命名空间。
正确做法是先反向查归属：
- 用
bridge link（centos 8+）或brctl show docker0（旧版）列出所有挂在docker0上的 port，记下vethxxx名字 - 对每个
vethxxx执行：readlink /sys/class/net/vethxxx/master确认它确实在docker0下；再执行readlink /sys/class/net/vethxxx/name（部分内核版本支持）或更可靠的方式：ls -l /sys/class/net/vethxxx/phys_port_name 2>/dev/NULL—— 若输出为空，说明无物理绑定，大概率是容器残留 - 查容器历史：运行
docker ps -a --format "{{.ID}}t{{.Names}}t{{.Status}}" | grep -i "exited|created"，比对容器创建/退出时间与veth创建时间（stat /sys/class/net/vethxxx看Birth时间戳）
为什么 docker rm -f 后 veth 还在？
Docker 删除容器时，本应自动解绑并删除对应 veth pair，但以下情况会导致“半残”状态：
- 容器进程僵死（zombie），网络命名空间未完全释放
- Docker daemon 异常重启过，状态同步丢失
- 手动用
nsenter或ip netns操作过命名空间，干扰了 Docker 的生命周期管理 - 使用了非标准存储驱动（如
overlay2异常卸载）或 rootfs 挂载点残留
此时 veth 在宿主机可见，但 ip link show vethxxx 会显示 state DOWN 且无 master 字段（或 master 指向已不存在的网桥），这就是典型残留特征。
安全删除残留 veth 的实操步骤
不能直接 ip link delete，必须先解除与网桥的绑定，再删除设备：
- 确认它确实没被任何命名空间持有：
ls /proc/*/ns/net 2>/dev/null | xargs -I{} sh -c 'echo {}; nsenter -n -t $(basename {}) ip link show | grep vethxxx' | grep -q vethxxx || echo "no active Namespace holds it" - 从网桥上摘除：
ip link set vethxxx master none（关键！这步解除逻辑绑定） - 再删除设备：
ip link delete vethxxx - 验证：
bridge link | grep vethxxx应无输出；ip link show vethxxx报错Device "vethxxx" does not exist
如果 ip link set ... master none 报错 Invalid argument，说明该接口已不在任何网桥上（可能是之前已手动解绑但没删），可跳过此步直接 ip link delete。
kubernetes 场景下 Pod 删除后 veth 残留怎么办？
K8s 的 CNI 插件（如 Calico、Cilium）负责创建和清理 veth，但若节点异常（OOM kill、kubelet crash），可能出现类似残留。此时不能只查 docker0，而要：
- 确认 CNI 类型：
ls /etc/cni/net.d/，看是10-calico.conflist还是05-cilium.conf - 查对应插件是否还在运行：
ps aux | grep -E "(calico|cilium|flannel)" - 调用 CNI 清理脚本（如有）：
/opt/cni/bin/calico-ipam --delete（仅示例，实际依插件文档） - 最稳妥方式：重启对应 CNI 守护进程（如
systemctl restart calico-node），它通常会在启动时扫描并清理孤儿 veth
注意：K8s 场景下，veth 名字通常带 pod UID 前缀（如 vethabc1234），可通过 kubectl get pods -A -o wide 查 UID 后反向匹配，比 Docker 场景更可追溯。
真正容易被忽略的是：某些云托管 K8s（如 EKS、AKS）禁用了节点 root 权限，ip link delete 会失败——此时必须通过平台控制台重建节点或提工单，硬删接口反而可能触发 CNI 冲突。