线上容器故障应按“状态→日志→网络→资源”分层排查：先用 docker ps -a 查 status/ports/created；再用 inspect、logs（含时间范围）、网络连通性命令逐层验证；无 shell 镜像需用 top/stats/port 等外部命令分析。
线上容器出问题，别急着 restart。真正有效的排查，是用一套固定命令组合，从外到内、分层采集证据，而不是靠经验瞎猜。
先看容器“活没活着”
执行 docker ps -a，重点看三列：
- STATUS：是 Up 2 seconds 还是 Exited (137)？退出码 137 表示被 OOM 杀掉，143 是正常终止，其他数字要查对应含义
- PORTS：端口映射是否为空或显示 0.0.0.0:？说明没成功暴露
- CREATED：如果容器反复重建（时间很新），大概率是启动后立刻崩溃
再查它“为什么活不了”
对异常容器，立刻运行这组命令，顺序不能乱：
- docker inspect 容器名：确认 IP、挂载路径、环境变量、重启策略是否符合预期；特别注意 State.Status 和 State.ExitCode
- docker logs --tail 100 容器名：只取最后 100 行，避免刷屏；加 -t 看时间戳，判断崩溃发生时刻
- docker logs --since "2026-09-25T02:00:00" 容器名：按时间范围拉日志，比盲目翻更准
网络连不通？别只 ping
“连不上”是最模糊的说法，得拆开验证：
- 查容器有没有 IP：docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' 容器名
- 查宿主机能否通容器 IP：curl -v http://容器IP:端口 或 nc -zv 容器IP 端口
- 查容器能不能访问依赖服务：docker exec 容器名 curl -v http://服务名:端口（确保在自定义网络中）
- 查 DNS 是否生效：docker exec 容器名 cat /etc/resolv.conf，对比宿主机的 /etc/resolv.conf
容器里啥都没有？那就别进去了
slim/hardened 镜像没有 sh、bash、netstat——这是设计，不是缺陷。排查必须绕过容器内部：
- 用 docker top 容器名 看进程是否真在跑，PID 是否频繁变化
- 用 docker stats --no-stream 容器名 看 CPU、内存是否瞬间飙高后归零（典型启动失败循环）
- 用 docker port 容器名 确认端口映射规则是否生成，再用 ss -tlnp | grep :端口 查宿主机上谁在监听
- 把 docker inspect 输出重定向保存：docker inspect 容器名 > inspect-$(date +%s).json，留作复盘依据
