用iftop实时盯住高耗带宽的IP和端口，应执行iftop -P 80,443按流量排序定位HTTP/HTTPS异常连接，并重点关注TX（出向）数值拉满的IP及目标端口，同时警惕127.0.0.1本地回环高频通信所揭示的PHP-FPM与Nginx内部异常调用。
用 iftop 实时盯住哪个 IP 和端口在狂刷带宽
宝塔面板首页的「实时带宽」只是个总和数字，看不出是爬虫在扫接口、还是某个 PHP 脚本死循环调自己、抑或是 rsync 同步卡死往外吐数据。真要定位，得进终端用 iftop。
常见错误现象：TX（出向）数值拉满，说明服务器正在疯狂往外发数据；RX（入向）高则多是攻击或大量 POST 请求。
-
iftop -P 80,443：只看 HTTP/HTTPS 流量，按流量大小排序，一眼揪出高耗带宽的 IP 和目标端口 -
iftop -f "port 3306"：怀疑数据库拖垮带宽时单独过滤 MySQL 流量 - 注意右上角 TX/RX 数值——别被 127.0.0.1 的高流量骗了，那可能是 Nginx 和 PHP-FPM 通信异常或脚本自调用死循环
查访问日志确认是不是恶意请求或异常接口调用
流量跑满不等于被攻击，也可能是某个没加限流的 API 接口被业务方误调、或某段 JS 前端无限轮询后端。
使用场景：iftop 找到可疑 IP 后，立刻去对应站点日志里搜它干了啥。
- 日志路径通常是
/www/wwwlogs/yourdomain.com.log，用grep "123.45.67.89" /www/wwwlogs/yourdomain.com.log | tail -50快速查看该 IP 最近 50 条请求 - 重点看状态码：大量
200但响应体极大（比如返回整张表 JSON），说明接口没做分页或字段裁剪；大量404或500则可能是扫描器或错误配置 - 如果发现高频访问某个路径如
/api/v1/stat，且无鉴权，立刻加 Nginx 限流或临时 return 444
检查 CDN 配置是否导致无效回源和持续上行
CDN 上行流量持续跑满，八成不是攻击，而是缓存策略失效或回源配置错误，让 CDN 每次都重新拉取原始资源。
性能影响：无效回源会把本该由 CDN 承担的请求压力全压回源站，同时产生双倍上行（CDN 拉源站）+ 下行（用户拉 CDN）流量。
- 登录宝塔 → 「CDN」→ 查看「上行流量统计」，确认是否集中在某几个域名或路径
- 检查缓存规则：确认关键静态资源（.js/.css/.jpg 等）设置了合理
Cache-Control: public, max-age=31536000，而非no-cache或短过期 - 检查回源 Host：若 CDN 回源时用了错误的
Host头，可能触发源站重定向或动态逻辑，导致每次请求都走 PHP 而非直接返回文件
别跳过本地回环（127.0.0.1）流量这个坑
很多人看到 iftop 里 127.0.0.1 占带宽第一就忽略，其实这是最危险的信号之一——说明问题出在服务内部耦合上，而不是外部攻击。
为什么容易被忽略：监控页面不显示回环流量细节，宝塔日志也不归类统计。
- 典型表现：
iftop显示大量 127.0.0.1:9000 ↔ 127.0.0.1:52923 这类连接，且 TX 持续高位 → 很可能是 PHP-FPM 子进程反复调用本机 API 接口（比如 WordPress 插件轮询 wp-json） - 验证方法：用
lsof -i @127.0.0.1查看哪些进程在密集建连；再结合strace -p [pid]抓一个 PHP 进程看它在调什么 - 临时缓解：在 Nginx 配置里对内网调用路径加
limit_req，或在代码层加 sleep / 缓存开关
iftop 定向，再日志验行为，接着核对 CDN 和回源逻辑，最后死磕本地回环——漏掉最后一步，往往修了半天，流量又悄悄涨回来。 
