tcpdump抓包文件默认保存在当前工作目录，执行tcpdump -i eth0 -w capture.pcap时生成capture.pcap于当前shell所在路径；未指定-w则仅输出到终端不落地；相对路径需确保目录存在，sudo执行时目标路径须有写权限。
Linux 本身不提供“网络封包位置”这种抽象概念——封包没有物理存储位置，它只在网卡驱动、内核协议栈、socket 缓冲区中瞬时流转。所谓“查看封包位置”，实际是指：在哪抓、在哪存、在哪读。
tcpdump 抓包文件存在哪？
你执行 tcpdump -i eth0 -w capture.pcap 时，capture.pcap 就生成在当前 shell 的工作目录下，不是系统固定路径。容易踩的坑是：
- 没加
-w参数，命令就直接打印到终端，封包没落地，关掉终端就丢光了 - 用了相对路径如
-w ./logs/dump.cap，但./logs目录不存在，tcpdump会静默失败（不报错，也不写文件） - 用
sudo tcpdump执行，但当前用户对目标路径无写权限，比如-w /var/log/dump.pcap，会提示Permission denied
怎么确认封包是否真被写进文件？
别只看命令有没有报错，要验证文件内容：
- 执行完
tcpdump -i eth0 -c 10 -w test.pcap后，立刻运行ls -lh test.pcap—— 如果大小是 0 字节，说明没抓到或写入失败 - 用
file test.pcap检查文件类型，正常应输出类似test.pcap: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 262144) - 用
tcpdump -r test.pcap -c 1读取头一个包，能解析出 IP 和端口才算真正有效
Wireshark 能不能直接读 Linux 内存里的封包？
不能。Wireshark 在 Linux 上默认依赖 libpcap，和 tcpdump 是同一套底层机制——都靠把网卡设为混杂模式并从内核 ring buffer 复制数据。它不访问内核内存空间，也不能“定位”某个封包在 RAM 的哪个地址。你看到的只是复制出来的一份副本。
如果你真想查封包在内核中的流转路径（比如卡在 netif_receive_skb 还是 ip_rcv），得用 perf、ebpf 或内核日志，而不是抓包工具。
为什么有时候明明有流量却抓不到包？
最常忽略的是网卡选错或流量不在该接口上：
-
ifconfig或ip link看到的eth0可能不是业务流量走的口，比如容器通信走docker0，K8s Pod 间通信走cni0或vethxxx - 云服务器常用
ens3、enp0s3这类命名，不是传统eth0；用tcpdump -D列出所有可用接口最稳妥 - 某些加密流量（如 TLS 1.3 的 early data）、AF_UNIX 本地 socket、或被 eBPF program 提前 drop 的包，根本不会到达
libpcap层
抓包不是“找位置”，是“选接口 + 设过滤 + 定落点”。漏掉任意一环，封包就从你视野里彻底消失，而不是藏在某个目录里等你发现。
