tcpdump滚动捕获必须用-c配合-w，单独-g会丢包；-c按大小轮转、-w限制文件数，确保i/o可控；-g与-c混用会导致轮转逻辑异常，二者应择一使用。
tcpdump 滚动捕获必须用 -C + -W 配合，单独 -G 会丢包
Linux 下想让 tcpdump 自动轮转文件、避免单文件过大或内存耗尽，-G 看起来最直观（按秒切），但实际运行中常发现中间几秒的流量完全丢失。这是因为 -G 触发轮转时，tcpdump 需要关闭旧文件、打开新文件，期间内核接收缓冲区若满，包就直接被丢弃——它不暂停抓包，也不排队。
真正可靠的做法是用 -C（按大小轮转）配合 -W（限制总文件数），让写入始终在内存和磁盘 I/O 可控范围内进行：
-
-C 100表示每个文件最多 100MB（注意：单位是 MB，不是 KB 或字节） -
-W 5表示最多保留 5 个循环文件（capture_00001.pcap→capture_00005.pcap，然后覆盖最早的） - 加上
-w capture_%Y-%m-%d_%H:%M:%S.pcap也能带时间戳，但仅作命名，不参与轮转逻辑——轮转动作只由-C和-W控制
Wireshark 打不开 tcpdump -C 轮转出的多个 pcap 文件？检查文件是否完整截断
tcpdump 用 -C 切文件时，会在达到大小阈值的**下一个 packet 写入前**立即切换文件。这意味着最后一个文件大概率不包含完整的 TCP 会话（比如 TLS 握手断在中间），但 Wireshark 本身能处理这种“不完整 pcap”——只要文件头没损坏。
真正打不开的常见原因是：tcpdump 进程被 kill -9 或系统崩溃导致当前文件没写完文件尾（pcap 的 magic number 或 section header 损坏）。这时 Wireshark 报错类似 File appears to have been cut short 或直接拒绝加载。
- 用
file capture_00003.pcap看输出是否含pcap capture file—— 不是则文件已损坏 - 用
tcpdump -r capture_00003.pcap -c 1快速验证能否读取第一条包；失败说明头部异常 - 生产环境建议加
-Z nobody降低权限，避免因权限问题导致写入中断
为什么 -G 和 -C 不能混用？参数冲突会静默失效
tcpdump 文档里没明说，但源码中 -G 和 -C 共享同一套轮转状态机。一旦同时指定，-C 的大小判断优先级高于 -G 的时间判断——也就是说，即使设了 -G 60（每分钟切），只要还没到 -C 设的大小，就不会切；而一旦先触发 -C，-G 的计时器就重置，不再按固定间隔执行。
- 现象：你期望每分钟一个文件，结果可能连续 3 分钟都写进同一个文件，直到它涨到 100MB
- 更糟的是：如果
-C值设得太小（如-C 1），会频繁 open/close 文件，I/O 毛刺明显，甚至拖慢抓包速率 - 结论：需要定时切用
-G，需要控体积用-C+-W，二者选一，别混
离线分析时，Wireshark 合并多个轮转 pcap 的正确方式
tcpdump 轮转出的 capture_00001.pcap、capture_00002.pcap… 是严格按时间顺序写的，但它们之间**没有跨文件的 TCP 重组上下文**。Wireshark 直接依次打开多个文件，不会自动把一个 HTTP 请求的 request 和 response 拼到一起（尤其当它们落在不同文件里）。
- 不要用 “File → Merge” —— 它只是拼接数据包列表，不重建流状态，对深度协议分析（如 TLS 解密、HTTP2 stream tracking）基本无效
- 推荐做法：用
mergecap -w merged.pcap capture_*.pcap合并为单个 pcap，再用 Wireshark 打开；mergecap会重排时间戳并修复部分跨文件边界问题 - 如果原始抓包启用了
-s 0（全包抓取），合并后可正常做 TCP 重组；若用了-s 68等截断长度，合并也没法恢复被丢掉的 payload
滚动捕获真正难的不是命令怎么写，而是得提前想清楚：你要的是精确时间边界，还是可控文件体积；要不要跨文件分析；磁盘空间和 I/O 能不能扛住频繁 write/fsync。这些决定了 -C、-W、-G 里哪个参数该设、设多大。
