tcpdump抓不到包主因是网卡选错或权限不足；需用ip link确认活跃网卡，sudo运行，容器场景应在宿主机抓docker0/cni0；wireshark打不开pcap需检查时间戳精度和snaplen；分析失败时按SYN/SYN-ACK/Client Hello序列判断DNS、路由、防火墙或TLS兼容性问题。
tcpdump 抓不到包？先确认网卡和权限
很多情况下不是 tcpdump 不工作，而是它根本没看到流量。最常见的是抓了错误的网卡，或者没用 sudo 权限——非 root 用户默认无法访问原始套接字。
- 用
ip link show或ifconfig看当前活跃网卡名（比如eth0、ens33、enp0s3），别直接写lo就以为是本机通信 -
tcpdump -i any看起来省事，但内核 3.10+ 默认禁用，会报错tcpdump: any: No such device exists；得加-Z root或改 sysctl（不推荐） - 容器或 kubernetes 场景下，宿主机上抓
docker0或cni0才能看到 Pod 间通信，进容器里抓往往只能看到 loopback 流量
Wireshark 打不开 tcpdump 的 .pcap？检查文件格式和截断长度
tcpdump 默认用 libpcap 格式，Wireshark 理论上能读，但实际常因两个参数出问题：时间戳精度和 snaplen。
- 老版本
tcpdump（-J 参数强制用纳秒：tcpdump -J -w trace.pcap - 如果只看到 TCP 头没有 payload，大概率是
-s截断太小（如-s 68只抓 IP+TCP 头），Wireshark 解析时误判为异常包；建议至少-s 1500（MTU 大小）或直接-s 0抓全帧 - 用
file trace.pcap确认格式是否为tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture Length 1500)，否则可能是 stdout 重定向出错或磁盘满导致写坏
抓 httpS 流量只能看到 TLS 握手？别指望解密，但可以定位连接阶段问题
https 加密层之下，TCP 连接行为完全可见。tcpdump 虽不能解密应用层内容，但能精准暴露握手失败、重传、RST、零窗等关键信号。
- 过滤特定域名请求：HTTPS 没有明文 Host，但 SNI 在 Client Hello 里（TLSv1.2+），可用
tcpdump -i eth0 -nn -A 'port 443 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x16030100'粗略匹配，不过更稳的是抓三次握手 + RST/ACK 模式 - 快速判断是 DNS、TCP 还是 TLS 层失败：
— 无 SYN → 查 DNS 或客户端路由
— 有 SYN 无 SYN-ACK → 服务端未响应（防火墙、进程未监听、端口错）
— 有 SYN-ACK 但后续全是重传 → 网络丢包或中间设备干扰
— Client Hello 后立刻 RST → 服务端 TLS 版本/密码套件不兼容 - 避免在高流量接口上
-w全量写盘，用-C 100 -W 5自动轮转 100MB 文件，防止磁盘打爆
用 tshark 替代 tcpdump 做轻量实时分析
当只需要看连接状态、HTTP 方法或 TLS 版本，又不想保存文件再开 Wireshark，tshark 是更直接的选择——它是 Wireshark 的命令行版，解析能力更强，且支持字段提取。
-
tshark -i eth0 -Y "http.request.method == "GET"" -T fields -e ip.src -e http.host -e http.request.uri可实时打印 GET 请求的来源、域名和路径 - 注意
-Y（显示过滤）和-f（捕获过滤）区别：前者在抓完后过滤，后者在内核态过滤，性能差一个数量级；高频场景务必用-f "port 443"先筛 - 输出含中文或特殊字符时加
-G column-formats查字段名，避免写错http.user_agent写成http_ua导致空输出 - 别在生产环境长期跑
tshark -i any -Y "tcp"，它比tcpdump更吃 CPU，尤其开启解析时
真正难的不是抓到包，是确定该在哪抓、以什么粒度抓、以及怎么把一屏乱码和几百兆文件对应到具体一次超时或重定向。网络栈每一层都可能静默吞掉包，而 tcpdump 只反映它看到的那一层——这个“看到”，本身就依赖你对网卡、命名空间、eBPF、甚至虚拟交换机转发逻辑的理解。