Linux TC限速实战：从基础配置到精准控制的避坑指南

直接使用 tc 进行网络限速，无疑是Linux系统下最底层、最精细的控制手段。但这里有个常见的误区：很多人以为加条命令就万事大吉。实际上，tc 更像一个精密的调节阀，参数配置稍有偏差，结果可能就是丢包严重、延迟飙升，甚至导致SSH连接中断。所以，关键不在于“用不用”，而在于“怎么用对”。

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

说起限速，TBF（令牌桶过滤器）通常是入门首选，因为它配置相对直观。但它的“脾气”也很大，尤其是对 burst（突发量）和 latency（延迟）这两个参数极其敏感。设置得太小，网络中的小数据包会因为频繁排队超时而被丢弃；设置得太大，突发流量又会瞬间冲垮你设定的限速目标，让限速形同虚设。

这里有几个必须牢记的细节：burst 的单位是 bit，而不是 byte，其值至少需要大于等于单个数据包最大长度的两倍。在千兆网卡环境下，常见的MTU是1500字节，因此一个比较稳妥的起始值可以设为 burst 32kbit（相当于4KB）。另一个关键参数 latency，它代表的是数据包在队列中等待的“最长期限”，而不是我们期望的延迟目标。如果设置为 50ms，就意味着任何数据包排队超过50毫秒就会被直接丢弃。试想一下，如果在上传限速时把这个值设成 400ms，SSH操作的响应卡顿感就会非常明显。

那么，如何安全地开始呢？建议先用一组保守的参数进行测试：tc qdisc add dev eth0 root tbf rate 5mbit burst 32kbit latency 100ms。配置完成后，不要只看网速，一定要通过 tc -s qdisc show dev eth0 命令，持续观察输出结果中的 drops（丢包数）和 overlimits（超限次数）这两个计数器。根据它们的增长情况，再逐步调整 rate 等参数，这才是科学的调优过程。

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

这是Linux网络限速中一个经典的“坑”：内核本身并不支持在入向流量（即下载方向）上直接挂载 tbf 或 htb 这类队列规则。你可能会看到有人执行 tc qdisc add dev eth0 ingress，但这仅仅创建了一个流量捕获点，真正的限速动作，需要借助IFB（Intermediate Functional Block）虚拟设备，把入向流量“镜像”成出向流量来处理。

整个流程必须按顺序来，一步都不能错：首先，加载内核模块：modprobe ifb numifbs=1；接着，启用虚拟网卡：ip link set dev ifb0 up。然后才是配置规则链：先在物理网卡上设置 ingress 捕获点，再用过滤器将捕获的流量重定向到虚拟网卡 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 这类虚拟设备在系统重启后通常不会自动启用。因此，如果你的配置需要持久化，务必在脚本中显式加入 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 是一个接口级的流量整形器，它只关心“从这张网卡出去的总流量是多少”，而无法区分“这些流量是谁的”。因此，如果你想实现更精细的控制，比如只限制源端口为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 表示精确匹配端口8080，如果误写成 0xff00，就会错误地匹配到8080到8175这一整个端口范围。配置完成后，务必使用 tc -s filter show dev eth0 parent 1:0 命令进行验证，观察 sent 计数是否随着目标端口的流量增加而上升。

说到底，TC限速真正的难点，从来不是写对第一条命令。而是在于出现问题后，如何快速定位：到底是哪一层的规则在丢包？哪个队列出现了堆积？为什么设置了 latency 却没有达到预期效果？要回答这些问题，离不开 tc -s qdisc 和 tc -s class 这些命令提供的实时统计数据。跳过监控和验证这一步，你只是在盲目地修改配置，而非真正地掌控流量。