一、为什么容器网络总爱闹脾气

搞技术的朋友肯定都遇到过这样的情况：明明容器跑得好好的，突然就连不上数据库了；或者两个容器之间死活ping不通，就像两个闹别扭的小孩子。这种网络问题在Docker环境里特别常见，就像家里的Wi-Fi时不时抽风一样让人头疼。

先说说最常见的几种症状吧：容器完全无法访问外网、容器之间互相找不到对方、端口映射莫名其妙失效、DNS解析突然罢工。这些问题看似简单，但排查起来往往让人抓狂。我见过最夸张的一个案例是，某公司的测试环境因为容器网络问题，整整耽误了两天的发版进度。

二、诊断网络问题的三板斧

1. 先看看容器还活着吗

# 检查容器状态（技术栈：Docker）
docker ps -a
# 输出示例：
# CONTAINER ID   IMAGE          COMMAND                  STATUS                      PORTS     NAMES
# a1b2c3d4e5f6   nginx:latest   "/docker-entrypoint.…"   Up 2 minutes               80/tcp    web-server
# 如果STATUS不是"Up"，说明容器根本没运行起来

这个命令就像给容器把脉，能第一时间知道容器是死是活。如果容器都没跑起来，谈什么网络连接呢？

2. 检查网络配置

# 查看容器网络详情（技术栈：Docker）
docker inspect <container_id> | grep IPAddress
# 输出示例：
# "IPAddress": "172.17.0.2",
# 如果没有IP地址或者显示"", 说明网络配置有问题

# 查看端口映射情况
docker port <container_id>
# 输出示例：
# 80/tcp -> 0.0.0.0:8080
# 如果该有的端口没映射出来，外部自然访问不到

3. 来点实际的连通性测试

# 进入容器内部测试（技术栈：Docker）
docker exec -it <container_id> /bin/bash
# 然后在容器内执行：
ping 8.8.8.8  # 测试外网连通性
ping <另一个容器的IP>  # 测试容器间连通性
curl http://localhost:<端口>  # 测试服务是否监听
nslookup google.com  # 测试DNS解析

这套组合拳打下来，90%的基础网络问题都能现出原形。如果还不行，那就要上点高级手段了。

三、那些年我们踩过的网络坑

1. 桥接网络的坑

Docker默认的桥接网络(bridge)虽然方便，但限制也不少。比如默认情况下，容器之间是通过IP互访的，这在实际使用中很不方便。

解决方案是创建自定义网络：

# 创建自定义网络（技术栈：Docker）
docker network create --driver bridge my-network
# 把容器连接到自定义网络
docker network connect my-network <container_id>
# 现在容器之间可以通过容器名互相访问了

2. 端口冲突的坑

有时候明明配置了端口映射，但就是访问不了。很可能是端口被占用了：

# 检查端口占用情况（技术栈：Linux）
netstat -tulnp | grep <端口号>
# 或者用更现代的ss命令
ss -tulnp | grep <端口号>
# 如果发现端口被占用，要么改配置，要么停掉占用端口的进程

3. DNS解析的坑

容器内DNS解析失败也是常见问题。可以这样检查：

# 查看容器DNS配置（技术栈：Docker）
docker run --rm busybox cat /etc/resolv.conf
# 如果发现DNS服务器不对，可以这样指定：
docker run --dns 8.8.8.8 --dns 8.8.4.4 <image>

四、高级诊断工具包

当基础方法都不管用时，就该祭出这些神器了：

1. tcpdump网络抓包

# 在宿主机上抓包（技术栈：Linux）
tcpdump -i docker0 -nn -vv
# 在容器内抓包需要先安装：
docker exec -it <container_id> apt-get update && apt-get install tcpdump
docker exec -it <container_id> tcpdump -i eth0 -nn -vv

2. 可视化网络拓扑

# 使用weave scope可视化（技术栈：Docker）
docker run -d --name weavescope --privileged \
    --net=host -v /var/run/docker.sock:/var/run/docker.sock \
    weaveworks/scope:latest
# 然后访问http://localhost:4040就能看到漂亮的网络拓扑图了

3. 使用nsenter深入容器网络命名空间

# 获取容器进程ID
docker inspect -f '{{.State.Pid}}' <container_id>
# 进入容器的网络命名空间
nsenter -t <pid> -n ip addr
# 现在你可以像在容器内一样操作网络了

五、防患于未然的网络最佳实践

根据我多年的填坑经验，总结出这些黄金法则：

  1. 尽量使用自定义网络，不要用默认的bridge
  2. 容器间通信优先使用容器名，而不是IP
  3. 生产环境一定要配置资源限制，避免一个容器吃光所有网络带宽
  4. 复杂的应用考虑使用docker-compose管理网络
  5. 跨主机通信考虑overlay网络或者专门的网络方案

举个docker-compose的例子：

# docker-compose.yml示例（技术栈：Docker）
version: '3'
services:
  web:
    image: nginx
    networks:
      - mynet
    ports:
      - "8080:80"
  db:
    image: mysql
    networks:
      - mynet
    environment:
      MYSQL_ROOT_PASSWORD: example

networks:
  mynet:
    driver: bridge

这样配置后，web服务可以直接通过"db"这个主机名访问数据库，完全不用关心IP地址变化。

六、当所有方法都失效时

如果真的遇到连Google都搜不到的奇葩网络问题，可以试试这些终极大法：

  1. 重启Docker服务：sudo systemctl restart docker
  2. 重置Docker网络：docker network prune
  3. 最狠的：sudo rm -rf /var/lib/docker/network/files（慎用！）

不过要提醒的是，最后一个方法相当于核武器，会把所有网络配置都清空，只能在万不得已时使用。

七、写在最后

容器网络问题就像迷宫，但只要掌握了正确的工具和方法，总能找到出口。关键是要有系统地排查：从容器状态到网络配置，从基础连通性到高级诊断。记住，大多数情况下问题都不复杂，只是我们容易把简单问题想复杂了。

最后送大家一个万能检查清单：

  1. 容器运行状态
  2. 网络配置
  3. 端口映射
  4. 防火墙规则
  5. DNS设置
  6. 网络驱动和模式

按照这个顺序一步步检查，相信你也能成为容器网络问题的解决高手！