容器网络异常根源在于对Network Namespace、veth pair、网桥及iptables/NFTables协同机制理解不足；需按DNS配置、路由、防火墙、CNI插件规则等逐层排查，并善用nsenter、tcpdump、iptables-save等工具链。
Linux容器网络异常，往往不是单纯配置错误，而是对底层网络模型理解不深导致的误操作或设计缺陷。要快速定位和解决，得先理清容器网络怎么“连起来”的——核心在于：容器本身没有独立网络栈，它复用或隔离宿主机的网络命名空间，并通过虚拟设备、网桥、iptables/NFTables、路由规则等协同工作。
容器网络的本质：Network Namespace + 虚拟连接
每个容器启动时，默认会创建一个独立的 network namespace（网络命名空间），里面包含自己的回环设备、路由表、iptables 规则、socket 列表等。但这个 namespace 本身是“空”的，需要外部“接线”才能通信：
- 最常见方式是 veth pair：一端在容器 netns 内（如 eth0），另一端在宿主机 netns 中（如 vethabc123），再挂到网桥（如 docker0 或 cni0）上
- 网桥充当二层交换角色，让同桥下的容器能互通；跨节点通信则依赖 CNI 插件（如 Flannel 的 VXLAN、Calico 的 BGP）封装转发
- 容器出向流量经 SNAT（通常由 iptables MASQUERADE 实现），入向则靠 DNAT 或 hostPort 映射
典型异常场景与对应排查点
网络不通、DNS 解析失败、端口无法访问等问题，基本可按以下路径逐层验证：
- 容器内连不上外网？ 检查容器内 /etc/resolv.conf 是否指向有效 DNS（如 8.8.8.8 或宿主机的 systemd-resolved），再 ping 114.114.114.114 看是否通——若通但域名不行，就是 DNS 配置问题；若全不通，看 ip route show、ip addr show eth0，确认默认路由和 IP 分配是否正常
- 宿主机能 ping 通容器 IP，但容器 ping 不通宿主机？ 很可能是容器 netns 内缺少默认路由（比如只配了 link-local 地址），或宿主机防火墙（firewalld/ufw）拦截了来自网桥段的入向包
- 两个容器之间 ping 不通？ 先确认它们是否在同一网桥/CNI 网络下；再检查双方 veth 设备状态（ip link show）、网桥 FDB 表（brctl showmacs docker0）、以及是否有 ebtables/iptables DROP 规则干扰二层转发
CNI 插件带来的复杂性不容忽视
Docker 自带的 bridge 网络较简单，但 Kubernetes 生态普遍使用 CNI（如 Calico、Cilium、Flannel）。它们不只是建网桥，还会：
- 动态写入路由（如为每个 Node 分配 CIDR 并添加 kernel 路由）
- 接管 conntrack、重写 iptables/NFTables 规则（尤其涉及 NetworkPolicy）
- 启用 eBPF 程序做高性能转发（Cilium）或绕过 iptables（部分模式下）
- 因此出现异常时，不能只看 docker0 或 ifconfig，而要查 cni/bin 下插件日志、kubectl get nodes -o wide 确认 CNI 分配的 PodCIDR、ip route list table all 查所有路由表
调试工具链要会组合用
单靠 ping 或 curl 往往卡在表层。真正高效的排查依赖几个关键命令配合：
- nsenter -n -t $(pidof containerd-shim) -- ip addr：进入容器 runtime 进程的 netns，查看真实网络视图（比 docker exec 更底层）
- tcpdump -i any port 53 或 tcpdump -i cni0 -w cap.pcap：抓包确认 DNS 流量是否发出、是否被丢弃
- iptables-save -c | grep -A 5 'KUBE- 或 nft list ruleset：看 NAT 和 filter 链是否命中、计数器是否增长
- ip neigh show：检查 ARP 表是否老化或缺失，常用于诊断“能 ping 通 IP 却不通端口”的情况
