封包在Linux内核中流向由协议栈硬逻辑决定：接收路径为网卡驱动→netif_receive_skb()→ip_rcv()→tcp_v4_rcv()/udp_rcv()→sock_queue_rcv()→应用层read()；发送路径反之。验证需依赖tracepoint（如bpftrace打点net:netif_receive_skb）、/proc/net/snmp与/proc/net/netstat计数器比对，而非ifconfig/ss等状态快照工具。
怎么看封包在内核里走了哪几层
封包在 Linux 内核里的流向不是靠“看日志”猜出来的，而是由网络协议栈的固定路径决定的。接收方向是：网卡驱动 → netif_receive_skb() → ip_rcv() → tcp_v4_rcv()/udp_rcv() → sock_queue_rcv() → 应用层 read()；发送方向反过来，从 write() 进入套接字层，经 tcp_transmit_skb() 或 udp_send_skb()，最终到 dev_queue_xmit() 交给驱动发出去。
这个路径不依赖用户配置，是内核编译时确定的硬逻辑。想验证某条路径是否走通，不能只看 /proc/net/，得结合函数入口点或 tracepoint —— 比如用 bpftrace 打点 net:netif_receive_skb 和 sock:inet_sock_set_state，就能确认封包是否进了 IP 层、有没有被 TCP 模块接手。
为什么 ifconfig / ss / netstat 看不到流向细节
ifconfig 只读 /sys/class/net/ 下设备统计，ss 和 netstat 查的是 /proc/net/{tcp,udp}，它们反映的是连接状态快照，不是封包实时路径。比如一个 SYN 包卡在防火墙规则里没进 IP 层，ss -tln 根本不会显示它，但 iptables -L -v 的计数器会涨。
- 封包被
iptables的INPUT链 DROP，它根本不会走到ip_rcv() - 封包进了
ip_rcv()但校验和失败，会被静默丢弃，不进后续流程 - UDP 包目的端口无监听进程，会触发 ICMP port unreachable，但不会出现在
/proc/net/udp的任何一行里
用 cat /proc/net/nf_conntrack 能看出流向吗
能，但只限于经过 conntrack 的连接（即启用了 NAT 或 stateful 防火墙的场景）。/proc/net/nf_conntrack 记录的是连接跟踪表项，每行含 src=、dst=、proto=6（TCP）、state=ESTABLISHED、timeout= 等字段，说明该连接已通过 nf_conntrack_invert_tuple() 建立跟踪，并被 nf_conntrack_find_get() 复用过。
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
但它不告诉你封包是否经过 br_netfilter（桥接转发）、是否触发了 xt_owner 模块、有没有被 tc ingress 的 clsact 过滤 —— 这些都发生在 conntrack 之前或之后，需用 tc filter show dev eth0 ingress 或 cat /proc/sys/net/bridge/bridge-nf-call-iptables 辅助判断。
最轻量的流向验证方式：查 /proc/net/snmp 和 /proc/net/netstat
/proc/net/snmp 按协议分组统计收发错误，比如 TcpInSegs 是进入 TCP 层的段数，TcpOutSegs 是发出的段数，TcpRetransSegs 是重传段数；而 /proc/net/netstat 更细，含 TcpExtDirectCopyFromBacklog（直接从 backlog 拷贝）、TcpExtListenOverflows（全连接队列溢出）等。
对比这两组数字，能快速定位瓶颈在哪一层：
- 如果
TcpInSegs远大于TcpEstabResets，说明大部分包至少进了 TCP 层 - 如果
TcpExtListenOverflows持续增长，问题在应用层 accept 不及时，不是协议栈本身 - 如果
UdpInDatagrams正常但UdpNoPorts也高，说明 UDP 包送达了，只是端口没人 listen
这些文件是内核实时更新的计数器，没有采样延迟，也不依赖外部工具，是判断封包“是否抵达某层”的第一手依据。
