netstat 定位网络连接数据包丢失现象

netstat -s 不显示具体丢包数据包，但通过统计计数精准定位丢包环节：TCP 关注 segments retransmitted、failed connection attempts 和 embryonic connections dropped；UDP 重点看 packet receive errors、receive buffer errors 和 in errors/no ports；需联动 ethtool、iptables、ss 等命令交叉验证。

netstat 本身不直接显示“哪个包丢了”，但它能暴露数据包丢失背后的协议栈异常行为——尤其是通过 netstat -s 输出的统计计数，可精准指向丢包发生的环节（如链路层、传输层或应用层缓冲区）。关键在于读懂那些增长异常的指标，而不是盯着连接列表。

重点关注 TCP 重传与连接建立失败
TCP 的可靠性机制会让丢包表现为重传行为，这是最可靠的丢包线索：

• segments retransmitted 持续上升 → 表明发送端反复重发，原因可能是中间链路丢包、接收端 ACK 延迟/丢失，或往返时延（RTT）剧烈波动。此时应配合 mtr 查路径，用 ping -R 看路由是否跳变。
• connection attempts failed 或 failed connection attempts 显著增加 → 不是丢包本身，而是连接根本建不起来。若伴随 no route to host，检查路由表或网关；若为 connection refused，说明目标端口无服务监听，需用 ss -tlnp | grep :端口 验证。
• embryonic connections dropped 上升 → SYN 半连接队列溢出，常见于突发 SYN 请求（如扫描或攻击），或 net.ipv4.tcp_max_syn_backlog 设置过小。可通过 sysctl net.ipv4.tcp_max_syn_backlog 查当前值。

UDP 丢包要盯接收端缓冲与端口状态
UDP 没重传，丢包是静默的，netstat -s -u 中以下字段最有诊断价值：

• packet receive errors 非零 → 往往不是网络问题，而是内核收包失败：网卡 DMA 错误、驱动异常、或 sk_buff 内存分配失败（查 dmesg | grep -i "skb"）。
• receive buffer errors 增长 → UDP socket 接收缓冲区已满，新包被内核直接丢弃。运行 ss -uln 看对应端口的 Recv-Q 是否长期非零；若属实，调大 net.core.rmem_default 并确认应用是否及时 recv()。
• in errors 或 no ports 计数上升 → 数据包到达了本机，但目的端口没进程监听。典型场景包括：服务未启动、容器未映射 UDP 端口、或绑定 IP 不匹配（如程序绑 127.0.0.1 却从外网访问）。

结合其他命令交叉验证
netstat -s 是线索，不是结论。必须联动验证：

• 看网卡是否真丢包：ethtool -S eth0 | grep -E "(rx|tx)_.*drop|err"，尤其关注 rx_missed_errors（Ring Buffer 溢出）和 rx_frame_errors（物理层校验失败）。
• 查防火墙是否静默丢包：iptables -nvxL | grep -E "DROP|REJECT"，注意 conntrack 表满也会导致新建连接包被丢，dmesg | grep "nf_conntrack: table full" 可确认。
• 排除应用层瓶颈：ss -m 查 socket 内存使用，cat /proc/net/snmp | grep -A1 UDP 对比 InDatagrams 和 NoPorts，差值大说明大量包抵达但无人处理。

不复杂但容易忽略