为何针对TCP目标端口的TC u32过滤器第一条命令失效，第二条生效？

这是个很典型的TC u32过滤器匹配逻辑误区，我来给你拆解明白：

首先得搞懂TC的u32过滤器核心逻辑——它是基于数据包的字节偏移量+掩码来做匹配的，不是像用iptables那样直接识别高层协议的语义字段，对匹配顺序和前置条件要求很严格。

先看第一条命令为啥不行 #

你写的第一条命令：

$ tc filter add dev enp1s0 protocol ip parent 1:0 u32 match tcp dst 0x1451 0xffff flowid 1:10

这里的tcp dst其实是个容易踩的坑——u32压根不知道你要匹配的TCP目标端口在数据包的哪个位置！
IP头部的长度是可变的（可能包含可选扩展字段），TCP头部的起始位置不是固定偏移量。而且你没先告诉u32“这是一个TCP数据包”，它根本不知道从哪里开始找TCP的端口字段，相当于在数据包的随机位置找0x1451这个值，自然匹配不到目标流量。

再看第二条命令为啥能正常工作 #

第二条命令：

$ tc filter add dev enp1s0 protocol ip parent 1:0 u32 match ip protocol 6 ff match ip dport 0x1451 0xffff flowid 1:10

这里分两步，每一步都踩对了u32的匹配规则：

1. match ip protocol 6 ff：先匹配IP协议字段为6（也就是TCP协议），这一步不仅筛选出了TCP数据包，更关键的是让u32“记住”了这个数据包的上层协议类型，自动关联IP头部结构信息，能计算出TCP头部的起始偏移量（IP头部实际长度之后的位置）。
2. match ip dport 0x1451 0xffff：这里的ip dport是u32提供的快捷匹配方式，它会利用上一步得到的TCP头部偏移，直接定位到TCP头部的目标端口字段（TCP头部第2-3字节），再用0xffff掩码精确匹配16位的端口值（0x1451就是十进制的5201），所以能精准抓到目标流量。

额外补充个底层写法帮你加深理解 #

其实你也可以不用ip dport这个快捷方式，手动指定偏移量实现，效果和第二条命令完全一致：

$ tc filter add dev enp1s0 protocol ip parent 1:0 u32 match ip protocol 6 ff match u16 at nexthdr+2 0x1451 0xffff flowid 1:10

这里的nexthdr就是u32匹配IP协议后得到的TCP头部起始偏移，+2就是TCP目标端口在头部里的位置，本质和第二条命令逻辑相同。

总结一下：u32过滤器必须先明确上层协议类型，才能正确定位高层协议的字段位置，第一条命令跳过了这个关键前置步骤，所以失效；第二条命令按规则先确认TCP协议，再匹配端口，自然就能正常工作啦。

备注：内容来源于stack exchange，提问作者kogepan