容器启动失败应先观察退出状态和退出码：exited (1) 表示应用启动失败，127 为命令未找到，137 为 oom 被杀，139 为段错误；再结合 docker inspect 查 state.error、docker logs 加参数定位日志，并可手动运行入口点调试，同时排查主机端口、磁盘、内存及安全模块等环境问题。
容器启动失败，别急着重装镜像或删配置。先看它“退得有多快”——是根本没创建成功，还是启动后秒退？不同表现对应不同排查路径。
查状态和退出码
运行 docker ps -a，找到目标容器，重点看 STATUS 列。如果显示 Exited (1) 或类似格式，括号里的数字就是退出码：
- Exit code 1：通常是应用启动失败，比如配置文件错误、命令语法不对、依赖缺失
- Exit code 127：找不到可执行文件，比如镜像里没装
sh却用了/bin/sh启动 - Exit code 137：被系统 OOM Killer 杀掉，说明内存严重不足
- Exit code 139：段错误，常见于二进制不兼容（如 ARM 镜像跑在 x86 主机）
再用 docker inspect 容器名 查 State.Error 字段，有时会直接写出失败原因，比如 "failed to create endpoint: failed to add endpoint to sandbox" 就指向网络初始化问题。
读日志要带参数
docker logs 容器名 是起点，但默认只输出全部历史日志，容易淹没关键报错。建议加这些参数：
-
--tail 50：只看最后 50 行，聚焦最新错误 -
-f：实时跟踪，适合反复重启的容器 -
-t：带上时间戳，方便比对其他服务日志 -
--since "2026-07-06T14:00:00"：查指定时间之后的日志，避开旧干扰项
注意：如果 docker run 命令本身就报错（比如 “port is already allocated”），那容器根本没生成，日志也不存在——这时候错误信息就在终端里，别跳过。
绕过入口点手动调试
日志只说 “application failed to start”，但没说哪一行代码崩了？那就进容器内部自己跑一遍：
- 用
docker run -it --rm --entrypoint /bin/sh 镜像名进入一个干净 shell - 如果镜像没
/bin/sh，试试/bin/ash（Alpine）或sh - 进去后，手动执行原启动命令，比如
npm start或java -jar app.jar - 顺便检查权限：
ls -l /app/config.yml、确认挂载目录是否可写：touch /data/test && rm /data/test
这一步能暴露配置路径错、环境变量没生效、用户权限不够等深层问题。
盯住宿主机环境
很多失败其实跟容器无关，而是主机“拦路”：
-
端口冲突：用
sudo lsof -i :8080（Linux/macOS）或netstat -ano | findstr :8080（Windows）查谁占了端口 -
磁盘满：
df -h /var/lib/docker，超 90% 就可能触发静默失败 -
内存告急：
free -h看可用内存，再dmesg | grep -i "killed process"确认是否被 OOM 杀过 -
SELinux 或 AppArmor：CentOS/RHEL 上临时
setenforce 0测试是否为此限制
特别是宝塔面板用户，注意它可能自动生成 /etc/docker/daemon.json，JSON 格式出错会导致 Docker 服务整个起不来，可用 jq . /etc/docker/daemon.json 验证语法。
