Docker 容器起不来、网络不通、数据丢了？这份“避坑+实战”手册请收好

前言：容器化部署，为什么老是“卡壳”？

最近不少朋友跟笔者吐槽，说 Docker 这东西入门容易，但一到了真刀真枪部署应用时，各种幺蛾子就全冒出来了。不是容器启动后秒退，就是宿主机重启后服务全丢，更别提那让人头大的容器间网络通信问题。其实，绝大多数“疑难杂症”背后，都藏着对 Docker 底层逻辑和最佳实践的理解偏差。今天，笔者不打算念枯燥的官方文档，而是挑几个大家问得最多的“坑”，结合真实的实操命令，带各位彻底排排雷。如果你正准备用 Docker 部署业务，或者在运维过程中已经焦头烂额，这篇文章请你务必看完。

问题一：容器一启动就退出（Exited），日志却啥也没打印？

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

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

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

💡 延伸阅读：从零开始用 Docker 跑通你的第一个应用：一份拿来即用的开发实操指南

为什么我的容器总是“活不过三秒”？

这是新手最容易踩的坑。很多朋友用 docker run 启动一个 Nginx 或者 MySQL，结果 docker ps -a 一看，状态栏赫然写着 Exited (0) 或者 Exited (1)。用 docker logs 查看，却发现日志文件空空如也，或者只有几行初始化信息。

根因剖析：这通常不是应用本身出了问题，而是容器没有前台进程在运行。Docker 的设计哲学是“一个容器只跑一个主进程”，如果这个主进程后台化了（比如直接执行 nginx 命令，它会 fork 出 worker 进程后自己退出），或者根本没有启动任何常驻进程，容器就会因为无事可做而立刻退出。

解决方案：确保你的启动命令是“前台运行”模式。以 Nginx 为例，正确的启动方式应该是：

# 错误示范：容器会秒退
docker run -d --name mynginx nginx /usr/sbin/nginx

# 正确示范：使用 -g 指令让 Nginx 保持前台运行
docker run -d --name mynginx -p 80:80 nginx:latest nginx -g 'daemon off;'

如果你用的是自定义的 Dockerfile，请务必将启动命令写成类似 CMD ["nginx", "-g", "daemon off;"] 或者使用 supervisor 来管理多个前台进程。对于 Java 应用，务必使用 java -jar app.jar 直接启动，切勿加 & 让它后台执行。

预防建议：养成好习惯，创建容器时加上 -it 参数（仅调试时），或者第一时间用 docker logs 容器ID 查看输出。如果日志没内容，优先检查启动命令是否阻塞了前台。

问题二：宿主机重启后，数据库容器数据全没了？

💡 深度技术指南：从零到一：Docker 项目开发全流程实操指南，解决环境一致性的终极难题

Docker 容器删了重建，数据如何做到“不丢”？

这个问题非常致命。很多朋友为了方便，直接用 docker run 启动 MySQL，并且把数据目录放在了容器可写层。一旦容器被删除（docker rm）或者宿主机重启导致容器异常退出后无法启动，无奈之下只能删掉重建，这时候你会惊恐地发现：数据全没了。

根因剖析：容器是“一次性”的，它的可写层与容器的生命周期绑定。只要容器没了，这层数据就随之销毁。解决之道在于使用 Volume（数据卷） 或 Bind Mount（绑定挂载），将数据持久化到宿主机文件系统中。

解决方案：笔者强烈推荐使用具名 Volume 来管理数据库等高危数据。操作如下：

# 1. 创建具名卷
docker volume create mysql_data

# 2. 启动容器并挂载该卷到容器内的数据目录
docker run -d \
  --name mysql-server \
  -e MYSQL_ROOT_PASSWORD=YourStrongPass \
  -v mysql_data:/var/lib/mysql \
  -p 3306:3306 \
  mysql:8.0

# 3. 即使删除容器，数据依然安全
docker rm -f mysql-server
docker run -d --name mysql-server \
  -e MYSQL_ROOT_PASSWORD=YourStrongPass \
  -v mysql_data:/var/lib/mysql \
  -p 3306:3306 \
  mysql:8.0

通过 -v mysql_data:/var/lib/mysql，我们让 MySQL 的数据直接写入宿主机上的 Docker 管理区域。无论容器怎么删、怎么重建，只要卷还在，数据就在。

预防建议：在 Dockerfile 里用 VOLUME 指令声明数据目录，或者运行容器时务必配置 -v。对于生产环境，建议使用 NFS 或云厂商的块存储挂载到宿主机目录，再通过 Bind Mount 方式映射进容器。

问题三：容器能起来，但宿主机访问不到，网络不通？

端口映射 -p 80:80 明明加了，为何还是 Connection Refused？

