tc限速需精准配置burst与latency，下载限速须用ifb虚拟设备，清除规则需同步删除ingress、root及ifb队列；端口级限速依赖u32分类器配合htb子类。

直接用 tc 限速是最底层、最可控的方式，但错配参数会导致丢包严重、延迟飙升，甚至 SSH 断连。别信“加条命令就完事”的说法——tc 不是开关，是调节阀，得看准方向、拧对圈数。

tc qdisc add root tbf：为什么 burst 和 latency 必须配平

TBF（Token Bucket Filter）是最易上手的限速方式，但它对 burst 和 latency 非常敏感。设得太小，小包频繁排队超时被丢；设得太大，突发流量直接冲垮限速目标。

• burst 单位是 bit（不是 byte），必须 ≥ 单个数据包最大长度 × 2。千兆网卡下常见 MTU 是 1500，推荐起始值设为 burst 32kbit（即 4KB）
• latency 是排队等待上限，不是延迟目标。设成 50ms 意味着包最多等 50ms，超时就丢。上传限速时若设 400ms，SSH 响应会明显卡顿
• 实操建议：先用保守值测试 —— tc qdisc add dev eth0 root tbf rate 5mbit burst 32kbit latency 100ms，再逐步调高 rate 并观察 tc -s qdisc show dev eth0 中的 drops 和 overlimits 计数

tc 限制下载带宽必须用 ifb：入口流量不能直接限

Linux 内核不支持对入向流量（download）直接挂 tbf 或 htb。你看到的 “tc qdisc add dev eth0 ingress” 只是捕获点，真正限速得靠 IFB 虚拟设备把入向转成出向。

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

• 必须先加载模块：modprobe ifb numifbs=1，再启用虚拟网卡：ip link set dev ifb0 up
• 重定向规则顺序不能错：先 ingress 捕获，再 mirred 转发到 ifb0，最后在 ifb0 上挂限速器。漏掉任意一环，限速无效
• 典型命令链：

  tc qdisc add dev eth0 handle ffff: ingress
  tc filter add dev eth0 parent ffff: protocol ip u32 match ip src 0.0.0.0/0 action mirred egress redirect dev ifb0
  tc qdisc add dev ifb0 root tbf rate 2mbit burst 32kbit latency 200ms

• 注意：ifb0 是虚拟设备，重启后不会自动 up，脚本中需显式 ip link set dev ifb0 up

清除 tc 规则不能只删 root：ingress 和 ifb 都要清

执行 tc qdisc del dev eth0 root 只能删掉出口队列，ingress 捕获点和 ifb0 上的限速器还在运行，会造成规则残留、统计错乱，甚至影响后续配置。

• 完整清理顺序：

  tc qdisc del dev ifb0 root 2>/dev/null
  tc qdisc del dev eth0 root 2>/dev/null
  tc qdisc del dev eth0 ingress 2>/dev/null
  ip link set dev ifb0 down 2>/dev/null

• 检查是否清干净：tc qdisc show dev eth0 应返回空；tc qdisc show dev ifb0 同样应为空
• 别依赖 wondershaper -c 全清——它只处理自己加的规则，手动加的 ifb 流程它不认

端口级限速要用 u32 + filter：tbf 本身不识别端口

tbf 是接口级整形器，它只管“从这个网卡出去多少”，不管“谁的数据”。要限某端口（比如只限 src port 8080 的上传），必须用分类器（u32 或 fw）先把流量筛出来，再扔进子类限速。

• 先建 HTB 根队列：tc qdisc add dev eth0 root handle 1: htb default 30
• 再建子类并绑定端口过滤器：

  tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit
  tc filter add dev eth0 protocol ip parent 1:0 u32 match ip sport 8080 0xffff flowid 1:1

• 关键点：u32 匹配语法严格，sport 是源端口，dport 是目的端口；十六进制掩码 0xffff 表示精确匹配，写成 0xff00 就会误匹配 8080–8175
• 验证匹配效果：tc -s filter show dev eth0 parent 1:0 看 sent 计数是否随目标端口流量上升

真正难的不是写对第一条命令，而是搞清哪一层在丢包、哪个队列在堆积、为什么 latency 设了却没效果——这些都得靠 tc -s qdisc 和 tc -s class 的实时统计来交叉验证。别跳过这步，否则你只是在改配置，不是在控流量。