ip -s link show是现代Linux查看网卡转发统计的标准命令，它分RX/TX两段清晰展示bytes、packets、errors、dropped、missed等字段，其中dropped表内核协议栈丢弃，missed表Ring Buffer溢出，而ifconfig已废弃、字段模糊且不区分丢包层级。
查网卡转发统计用 ip -s link show，不是 ifconfig
ifconfig 已被废弃，输出字段模糊（比如把 dropped 和 overruns 混在一起），且不区分接收/发送侧丢包原因。ip -s link show 才是现代标准，它分两段展示 RX（接收）和 TX（发送）的完整计数器：
-
RX: bytes packets errors dropped missed mcast—— 其中dropped表示内核协议栈主动丢弃（如缓冲区满、反向路径过滤失败）；missed是 Ring Buffer 溢出，属驱动/硬件层问题 -
TX: bytes packets errors dropped carrier collsns—— 这里的dropped多因队列满（如tx_queue_len设置过小）或驱动拒绝发包 - 执行
ip -s link show eth0后，两次运行取差值，才能看出单位时间内的丢包趋势；单次数值无意义
定位物理链路丢包必须看 ethtool -S 和 /proc/net/dev
内核层 dropped 高，不等于物理链路有问题；但物理层异常（线缆松动、光模块衰减、双工不匹配）一定会在底层计数器里留下痕迹。关键要看：
-
ethtool -S eth0 | grep -E "(crc|frame|fifo|drop)"：重点盯rx_crc_errors（CRC校验失败）、rx_frame_errors（帧格式错）、rx_fifo_errors（接收 FIFO 溢出）。这些非零且持续增长，基本可断定是物理链路隐患 -
cat /proc/net/dev中 eth0 行的errs列：对应传统 ifconfig 的 “RX errors”，本质是驱动上报的硬件错误总和；若该值 > 0，ethtool -S必须跟进 - 注意：
ethtool -S输出因网卡芯片而异（Intel igb 和 Broadcom bnxt 字段名不同），不能只搜关键词，得结合ethtool eth0确认 Link 状态、Speed、Duplex 是否一致
dropwatch 能告诉你“在哪一行内核代码丢的包”，但别一上来就编译它
dropwatch 是唯一能追踪到具体丢包函数（如 tcp_v4_rcv、ip_rcv_finish）的工具，但它依赖 kprobes，需调试符号、内核头文件，且默认不记录上下文（如源 IP、端口）。实际使用前先确认：
- 你是否已排除物理层和驱动层问题？如果
rx_crc_errors > 0，dropwatch结果毫无价值——包根本没进协议栈 - 是否已用
ip -s link show确认rx_dropped显著上升？否则dropwatch会捕获大量噪音（如 UDP socket buffer full 的常规丢包） - 生产环境慎用：它会增加内核 probe 开销，高流量下可能加剧丢包；建议先在复现环境跑
dropwatch -l kas看热点函数，再针对性加日志
mtr 和 ping 只能测通路，不能替代本地丢包分析
很多人看到 mtr 某跳 Loss% 高，就以为是运营商问题，结果发现是自己服务器 rp_filter=1 导致反向路径验证失败，把回包全丢了。真正要分清责任边界：
-
ping -c 100 8.8.8.8丢包率 > 5%，先别急着联系 ISP —— 执行ip -s link show eth0看本地TX: dropped是否同步增长；若不变，说明丢包发生在本机以外 -
mtr --tcp -P 443 example.com比 ICMP 更可靠，但依然无法反映本机内核处理瓶颈；它只回答“哪一跳不可达”，不回答“为什么本机收不到对端响应” - 若
ip -s link show显示RX: dropped高，而ethtool -S一切正常，大概率是应用读包太慢（ss -i看rcv_ssthresh是否压到 1）或防火墙规则（iptables -t raw -nvx查PREROUTING链 drop 计数）
最常被忽略的是：同一块网卡的 rx_dropped 和 rx_missed 增长原因完全不同，但很多人只盯着一个数调参。前者调 net.core.rmem_max，后者得调 ethtool -G eth0 rx 4096 或绑中断到多核。
