Docker 容器重启策略详解：always / unless-stopped / on-failure 怎么选

原创于 2026-10-08 09:00:04 发布 · 177 阅读

0 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

Docker实战学习手册

服务器重启后容器没跟着起来、容器崩了没人拉、或者反过来——你明明 docker stop 了它却又自己活过来。这三个现象背后都是同一个配置在起作用：重启策略（restart policy）。

很多人图省事一律写 restart: always，结果在"手动停止后宿主机重启，容器又自己跑起来"这种场景踩坑。这篇把四种策略的行为差异讲透，给出一张行为对照表和选型建议。

四种策略

策略	含义
no	默认值。任何情况都不自动重启
on-failure[:次数]	仅当容器非 0 退出码退出时重启，可限制最大重试次数
always	无论怎么停的都重启；宿主机/Docker 守护进程重启后也拉起
unless-stopped	类似 always，但手动 stop 过的容器，守护进程重启后不再拉起

设置方式：

docker run -d --restart unless-stopped --name app myapp:1.0

# on-failure 限制重试 5 次
docker run -d --restart on-failure:5 --name worker myworker:1.0

Compose：

services:
  app:
    image: myapp:1.0
    restart: unless-stopped

行为对照表（核心）

四种策略在三个关键场景下的表现：

场景	no	on-failure	always	unless-stopped
容器崩溃（非 0 退出）	不重启	重启	重启	重启
容器正常退出（退出码 0）	不重启	不重启	重启	重启
手动 docker stop 后	保持停	保持停	保持停	保持停
手动 stop 后宿主机重启	保持停	保持停	自动拉起	保持停
未手动 stop，宿主机重启	保持停	保持停	自动拉起	自动拉起

always 和 unless-stopped 的唯一区别就在第四行：手动 stop 之后宿主机重启，always 会把容器再拉起来（因为它只认"是否被 stop 过"在 daemon 重启时被重置），unless-stopped 会记住"你手动停过"，保持停止。

这个差异在运维时很要命：你为了维护手动 stop 了一个容器，重启服务器后发现它又跑起来了（always），可能干扰维护窗口或抢占端口。用 unless-stopped 就不会。

on-failure 的"正常退出不重启"：如果容器以退出码 0 结束（比如一个跑完就退的批处理任务），on-failure 不会重启它——这正是批处理想要的行为。而 always 会把它再拉起来无限循环跑，批处理任务用 always 是灾难。

查看和修改现有容器的策略

查看：

docker inspect <容器名> --format '{{.HostConfig.RestartPolicy.Name}} {{.HostConfig.RestartPolicy.MaximumRetryCount}}'
# 输出如：unless-stopped 0
#        on-failure 5

批量看所有容器：

docker ps -a --format "{{.Names}}\t{{.Status}}" 
for c in $(docker ps -aq); do
  echo -n "$(docker inspect $c --format '{{.Name}} ')";
  docker inspect $c --format '{{.HostConfig.RestartPolicy.Name}}';
done

修改运行中的容器（不用重建）：

docker update --restart unless-stopped <容器名>

# 取消自动重启
docker update --restart no <容器名>

docker update 对重启策略立即生效，不用重启容器，运维改策略很方便。

选型建议

长期运行的服务（Web、数据库、中间件） → unless-stopped

理由：崩溃要自动拉起，宿主机重启要自动恢复，但尊重运维的手动停止。这是生产环境最稳妥的默认值。

批处理 / 一次性任务（跑完就退） → no 或 on-failure:N

理由：正常退出（码 0）不该重启。失败时希望重试几次就用 on-failure:3，避免无限重试。绝不要用 always。

容易抖动但希望有限重试的服务 → on-failure:N

理由：限制重试次数，避免 crash loop 把资源耗死或把日志刷爆。超过次数后保持停止，等人介入。

开发 / 测试容器 → no

理由：开发时你经常手动 stop/start，自动重启会干扰调试。

重启的退避机制（backoff）

Docker 对自动重启有指数退避：第一次崩溃后等 100ms 重启，再崩等 200ms、400ms、800ms……最长到 1 分钟。目的是避免 crash loop 瞬间打满 CPU 和日志。

这意味着：容器崩溃后不会立刻复活，docker ps 里可能短暂看到 Restarting 状态：

docker ps
# STATUS: Restarting (1) 10 seconds ago

Restarting (1) 里的 1 是退出码。看到这个状态说明容器在反复崩溃-重启循环，用 docker logs 看崩溃原因，而不是怪重启策略。

容器成功运行 10 秒后，退避计数器重置。所以一个稳定跑了很久再崩的容器，重启会很快（从 100ms 重新开始）。

几个常见误区

误区一：restart 能修复崩溃。不能。重启策略只是"崩了再拉起来"，崩溃的根因（配置错、OOM、依赖没就绪）还在。容器反复 Restarting 时先查 docker logs，别指望重启策略兜底。

误区二：on-failure 会对任何停止都重试。只对非 0 退出码。正常退出（0）不重试。想"无论如何都拉起"用 always/unless-stopped。

误区三：docker stop 后策略就失效了。stop 之后容器是 stopped 状态，策略不触发（没在崩）。但宿主机重启后，always 会无视你之前的 stop 把容器拉起，unless-stopped 才不会。这是两者关键差异。

误区四：Compose 的 restart 和 deploy.restart_policy 是一回事。单机 docker compose up 用 restart: 字段；swarm 模式用 deploy.restart_policy。非 swarm 场景写 restart: 就够了，两个都写可能冲突。

与依赖顺序的配合

重启策略只管"单个容器崩了拉起来"，不管容器之间的启动顺序。如果 app 依赖 mysql，宿主机重启后两者都被拉起，但 mysql 可能还没就绪 app 就启动连库失败。

配合健康检查依赖（Compose）才能解决顺序问题：

services:
  mysql:
    image: mysql:8.4
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 10
  app:
    image: myapp:1.0
    restart: unless-stopped
    depends_on:
      mysql:
        condition: service_healthy

这样宿主机重启后，app 会等 mysql 健康检查通过才启动，避免"重启后应用连不上库"的经典问题。重启策略 + 健康检查依赖，两者配合才是完整的自愈方案。