容器处于 exited 状态但 docker logs 为空，主因是日志未产生或被禁用：需先检查 logconfig.type 是否为 "none"；再验证 exitcode（如127表示命令未找到）；若应用写文件日志（如 nginx），则需用 docker cp 提取对应日志文件分析。
容器处于 exited 状态但 docker logs 输出为空，不是日志丢失，而是日志根本没产生或被禁用——关键要分清“没日志”和“看不到日志”是两回事。
确认日志是否真实存在
执行 docker logs <container_id></container_id> 为空时，先验证容器是否真的输出过内容：
- 运行
docker inspect <container_id> | grep -A 5 'LogConfig'</container_id>，检查"Type": "json-file"是否存在；若为"none"，说明启动时加了--log-driver=none，Docker 压根没记录 stdout/stderr - 执行
docker inspect <container_id> | grep -A 10 'State'</container_id>，确认FinishedAt时间是否合理、ExitCode是否非零（如 1、127、137） - 若
ExitCode是 127，常见于命令未找到（如镜像里没有sh或bash），主进程甚至没来得及执行就失败，自然无日志
排查应用自身是否绕过 stdout 写日志
很多服务（如 Nginx、Java 应用、Supervisor 管理的进程）默认把日志写入文件而非终端。此时 docker logs 必然为空：
OpenClaw Docker Setup
下载
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
- 查镜像文档或 Dockerfile，确认日志路径（如
/var/log/nginx/error.log、/app/logs/app.log） - 用
docker cp <container_id>:/path/to/app.log ./app.log</container_id>拷出日志文件本地分析 - 后续优化：构建镜像时重定向应用日志到 stdout（例如 Nginx 加
daemon off; error_log /dev/stdout info;）
临时进入容器环境复现与诊断
只要容器没被 rm 删除，就能复用其挂载卷、网络配置做深度检查：
- 用交互方式运行同镜像：
docker run -it --volumes-from <exited_name> --network container:<exited_name> --rm <image_name> sh</image_name></exited_name></exited_name> - 进 shell 后检查：
ls -l /etc/（配置是否存在）、ls -l /usr/bin/（二进制是否缺失）、cat /proc/self/cgroup（是否被限制内存导致 OOM） - 手动执行原 CMD 命令（通过
docker inspect <id> --format='{{.Config.Cmd}}'</id>获取），观察是否报错（如Permission denied、kernel too old）
预防下次再“静默退出”
避免再次陷入“Exited + 无日志”的被动局面：
- 启动时加
--log-opt max-size=10m --log-opt max-file=3，防止日志轮转误删 - 开发阶段优先使用
docker run -it而非-d，第一时间看到终端输出 - 对关键服务，在入口脚本开头加
set -x，让每条命令执行过程都打印出来 - 镜像中避免用
CMD ["app"]这种极简写法，改用CMD ["sh", "-c", "exec app 2>&1"]显式捕获错误流
