Linux网络吞吐不稳定需分层定位：先用iftop -P、nethogs查实时带宽与进程占用，再用ss分析TCP连接状态及Recv-Q/Send-Q堆积，接着用ip -s link、tc -s qdisc、netstat -s排查底层丢包与队列丢弃，最后通过tcpdump+Wireshark抓包分析TCP握手、首字节响应和传输耗时。
Linux 网络吞吐不稳定，核心在于区分“现象”和“根源”：是带宽被占满、链路丢包、协议栈拥塞，还是应用层处理滞后？流量分析不是单纯看“有多少字节”，而是要分层定位瓶颈点。
实时带宽与进程级占用分析
先确认是否真有带宽争抢。用 iftop -P 查看实时端口级流量，加 -P 可显示端口号，快速识别哪个服务或连接在猛发数据；nethogs 则直接按进程展示上下行速率，适合判断是否某个后台程序（如 rsync、日志同步、监控 agent）突发拉高出口带宽。
注意：这些工具默认只统计当前活跃连接，若吞吐波动周期较长（如每分钟一次峰值），建议配合 vnstat -l 查看历史分钟级汇总，确认是否为规律性行为。
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
TCP 连接状态与队列堆积检查
吞吐不稳常伴随连接异常。运行 ss -s 查总连接数分布，重点关注 TIME-WAIT 和 ESTABLISHED 是否异常偏高；再执行 ss -tan state established | wc -l 统计活跃连接数，若远超预期（如 Web 服务通常几百，却达上万），说明连接未及时释放或存在慢客户端拖累。
关键看 Recv-Q 和 Send-Q：若某连接的 Recv-Q 持续 > 0，表示应用读取太慢，内核接收缓冲区积压；若 Send-Q 长期非零，说明对方 ACK 延迟或网络拥塞导致发送卡住。这两者都会直接压制吞吐稳定性。
底层丢包与队列丢弃验证
跳过中间猜测，直查硬件和驱动层证据：
• 执行 ip -s link show eth0（替换为实际网卡名），检查 rx_errors、tx_dropped、rx_missed 是否增长——持续上升指向网卡、驱动或物理链路问题；
• 运行 tc -s qdisc show dev eth0，关注 dropped 字段。非零且随时间增加，说明本地出口队列已饱和，是典型的拥塞信号，需调整 qdisc 或限速；
• 查 netstat -s | grep -i "retransmitted"，重传段数短时激增，表明路径中存在丢包，需结合 mtr 定位具体跳点。
抓包聚焦关键路径耗时
对典型请求做精细耗时拆解，避免泛泛而谈“网络慢”：
• 用 tcpdump -i eth0 -s 0 port 80 -w http.pcap 抓 HTTP 流量；
• 在 Wireshark 中打开，右键任一 HTTP 包 → Follow → HTTP Stream，自动关联请求与响应；
• 观察三阶段时间：
- TCP 握手耗时（SYN → SYN-ACK）反映基础延迟；
- 首字节响应时间（GET 发出 → HTTP/1.1 200 第一个字节）体现服务端处理+网络往返；
- 完整响应传输时长（首字节 → 最后一个 ACK）反映带宽与窗口大小是否受限。
若握手快但首字节响应慢，问题在服务端；若首字节快但传输慢，可能是带宽打满或 TCP 窗口收缩。
