Docker 容器频繁重启、端口冲突、镜像拉取失败？运维排坑实战指南

前言：容器化部署的“甜蜜”与“负担”

最近有不少朋友在后台私信我，说公司业务上了 Docker 之后，确实爽——一条命令就能拉起整套环境，开发、测试、生产环境高度一致。但爽完之后，运维的“坑”也随之而来。容器频繁 Crash、端口被莫名占用、镜像 build 到一半失败、磁盘空间被悬空镜像塞满……这些问题如果不摸清底层逻辑，排查起来真的会让人头秃。

笔者自己维护过几十台生产节点的 Docker 集群，也踩过无数“新手村”的坑。今天这篇文章不聊虚的，直接针对大家高频遇到的 4 个报错和疑问，从根因到实操，手把手带你把 Docker 运维的硬骨头啃下来。全文干货，建议收藏后对照操作。

疑问一：容器启动后一直处于 Restarting 状态，日志却看不到报错？

🔥 【限时特惠福利】高性价比独享云服务器限时 1 折起

搭建网站或部署容器推荐选择高稳定性独享云服务器。限时特惠通道开放中，点击即可领取专属满减代金券与特惠折扣：

👉 立刻领取云服务器限时优惠券

💡 延伸阅读：从零到生产级：一位老站长手把手教你用Docker搭建可维护的软件交付流水线

Q1：docker ps 显示 STATUS 为 “Restarting (1) 5 seconds ago”，docker logs 却只输出几行无关紧要的信息，这到底是什么情况？

这是新手运维最常遇到的头号问题。很多朋友第一反应是“代码写错了”，但往往忽略了一个关键点：容器的主进程（PID 1）是否在前台运行。

根因剖析：Docker 容器不是虚拟机，它只是一个进程隔离环境。如果你的启动命令（CMD 或 ENTRYPOINT）执行的是一个后台守护进程（比如 nginx 或 java -jar xxx.jar &），那么容器启动后，PID 1 进程会立刻执行完毕并退出。由于 Docker 默认的 restart 策略是 no，但如果你指定了 --restart=always，Docker 就会无限尝试重启，导致 STATUS 一直显示 Restarting。

另外，健康检查（HEALTHCHECK）失败也会导致容器被强制重启，但这种情况通常日志里会有 unhealthy 的提示。

解决方案：

首先，我们需要确认主进程是否正确。以 Nginx 为例，Dockerfile 中的正确写法应该是：

# 错误写法：后台运行导致容器秒退
CMD ["nginx", "-g", "daemon off;"]
# 或者使用 service 命令（不推荐，因为 service 会 fork 出子进程）

正确的做法是确保主进程在前台运行。对于 Java 应用，请使用 exec java -jar app.jar，而不是 java -jar app.jar &。

如果代码没问题，检查一下健康检查配置。如果你在 Dockerfile 或 compose 文件中配置了 HEALTHCHECK，请手动在容器内执行一下该命令，看是否返回非 0 状态码：

# 进入容器手动执行健康检查命令
docker exec -it <container_id> /bin/sh
curl -f http://localhost:8080/health
echo $?   # 如果输出非 0，说明健康检查命令本身有问题

预防建议：写 Dockerfile 时，务必保证 CMD/ENTRYPOINT 指向前台进程。同时，不要轻易使用 --restart=always，建议使用 --restart=unless-stopped，避免因手动 stop 后又被自动拉起。

疑问二：端口映射成功但外部无法访问，防火墙也关了为什么？

💡 深度技术指南：Linux服务器配置与安全管理：三套主流方案实测对比，哪套更适合你的生产环境？

Q2：docker run -p 8080:80 已经执行，ss -ltn 也能看到 8080 端口在监听，但浏览器就是打不开，防火墙也关了，这合理吗？

这个问题的迷惑性极强。很多朋友在云服务器上部署，第一反应是安全组规则没配好，但检查后发现安全组放行了所有端口，问题依旧。

