tc限速仅对本机出站流量生效且必须绑定物理网卡；tbf适用于整体出口硬限速，htb+filter支持按ip/端口分流，wondershaper为简化封装工具但不支持精细控制。
tc限速只对出站流量生效，且必须作用于真实网卡
这是最常被忽略的前提：无论你配得多精细，tc 的限速规则**只影响本机发出的数据（OUTPUT 方向）**，对进来的流量（如别人下载你的服务）完全无效。想限“下载速度”，得在对方机器上配；想限“上传速度”，才在你这配。
同时，tc 只能挂载到物理网卡（如 eth0、ens33），不能用在 lo、docker0 或 veth* 这类虚拟接口上——除非你明确在容器或命名空间里做透传，否则直接报错或静默失效。
- 先确认网卡名和状态：
ip link show，确保目标接口是UP - 检查是否已有规则：
tc qdisc show dev eth0，有输出就得先清掉，否则新规则不生效 - 所有命令必须带
sudo，普通用户权限不够
用 tbf 最简限速：适合整体出口带宽硬限制
tbf（Token Bucket Filter）是入门首选，原理简单、开销低、不依赖分类匹配，适合“把整个网卡发出去的流量压到 XX Mbps”这种场景。
比如把 eth0 出口压到 2Mbps：sudo tc qdisc add dev eth0 root tbf rate 2mbit burst 5kb latency 50ms
-
rate是平均速率，单位大小写敏感：mbit≠mbps，推荐统一用kbit/mbit -
burst太小（如1kb）会导致小包频繁丢弃，SSH 都可能卡顿；太大（如100kb）会让限速形同虚设；经验上设为rate / 10左右较稳 -
latency不是延迟目标，而是允许排队等待的最大时长，设太小会激进丢包 - 删规则只需：
sudo tc qdisc del dev eth0 root，不用记 classid 或 handle
按 IP 或端口限速：必须用 htb + filter 组合
想只限某台客户端（如 192.168.1.100）的上传，或只压 HTTP 流量（--dport 80），就不能单靠 tbf，得用分层结构：htb 定义带宽树，再用 u32 或 fw 过滤器把流量导进去。
常见错误是漏掉“根类”或搞错 parent 关系。正确链路是：root qdisc → 根 class → 子 class → filter 匹配 → flowid 导入。
- 必须先建根类（
classid 1:1），哪怕它只是总带宽占位符（如100mbit） - 子类的
classid必须带冒号，如1:10，不能写成110或10 - 过滤器要指定
protocol ip和parent 1:0（不是1:或1:1） - 若用
iptables打标（MARK），记得用fw类型 filter，并确保mangle表规则已加载
wondershaper 是什么？它不是万能胶，而是快速兜底工具
wondershaper 就是个封装了 tc + netem 的 shell 脚本，优势是快、少出错、自动处理上下行分离。但它不支持按 IP/端口精细分流，也不暴露底层 class 控制权。
装完直接跑：sudo wondershaper eth0 2048 512（下行 2048 Kbps，上行 512 Kbps）
- 它对上传限速靠
tbf，下载限速靠“入队丢包”，所以下载压得越狠，丢包率越高，TCP 重传越多 - 清除规则用
sudo wondershaper clear eth0，别用tc qdisc del混用，否则残留规则会冲突 - 如果你需要动态开关某 IP 的限速，或者做 QoS 优先级调度，
wondershaper就不够用了，得切回原生tc
真正容易被忽略的是：所有基于 tc 的限速，都只在数据包离开协议栈、进入驱动前生效。一旦网卡硬件队列已满，或者中断处理不过来，限速就失准了——这不是配置问题，是内核网络栈与硬件协同的天然边界。
