Linux 服务器上最快的办法是先装 nethogs，它按进程列出实时上下行速率，一条命令就能定位到是哪个 PID 在吃带宽。 nethogs 看不到东西，再退回 iftop 看连接、用 ss -tunp 反查进程，最后用抓包确认，绝大多数“带宽跑满”的现场，十几分钟内都能收敛到一两个进程。
Linux服务器怎么看哪个进程占用带宽：先把视角分清楚
带宽排查容易绕晕,原因在于 Linux 里“流量”有两个视角：网卡视角和进程视角。
- 网卡视角：
/proc/net/dev、sar -n DEV、iftop、bmon，它们只看 eth0 上一共流了多少字节，不知道是谁发的。 - 进程视角：
nethogs、ss -tunp、lsof -i、eBPF 工具，它们能把流量挂到 PID 上，这才是你要的答案。
行业共识认为,排查顺序应该反过来：先确认网卡真的跑满了，再去找进程，否则容易查半天，发现是监控统计口径问题比如云厂商的带宽统计包含内网、或者按 95 峰值计费，和你看到的瞬时值不是一回事。
先花十秒确认网卡到底有没有跑满
cat /proc/net/dev # 隔 2 秒再看一次，用 (第二次RX - 第一次RX)/2 粗略得到速率 sar -n DEV 2 5
sar 的 rxkB/s、txkB/s 比 cat 直观得多，单位是 KB/s，乘 8 kbps，别拿 KB/s 去和 100Mbps 带宽直接比，这是最常见的误判。
nethogs：直接回答“哪个进程占带宽”的工具
nethogs 的原理是抓包并关联到进程，界面上直接列 PID / USER / PROGRAM / SENT / RECEIVED，它是这类需求事实上的首选，也是最常被搜索的那个工具。
CentOS 与 Ubuntu 安装路径不一样
# CentOS 7/8、Rocky、AlmaLinux yum install -y epel-release && yum install -y nethogs # Ubuntu / Debian apt update && apt install -y nethogs
CentOS 7 上如果 EPEL 版本太老，nethogs 可能不支持 IPv6 或容器网络，建议源码编译或换 iftop 过渡。
常用参数与实操命令
nethogs # 默认监控所有网卡 nethogs eth0 # 只看业务网卡 nethogs -d 2 eth0 # 每 2 秒刷新，默认是 1 秒 nethogs -t eth0 # 追踪模式，纯文本输出，适合重定向到文件 nethogs -v 3 # 视图模式：0 KB/s，1 KB/s+总量，3 字节
线上机器推荐 nethogs -t eth0 > /tmp/bandwidth.log 挂后台跑几分钟，再用 sort、awk 抓峰值，比在终端里盯着看靠谱，界面里的 可以切换显示单位，m 切换 KB/s、B/s、MB/s，q 退出。
三个高频坑
- 必须 root，普通用户会报
creating socket failed while establishing local IP - are you root? - 容器里看不到宿主进程，在 Docker 容器内跑
nethogs，PID 命名空间被隔离，你只能看到容器内的进程，要查宿主，得nsenter -t <PID> -n nethogs进到目标 netns。 - 虚拟化网卡识别不全，部分 KVM、OpenVZ 环境下抓不到包，
nethogs界面显示一堆unknown TCP，就得换方案。
服务器带宽被占用怎么排查：iftop 加 ss 的组合拳
nethogs 装不上或看不到进程时，用这套组合，业内专家指出，连接级分析往往比进程级更快定位到问题对端。
iftop 看的是连接和远端 IP
yum install -y iftop # 或 apt install iftop iftop -i eth0 -n -P # -n 不解析域名，-P 显示端口
界面里 => 是发送、<= 是接收，底部三段带宽刻度能直接看出哪条连接最粗，按 t 切换显示模式，按 s、d 只看源或目的，按 L 打开过滤。iftop 不告诉你 PID，但它给你远端 IP 和端口，这是下一步的钥匙。
ss 把连接反查回进程
ss -tunp | grep 443 ss -tunp state established '( dport = :443 )' lsof -i :8080
ss -tunp 的 users:(("nginx",pid=1234,fd=6)) 就是答案，对长连接服务，用 ss -tni 还能看到发送队列 Send-Q 是否堆积，堆积说明对端收得慢，不是你发得太快。
需要历史数据就靠 sar 和 vnstat
nethogs、iftop 都是实时的，人不在现场就抓不到。sysstat 默认每 10 分钟记一次，sar -n DEV -f /var/log/sa/sa15 能回看某天哪个时段网卡跑满。vnstat -l -i eth0 实时看，vnstat -d 看日流量，这两样适合事后复盘，不适合定位进程，别指望它们给出 PID。
nethogs和iftop哪个更适合看进程带宽
一张表说清楚,省得反复试。
| 维度 | nethogs | iftop |
|---|---|---|
| 展示粒度 | 进程 / PID | 连接 / 远端 IP |
| 能否定位进程 | 能，直接给 PID | 不能，需配合 ss、lsof |
| 安装依赖 | 需 EPEL 或编译 | 主流源都有 |
| 容器内可用性 | 需进目标 netns | 同样受限 |
| 适合场景 | 快速锁定“谁在吃带宽” | 分析“流量去了哪里” |
| 资源占用 | 抓包，流量大时 CPU 略高 | 同样抓包，界面开销低 |
实务上的顺序是：nethogs 先扫一遍，锁定可疑 PID；如果进程是 nginx、java 这类多连接服务，再用 iftop 看具体是哪条连接、哪个对端，ss -tunp 或 lsof 坐实。
云服务器带宽跑满怎么查：几个容易踩的额外变量
云上排查和物理机有一处本质不同：你看到的“带宽”可能是计费口径，不是网卡口径。
- 峰值计费：多数云厂商按出方向 95 峰值或固定带宽计费，入方向通常免费。
nethogs显示上传高，才对应到账单。 - 内网流量不计费但占网卡：同地域 VPC 内传输走内网，
iftop会显示跑满，账单却不动，先看对端 IP 是不是 10.x、172.16.x、192.168.x。 - 突发性能实例：部分共享型实例有带宽积分，积分耗尽后限速，表现是“怎么优化都跑不快”。
- 攻击流量：
iftop里出现大量陌生 IP 打同一端口，配合ss -tunp | wc -l看连接数是否异常，再看netstat -s | grep -i "SYNs to LISTEN"，这种情况查进程没意义，得在安全组和清洗上做。
docker stats 给的 NET I/O 是累计值，不是速率，很多人在这一步误判，要容器级的实时速率，进容器 netns 跑 nethogs，或直接用 cAdvisor、Netdata 这类采集器。
想长期把账算清楚：eBPF 和 tc
需要按进程长期统计、而不是临时排障时，几种做法：
- bcc 工具集：
tcptop -C 5按进程聚合 TCP 收发字节，netqtop看内核网络队列，内核版本建议 4.14 以上。 - iptables 计数：对特定端口打
-m comment --comment "web"再加-j RETURN，用iptables -L -v -n看字节累加，适合给固定业务做流量画像。 - tc 限速：定位到进程后要止血，
tc qdisc add dev eth0 root tbf rate 20mbit burst 32kbit latency 400ms能先压住网卡总量；更精细的做法是按 cgroup 加 filter。
pidstat -d 是磁盘 I/O，pidstat -r 是内存，pidstat -n 才是网络，这个参数老有人记混，看到 kB_rd/s 就以为是流量，实际上那是读盘速度。
关于进程带宽占用的常见问题
Linux服务器怎么看哪个进程占用带宽，没有 root 权限怎么办
没有 root 基本看不了进程级流量。nethogs、iftop 都需要 CAP_NET_RAW 或 CAP_NET_ADMIN，折中办法：用 ss -tunp 看自己能看到的连接（只能看到同 UID 的进程），或者请管理员配 sudo 白名单，只放开这几个命令。
nethogs 显示 unknown TCP 是什么原因
多数是抓到的包对应不上已有 socket，常见于三种情况：进程刚退出但连接还在 TIME_WAIT；流量来自宿主机或其它 netns；网卡做了 bonding、VLAN 或 offload，抓包点拿不到原始进程信息，可以先 ethtool -K eth0 gro off gso off tso off 关掉卸载再试，或者改用 ss 从连接侧反查。
进程带宽和网卡带宽对不上，差在哪里
差额通常来自内核协议栈开销、重传和抓包点差异。nethogs 统计的是应用层可识别的字节，网卡计数器包含以太网帧头、VLAN tag 和 TCP 重传，MTU 1500 下，小包多时帧头开销能占到较大比例，两边差个百分之十几属于正常范围；如果差得离谱，先查 netstat -s | grep retrans 看是不是网络质量在拖后腿。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/797368.html
