Linux内核本身并没有那种“执行一条命令就能自动生成网络数据包流向图”的现成能力。实际排查时，通常需要把多种方法结合起来使用：一方面，可以配合 trace-cmd 和 kernelshark，基于 tracepoint 对数据包处理过程进行跟踪，并把时序路径可视化；另一方面，也可以借助 bpftrace 在关键内核函数上打点，验证数据包真实经过的处理链路。除此之外，forwarding 状态、路由策略以及 netfilter 配置也必须同时核查，只有把这些运行时条件都确认清楚，才能最终判断当前真正生效的网络转发路径。
Linux内核协议栈数据包流向没有现成“流向图”命令
Linux 内核并不提供一键生成网络数据包完整流向图的命令或工具。所谓“流向图”，本质上是指数据包从网卡进入系统后，依次经过 netif_receive_skb() → ip_rcv() → ip_forward() 或 ip_local_deliver() → 各层协议处理（如 TCP/UDP）→ socket 接收队列的处理路径。需要注意的是，这条路径并不是固定不变的静态拓扑，而是会受到当前系统配置影响，例如 iptables、nftables、eBPF、路由表以及 socket 类型等因素，最终动态决定数据包在 Linux 内核协议栈中的实际流向。
用 trace-cmd + kernelshark 可视化关键 tracepoint
如果想尽可能接近“Linux 网络数据包流向图”的效果，最实用的方法就是跟踪内核网络子系统中的关键 tracepoint，再通过图形化工具还原完整时序路径。你需要：
- 确保内核启用
CONFIG_TRACING和CONFIG_NET_TRACING（大多数主流 Linux 发行版默认已经开启） - 安装
trace-cmd和kernelshark（Ubuntu/Debian：`sudo apt install trace-cmd kernelshark`） - 捕获典型网络流量（如 `ping` 或 `curl`），同时跟踪与网络路径相关的事件：
sudo trace-cmd record -e net:* -e skb:* -e napi:* -e irq:* -e tcp:* -e udp:* --filter 'comm == "ping"'
随后，用 kernelshark 打开生成的 trace.dat 文件，再按照 CPU 或 PID 的时间轴展开调用链。这样就能更直观地看到数据包是如何在 netif_receive_skb、ip_rcv、tcp_v4_do_rcv 等函数之间逐步流转的。与单纯阅读文字说明相比，这种方式更适合排查 Linux 内核协议栈中的数据包流向，也更接近用户理解中的“流向图”。
cat /proc/sys/net/ipv4/conf/*/forwarding 和 ip rule show 决定实际路径分支
很多人在分析 Linux 网络包路径时，会默认认为数据包一定会走到 ip_forward，但现实中是否发生转发、匹配哪条路由、是否被 netfilter 提前拦截，全部都由当前运行时状态决定。因此必须重点检查：
cat /proc/sys/net/ipv4/conf/all/forwarding和/proc/sys/net/ipv4/conf/eth0/forwarding—— 如果值为 0，那么即使系统中存在可用路由，也不会执行转发ip rule show和ip route show table local—— 这会决定数据包最终进入ip_local_deliver还是ip_forward分支iptables -t raw -L -v -n或nft list ruleset——PREROUTING与OUTPUT链中的NOTRACK或CT规则可能绕过连接跟踪，从而改变后续处理路径
如果忽略这些配置，只根据函数调用顺序来判断，很容易误判数据包在当前系统中的真实流向。
用 bpftrace 在关键函数打点验证路径
如果你的目标只是确认某一类数据包（例如目的端口为 80 的 TCP 报文）是否经过某个关键函数，那么使用 bpftrace 会更轻量也更高效：
bpftrace -e '
kprobe:ip_rcv { printf("→ ip_rcv\n"); }
kprobe:ip_forward { printf("→ ip_forward\n"); }
kprobe:ip_local_deliver { printf("→ ip_local_deliver\n"); }
kprobe:tcp_v4_rcv { printf("→ tcp_v4_rcv\n"); }
'执行后再触发对应流量，终端输出就是你实际观察到的函数经过路径。需要注意的是，kprobe 并不能保证 100% 触发，例如数据包可能被 eBPF 程序提前处理，或者被 fast path 直接跳过。不过在验证“某条路径是否会经过”这个问题上，它通常比单纯阅读源码更快，也更适合快速定位 Linux 网络数据包在内核协议栈中的处理流程。
真正复杂的地方，不是简单把路径画出来，而是要理解每一个节点是否被跳过、被重定向，或者被其他模块替换，例如 AF_XDP 直接绕过协议栈，或者 XDP 程序在更早阶段就直接丢包。因此在动手分析之前，最好先明确你要确认的是“理论上的协议栈路径”，还是“当前系统中实际生效的数据包处理路径”。
