Margrop
Articles362
Tags618
Categories7

Categories

0步 12类 1password 401 503 6个节点 AC ACP AI AI Coding Assistant AI编程助手 AI辅助 AI辅助编程 AP API Alertmanager AppDaemon Aqara BaiduPCS CC-Switch CI/CD CLI Tools CLI工具 Caddy Claude Code Cloudflare Codex Cookie 认证 Cron D1 DB探针 DB静止 DIY-MINI Date Diagrams.net Diary Docker Docker Compose Efficiency Tools Electerm English FTS5 Gateway Gemini CLI GitHub Actions HA HADashboard Hermes Hexo HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax Multi-Agent MySQL NAS NRestarts Nginx Node-RED Node.js OOM OpenAI OpenClaw OpenCode OpenResty OpenWrt PPPoE Portainer PostgreSQL ProcessOn Prometheus Proxmox VE RPC SOCKS5 SQLite SSL Session Shell Subagent TTS TimeMachine UML Uptime Kuma VPN VPS WeCom Web WebSocket Windows Workers activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser by-design caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit connected container cron crontab cron任务 cron设计 ctyun dashboard ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban fallback fallback失效 feign firewall-cmd flow frp frpc frps fuckgfw function fuser gcc gfw git gitea github golang google_gemma-4 gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https iKuai idea image img img2kvm immortalwrt import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jieba jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live loopback-proxy low-code lsof lvm lxc m3u8 mac macos manual mariadb markdown maven md5 meta-acceptance meta-pattern meta-probe microcode mirror model provider modem modules monitor mount mstsc mysql n2n n5105 nas netstat network new-api nfs node node-red nodejs nohup notepad++ npm nssm ntp one-api oop openfeign openssl os otp ovz p14 packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reconnect循环 reflog remote remote desktop renew repo resize retina root route router rule rules running runtime safari sata scipy-notebook scoping scp server server is busy slmgr so socket-proxyd socks source spk spring springboot springfox ss ssh ssl stale stash string supernode svg svn swagger sync synology systemctl systemd systemd unit systemd-socket tap tap-windows tapwindows telecom template terminal tls tmux token token失效 totp trigram tvbox txt ubuntu udisk ui undertow unicode61 uninstall unlocker upgrade uptimeMs url v1探针 v2ray v6探针 v7探针 v8探针 vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 中文搜索 主动不追问 主动周一 主动意识到 主动追问 云电脑 交换机 人机协作 代理 优化 体检 值班 假阳 假阴 健康检查 元递归 光猫 全绿 全量同步 公网IP 内存 内存优化 内网 内网IP 内网渗透 写作 分词 切换 升级 协作 单位混淆 博客 反向代理 反常稳定 反应 vs 知识 启动 告警 告警优化 周一 周一焦虑 周三 周二 周五 周六 周四 周报 周日 周末 周末突破 周末第二天 夏令时 多场景 多智能体 多节点 多节点管理 天猫精灵 天翼云 安全 安装 定时任务 容器 容器网络 导入 小米 工作感悟 工作日 工作日常 常用软件 幂等 广告屏蔽 序列号 应用市场 异常 循环类 心态 心智成长 心理模型 心跳 心跳检查 性能优化 感悟 打工 打工人 批量校验 技术 抓包 排查 探针再升级 探针本身 探针版本 探针管理 探针自检 接受 接受之后 接受层 接受本身 接受递归 描述文件 放下 故障 故障排查 效率 效率工具 数据 旁路由 无服务器 日记 时区 显卡虚拟化 智能家居 智能音箱 服务器 服务管理 架构 梯子 模块 模型探测 模型调用 毫秒 流程 流程图 流程管理 浏览器 清单之后 清单之外 清单之外也包括接受本身 清单设计 清单边界 清单进化 源码备份 漫游 激活 火绒 焦虑 玄学 生活 电信 画图 监控 监控系统 直播源 直觉 磁盘 端口 端口冲突 端口扫描 第10类 第11类 第12类 第13类 第14类 第15类 第16类 第17类 第18类 第6天 第7天 第8天 第9天 第9类 管理 续期 网关 网络 网络风暴 群晖 脚本 脚本优化 腾讯 自动化 自动恢复 自建应用 自我反思 自我打脸 节点角色 虚拟机 被动意识到 角色不匹配 角色误判 角色误配 角色错配 认证 设计偏差 证书 语雀 误报 误报过滤 超时 路由 路由器 软件管家 软路由 运维 运维监控 进程 连接保活 连接问题 通信机制 通知 部署 部署链路 配置 钉钉 镜像 镜像源 长期稳定 长连接 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客 静默期 飞书

