云服务器Docker常见故障：诊断与解决指南

在云服务器上用Docker部署应用时，最让人头疼的就是容器突然启动失败，或者镜像拉取卡壳。今天就以两个高频问题为例，手把手教你诊断和解决。

容器无法启动：从报错到修复的全流程

用户常见场景

刚在云服务器上买了新实例，想快速跑一个Nginx容器，输入`docker run -p 80:80 nginx`命令后，终端跳出提示：“Error response from daemon: Cannot start container”，浏览器输入公网IP也打不开页面。这是容器无法启动的典型表现。

如何快速定位问题？

容器启动失败的“线索”藏在日志里。用`docker logs <容器ID>`命令（不知道ID的话，先执行`docker ps -a`查看），能直接看到具体报错。比如日志显示“Bind for 0.0.0.0:80 failed: port is already allocated”，说明80端口被其他进程占用了；如果提示“Connection refused to mysql:3306”，那可能是容器依赖的数据库服务没启动。

针对性解决方法

- **端口冲突**：用`netstat -tulnp | grep 80`查哪个进程占了端口，假设显示“1234/python3”，就执行`kill -9 1234`终止进程。如果不想关进程，也可以修改容器端口映射，比如`-p 8080:80`，把容器80端口映射到云服务器的8080端口。
- **依赖服务未启动**：比如容器需要连接MySQL，先检查MySQL容器是否运行（`docker ps`看状态），没启动的话用`docker start mysql-container`启动，再重启当前容器。
- **镜像损坏**：如果日志提示“invalid header”之类的镜像错误，直接删了重拉。用`docker rmi nginx`删除镜像，再`docker pull nginx`重新拉取最新版。

镜像拉取失败：网络与仓库的排查技巧

用户真实痛点

想拉取最新的Ubuntu镜像，输入`docker pull ubuntu`后等了十分钟，终端显示“net/http: TLS handshake timeout”，进度条一直卡在10%——这是镜像拉取失败的常见现象，有时还会遇到“unauthorized: authentication required”的认证错误。

三步诊断法

第一步查网络：用`ping registry-1.docker.io`测试与Docker官方仓库的连通性。如果丢包率高（比如连续5次ping有3次超时），说明是云服务器网络问题；如果能ping通但拉取慢，可能是仓库负载高或被墙了。
第二步查仓库状态：访问Docker Hub官网（需科学上网），看是否有“服务维护”公告。曾有用户遇到过因仓库区域性故障，导致国内云服务器拉取超时的情况。
第三步查认证：如果拉取的是私有镜像，终端提示“authentication required”，说明没登录仓库账号。这时候执行`docker login`，输入账号密码就能解决。

分情况处理方案

- **网络问题**：修改云服务器的Docker代理配置。编辑`/etc/docker/daemon.json`文件（没有就新建），添加：
```
{
"proxies": {
"default": {
"httpProxy": "http://proxy.example.com:8080",
"httpsProxy": "http://proxy.example.com:8080"
}
}
}
```
保存后执行`systemctl restart docker`重启服务，再试拉取。
- **仓库不可用**：换用其他镜像源，比如国内的阿里云镜像（需注意：这里仅作示例，实际替换为可用的公共镜像地址）。修改`daemon.json`添加`"registry-mirrors": ["https://xxx.mirror.aliyuncs.com"]`，同样重启Docker。
- **认证失败**：直接`docker login`，按提示输入用户名和密码，认证成功后再拉取私有镜像。

在云服务器上用Docker遇到故障时，关键是保持冷静。先看日志定位问题类型，再针对性排查网络、端口或依赖，大部分情况都能快速解决。掌握这些方法，云服务器的Docker环境运维会更高效省心。