定位Docker容器丢包瓶颈的关键是分层排查veth-pair两端及转发节点：先验证容器内eth0状态与连通性，再匹配宿主机端veth接口查drop计数，接着检查docker0网桥、iptables和conntrack表溢出，最后才分析物理网卡驱动与中断负载。
定位 Docker 容器内丢包瓶颈，关键不是直接查物理网卡，而是理清 veth-pair 两端的流量路径和转发节点。veth-pair 本身几乎不丢包（内核内存拷贝），真正可能丢包的位置集中在：宿主机 iptables 规则、docker0 网桥转发、内核 netfilter 队列、或物理网卡驱动/队列溢出。需逐层验证，而非盲目盯住物理网卡。
确认容器侧 veth 接口状态与基础连通性
先排除容器内部问题。进入容器执行：
- ip addr show eth0：检查是否获取到有效 IP（如 172.17.0.x），状态为 UP，且无 TX/RX errors 或 dropped 计数异常增长
- ping -c 3 172.17.0.1（docker0 网桥地址）：验证容器到宿主机网络命名空间的直连通性。不通说明 veth-pair 或 docker0 异常
- cat /proc/net/dev | grep eth0：观察 RX/TX 的 drop 和 errs 字段，非零值需立即排查容器内应用或配置
匹配宿主机端 veth 接口并检查其统计信息
veth pair 的宿主机端接口名通常形如 vethxxxxxx，可通过 iflink 快速定位：
- 在容器中运行 ip link show eth0，记下输出末尾的
link-netnsid N - 在宿主机执行 ip link | grep "link-netnsid N"，即可找到对应 veth 接口（如
vethabc123@if12） - 对这个 veth 接口运行 cat /proc/net/dev | grep vethabc123：重点看 RX 的 drop（表示被内核丢弃，常见于 netfilter 队列满或 conntrack 溢出）、TX 的 carrier（链路异常）或 collisions（极少，但若存在说明底层桥接异常）
检查 docker0 网桥与内核转发行为
docker0 是流量必经中转点，其转发能力受内核参数限制：
- brctl show docker0：确认目标 veth 已正确 attach 到 docker0
- sysctl net.bridge.bridge-nf-call-iptables：若为 1（默认），说明经过 docker0 的包会触发 iptables；若规则复杂或 conntrack 表满，会导致延迟甚至丢包
- cat /proc/sys/net/netfilter/nf_conntrack_count 与 /proc/sys/net/netfilter/nf_conntrack_max：比值 >90% 时 conntrack 溢出是高频丢包原因，尤其在短连接密集场景
- ethtool -S docker0 | grep -i drop：部分内核版本支持查看网桥级丢包计数（如 rx_dropped），可辅助判断
追踪物理网卡真实负载与驱动瓶颈
只有确认前几层无异常后，才需深入物理网卡：
- ethtool -S ens33 | grep -i "drop\|error\|over"（将 ens33 替换为实际物理网卡名）：重点关注 rx_missed_errors（接收队列溢出）、tx_aborted_errors、rx_over_errors
- cat /proc/interrupts | grep ens33：单个 CPU 处理中断过于集中（某 CPU 中断数远高于其他）易导致软中断处理不及时，引发丢包
- ip -s link show ens33：查看 qdisc 队列长度（backlog）和 drops，若 backlog 常年 >1000 且 drops 持续增长，说明网卡驱动或队列深度配置不足