根因剖析：这里隐藏着一个非常容易被忽略的 Docker 网络模式知识点。当你使用 -p 8080:80 时，Docker 默认通过 Docker-proxy（用户态进程）和 iptables NAT 规则来实现端口转发。如果你在启动 Docker 服务时，修改了 /etc/docker/daemon.json 中的 "iptables": false，那么 Docker 将不会自动写入 NAT 规则，导致流量无法转发到容器内部的 80 端口。

此外，还有一个常见原因：容器内的服务只监听了 IPv6 地址。如果你的容器基础镜像默认只绑定了 :: 或 127.0.0.1，而你的宿主机 IPv4 端口映射正常，但容器内服务未监听 0.0.0.0，同样无法访问。

解决方案：

第一步，检查 Docker 的 iptables 规则是否生效：

iptables -t nat -L -n | grep 8080
# 如果没有输出，说明 Docker 没有写入 NAT 规则

如果确实没有规则，请检查 /etc/docker/daemon.json，确保没有设置 "iptables": false。修改后重启 Docker：

systemctl restart docker

第二步，如果规则存在但依然无法访问，进入容器检查服务监听地址：

docker exec -it <container_id> netstat -tlnp
# 如果显示 127.0.0.1:80 或 :::80，说明服务绑定地址有误

修改应用配置，将监听地址改为 0.0.0.0 即可。

预防建议：在云平台购买服务器时，一定要在控制台的安全组中额外放行 Docker 映射的端口，不要盲目依赖系统防火墙。同时，尽量保持 Docker 默认的 iptables 管理功能开启。

疑问三：镜像构建时提示 “no space left on device”，但 df -h 显示磁盘还有几十 G？

Q3：docker build 过程中报错 no space left on device，可是我用 df -h 查看根分区还有 50G 可用，这磁盘空间到底去哪了？

这个问题非常经典，也是笔者当年在构建大型镜像时踩过的坑。根因在于 Docker 使用的存储驱动（Storage Driver）与磁盘配额机制。

根因剖析：Docker 默认的存储驱动是 overlay2。它会在你 Docker 根目录（通常是 /var/lib/docker）下创建多层目录。如果你的 Docker 根目录所在分区是独立挂载的（比如单独挂载了 /var/lib/docker），那么 df -h / 看到的是根分区空间，而 Docker 实际使用的是另一个分区。

另外，inode 耗尽也会导致这个报错。当你的镜像层数非常多，或者有小文件碎片堆积时，即使磁盘空间充足，inode 用完了也无法创建新文件。

解决方案：

第一步，确认 Docker 根目录所在分区的真实使用率：

df -h /var/lib/docker
df -i /var/lib/docker   # 查看 inode 使用率

如果发现是 /var/lib/docker 分区满了，最直接的清理方式是删除悬空镜像和停止的容器：

# 一键清理所有悬空镜像（无标签镜像）
docker image prune -f
# 清理所有停止的容器
docker container prune -f
# 终极清理：清理所有无用数据（慎用，会删除所有未运行的容器和未使用的镜像）
docker system prune -a -f

如果空间还是不够，且你的数据盘有空间，可以通过修改 daemon.json 将 Docker 数据目录迁移到大分区：

# 编辑 /etc/docker/daemon.json
{
  "data-root": "/data/docker"
}
# 重启 Docker 生效（注意：迁移后原有镜像不会自动迁移，需要重新 pull）
systemctl restart docker

预防建议：在生产环境，强烈建议将 /var/lib/docker 单独挂载到容量大、性能好的数据盘。同时，建立定时任务定期执行 docker image prune，避免 CI/CD 频繁构建导致磁盘暴涨。

疑问四：Docker Compose 中多个容器如何实现互相通信？用 IP 还是服务名？

Q4：我写了 docker-compose.yml 启动了 3 个服务（nginx, php, mysql），但 php 容器里 ping mysql 的 IP 能通，ping mysql 这个服务名却不通，这是为什么？

这个问题的本质是对 Docker 默认网络模式的理解不够透彻。

