关键不是看“容器有没有网”，而是定位“流量在哪儿卡住”。需依次排查CNI插件引入的额外跳转、NetworkPolicy强制流量过载、DNS解析瓶颈、宿主机与容器网络栈差异四大环节，结合命令验证与抓包比对，精准识别延迟根因。
排查容器内部网络延迟过高，关键不是看“容器有没有网”，而是定位“流量在哪儿卡住”。服务编排（如 Kubernetes 或 Docker Compose）会叠加调度、网络插件、策略等多层抽象，让问题更隐蔽。下面从四个最常出问题的环节切入，直击要害。
检查 CNI 插件是否引入额外跳转
默认桥接或某些 CNI 插件（如 Flannel 的 VXLAN 模式）会让东西向流量绕行节点网关，增加毫秒级延迟。尤其在边缘或低配节点上影响显著。
- 运行
kubectl get pods -n kube-system查看 CNI 相关 Pod（如 calico-node、cilium-operator）是否全部 Ready - 执行
ip route show进入任意业务 Pod，确认目标服务 IP 是否走 host-local 路由（如10.244.1.0/24 via 10.244.1.1 dev eth0），而非经由 iptables 或 tunl0 - 若使用 Calico，启用
IP-in-IP disabled和BGP host routes模式；若用 Cilium，开启host-reachable-services和 eBPF-based node port
验证 NetworkPolicy 是否强制流量过载
一条看似合理的 NetworkPolicy，可能让所有 Pod 流量被重定向到集中式策略引擎处理，破坏边缘就近通信优势。
- 执行
kubectl get networkpolicy --all-namespaces，重点检查是否有policyTypes: ["Ingress", "Egress"]全局策略 - 用
kubectl describe networkpolicy xxx -n ns查看规则是否匹配宽泛 CIDR（如0.0.0.0/0）或未加命名空间限定 - 临时禁用可疑策略后，用
curl -w "@format.txt" -o /dev/null http://target-svc对比延迟变化（format.txt含%{time_total}）
确认 DNS 解析是否成为瓶颈
容器内 nslookup 或 dig 延迟高，常因 CoreDNS 配置不当或上游 DNS 不稳定，导致应用连接超时或重试堆积。
- 进 Pod 执行
cat /etc/resolv.conf，确认 nameserver 是集群 CoreDNS ClusterIP（如10.96.0.10），而非宿主机 DNS - 检查 CoreDNS 日志：
kubectl logs -n kube-system deployment/coredns | grep -i "slow"，留意 query latency > 100ms 的记录 - 在 CoreDNS ConfigMap 中添加缓存插件并调大 TTL：
cache 30（单位秒），避免高频重复解析
抓包比对宿主机与容器内路径差异
同一请求，在宿主机 curl 很快，进容器就慢——说明问题出在容器网络栈或命名空间隔离层。
- 在宿主机和 Pod 内分别执行：
tcpdump -i any port 8080 -w trace.pcap，然后用 Wireshark 对比三次握手耗时、ACK 延迟、重传次数 - 重点关注是否出现
TCP Retransmission或Duplicate ACK，若有，检查容器所在节点的net.core.somaxconn和net.ipv4.tcp_rmem是否过小 - 对比两个 trace 中 SYN 包发出时间差，若相差明显（>5ms），说明容器 netns 初始化或 iptables 规则加载拖慢了 socket 创建
不复杂但容易忽略：很多“网络延迟高”实际是健康探针反复失败触发重连，或应用自身重试逻辑没设 timeout，把一次慢响应放大成持续抖动。先盯紧 docker logs 或 kubectl logs 里反复出现的连接拒绝、超时字样，再动手调网络。