Hitokoto

Archive

Docker容器bridge网络模式下容器间无法通信的完整排查与解决方案

Docker容器bridge网络模式下容器间无法通信的完整排查与解决方案

前言

在使用Docker部署容器化应用时,容器间网络通信是一个基础但又容易出问题的环节。近期在排查一台VPS服务器的网络问题时,发现了一个典型的Docker bridge网络配置问题导致的容器间无法通信故障。本文将详细记录整个排查过程,并提供完整的解决方案和最佳实践指南。

问题背景

业务场景

一台VPS服务器上运行着多个Docker容器服务,这些容器之间需要通过网络进行通信。例如:

  • Web应用容器需要访问数据库容器
  • API服务容器需要访问缓存容器
  • 定时任务容器需要访问消息队列容器

这些容器通过Docker网络模式进行连接,确保服务间能够正常通信。

问题现象

  • 故障表现:从容器A无法访问容器B的服务
  • 超时现象:curl命令持续等待,最终显示连接超时
  • 影响范围:所有跨容器通信失败
  • 监控状态:容器进程均运行正常,但网络不通

环境信息

组件 类型 说明
宿主机 VPS Ubuntu 24.04
Docker 容器运行时 最新稳定版
容器网络 bridge模式 默认bridge网络

排查过程

第一步:确认容器状态

首先检查所有容器是否正常运行:

1
2
3
4
5
6
7
8
# 查看所有容器状态
docker ps -a

# 查看运行中的容器
docker ps

# 检查容器详细信息
docker inspect 容器名

结果:所有容器进程正常运行,状态为”Up”,没有异常退出。

第二步:检查Docker网络配置

检查容器的网络配置:

1
2
3
4
5
# 查看Docker网络列表
docker network ls

# 查看网络详细信息
docker network inspect bridge

结果

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
"Name": "bridge",
"Id": "xxx",
"Driver": "bridge",
"IPAM": {
"Config": [
{
"Subnet": "172.17.0.0/16"
}
]
},
"Containers": {
# 这里应该显示连接的容器,但没有
}
}

关键发现:bridge网络的Containers字段为空,说明容器可能没有连接到默认bridge网络。

第三步:检查容器网络连接

查看单个容器的网络配置:

1
2
3
4
5
# 查看容器网络配置
docker inspect 容器名 --format '{{json .NetworkSettings.Networks}}' | jq

# 查看容器IP地址
docker inspect 容器名 --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'

结果:容器IP地址为空,说明容器确实没有连接到bridge网络。

第四步:确认容器创建方式

检查容器是如何创建的:

1
2
3
4
5
# 如果使用docker-compose
cat docker-compose.yml | grep -A5 networks

# 如果使用docker run
docker ps --format "{{.Names}}" | xargs -I {} docker inspect {} --format '{{.Name}}: {{.HostConfig.NetworkMode}}'

发现:容器使用了--network noneNetworkMode: none,导致完全没有网络连接。

第五步:深入分析

为什么容器会没有网络?可能的原因包括:

  1. 创建时指定了--network none
  2. docker-compose中配置了network_mode: none
  3. 容器加入了一个不存在的自定义网络
  4. Docker网络驱动异常

验证当前容器的网络模式:

1
2
3
4
5
6
# 检查所有容器的网络模式
for container in $(docker ps -q); do
name=$(docker inspect --format '{{.Name}}' $container)
mode=$(docker inspect --format '{{.HostConfig.NetworkMode}}' $container)
echo "$name: $mode"
done

