docker run 的容器重启后没自动起来：--restart 三种策略怎么选

服务器重启后，之前 docker run 起来的容器没跟着起来，这是新手最常踩的坑之一。问题不在容器本身，而在两处：docker 服务有没有开机自启，以及容器有没有配重启策略。先把这两处分开查，就不难定位。

一、先确认 docker 服务本身会开机自启

容器要靠 daemon 拉起来，daemon 自己没起来，什么策略都没用。先看服务状态：

systemctl status docker

如果没设开机自启，先补上：

systemctl enable docker

这一步是前提，后面说的策略都是建立在 daemon 能起来的基础上的。

二、–restart 有哪几种，先讲清楚再选

docker run 的 --restart 参数决定容器退出后怎么办，常见四种：

1. no：默认策略，不自动重启。容器退了就停在那里，适合只跑一次的调试任务。
2. on-failure：只有非零状态退出时才重启，还可以加次数，比如 on-failure:3，最多重试 3 次。适合偶尔闪退、但不值得无限重试的任务。
3. always：不管什么原因退出都重启。哪怕你手动 docker stop 停掉它，下次 daemon 重启时它还是会被拉起来，约束力最强。
4. unless-stopped：和 always 很像，区别只在手动停掉的情况：你手动 stop 的容器，daemon 重启后不会自动拉起来；只有非手动原因退出的，才会自动重启。

日常跑服务，我一般选 unless-stopped：既能做到重启自愈，又不会出现“我明明手动停了，它怎么又起来了”的困惑。需要强保证、停了也必须拉起来的，才用 always。

三、新容器：run 的时候就把策略带上

起新容器时直接在命令里写清楚，别事后补：

docker run -d --name my-app --restart=unless-stopped my-image

把 my-app 和 my-image 换成自己的容器名和镜像名。写在命令里，以后不管谁来接手，一眼就能看出这个容器的重启策略。

四、已经跑起来的容器：用 update 改，不用重建

容器已经在跑了，不想删了重建，可以直接改策略，立即生效：

docker update --restart=unless-stopped my-app

改完用 inspect 确认一下：

docker inspect my-app --format '{{.HostConfig.RestartPolicy.Name}}'

输出 unless-stopped 就说明改对了。注意 update 只改策略，不会重启容器本身，正在跑的服务不受影响。

五、验证：别只看一次 ps 就算完

改完策略，建议按这个顺序验一遍：

1. docker ps 看容器在跑；
2. 重启服务器（或重启 docker 服务）；
3. 再 docker ps，看容器是不是自己回来了；
4. 顺手看一下日志，确认应用本身也正常起来了，不只是容器进程在。

如果重启后容器还是没起来，按顺序排查：先看 systemctl status docker，再看 docker inspect 的 RestartPolicy，最后看容器日志。多数情况卡在前两步：要么 daemon 没设自启，要么策略根本没写上。

小结

服务器重启后容器自启 = docker 服务开机自启 + 容器配了合适的 --restart 策略。两个条件缺一不可；策略上日常选 unless-stopped，需要强保证再选 always。