Docker 容器反复重启时，用 docker inspect 查看退出码、OOM 标记、重启次数和重启策略，再用同一时间段的容器日志定位主进程退出原因。重启策略决定 Docker 是否尝试拉起容器，修复要针对导致退出的问题。

适用版本与前提

示例面向 Linux 上的 Docker Engine 25.0 及以上版本，由官方文档整理，未在目标环境实测。需要有权限访问目标 Docker daemon。将示例名称 web 替换为实际容器名或 ID。Swarm 服务要查看服务和任务的状态，本文步骤以普通容器为对象。

先保留容器状态和应用日志

  1. 确认当前 Docker context，并用 docker ps -a 找到目标容器，记录容器 ID。排查过程中用同一个 ID，避免重建后误把新容器当成原容器。
  2. 用 inspect 读取 Docker 保存的状态和实际生效的重启策略。连续重启时状态可能很快变化，保存多次采样时间，观察 RestartCount 是否持续增加。
  3. 读取近十分钟的应用日志，并按时间戳对照退出时刻。若故障发生得更早，应调整时间范围。
docker context show
docker ps -a
docker inspect --type container --format '{{json .State}}' web
docker inspect --type container --format '{{.RestartCount}} {{json .HostConfig.RestartPolicy}}' web
docker logs --since 10m --timestamps --tail 100 web

--type container 将查询限定为容器，--format 用模板选出字段。--since 10m 限定日志时间范围，--tail 100 控制行数。先看 ExitCode、OOMKilled、Error 和 FinishedAt。如果进程已再次启动，再与历史日志对照。Docker inspect 官方参考

按证据判断退出原因

  • 退出码为 0 时，检查入口命令是否完成后正常退出。一次性任务可能本来就该结束。持续服务则要检查应用是否保持在前台运行。
  • 退出码非零时，先读退出前的应用错误，核对配置、挂载路径和依赖是否就绪。若 OOMKilled 为 true，再核对容器内存上限、宿主机内存压力和故障时的系统日志。退出码 137 本身不足以确认 OOM。
  • 应用日志为空时，检查 State.Error 是否记录了启动阶段错误，再确认应用是否写入标准输出或标准错误，以及所用日志驱动能否通过 docker logs 读取。

检查重启策略是否符合用途

no 不自动重启。on-failure 仅对非零退出触发重启，可设置重试上限，daemon 重启本身不会靠此策略拉起容器。always 和 unless-stopped 的区别之一是手动停止后再次启动 daemon 时，前者可恢复启动，后者维持停止状态。先确认当前策略，再在部署配置中按服务用途维护它。Docker 容器重启策略官方说明

修复后怎样验证

按原部署流程应用修复，再用同样的命令记录容器 ID、运行状态和重启次数。跨过此前常见的退出时间观察同一容器，确认重启计数不再增加，日志不再出现原错误，并从正常客户端验证业务请求。若部署重建了容器，按新 ID 建立新的计数基线。

容器一直运行，但显示 unhealthy 怎么办？

先检查是否确有主进程退出。若状态保持运行且重启次数稳定，应检查健康探针的命令和日志。Docker 容器 unhealthy 的排查步骤