根因是IP地址冲突，一台新接入的物联网设备占用了服务器的IP，导致周期性卡顿。排查发现服务器资源正常但用户侧体验极差，最终通过网络层分析锁定冲突源。
服务器突然打不开、接口超时、后台响应慢到转圈，登录宝塔或监控面板一看，出网带宽100%贴顶，但top里CPU和内存都正常——这种“卡在网口”的故障，必须立刻锁定是哪个IP或哪个进程在疯狂发包。
确认是否真被带宽打满
先排除误判：用sar -n DEV 1 5连续采样5秒，重点看txkB/s（出向带宽）是否持续超过实例规格上限。比如2Mbps带宽的ECS，理论峰值约250KB/s；若eth0的txkB/s稳定在900+，基本可断定出向被打满。
注意：【不要只看ifconfig显示的RX/TX累计值】，那只是总量，无法反映瞬时压力。
定位高流量网卡和方向
执行ip link show列出所有网卡，重点关注状态为UP且有公网IP的设备（如eth0或ens3）。若服务器有多网卡，必须先明确攻击流量走的是哪一张——内网卡异常飙升通常意味着横向渗透，公网卡爆满才对应外部恶意请求。
运行sudo sar -n DEV 1 5后，对比各IFACE的txkB/s平均值，数值最高的即为问题网卡。
揪出耗带宽的IP地址
方法一：用iftop -i eth0 -P -n实时查看（将eth0替换成你确认的问题网卡名）。
界面中右侧IP列按实时流量降序排列，箭头=>表示本机向外发送数据，<=表示对方往本机发包。紧盯=>方向流量最大的那个IP，它极大概率就是元凶。
方法二：若iftop因权限或未安装无法使用，改用ss -tunp | awk '{print }' | cut -d: -f1 | sort | uniq -c | sort -nr | head -10粗筛高频外连目标IP——这招不依赖第三方工具，但只能统计连接数，不能反映实际字节数。
锁定具体进程PID
第一步：运行nethogs -t 2 eth0（同样替换网卡名），界面左侧直接显示进程PID和命令名，右侧实时刷新该进程的上行/下行速率。
第二步：若看到某个PID持续占满90%+带宽，记下PID，执行ps -p PID -o pid,ppid,cmd,%mem,%cpu确认进程归属和启动路径。
第三步：检查该进程是否合理——比如/usr/bin/python3 /opt/backup/sync.py突然占用200MB/s，明显异常；而nginx: worker process在大促期间短暂冲高则需结合访问日志进一步判断。
若nethogs未安装，可用lsof -i -P -n | grep "ESTABLISHED" | awk '{print $2,$9}' | sort | uniq -c | sort -nr | head -5辅助定位高频通信进程ID。
立即阻断恶意流量
确认IP为恶意来源后，执行iptables -A OUTPUT -d xxx.xxx.xxx.xxx -j DROP封禁本机对外发送到该IP的所有数据包。此规则生效快、无延迟，比应用层限速更直接。
封禁后立刻再跑一遍iftop -i eth0，观察txkB/s是否断崖式下跌。若下降不明显，说明还有其他IP或端口在发包，需回到上一步继续筛查。
注意：【DROP规则不可逆，执行前务必确认IP无业务关联】，误封支付回调或CDN回源IP会导致线上故障。
