外观
容器问题
第一步永远是看日志
sh
docker logs -n 100 容器名容器起不来时，日志几乎总能给出原因。先看它，再做其他猜测。 如果容器反复重启，日志会滚动刷新，用 docker logs 看最后几十行通常就够。
症状一：容器启动后立刻退出
| 日志里的线索 | 原因 |
|---|---|
permission denied | 挂载目录的权限不对，见下文 |
address already in use | 端口被占用 |
no such file or directory | 挂载路径写错了，或者宿主机上不存在 |
| 数据库连接失败 | 依赖的容器还没起来，或网络配置不对 |
| 配置文件解析错误 | 环境变量或配置文件有误 |
症状二：端口冲突
先找出谁占用了这个端口：
sh
ss -tlnp | grep 8080处理方式：改宿主机侧的映射端口，而不是容器内部端口。例如把 8080:80 改成 8081:80。常见端口的默认值见端口速查。
症状三：镜像拉取失败
按层排查，详见逐层排查镜像拉取失败：
- 镜像名和标签拼写是否正确。
- 架构是否匹配（ARM 设备不能跑 amd64 镜像）。
- DNS 是否正常：在 NAS 上解析一个外网域名试试。
- 网络连通性：能否访问镜像仓库。
- 是否需要认证：私有镜像需要先登录。
症状四：权限报错
容器内的进程以某个用户身份运行，它需要对挂载进来的目录有相应权限。
排查思路：
- 确认容器以哪个 UID/GID 运行（多数镜像支持用环境变量指定）。
- 检查宿主机上被挂载目录的所有者和权限。
- 让两者匹配——优先调整目录的属主，而不是把目录权限改成 777。
目录规划的正确做法见规划 Docker 应用目录与权限。
症状五：容器之间连不通
- 同一个自定义网络里的容器可以用容器名互相访问，默认 bridge 网络不行。
- 容器访问宿主机上的服务，不能用
127.0.0.1——那是容器自己。 - 网络模式的区别见bridge、host、macvlan。
症状六：更新后容器坏了
- 先看日志，多数是配置格式变更或需要数据库迁移。
- 查看该镜像的发布说明，确认是否有破坏性变更。
- 回滚到之前的版本标签——这就是为什么不该用
latest标签，见安全更新容器。 - 从备份恢复数据目录（如果更新过程改写了数据）。
症状七：磁盘被容器占满
sh
docker system df # 查看镜像、容器、卷各占多少
docker image ls # 列出所有镜像常见的占用来源：旧版本镜像、停止但未删除的容器、容器日志。清理前先确认哪些镜像还在被使用，不要盲目执行清理命令。