Docker Bridge模式下抓包应聚焦容器eth0、宿主机veth接口和docker0网桥三个关键节点，结合iptables NAT规则与内核转发状态验证通信路径，避免在物理网卡盲目抓包。
直接在宿主机或容器内抓包，结合网络结构定位数据流向，是分析 Docker Bridge 网络最有效的方式。关键不是“能不能抓到”，而是“在哪抓、抓什么、怎么对应上容器通信路径”。
明确抓包位置：三个核心节点
Docker Bridge 模式下，一个典型请求（比如容器访问外网）会经过三个关键网络点：
- 容器内部 eth0 接口：看到原始源 IP（如 172.17.0.2）、目的地址、未修改的 TCP/UDP 包
- 宿主机上的 vethxxx 接口：与容器 eth0 成对，流量镜像一致，但已进入主机命名空间
- docker0 网桥接口：所有容器流量汇聚点，可观察跨容器通信或出向转发前的状态
不建议直接抓物理网卡（如 eth0/enp0s3），除非你要验证 SNAT 后的最终外发包；多数问题在 docker0 或 veth 层就能定位。
快速启动抓包的两种常用方式
根据排查目标选择更高效的方式：
minimax-mcp-docker版（适配极空间）
下载
MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。
-
在容器内抓包：适合确认应用是否发出请求、端口监听是否正常
命令示例：docker exec -it <容器名> tcpdump -i eth0 -w /tmp/out.pcap port 80
注意：需先安装 tcpdump（apt-get install -y tcpdump） -
在宿主机抓 veth 或 docker0：适合对比容器收发、验证路由/NAT 行为
先查 veth 名：brctl show | grep veth或ip link show | grep veth
再抓包：sudo tcpdump -i vetha1b2c3 -w host_veth.pcap
结合网络配置验证抓包结果
单看 pcap 文件容易误判，必须同步检查当前网络状态：
- 确认容器 IP 和网关：
docker inspect <容器名> | grep -A 5 "IPAddress\|Gateway"（应为 172.17.0.x / 172.17.0.1） - 验证 NAT 规则是否存在：
sudo iptables -t nat -vnL POSTROUTING | grep MASQUERADE（必须有匹配 172.17.0.0/16 的规则） - 检查内核转发是否开启：
sysctl net.ipv4.ip_forward（值应为 1）
如果抓到容器发出了 SYN，但在 veth 或 docker0 上消失，大概率是 iptables DROP 规则或转发未启用；如果 docker0 有包但物理网卡没有，说明 MASQUERADE 失效或路由错误。
用 Wireshark 分析时关注的关键字段
导入 pcap 后，重点过滤和比对以下信息：
- IPv4 Source/Destination：确认是否始终是容器 IP ↔ 网关 IP ↔ 外部 IP
- TCP Flags：SYN → SYN-ACK → ACK 是否完整，中断在哪一环
- ICMP Type/Code：若出现 “Destination unreachable (Port unreachable)”，说明目标端口没监听或被防火墙拦截
- Follow TCP Stream：右键追踪流，快速判断 HTTP 请求是否到达、响应是否返回
特别注意：同一通信在容器 eth0 和 veth 接口上看到的包内容完全一致；而到了 docker0 或物理网卡，源 IP 可能已被 SNAT 替换——这是正常行为，不是故障。
