Docker 容器异常退出排查如何做

容器一启动就退出，关键先看状态、日志、资源：Exited (0)为正常结束，非0退出码（如1、127、137）指向命令错误、文件缺失或OOM；docker logs查stdout/stderr线索；137需检查内存限制及tmpfs配置；最后用docker run -it交互验证启动命令。

容器一启动就退出，不是配错端口就是踩了坑。关键不是马上改配置，而是先看清它为什么走——状态、日志、资源，三步就能锁定八成问题。

看退出码和状态，分清“正常结束”还是“挂了”

执行 docker ps -a，找到目标容器，重点盯 STATUS 列：

1. Exited (0)：主进程跑完就收工，比如 docker run hello-world，这是设计如此，不用修；
2. Exited (1)、(127)、(137)：异常退出——1 多是命令写错或依赖缺失，127 常见于找不到可执行文件，137 几乎等于被系统杀掉（OOM）；
3. Up 2 seconds 或反复重启：说明 pid 1 进程没稳住，大概率是应用后台化（如 nginx 默认 daemon on）、脚本执行完就退出，或 entrypoint 写法不对。

查日志，90% 的线索藏在 stdout/stderr 里

用 docker logs --tail 100 容器名 看最后百行输出。注意：

1. 只能看到打印到控制台的日志，写进 /var/log/xxx.log 的内容不会出现；
2. 如果日志空空如也，别急着怀疑代码，先检查是不是应用根本没启动成功（比如配置文件路径错、环境变量没传）；
3. 常见报错如 Connection refused（连不上数据库）、No such file or directory（找不到 jar 或 bin）、Address already in use（端口被占），直接定位根因。

查资源限制，OOM 和 tmpfs 不够最隐蔽

退出码是 137 或 docker inspect 容器名 显示 "OOMKilled": true，基本就是内存超限：

1. 运行 dmesg | grep -i "killed process"，确认内核是否杀了它；
2. 检查容器是否设了 -m 或 mem_limit，数值是否太小；
3. 临时目录（如 /tmp）如果挂了 tmpfs 却没设 size，应用写缓存失败也会静默退出——加 --tmpfs /tmp:size=512m 就能试出来。

进容器手动验证，绕过启动逻辑直击问题

如果以上都看不出头绪，用 docker run -it 镜像名 /bin/sh 进去，手动执行启动命令（比如 nginx -t、java -jar app.jar）：

1. 能跑通说明配置没问题，问题出在 Docker 启动方式（CMD/ENTRYPOINT 写法）；
2. 报错则暴露真实依赖或权限问题（比如证书路径不对、用户没权限读配置）；
3. 特别注意：有些镜像要求非 root 用户运行，但 Docker 默认以 root 启动，得加 --user 参数模拟。