ip netns list 显示无效条目说明存在“幽灵 namespace”，需先用 find /proc/[0-9]*/ns/net -samefile /var/run/netns/xxx 判断是否无进程引用，再 umount 后删除文件，避免直接 rm；注意检查 /run/netns/ 和 /var/run/netns/ 两路径，清理前须加白名单与 dry-run 防误删。
ip netns list 显示一堆无效条目，但 ip netns delete 报错或无反应
这说明 netns 文件（如 /var/run/netns/xxx）还存在，但背后已无进程引用 —— 它们是“幽灵 namespace”，不能直接删，也不能靠 ip netns delete 清掉（该命令只对当前挂载有效的 netns 生效）。真正要做的，是先确认它是否真的没人用，再手动解绑并删除。
- 检查每个 netns 文件是否被任何进程持有：
find /proc/[0-9]*/ns/net -samefile /var/run/netns/xxx 2>/dev/null | head -n1，若无输出，说明可删 - 注意路径：有些系统用
/run/netns/而非/var/run/netns/，需两边都查 - 不要用
rm -f直接删文件：netns 是 bind mount，得先umount /var/run/netns/xxx，再删文件，否则下次ip netns list还会显示（只是失效条目） - 若
umount报 “not mounted”，说明它本就不是挂载点，而是残留符号链接或空文件，可直接rm
容器运行时异常退出后，veth 接口和 br- 网桥还在，怎么识别哪些该删
残留 veth 对通常成对出现（一端在 host，一端在容器 netns），但容器销毁后 host 侧的那端不会自动消失。关键不是“名字像不像容器”，而是看它是否还连着一个活跃的 netns 或被其他工具（如 CNI 插件）管理。
- 列出所有 veth：
ip link show type veth，重点关注状态为DOWN且无 IP、无流量（cat /proc/net/dev | grep veth查 rx/tx 为 0）的接口 - 检查它是否仍关联到某个 netns：
readlink /sys/class/net/vethxxx/name（部分内核支持）；更通用的是：ls -l /sys/class/net/vethxxx/master，若指向br-xxx且该网桥下无其他 up 状态 port，则网桥也可考虑删 - 删前先试禁用：
ip link set vethxxx down && ip link delete vethxxx；若报 “Device or resource busy”，说明仍有 netns 持有它（可能对应一个没列出来的残留 netns），得先处理那个 netns
写自动清理脚本时，为什么必须加白名单和 dry-run 模式
因为 ip netns 和 veth 清理是不可逆操作，一旦误删正在被 kubelet、CNI 或自定义脚本使用的资源，会导致网络中断甚至节点失联。线上环境出过因定时任务把 netns/cni-loopback 或 vethcni0 当垃圾删掉，导致 Pod 无法分配 IP 的事故。
- 白名单示例：保留
cni-loopback、host、calico开头的 netns 名，以及br-*中名称含k8s或docker的网桥 - dry-run 模式先输出将删什么，不执行：
echo "[DRY RUN] would umount and rm /var/run/netns/xxx" - 避免并发冲突：脚本开头加
if [ -f /tmp/netns-cleanup.lock ]; then exit; fi; touch /tmp/netns-cleanup.lock; trap 'rm /tmp/netns-cleanup.lock' EXIT
为什么 docker system prune 不管 netns 和 veth 垃圾
docker system prune 只管 Docker daemon 自己创建和跟踪的资源。而 netns 和 veth 很多是容器运行时（如 containerd）或 CNI 插件（如 Calico、Flannel）直接调用 ip 命令创建的，Docker 完全不知道它们的存在，自然不会清理。
- containerd 场景下，残留 netns 更常见：它默认不注册 netns 到
ip netns，但某些 CNI 配置会手动 bind mount 到/var/run/netns/，这就留下断连痕迹 - systemd 服务启停脚本若没配
ExecStopPost=ip netns delete xxx，也会漏删 - 真正可靠的清理入口，是定期跑一遍基于
find /proc/*/ns/net的扫描脚本，而不是依赖某一个工具
/var/run/netns/ 下的文件权限常为 root:root 且 mode 600，普通用户或 cron job 若没用 sudo，find -samefile 会静默失败，导致误判“无人引用”而误删**。务必在脚本里加 sudo -n true 2>/dev/null || { echo "no sudo"; exit 1; } 做权限兜底。 
