应先用ethtool查网卡标称速率（如1000mb/s），再用sar -n dev 1 5看txkb/s实时值，换算为mbps（×8÷1000）判断是否真跑满；若未满，再用iperf3多流压测、iftop/nethogs定位进程与连接，结合中断分布、tcp参数及连接状态日志综合排查瓶颈根源。
先确认是不是真跑满了，再查谁在用、怎么用、为什么用不满——带宽跑满不是现象，而是结果。
看清楚网卡真实吞吐量
别只盯着监控图上的“98%”，得核对单位和基准。用 ethtool eth0 查网卡标称速率（1G/10G），再用 sar -n DEV 1 5 看 txkB/s 实时值，换算成 Mbps：乘以 8 再除以 1000。比如看到 txkB/s 是 125000，实际是 1000Mbps，那对千兆网卡就是真跑满了；若网卡是 10G，这数值才占 10%，根本不算瓶颈。
再补一刀验证：服务端起 iperf3 -s，客户端用 iperf3 -c IP -P 8 -t 30 多流压测。单流跑不满但多流轻松打满，说明是应用层并发能力或 TCP 参数限制，不是物理带宽问题。
Browser Setup (No-Root Linux)
下载
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
定位到具体进程和连接来源
iftop 和 nethogs 配合使用，才能闭环追踪：
- iftop -i eth0 -P：暂停（按 P 键）后记下高流量的 IP:Port，注意区分内网/外网、HTTP/HTTPS/自定义端口
- nethogs -d 2 eth0：直接显示进程名、PID、实时速率，按 ↑/↓ 排序，一眼看出哪个 Python 脚本或 Java 进程在刷流量
- 如果 nethogs 权限受限，用 ss -tunlp | grep :PORT 反查端口归属，避免把 Nginx 日志轮转或监控探针误判成业务流量
检查内核协议栈是否成为隐形瓶颈
流量确实来自合法进程，但带宽还是上不去？可能是内核“自己卡住了”：
- 运行 watch -n1 'cat /proc/interrupts | grep eth0'，观察各 CPU 列数值是否严重不均——中断全挤在 CPU0 上，其他核空转，就是典型软中断瓶颈
- 执行 netstat -s | grep -i "listen.*drops\|retransmit"，若 “listen drops” 持续增长，说明 SYN 包在进协议栈前就被丢弃，要调 net.core.somaxconn 和 net.ipv4.tcp_max_syn_backlog
- 查 TCP 缓冲区是否够用：sysctl net.ipv4.tcp_rmem，1G 带宽 + 30ms RTT 的 BDP 约 3.75MB，若 max 值只有 4MB 但窗口缩放未启用（net.ipv4.tcp_window_scaling=0），单流永远跑不满
结合连接状态和日志交叉验证
高并发不等于合理请求，得判断流量性质：
- 用 netstat -ant | awk '{print $6}' | sort | uniq -c | sort -nr 统计 TCP 状态，大量 TIME_WAIT 是正常释放，但大量 SYN_RECV 或 ESTABLISHED 持续增长，可能遭遇 CC 攻击
- 按源 IP 统计连接数：netstat -nat | grep ':80' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10，找出异常 IP 段
- 对应查 Web 访问日志：tail -1000 access.log | awk '{print $1}' | sort | uniq -c | sort -nr，比对是否与 netstat 结果一致；若日志里没记录，但连接数暴增，大概率是扫描或恶意建连
