宝塔面板不监控具体带宽占用进程，需用iftop排查实时连接；网站限速失效常见于绕过Nginx的PHP直连、未查错误日志或HTTP/2兼容问题；tc限速须用mbit单位并设合理burst值；API细粒度限流需手动配置Nginx limit_req；排查前应先停用宝塔防火墙插件。

宝塔面板本身不监控“谁在占带宽”，它只显示网卡总流量曲线——所以看到带宽跑满，第一反应不该是“怎么限速”，而是“哪个进程或哪类请求在发疯”。排查清楚再动手，否则限速可能限错地方，甚至让 SSH 都连不上。

怎么看实时流量来源？用iftop盯住具体连接

宝塔监控页面里的「实时带宽」只是个总和数字，看不出是 PHP 在刷 MySQL、还是某个 API 被爬虫打爆、抑或是 rsync 同步卡死。必须进终端看真实连接：

• 运行 iftop -P 80,443：只看 HTTP/HTTPS 流量，按流量大小排序，一眼揪出高耗带宽的 IP 和端口
• 运行 iftop -f "port 3306"：如果怀疑是数据库拖垮带宽，单独过滤 MySQL 流量
• 注意右上角的 TX（出向）/ RX（入向）数值——带宽跑满通常指 TX 拉满，说明你的服务器正在疯狂往外吐数据（比如图片站被镜像、视频接口被盗链）
• 别信“本地回环”127.0.0.1 的高流量：可能是 PHP-FPM 和 Nginx 之间通信异常，或某脚本死循环调自己接口

为什么站点限速没生效？三个常见断点

你在「网站 → 流量限制」里设了并发 30、单 IP 5，但 ab 压测照样打出 200 QPS——大概率卡在这几个环节：

• limit_conn 和 limit_req 规则只对经过 Nginx 的 HTTP 请求有效；后台 cron 脚本、file_get_contents()、curl_exec() 发起的请求完全绕过，它们走的是 PHP 进程直连网络，宝塔看不见
• 你启用了限速，但没检查 Nginx 错误日志：/www/wwwlogs/your-site.error.log，里面会有类似 limiting requests, excess: 12 by zone "xxx" 的记录，没这条就等于没生效
• HTTPS 站点若启用了 HTTP/2，某些旧版 Nginx 对 limit_req 支持不稳，建议临时切回 HTTP/1.1 测试是否规则被跳过

tc 命令封网卡出口，但rate单位不是 MB/s

想把 eth0 出向带宽硬锁在 100Mbps，直接抄网上教程写 tc qdisc add dev eth0 root tbf rate 100mbps 会失效——Linux tc 认的是 mbit，不是 mbps 或 MB/s：

• 确认真实网卡名：ip -br a | grep UP，输出如 ens3 UP 192.168.1.100/24，那就用 ens3，别硬写 eth0
• 正确命令：tc qdisc add dev ens3 root tbf rate 100mbit burst 32kb latency 70ms
• burst 值太小（比如只设 1kb）会导致小包频繁丢弃，网页加载卡顿；太大（>10mb）则失去限速意义；32kb 是较稳的起点
• 该命令重启即失效；要持久化，得写进 /etc/rc.local（注意加 tc qdisc del dev ens3 root 2>/dev/null 前置清理）

API 接口单独限流必须手写 Nginx 配置

宝塔的「流量限制」是整站开关，没法做到 /api/pay 限 2r/s、/api/status 不限。真要细粒度控，只能进「网站 → 设置 → 配置文件」手动加：

• 在 http 块（靠前位置）加：limit_req_zone $binary_remote_addr zone=pay:10m rate=2r/s;
• 在对应 location /api/pay 块里加：limit_req zone=pay burst=4 nodelay;
• 注意 burst 是缓冲队列长度，nodelay 表示不延迟响应（超了直接 503），不加则排队等，容易积压阻塞
• 改完必须点「保存」再点「重载配置」，光保存不重载，Nginx 根本不读新规则

最易被忽略的一点：带宽跑满时，先关掉宝塔自带的「防火墙」插件再排查。它底层用 iptables 记录所有连接，高并发下自身就会吃掉大量 CPU 和内存，反而加剧问题。临时停用命令是 bt 8，不是删规则，是停服务。