直接看崩溃前的最后几行日志是最快速定位应用退出原因的方式，使用docker logs --tail 50 <容器名或ID>可精准捕获终止瞬间的错误线索，配合--timestamps便于比对崩溃时刻，若日志为空则需检查应用是否写入文件或是否启用--log-driver=none。
直接看崩溃前的最后几行日志，是最快速定位应用退出原因的方式。关键不是“全量翻查”，而是精准捕获终止瞬间的错误线索。
用 docker logs --tail 快速抓末尾报错
容器已退出但未被删除时，docker logs 仍可读取其 stdout/stderr 缓存：
-
docker logs --tail 50 <容器名或ID>：只显示最后 50 行，通常足够覆盖崩溃前堆栈、panic 或 exit message -
docker logs --tail 100 --timestamps <容器名>：带时间戳，便于比对崩溃时刻（如配合docker ps -a中的 CreatedAt） - 如果日志里有明显关键字（如
FATAL、panic:、java.lang.OutOfMemoryError、exit code 137），基本能一锤定音
容器反复重启时，用 --previous 查上一次实例
在 Kubernetes 环境中，Pod 内容器崩溃后重启，旧实例日志默认保留。此时标准 kubectl logs 只能看到当前运行实例——而问题往往出在上一次：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 单容器 Pod：
kubectl logs <pod-name> --previous - 多容器 Pod：
kubectl logs <pod-name> --previous -c <container-name> - 该命令实际读取的是 kubelet 维护的上一个容器实例的日志文件链接（指向
/var/log/pods/.../xxx.log），无需容器还存在
结合退出码和状态确认崩溃性质
光看日志不够，需对照退出行为判断根本类型：
- 执行
docker ps -a | grep <容器名>，看状态栏是否为Exited (137)—— 这代表被 OOM Killer 杀掉，不是应用自身报错，而是内存超限 -
docker inspect <容器ID> --format='{{.State.OOMKilled}}'返回true可确认 - 退出码为
143说明收到 SIGTERM 后正常关闭；1多为启动脚本失败、命令不存在或配置加载异常
日志为空？检查应用是否写到了文件里
有些应用（如 Nginx、Java Spring Boot 默认配置）不输出到 stdout，而是写进容器内日志文件：
- 先尝试：
docker exec <容器名> tail -50 /var/log/app.log（路径按实际调整，常见有/app/logs/、/var/log/nginx/error.log） - 若容器已退出但未删，仍可用
docker cp拷出日志文件分析：docker cp <容器名>:/var/log/app.log ./app.log - 注意：若启动时指定了
--log-driver=none，docker logs必然为空，必须查应用日志文件