这是排查起来最让人抓狂的问题。明明 docker ps 显示端口映射已经生效（例如 0.0.0.0:8080->80/tcp），但浏览器就是访问不了。

根因剖析：通常有三个层面的原因。第一，防火墙拦截，宿主机自身的 iptables 或安全组策略没有放行对应端口。第二，容器内应用监听地址错误，比如容器内的 Nginx 只监听了 127.0.0.1，而不是 0.0.0.0，导致外部流量无法进入容器网络栈。第三，Docker 的 NAT 网络问题，特别是当你手动修改了 Docker 的 iptables 规则后，会导致端口转发失效。

解决方案：按以下顺序逐一排查，切勿盲目重启。

# 1. 检查容器内应用监听地址（进入容器内执行）
docker exec -it 容器ID /bin/bash
# 在容器内执行，看是否监听 0.0.0.0:80 或 :::80
netstat -tunlp | grep 80
# 若是 127.0.0.1:80，需修改应用配置改为 0.0.0.0

# 2. 检查宿主机防火墙（以 CentOS/Ubuntu 为例）
# 查看防火墙状态
sudo ufw status
# 若有开启，放行端口
sudo ufw allow 8080/tcp

# 3. 检查 Docker 端口映射是否真的生效
docker port 容器ID

如果你是在云服务器上，务必去云控制台检查安全组入方向规则是否放行了对应端口，这步最容易忽略。

预防建议：启动容器时，尽量使用 -p 宿主机IP:端口:容器端口 来避免端口冲突。避免在宿主机上随意修改 Docker 的 iptables 策略，如需精细化管控，请使用 Docker 网络策略。

问题四：容器内服务间通信，用 IP 还是别名？

多个容器（如 Nginx + PHP-FPM）如何优雅互联？

当你把应用拆成多个容器后（比如前端 Nginx 容器 + 后端 PHP-FPM 容器），你可能会发现，在 Nginx 容器里通过 localhost 去连 PHP-FPM 是行不通的。因为每个容器都有自己独立的网络命名空间。

根因剖析：容器之间默认是相互隔离的。正确的做法是让它们加入同一个用户自定义的 Bridge 网络，并通过容器名作为稳定的 DNS 域名进行互访。使用容器名而非 IP 的好处是，即使容器重建导致 IP 变化，服务间依然能通过名字找到彼此。

解决方案：创建一个自定义网络，然后让所有相关容器都加入进来。

# 1. 创建自定义桥接网络
docker network create my_app_net

# 2. 启动 PHP-FPM 容器，并指定网络
docker run -d --name php-fpm \
  --network my_app_net \
  -v /var/www/html:/var/www/html \
  php:7.4-fpm

# 3. 启动 Nginx 容器，同样指定网络，并挂载相同代码目录
docker run -d --name web-nginx \
  --network my_app_net \
  -p 80:80 \
  -v /var/www/html:/var/www/html \
  nginx:latest

# 4. 此时在 Nginx 容器内，直接 ping php-fpm 就能通
docker exec web-nginx ping php-fpm

在 Nginx 的配置文件中，你只需要将 fastcgi_pass 指向 php-fpm:9000 即可，无需关心底层 IP 地址。

预防建议：摒弃 --link 这个老掉牙的参数，全面拥抱自定义网络。如果追求极致的性能隔离，可以考虑使用 --network host，但要注意端口冲突问题。

核心总结与避坑清单

聊了这么多，笔者最后再帮大家梳理一份“防呆”清单，希望能帮你省下不少排查时间。

高频症状	核心原因	第一排查命令
容器启动后立即退出	无前台进程 / 启动命令错误	`docker logs 容器ID`
删除容器后数据丢失	未挂载持久化存储	`docker inspect 容器ID` 查看 Mounts
外部无法访问服务	防火墙/安全组未放行，或应用监听 127.0.0.1	`docker port 容器ID` 和宿主机 `ss -tunlp`
容器间无法通信	不在同一自定义网络内	`docker network inspect 网络名`

当然，工欲善其事，必先利其器。想要把 Docker 玩得溜，一台配置靠谱的 Linux 服务器是前提。笔者建议大家在选购云服务器时，一定要关注 IO 性能和网络带宽，毕竟容器镜像的拉取和运行时的磁盘读写都吃这俩指标。如果你是个人学习或小型项目，选择一家口碑好的服务商，开通一台按量付费的 2C4G 实例练手就足够了，等业务跑顺了再升级配置也不迟。

容器化这条路，坑确实不少，但只要你理解了“进程、网络、存储”这三大命门，绝大多数问题都能迎刃而解。希望这篇文章能成为你手边的一份参考手册，咱们下期再见。