tc不是“开个开关就能限速”的工具，它依赖队列规则（qdisc）、类定义（class）和过滤器（filter）三层结构协同工作；未配对qdisc与class或遗漏filter将导致限速无效。
直接说结论：tc 不是“开个开关就能限速”的工具，它依赖队列规则、类定义和过滤器三层结构协同工作；没配对 qdisc 和 class，或漏掉 filter，限速基本无效。
为什么tc加了规则却完全不生效？
最常见原因是把限速规则加在了错误的网络接口上，或者没指定出口方向（egress）。tc 只能控制本机发出的数据包（即 egress），无法限制流入（ingress）带宽——除非用 ifb 模块做重定向。
-
tc默认只作用于egress，想限下载得把流量先“拉”到虚拟接口ifb0上再限 - 物理网卡如
eth0不能直接挂htb+sfq复合 qdisc，必须先删掉默认的pfifo_fast：tc qdisc del dev eth0 root
- 误把
rate单位写成mbit（应为mbit是合法的，但mbps或Mbps会静默失败） - 没加载
sch_htb和sch_sfq内核模块（某些精简内核需手动modprobe sch_htb sch_sfq）
tc 限速时如何精准匹配某类流量？
靠 filter + u32 或 fw 匹配器。用 u32 写 IP/端口条件容易出错，推荐先用 iptables 打标记，再用 tc filter 查 fw 标记——更稳定、易调试。
- 给目标流量打标记：
iptables -t mangle -A OUTPUT -d 192.168.1.100 -j MARK --set-mark 1
- 在
htb下挂 class 并绑定 filter：tc filter add dev eth0 parent 1: protocol ip u32 match ip dst 192.168.1.100 flowid 1:10
（u32方式）
或更推荐：tc filter add dev eth0 parent 1: protocol ip handle 1 fw flowid 1:10
-
handle值必须和iptables的--set-mark一致；flowid必须对应已创建的classID（如1:10）
单台服务器限速多个客户端，tc 怎么避免互相抢占？
关键在 htb 的 ceil 和 rate 配合，以及子类的 burst/cburst 设置。单纯设 rate 会导致突发流量被丢弃，体验卡顿；不设 ceil 则无法实现“保底+弹性”。
- 根类设总带宽上限：
tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit ceil 100mbit
- 每个客户端分一个子类，
rate是保障带宽，ceil是峰值上限：tc class add dev eth0 parent 1:1 classid 1:10 htb rate 10mbit ceil 20mbit burst 15k cburst 15k
- 务必给每个
class挂一个sfqqdisc 做内部排队：tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
- 漏掉
sfq，多个 TCP 流会因 ACK 拥塞而严重不均——这是实际部署中最常被忽略的一环
真正难的不是写对几条 tc 命令，而是理解每层 qdisc/class/filter 如何传递数据包；一旦某个 class 没绑 qdisc，或 filter 的 flowid 指向不存在的 class，整个链路就静默失效——连日志都不会报错。
