nethogs是唯一开箱即用的进程级实时流量监控工具；它必须用sudo运行，因其依赖libpcap捕获原始数据包，需cap_net_raw权限访问网卡驱动层，不加sudo会报“permission denied”错误，即使监控lo接口亦如此。
直接看进程级实时流量，nethogs 是唯一开箱即用的方案；其他工具要么看不到进程名（如 iftop），要么只能靠间接推断（如 ss + lsof），且都绕不开权限和上下文限制。
为什么必须用 sudo 运行 nethogs
nethogs 依赖 libpcap 捕获原始数据包，需 CAP_NET_RAW 权限才能访问网卡驱动层。不加 sudo 会报错：Unable to create socket: Permission denied——哪怕只监控 lo 接口也一样。普通用户运行时，它最多只显示自己启动的进程，系统级服务（如 systemd-journald、dbus-broker）完全不可见。
- 常见错误：直接运行
nethogs报Unable to open /dev/tty: No such device or address，大概率是终端不支持 curses 图形模式，换用nethogs -t（文本模式）即可 - 云服务器上默认网卡名不是
eth0（如阿里云是ens33，AWS 是eth1），不指定接口会失败，必须显式写sudo nethogs ens33 - 多网卡需一次列出：
sudo nethogs ens33 docker0；运行中无法动态增删接口
nethogs 单位切换和排序陷阱
nethogs 的单位标识容易误读：kb/s 是千比特每秒（×125 字节），而 KB 是千字节（×1024 字节），数值差约 8 倍。按 m 切换单位时，若启用 -t（跟踪模式），显示的是累计流量（单位 KB），不是瞬时速率，此时 s/r 排序键完全失效。
- 按发送速率排序：用
sudo nethogs -s ens33（-s表示 sort by sent） - 导出快照分析：配合
head截取前几行，如sudo nethogs -t ens33 | head -15 - 容器内无效：它无法穿透网络命名空间，宿主机上运行
nethogs看不到容器内进程的真实流量归因
没有 nethogs 时的兜底方案：ss + lsof
当 nethogs 不可用或权限受限（如 SELinux 强制策略、cgroups v2 环境），可用 ss 查连接 + lsof 反查进程。但要注意：ss 默认不统计已收发字节数，所以不能靠“字节数”排序，得靠连接频次、并发数、目标地址异常性来判断“耗带宽”。
- 必须用
sudo：否则lsof查不到其他用户的进程，ss -tunap中的p（显示 PID）也会为空 - 快速定位高活跃连接：
sudo ss -tunap | grep ESTAB | sort -k7,7nr | head -5（第 7 列是 inode，非字节数） - 若
ss输出中pid字段为-，说明该 socket 属于内核线程或权限不足，改用sudo lsof -i -P -n | grep ESTAB | sort -k9,9nr | head -5（lsof第 9 列通常是发送字节）
真正要归因到具体进程，nethogs 仍是首选；但它对多线程程序（如 Chrome、Java 应用）可能只显示主线程名，且在 systemd socket 激活机制下，部分服务的初始连接可能短暂归属 systemd 进程，这些细节容易被忽略。
