容器网络不通，排查路径应遵循从内到外、从底层到上层的原则，先检查容器自身网络配置，再确认宿主机网络和防火墙，最后排查CNI插件及网络策略。
容器网络不通排查步骤：从容器内到宿主机
容器网络不通时,第一步不是查日志或看监控，而是进入容器内部做基础连通性测试，绝大多数问题都卡在这一步，只是被表象掩盖。
检查容器的网络模式与IP分配
- 执行
docker inspect <容器名> | grep -i network查看网络模式，确认是bridge、host还是overlay。 - 对于Kubernetes环境,使用
kubectl describe pod <pod名>查看Pod的IP地址和所属网络命名空间。 - 检查端口映射是否按预期暴露,
docker port <容器名>可快速确认映射关系。 - 确认DNS配置是否正常,查看
/etc/resolv.conf文件，确保nameserver可访问。
测试容器内部连通性
- 进入容器：
docker exec -it <容器名> /bin/sh或kubectl exec -it <pod名> -- /bin/sh。 - 先ping宿主机IP（如网关地址），不通则说明容器与宿主机之间的网络桥接或veth pair有问题。
- 再ping外网IP（如8.8.8.8），不通则需检查宿主机是否开启IP转发以及iptables规则。
- 使用
curl或wget测试HTTP服务，确认应用层协议是否正常。
docker容器网络故障解决方法：常见命令与排查要点
- 若容器内无法ping通任何地址,先检查宿主机
/proc/sys/net/ipv4/ip_forward是否为1，行业共识认为，这是最容易忽略的底层配置。 - 使用
nsenter进入容器网络命名空间，直接操作网络接口。nsenter -t $(docker inspect --format '{{.State.Pid}}' <容器名>) -n ip addr，可查看容器视角的完整网络栈。 - 对比容器内和宿主机上的路由表,确认默认网关是否正确指向docker0或cni0。
宿主机网络与防火墙：容器网络故障的隐形杀手
容器网络正常,但服务无法从外部访问，或者容器无法访问外部，宿主机层的iptables和安全组往往是罪魁祸首。
iptables规则与FORWARD链
- 列出所有NAT规则：
iptables -t nat -L -n，查看POSTROUTING和PREROUTING是否包含容器网段的MASQUERADE规则。 - 检查FORWARD链的默认策略：大多数容器网络依赖
iptables -P FORWARD ACCEPT，若策略为DROP则跨容器通信会失败。 - 确认Docker/Kubernetes自动添加的规则没有被其他服务覆盖，常见冲突场景：在同一台机器上同时运行firewalld和iptables-services。
网络桥接与转发配置
- 查看docker0或cni0网桥的状态：
ip link show docker0，确认接口UP且分配了正确的IP地址。 - 检查veth pair是否成对出现：
ip link | grep veth，若一边丢失则需重启容器或网络插件。 - 统计数据显示,相当一部分容器跨主机通信问题源于宿主机上br_netfilter模块未加载，导致iptables无法过滤bridge流量，可通过
lsmod | grep br_netfilter确认。
云环境安全组与防火墙
- 简米云、酷番云等容器服务的安全组需要开放对应端口和协议，尤其是ICMP、TCP/UDP高位端口（用于节点间通信）。
- 本地防火墙（firewalld、ufw）默认可能拦截容器网段，需添加规则：
firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=172.17.0.0/16 accept'。 - 如果使用systemd-networkd，需确认网络配置文件中
IPForward=yes。
Kubernetes pod网络不通怎么办：Pod到Service的完整路径
Kubernetes环境下的网络故障通常比Docker复杂,因为涉及Service、DNS、NetworkPolicy等多个抽象层。
Pod间直接通信测试
- 从Pod1 ping Pod2的IP：
kubectl exec <pod1> -- ping <pod2_ip>，如果能通，说明Pod网络层和CNI插件正常，问题在Service层。 - 若Pod间不通,检查CNI插件状态：
kubectl get pods -n kube-system | grep calico
- 查看CNI的日志：
kubectl logs -n kube-system calico-node-xxxxx，留意报错信息，如IP池耗尽、BGP邻居断连等。
Service与kube-proxy影响
- 测试Service集群IP：
kubectl exec <pod1> -- curl <service_ip>:<port>，不通则检查Service的Endpoints是否存在：kubectl get endpoints <service名>。 - 确认kube-proxy模式（iptables/ipvs），若使用ipvs，需检查
ipvsadm -L -n查看规则，并确保ipvs内核模块已加载。 - 检查Service的sessionAffinity和externalTrafficPolicy设置,避免因流量分发策略导致部分Pod不可达。
NetworkPolicy限制
- 执行
kubectl get networkpolicy -A查看是否有默认拒绝策略，若存在，需显式放行Pod间的通信端口。 - 使用
kubectl describe networkpolicy <策略名>查看具体规则，确认是否误拦了排查流量，业内专家指出，网络策略配置不当是Pod无法通信的常见原因之一。
容器跨主机通信问题排查：网络插件与路由诊断
当容器分布在不同的物理机或虚拟机,网络不通时重点在于主机间的路由和隧道封装。
主机路由表核对
- 在源主机执行
ip route get <目的容器IP>，查看数据包走向，期望结果应该是通过eth0或tunnel接口转发到对端主机。 - 在目标主机执行
ip route get <源容器IP>，确认回程路由存在且正确。 - 若路由缺失,需检查CNI插件的路由同步机制，例如Calico使用BGP，需确认BGP peer状态正常；Flannel使用etcd更新路由，需确认etcd健康。
网络插件模式对比
| 插件 | 默认模式 | 跨主机通信方式 | 常见故障点 |
|---|---|---|---|
| Flannel | VXLAN | UDP封装 | MTU不一致、端口未开放 |
| Calico | IPIP/BGP | 直接路由/隧道 | BGP邻居中断、IP池耗尽 |
| Weave | 快速数据通道 | 自定义UDP | 加密插件冲突 |
- 使用
calicoctl node status检查Calico节点状态，确认BGP peering。 - 使用
flanneld日志查看子网是否分配成功，以及backend接口是否正常创建。
抓包定位丢包点
- 在源主机抓包：
tcpdump -i eth0 icmp and host <目的容器IP>，确认数据包是否发出。 - 在目标主机抓包：
tcpdump -i eth0 icmp，确认数据包是否到达，若未到达，说明中间路由或防火墙丢弃。 - 若数据包到达目标主机但未进入容器,检查目标主机的iptables规则，确认FORWARD链是否允许容器网段流量。
Q&A：容器网络不通常见问题与排查方法
容器能ping通宿主机但无法访问外网，是什么原因？
宿主机可能未开启IP转发，或iptables的MASQUERADE规则缺失，检查 `sysctl net.ipv4.ip_forward` 是否为1，并确认 `iptables -t nat -L -n` 中包含对容器网段的MASQUERADE规则，若使用Docker，可尝试重启docker服务以重建规则。
重启容器后网络恢复，但过一会儿又断连，怎么办？
这种情况通常与IP地址冲突或ARP缓存有关，检查容器IP是否被其他设备占用，尤其是使用静态IP分配的场景，在Kubernetes中，若Pod频繁重启，检查CNI插件是否在IP释放时未正确清理路由，可尝试在宿主机上手动清除ARP缓存：`ip neigh flush all`。
两个容器在同一个宿主机上无法通信，可能是什么原因？
首先确认两个容器是否在同一网络命名空间或同一docker网络下，使用 `docker network inspect` 检查，若在同一网络，问题可能出在宿主机防火墙或iptables的FORWARD规则，检查 `iptables -L -n` 中FORWARD链的默认策略，若为DROP则需添加放行规则，同时确认docker0网桥的权限，以及br_netfilter模块是否已加载。