结果:多个容器的网络模式为”none”。

根因分析

问题根因

经过完整排查,发现问题的根本原因是:**容器创建时指定了--network none参数,或者docker-compose中配置了network_mode: none**,导致容器完全没有网络连接能力。

在Docker中,--network none意味着:

  • 容器有自己的network namespace
  • 但不连接到任何Docker网络
  • 只能通过localhost访问自身
  • 无法与任何其他容器或外部网络通信

影响分析

访问方式 结果 说明
localhost:端口 ✅ 正常 容器内部访问
容器IP:端口 ❌ 不通 容器无IP地址
容器名:端口 ❌ 不通 无法DNS解析
宿主机:端口映射 ❌ 不通 网络未映射

架构问题

当前架构存在以下问题:

  1. 网络配置遗漏:创建容器时忘记了配置网络
  2. 缺乏网络检查:没有在部署后验证容器网络连通性
  3. 文档缺失:网络配置要求没有明确记录

解决方案

方案一:将容器连接到bridge网络

1
2
3
4
5
# 将运行中的容器连接到bridge网络
docker network connect bridge 容器名

# 或者重新创建容器并指定网络
docker run -d --network bridge --name 容器名 镜像名

方案二:创建自定义bridge网络

创建独立的Docker网络,实现更好的隔离和管理:

1
2
3
4
5
6
7
8
9
10
11
12
# 创建自定义bridge网络
docker network create \
--driver bridge \
--subnet 172.25.0.0/16 \
--gateway 172.25.0.1 \
app-network

# 将容器连接到新网络
docker network connect app-network 容器名

# 验证网络连接
docker network inspect app-network

方案三:使用docker-compose管理网络

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
version: '3.8'

services:
web:
image: nginx:latest
container_name: web
networks:
- app-network
ports:
- "80:80"

api:
image: api:latest
container_name: api
networks:
- app-network
depends_on:
- db

db:
image: postgres:15
container_name: db
networks:
- app-network
volumes:
- db-data:/var/lib/postgresql/data

networks:
app-network:
driver: bridge
ipam:
config:
- subnet: 172.26.0.0/16

volumes:
db-data:

完整修复步骤

步骤1:检查当前网络状态

1
2
3
4
5
6
7
8
# 查看所有网络
docker network ls

# 查看容器网络详情
for c in $(docker ps -q); do
echo "=== $(docker inspect --format '{{.Name}}' $c) ==="
docker inspect $c --format '{{json .NetworkSettings.Networks}}' | jq
done

步骤2:创建必要的网络

1
2
# 创建应用网络
docker network create app-network --driver bridge --subnet 172.20.0.0/16

步骤3:连接容器到网络

1
2
3
4
# 连接所有需要的容器
docker network connect app-network web
docker network connect app-network api
docker network connect app-network db

步骤4:验证网络连通性

1
2
3
4
5
6
7
# 测试容器间通信
docker exec -it web ping -c 3 api
docker exec -it api ping -c 3 db

# 测试服务访问
docker exec -it web curl http://api:端口号/health
docker exec -it api curl http://db:5432

步骤5:持久化网络配置

修改docker-compose.yml,确保下次部署自动使用正确配置:

1
2
3
4
5
6
7
8
9
services:
web:
image: nginx:latest
networks:
- app-network

networks:
app-network:
external: true

一键排查脚本

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
#!/bin/bash

echo "========== Docker网络连通性排查 =========="

echo ""
echo "[1/7] 检查Docker网络列表..."
docker network ls

echo ""
echo "[2/7] 检查容器网络模式..."
for container in $(docker ps --format "{{.Names}}"); do
mode=$(docker inspect --format '{{.HostConfig.NetworkMode}}' $container)
ip=$(docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $container)
echo " $container: mode=$mode, ip=$ip"
done

echo ""
echo "[3/7] 检查bridge网络容器连接..."
docker network inspect bridge | grep -A5 Containers || echo " 无容器连接到bridge网络"

