running状态但实际离线，通常是网络命名空间损坏或失联所致，表现为ping不通、dns失败、服务无响应；需通过ip link show、/proc/pid/ns/net比对、docker inspect等确认，并强制重建网络上下文而非简单重启容器。
running 状态但实际离线，往往不是容器“没跑”，而是网络命名空间（network namespace）已损坏或失联——容器进程在，但网络栈不可用，表现为 ping 不通、dns 失败、服务无响应。这类问题常见于系统异常重启、docker 强制 kill、内核模块冲突或网络配置残留。修复核心在于重建网络上下文，而非单纯重启容器。
确认是否为网络命名空间损坏
先排除常规原因（如 DNS 配置、iptables 规则），再聚焦命名空间层面：
- 进入容器执行 ip link show：若只显示
lo（回环口），无eth0或类似虚拟网卡，极可能命名空间未正确挂载 - 执行 cat /proc/$(pidof your_process)/ns/net（替换 your_process 为容器内主进程名），再对比宿主机的
/proc/1/ns/net—— 若两者 inode 号相同，说明该进程意外共享了宿主机网络命名空间，而非独立命名空间 - 运行 docker inspect | grep -A 5 NetworkSettings：检查
IPAddress是否为空或为0.0.0.0，NetworkID是否有效；若Gateway缺失或为 null，也指向命名空间初始化失败
强制重建容器网络命名空间
不能靠 docker restart 解决——它只发信号重启进程，不重建网络命名空间。必须让 Docker 完整释放并重新分配：
- 停止容器：docker stop
- 移除容器网络连接：docker network disconnect bridge （若使用默认 bridge）
- 清理残留网络状态：sudo ip link delete vethxxx 2>/dev/null（vethxxx 为
docker network inspect bridge中查到的对应 veth 对，或直接跳过此步，由下一步触发自动清理） - 启动新实例（不复用旧容器）：docker start —— 注意：start 会尝试复用原网络配置；更稳妥的是 docker run 启动新容器，并显式指定
--network bridge或自定义网络
彻底重置 Docker 网络基础设施
当多个容器出现同类问题，或 docker0 网桥异常（如 IP 冲突、无地址、无法创建 veth），需重建底层网络：
- 停止 Docker：sudo systemctl stop docker
- 清除网络残留：sudo ip link delete docker0 2>/dev/null && sudo rm -rf /var/lib/docker/network/
- 重启 Docker：sudo systemctl start docker —— 启动时自动重建
docker0、NAT 规则和默认 bridge 网络 - 验证：ip addr show docker0 应返回
172.17.0.1/16类地址；docker network ls 应含bridge且状态正常
避免再次损坏的预防措施
网络命名空间损坏多由外部干预引发，日常应规避以下操作：
- 不用 kill -9 杀 Docker daemon 进程；停服统一用 systemctl stop docker
- 禁用 systemd-resolved 或手动管理
/etc/resolv.conf时，确保不覆盖 Docker 的 DNS 自动注入机制 - 升级内核或 Docker 版本后，检查
lsmod | grep bridge和lsmod | grep iptable，确保必要模块已加载 - 生产环境建议使用自定义 bridge 网络（docker network create mynet），比默认 bridge 更稳定，且支持静态 IP 分配，减少命名空间初始化随机性