根因剖析：Docker Compose 会自动为你创建一个默认的网络（默认是 bridge 驱动），并将所有服务连接到该网络。在这个网络内部，Docker 内置了 DNS 解析，服务名（即容器名）可以互相解析。但如果你在 docker-compose.yml 中显式指定了 network_mode: "host"，或者手动指定了 networks 但配置不当，就会导致 DNS 解析失败。

另外，如果你用 docker run 单独启动了一个容器，并希望通过服务名访问 compose 中的服务，那是行不通的，因为该容器不在 compose 创建的网络里。

解决方案：

确保你的 docker-compose.yml 配置正确，示例配置如下：

version: "3.8"
services:
  mysql:
    image: mysql:8.0
    networks:
      - backend
  php:
    image: php:7.4-fpm
    networks:
      - backend
    depends_on:
      - mysql
networks:
  backend:
    driver: bridge

在 php 容器中，直接使用 mysql 作为主机名连接数据库即可：

// PDO 连接示例
$pdo = new PDO('mysql:host=mysql;port=3306;dbname=test', 'user', 'pass');

如果你确实需要跨 compose 项目通信，可以使用 external 网络：

# 先手动创建外部网络
docker network create shared_net
# 在 compose 文件中引用
networks:
  default:
    external:
      name: shared_net

预防建议：除非有特殊性能需求，否则不要使用 host 网络模式，它会失去端口映射的灵活性，也容易引发端口冲突。尽量利用 compose 内置的 DNS 服务发现机制，让服务名代替 IP，这样即使 IP 变化，服务依然可以正常通信。

总结与运维建议

Docker 运维的核心，在于理解“进程即容器”的理念，以及掌握网络与存储这两个核心抽象。很多看似诡异的报错，追根溯源都是对底层原理的误解。

最后，笔者给正在做容器化转型的朋友几点忠告：

不要在生产环境使用 latest 标签，请固定镜像版本，否则一次 pull 可能带来不可控的变更。
资源限制必须加。使用 -m 和 --cpus 限制容器资源，防止单个容器吃光宿主机内存导致 OOM。
日志要集中管理。默认的 json-file 日志驱动会无限增长，建议配置 log rotation 或接入 ELK/Loki。
基础环境要选对。容器化部署虽然屏蔽了底层差异，但宿主机内核版本、磁盘 IO 性能依然至关重要。如果你还在为选择哪家云服务器而纠结，建议优先考虑磁盘 IO 性能优秀、网络稳定的靠谱服务商，毕竟容器再怎么轻量，也跑在物理机上。

希望这篇文章能帮你少走一些弯路。如果你在实操中遇到其他奇葩报错，欢迎在评论区留言，我们一起探讨。

Docker 容器频繁重启、端口冲突、镜像拉取失败？运维排坑实战指南

前言：容器化部署的“甜蜜”与“负担”

疑问一：容器启动后一直处于 Restarting 状态，日志却看不到报错？

🔥 【限时特惠福利】高性价比独享云服务器限时 1 折起

Q1：docker ps 显示 STATUS 为 “Restarting (1) 5 seconds ago”，docker logs 却只输出几行无关紧要的信息，这到底是什么情况？

疑问二：端口映射成功但外部无法访问，防火墙也关了为什么？

Q2：docker run -p 8080:80 已经执行，ss -ltn 也能看到 8080 端口在监听，但浏览器就是打不开，防火墙也关了，这合理吗？

疑问三：镜像构建时提示 “no space left on device”，但 df -h 显示磁盘还有几十 G？

Q3：docker build 过程中报错 no space left on device，可是我用 df -h 查看根分区还有 50G 可用，这磁盘空间到底去哪了？

疑问四：Docker Compose 中多个容器如何实现互相通信？用 IP 还是服务名？

Q4：我写了 docker-compose.yml 启动了 3 个服务（nginx, php, mysql），但 php 容器里 ping mysql 的 IP 能通，ping mysql 这个服务名却不通，这是为什么？

总结与运维建议

相关技术专题与延伸阅读

📦 【资源免费领】本文全套实操配置文件与避坑手册下载