echo ""
echo "[4/7] 测试容器间连通性..."
containers=$(docker ps --format "{{.Names}}" | head -2)
if [ $(echo "$containers" | wc -l) -ge 2 ]; then
c1=$(echo "$containers" | sed -n '1p')
c2=$(echo "$containers" | sed -n '2p')
echo " 测试 $c1 -> $c2..."
docker exec $c1 ping -c 1 -W 1 $c2 2>&1 || echo " 连接失败"
fi

echo ""
echo "[5/7] 检查DNS解析..."
if docker exec web getent hosts api 2>/dev/null; then
echo " DNS解析正常"
else
echo " DNS解析失败"
fi

echo ""
echo "[6/7] 检查端口映射..."
docker ps --format "{{.Names}}: {{.Ports}}" | grep -v ":$" || echo " 无端口映射"

echo ""
echo "[7/7] 检查网络驱动状态..."
docker network ls | grep bridge

echo ""
echo "========== 排查完成 =========="

常见问题解答

Q1:容器为什么会有IP地址为空的情况?

A:可能的原因包括:

  • 创建时指定了--network none
  • Docker网络驱动异常
  • 容器网络命名空间配置失败

建议使用docker network inspect检查网络状态。

Q2:如何选择bridge还是host网络模式?

A:

  • bridge(默认):适合大多数场景,容器有独立IP,可以互相通信
  • host:适合性能敏感场景,但缺乏隔离,不支持端口映射
  • overlay:适合Swarm集群,跨主机容器通信
  • none:完全禁用网络,适合特殊场景

Q3:容器间通信一定要通过bridge网络吗?

A:不一定。还可以通过:

  • Docker DNSdocker run --link(已废弃)或自定义网络
  • 服务发现:使用容器名作为hostname
  • 外部网络:通过宿主机端口映射访问

Q4:如何实现容器间安全隔离?

A:

1
2
3
4
5
# 创建内部网络(禁止外部访问)
docker network create --internal internal-network

# 只允许需要的容器加入
docker network connect internal-network 容器A

Q5:网络配置修改后需要重启容器吗?

A:

1
2
3
4
5
# 动态连接网络
docker network connect my-network 容器名

# 断开网络连接
docker network disconnect my-network 容器名

最佳实践总结

  1. 显式指定网络:创建容器时明确指定--network,不要依赖默认配置

  2. 使用自定义网络:创建专用的bridge网络,便于管理和隔离

    1
    docker network create --driver bridge --subnet 172.20.0.0/16 app-network
  3. 配置网络检查:部署后验证容器网络连通性

    1
    docker exec 容器A ping -c 3 容器B
  4. 使用docker-compose:通过YAML文件管理网络配置,确保环境一致性

  5. 设置网络策略:配置网络访问控制,限制不必要的通信

    1
    docker network create --internal isolated-network
  6. 定期审计网络配置:检查容器网络配置,及时发现异常

    1
    2
    3
    4
    5
    6
    # 审计脚本
    for c in $(docker ps -q); do
    if [ -z "$(docker inspect --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $c)" ]; then
    echo "警告: $(docker inspect --format '{{.Name}}' $c) 无网络配置"
    fi
    done

延伸阅读

总结

本文详细记录了一次Docker容器网络连通性问题的完整排查过程,核心要点包括:

  1. 理解网络模式:了解bridge、host、none、overlay四种网络模式的区别和适用场景
  2. 排查要有层次:从容器状态→网络配置→连通性测试,逐步排查
  3. 使用自定义网络:推荐创建专用的bridge网络,便于管理和问题定位
  4. 验证网络连通性:部署后必须验证容器间通信是否正常
  5. 持久化配置:使用docker-compose确保网络配置可重复和环境一致

容器网络是容器化部署的基础设施之一,只有理解其工作原理并掌握排查方法,才能在问题发生时快速定位和解决。

希望这篇文章能帮到你。如果有问题,欢迎在评论区讨论。


作者:小六,一个在上海努力搬砖的程序员

Author:Margrop
Link:http://blog.margrop.com/post/2026-03-18-docker-bridge-network-container-communication-troubleshooting/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可