用 ethtool -S 查 veth 对应容器需结合 peer_ifindex：先 ethtool -S vethxxx 获取 peer_ifindex 值，再 ip link | grep "@if${peer_ifindex}:" 定位容器内接口；ip -d link show 更快因直接显示 link-netnsid 和 peer 信息。
怎么用 ethtool -S 查 veth 对应的容器？
ethtool -S 本身不直接显示容器信息，它只输出网卡底层统计（如 rx_packets、peer_ifindex）。但关键线索在 peer_ifindex 字段——veth 是成对出现的，一端在宿主机，另一端在容器网络命名空间里，两者通过 ifindex 互指。
实操步骤：
- 先用
ip link show找出疑似残留的 veth 接口名（如vethabc123） - 运行
ethtool -S vethabc123，查找输出中类似peer_ifindex: 17的行 - 再执行
ip link | grep "^[0-9]\+:.*@if17:"（把 17 换成你查到的值），看哪条链路的 peer 描述匹配这个 ifindex - 如果匹配到某条带
@if17:的行（比如18: eth0@if17:），说明该容器内eth0连着宿主机的这个 veth
为什么 ip -d link show vethxxx 比 ethtool -S 更快定位容器？
ip -d link 的 -d（detail）模式会直接打印 veth 的对端索引和命名空间标识，比解析 ethtool 统计更直接。尤其当容器已退出但 veth 未清理时，它仍能暴露关联痕迹。
注意点：
- 运行
ip -d link show vethabc123，重点看输出中是否含link-netnsid字段（如link-netnsid 3） - 若有，说明该 veth 曾属于某个网络命名空间；用
ls -la /var/run/netns/或cat /proc/*/ns/net 2>/dev/null | grep -l "$(readlink /proc/*/ns/net 2>/dev/null | grep netnsid.3)"反查进程（较麻烦） - 更实用的是：用
ip link show | grep -A1 "vethabc123" | grep "@"快速扫 peer 描述，往往比深挖 netnsid 更快锁定容器名
容器退出后 veth 残留，ip link delete 能直接删吗？
不能盲目删。veth 删除失败常见报错是 Operation not supported 或 Device or resource busy，本质是内核仍认为该设备被某个命名空间引用（哪怕容器进程已死，netns 文件描述符可能还挂在某处）。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
安全清理路径：
- 先确认无活跃容器使用：
docker ps -a | grep -i "Exited\|Created"+podman ps -a（视环境而定） - 检查该 veth 是否被桥接或加入 network namespace：
ip link show vethabc123看master字段（如master docker0） - 若属 bridge，先
brctl delif docker0 vethabc123（或ip link set vethabc123 nomaster） - 最后再试
ip link delete vethabc123
真正难排查的是“双空闲”veth 对：两端都无命名空间、也无 peer 描述
极少数情况下，ip -d link 显示 link-netnsid 为 none，且 ethtool -S 中 peer_ifindex 为 0 或无效值。这通常是容器 runtime 异常退出导致的元数据断裂，内核保留了设备但丢失了配对关系。
此时唯一可靠手段是时间+日志交叉验证：
- 查
dmesg | grep -i "veth\|netns"看是否有异常解绑记录 - 翻容器引擎日志：
journalctl -u docker | grep -i "vethabc123"或crictl logs关联容器 ID - 若确认无业务影响，可强制卸载模块再重载（风险高）：
modprobe -r veth && modprobe veth—— 会清掉所有 veth，慎用
这类残留不会影响新容器创建，但会污染 ip link 输出和监控指标，最稳妥的方式其实是重启容器服务（如 systemctl restart docker），而非硬删单个接口。
