tcpdump 抓到的包不等于现场的全部：丢包发生在三个位置，排查顺序反了就永远查不到

抓到包，不等于抓全了。绝大多数人打开 tcpdump，屏幕上开始刷内容，就默认这件事已经成立了：数据有了，可以分析了。然后花一两个小时跟着一条流往下看，得出一串结论——某处重传偏多、某个响应回来得慢、某次连接断了又重连。等到命令退出，屏幕上还留着一行 packets dropped by kernel，那行字十有八九被当成噪音滑过去了，没人回头读它。

问题恰恰在于，那一行不是噪音，它是这份样本的可信度声明。它告诉你：在你看到的那批包之外，还有一批包在更早的环节里被扔掉了，你拿到的不是现场，是现场的一部分。

抓到包不等于抓全：一份残缺样本能推出多少错误结论

tcpdump 结束时会打印三个数：packets captured、packets received by filter、packets dropped by kernel。这三个数经常被人当成"抓了多少、收到多少、丢了多少"来读，其实三者的口径并不构成一个简单的加减关系——被过滤表达式排除掉的包根本不进入任何一项，接口层由驱动统计的丢弃在部分版本里还会单独作为一项出现。所以正确的读法不是拿它们去算丢包率，而是拿它们判断：这份 pcap 是不是完整地代表了那段时间里到达这个观测点的流量。

真正麻烦的地方在于，残缺样本不是随机抽样。丢包从来不是均匀洒在时间轴上的，它集中发生在流量最猛的那一刻——缓冲被填满，往往正是突发来袭的时候。而你打开抓包的目的，十有八九就是想看那一段突发。于是这份样本系统性地缺掉了你最关心的部分，而且缺得悄无声息。

这种有偏的缺失会推出一整串错误结论。缺失的那部分恰好包含大量重传、乱序和超时，于是你会觉得"重传其实不多"，把窗口和队列的问题轻轻放过；缺失的那段恰好是连接建立失败最密集的一段，于是你数出来的失败次数偏少，把偶发问题判成稳定问题；缺失的那段恰好是响应最慢的一段，于是你算出来的时延分布右尾被削平，看起来一切正常。说白了，残缺样本最危险的地方不是"少了一点"，而是它偏向于证明"没问题"。

还有一种更隐蔽的误判：把 pcap 里没出现的东西，当成网络上没发生。这个推理只在"抓全了"的前提下才成立。有人在 Wireshark 里搜某个目标地址搜不到，就下结论说请求没发出去——实际上请求发了，只是那一刻的包在缓冲里被挤掉了。这类结论一旦被写进故障报告，后面所有的排查方向都会被带偏。

所以取证之前必须先回答一个前置问题：这份样本全不全。这个问题不回答，后面所有分析都是在残缺材料上做推理，做得越细致，错得越自信。

先把丢包的三个位置摆出来：网卡层、内核层、用户态层

一个包从网线到你的 pcap 文件，要走过一条固定的链条：网线上的电信号进网卡，网卡交给驱动，驱动把包递到内核的抓包点，抓包点上的过滤器决定要不要，要的话放进一块缓冲，缓冲再被 tcpdump 这个用户态进程取走，最后写进文件。这条链上每一道箭头都是一个丢包位置。

按位置合并，一共三层。最上游是网卡与驱动这一层，包还没进内核的抓包机制就可能已经没了；中间是内核的 BPF 过滤与缓冲这一层，包到了抓包点但缓冲放不下；最下游是 tcpdump 自己这一层，包已经交到进程手里，但因为写盘慢、解析慢、名字解析卡住而来不及处理。

这三层的关系是串联的，不是并联的：下游能看到的量永远小于等于上游交给它的量。上游丢掉的，下游无论怎么调参数都补不回来；而你在下游看到的所有数字，都已经被上游削过一轮。这个关系决定了后面所有的排查顺序。

把三层各自的观测手段、常见诱因和处置动作并排摆出来，现场照着这张表逐层走一遍，就不会出现"调了半天参数、不知道自己在调哪一层"的情况：

第一层：网卡与驱动的丢包，怎么从接口统计上看到

这一层离网线最近，也最容易被忽略，因为 tcpdump 的输出里完全不会提到它。要看它，得走接口统计这条路。

三条现成的路子。ip -s link 会给出每个接口的收发统计，RX 一侧有若干列，其中 dropped、fifo、overruns 这几列和"包没进来"直接相关；cat /proc/net/dev 提供的是同一组计数的另一种读法，机器没有 iproute2 的时候可以用；ethtool -S 给出的是驱动自己维护的私有计数，不同网卡、不同驱动给出的字段名完全不一样，常见的是 no buffer、missed、fifo 这类名字，用之前先把字段全列出来对一遍，别凭字段名想当然。

读这些计数有一个必须养成的动作：抓之前记一次，抓之后再记一次，用差值说话。接口统计是开机或驱动加载以来累计的，直接看绝对值毫无意义——一个很大的数字可能来自上个月那次故障。只有差值才能告诉你"这一次抓取期间新产生了多少丢弃"。

这一层还有个容易被跳过的前置确认：你抓的接口是不是真的能看到目标流量。tcpdump 在选定的接口上会开启混杂模式，但在虚拟化环境里，同一宿主机上其他实例的流量未必能收到，取决于虚拟交换那一侧的策略；用 -i any 抓所有接口时，操作系统的行为也和抓单个物理口不一样，而且混杂模式不一定被打开。接口选错的话，后面三层调得再精细也没有意义——你抓的是另一条链路。

另外要分清接口统计里各列的含义，别把所有列都当丢包。校验错、帧长异常这类列指向的是另外的问题，把它们和"缓冲满"混在一起读，会得出南辕北辙的结论。这一篇只关心"包到了网卡但没能交上去"这一类，其余的不展开。

第二层：内核 BPF 过滤和缓冲，过滤表达式写在这里才有用

包进入内核之后，会经过一个抓包点。在 Linux 上，tcpdump 写的过滤表达式会被编译成 BPF 程序，挂在这个抓包点上执行。这一步是整条链上唯一能真正减轻负担的环节——不匹配的包在这里被扔掉，根本不会进入缓冲，也就不会给后面两层制造压力。

这一层的丢包，指的是包已经到了抓包点、也通过了过滤，但缓冲放不下。观测它有两个办法，一个在结束后，一个在过程中。结束后看 tcpdump 退出行里那句 dropped by kernel；过程中则可以读 /proc/net/packet，这个文件里每一行对应一个抓包套接字，行内带着收到数和丢弃数（字段名随内核版本略有差异），抓取时反复读几次，就能看到丢弃数是不是在实时增长，而不是等结束了才知道。

这一层最常见的浪费不是缓冲太小，而是过滤表达式没生效。tcpdump 的命令行解析有一个坑：过滤表达式必须放在所有选项的最后。写成 tcpdump -i eth0 host 10.0.0.1 -w x.pcap 这种把表达式夹在选项中间的形式，表达式不会被当成过滤条件，轻则报错退出，重则被当成别的位置参数吞掉，于是你以为自己在抓一个地址，实际上抓的是整个接口的全部流量。检查的办法很朴素：抓几秒就停，看看命中数量是不是符合预期，再决定要不要放长。

缓冲相关选项是存在的，但它的默认值在不同版本、不同平台上并不相同，且受内核参数约束，这里不写具体数值——需要调整时用 man tcpdump 和 man pcap 确认当前环境的实际取值，再结合上面那个实时计数去验证调整有没有效果。关键提醒：缓冲只能缓解这一层，它对网卡那一层的丢弃没有任何作用。

第三层：tcpdump 自己——写盘速度、解析开销、名字解析

包被 tcpdump 取到用户态之后，剩下的活儿由它自己完成：解析各层协议、按需格式化、写进文件或打印到终端。这一段同样会丢包，而且这一层的丢包在退出行里没有专门的一行来提示，只能靠间接迹象判断。

写盘速度是最直白的一项。如果 pcap 落在的这块盘本身正在被业务日志或数据库重写，写入队列一堵，取包的节奏就跟着慢下来，缓冲那边继续被填，压力立刻传导回第二层。所以输出目录要挑，不要图省事丢在当前目录——很多机器上当前目录正好是业务最忙的那块盘。

解析开销是第二项。把输出直接打到终端，每个包都要走一遍格式化、再被终端滚动渲染，这个开销比写文件高得多。这也是为什么现场一律应该 -w 写文件，事后用 -r 离线分析：写文件保留的是原始字节，代价最小，而且离线重放不会再产生任何新的丢包，你反复看十遍都是同一份样本。

名字解析是第三项，也是单独拎出来讲的一项，见后文。这里先给一句结论：第三层的所有开销都可以通过"少做点事"来压低，而网卡这一层的丢弃没有任何 tcpdump 参数能影响到。这个不对称是后面那条排查顺序的直接依据。

为什么排查顺序必须从上往下，不能从下往上

因为上游丢了，下游补不回来。这是串联结构决定的，不是经验之谈。

举个最常见的错误动作。看到 dropped by kernel 不为零，头一个反应是"缓冲不够"，于是去加大缓冲，或者干脆上 -s0 把包抓全。加大缓冲确实可能让这一次的 kernel drop 数字变小——但它对网卡那一层的丢弃毫无作用，包在驱动里就没了，缓冲再大也等不到它。更糟的是，抓得更全之后单个包更大、总量更多，写盘压力上升，丢包的位置从第二层转移到了第三层。你换了个丢包位置，没有换掉问题，而且因为退出行上的那个数字变好看了，你还会以为自己解决了。

从下往上排查还有一层隐蔽危害：它破坏你的对照组。参数改了之后，新旧两次抓取的观测条件不一样，你没法判断数字的变化来自"问题缓解"还是"观测方式变了"。从上往下走则相反，每一步的观测都建立在上一步的结论之上，改参数之前你已经知道丢在哪个位置，改完之后也有对应的计数可以去验证。

推荐的顺序是这样一条链：抓取前后各记一次接口统计，用差值确认网卡层有没有新增丢弃；抓取过程中反复读 /proc/net/packet，看内核层的丢弃计数是否在实时增长；命令退出后读那行 dropped by kernel，并比对 captured 与 received by filter 的差；确认这三层分别是什么状态之后，最后才去动 snaplen、缓冲、轮转这类参数。参数是最下游的手段，只有在你确定瓶颈就在那一层时才该动。

-s / snaplen：截断会让包在 pcap 里不完整，但不截断会放大后面两层的压力

snaplen 决定每个包最多保留多少字节。tcpdump 的默认值在不同版本和不同平台上并不相同，早期版本给得相当保守，后来的版本大幅提高，具体取什么值请用 man tcpdump 在当前机器上确认，不要沿用从别处看来的数字。

截断的后果是 pcap 里的包不完整：超过截断长度的部分被直接砍掉，载荷看不全，上层协议在解析时会显示被截断。如果你抓包是为了看请求内容、看响应体、看某个字段，截断会让你白抓一趟——文件里明明有这条流，就是看不到里面写了什么。

不截断（-s0 之类的写法）也不是免费的。每个包都按完整长度写入，第二层的缓冲占用被放大，第三层单位时间要写入的字节数被放大，两者一起把后面两层的压力推上去。而且注意：snaplen 是最下游的参数，它对网卡那一层的丢弃没有任何影响。用 -s0 去"解决"丢包，是最典型的顺序搞反。

怎么取舍看目的。只想看连接建立的过程、看时序、看头部字段，保持较小的截断值就够了，甚至更有利——体积小，抓得久，后两层都轻松。要看载荷内容，就必须不截断，但必须同时做两件事来抵偿：把过滤表达式收紧到只留必要的流，把抓取时长和体积设上界。用"范围换深度"，而不是"全都要"。

-n 关掉名字解析：它不是为了好看，是为了不改变时序

-n 通常被解释成"输出更清爽"，这个理由太轻了。真正的原因是：名字解析会制造丢包，还会污染时序。

解析是阻塞的。抓包主循环在解析一个地址的反向记录时，如果迟迟收不到应答，就会被拖在那里。这段时间里包还在不断到达，缓冲还在被填——你以为自己在"看清楚"，实际上这批包正在因为看清楚而丢失。现场网络本身解析就不通畅的时候，这个拖累尤其明显，因为每一次解析都可能要等一个完整的超时。

时序被污染这件事更隐蔽，也更致命。时间戳是内核在收包时打的，本身不会被改写；但包被处理和写出的节奏被解析拖住了，于是你在 pcap 里看到的包间隔、看到的处理顺序，都不再是现场的真实节奏。排障时很多人要靠"这个包和上一个包之间隔了多久"来判断问题出在哪一段，一旦这个间隔里混进了解析等待，判断就失去了基础。你在分析一份被自己观测行为扰动过的样本。

还有一个副作用：反向解析自己会发出 DNS 查询，这些查询也是包，会被抓进你自己的 pcap 里，混在业务流量中间，给事后分析平添噪声。加了 -n 之后这些查询自然消失。

需要名字对应关系的时候怎么办？离线补齐。用 -r 读文件时再开解析，或者自己维护一份地址与业务的映射表，把解析这件事从"现场同步做"改成"事后异步做"。现场只负责原样记录，这是抓包工具该干的活。

过滤表达式应该尽量前置，让内核先扔掉不要的包

前面说过，过滤表达式会在内核里以 BPF 程序的形式执行。这意味着它是整条链上性价比最高的动作：不要的包在进缓冲之前就被扔掉，第二层的缓冲占用下来了，第三层的写盘量下来了，pcap 的体积也下来了，一次动作同时减轻两层。

写法上有三条要守。表达式放在所有选项之后，这是命令行解析的硬要求，位置错了等于没写。用引号把整段表达式包起来，避免括号、感叹号这类字符被 shell 提前吃掉——这类错误不会报出"语法错"，只会静默地给你一个不一样的过滤条件。抓之前先用几秒试抓验证命中数量，符合预期再放长，别一次抓半小时回来发现筛错了。

这里要纠正一个常见做法：先全量抓下来，事后用 grep 或其他工具筛。这个做法的问题在于，全量抓取的代价已经在第二层和第三层实打实地付过了——缓冲被填满过、包被丢过、盘被写过。筛是在已经付出了代价之后才做的，它不能追回那些因为全量抓取而丢掉的包。过滤必须在最上游发生，事后筛是替代品，不是等价品。

表达式本身可以按五元组、协议、端口组合，用 and、or、not 与括号组织优先级，这部分属于 libpcap 的过滤语法，细节以 man pcap 为准。要点只有一句：把它写窄。写窄之后如果抓不到东西，随时可以放宽再抓一次；反过来，太宽的表达式造成的损失无法撤销。

-C 与 -W：用轮转文件守住磁盘，同时保住"最近一段时间"

-C 按文件大小切分，单位是兆字节，达到阈值就切到下一个文件；-W 限制保留的文件个数。两者一起用的时候行为是：文件数达到上限后复用最早的那个，把它覆盖掉。这个组合的实际效果不是"保存所有历史"，而是"维持一个固定大小的滚动窗口"——磁盘占用有明确上界，同时手上始终留着最近一段。

这个性质对排障非常合适。多数偶发问题的报告都是"刚才又出现了一次"，你要的不是从昨天到现在的全部，而是出问题前后那几分钟。滚动窗口正好给的是这个：出问题之后停掉抓取，窗口里就是刚才那一段。

与之配套的是 -G，按秒轮转，配合带时间格式的文件名使用，适合"每小时一份"这类归档型抓法。两种轮转的选择标准很简单：要"最近多少量"用 -C 加 -W，要"按时间归档"用 -G。

用轮转有两点要提前想清楚。其一，被覆盖的部分是真的没了，所以动手之前先判断你要的是"最近"还是"问题发生的那一刻"——如果问题已经过去很久，滚动窗口早就把它冲掉了。其二，轮转切换的瞬间有额外开销，文件切得太碎会让切换过于频繁，太大则窗口里的时间跨度不够。具体的选项组合与覆盖顺序细节以 man tcpdump 为准，不同版本的行为描述存在差异。

偶发问题不能靠人盯着：环形缓冲加触发条件的思路

偶发问题的特点是不知道什么时候来，人不可能一直守着终端。可行的做法是把它变成一个自动装置：一个滚动窗口长期跑着，一个触发条件负责在问题出现时把它停下来。

滚动窗口就是上面那个 -C 加 -W 的组合，体积小一些、文件数多一些，构成一个覆盖最近若干量的缓冲。它一直在写，但占用恒定，不会把盘吃光。触发条件可以有多种来源：接口错误计数超过阈值、应用日志里出现某个关键字、某个探测脚本连续失败若干次。触发之后不做分析，只做一件事——把抓包停掉，并把文件挪走或复制走。

挪走这一步很关键。窗口还在继续轮转的话，你辛辛苦苦抓到的那一段可能几分钟后就被覆盖了。停掉之后立刻转移，是这套流程里最容易漏掉、也最容易前功尽弃的一步。

还有一件必须记录的事：开始和结束的时间。一份 pcap 如果不知道它覆盖的是哪一段时间，就很难和业务侧的日志、监控曲线对齐，事后复盘时你会发现自己在猜。把时间戳随文件一起存下来，成本几乎为零。

最后一条纪律：无人值守的长时间抓取必须有体积上界。没有上界的抓包，最坏的结果不是抓不到，而是把盘写满——盘满会波及同一块盘上的业务日志和数据库，把一个观测动作变成一次事故。体积上界是这套流程的安全带，不是可选项。

pcap 体积怎么估：平均包长乘包数，先算再抓

抓之前先算一下会写多大，这一步花不了半分钟，能省掉后面很多麻烦。算法就是一句话：体积约等于平均包长乘包数，再加每个包的记录头开销。记录头的字节数是 pcap 格式定死的，单包开销不大，但包数一多就不能忽略，具体字节数以 pcap 格式文档为准。

平均包长怎么拿。最可靠的办法是从接口统计里算：抓前后各取一次字节数和包数，两个差值相除，就是这段时间这条链路上的实际平均包长。没有条件取值的时候，按业务特征粗判——小包为主的交互型业务和大包为主的分发型业务，平均包长能差出一个数量级，判错方向会让估算偏得很远。

包数怎么拿。同样可以从接口统计里取速率，乘以计划抓取的时长。如果有过滤表达式，还要再估一个命中比例——这一步只能粗估，所以估完之后要乘一个余量系数，别拿估算值当上限用。

有截断的时候要注意：写入长度按截断后的长度算，但别指望截断能把体积压到很小——本来就以小包为主的流量，绝大多数包根本没到截断值，截不截都一样。反过来，大包为主的流量，截断对体积的影响非常明显，这正是"看头部就够"的场景应该保留截断的理由。

算出结果之后做两件事。拿它去和 -C、-W 的参数对齐，决定单个文件多大、留几个；再拿它去和目标盘的剩余空间比一下，确认装得下。这两件事做完再敲回车，就是"先算再抓"。

生产环境抓包的三条自律：限时长、限体积、限影响面

在生产机上抓包，本质上是往一台正在跑业务的机器上加负载。抓包会占用 CPU，会占用磁盘 IO，占用多少取决于流量大小和你的参数写法。这不意味着不能抓，而是意味着要带着约束去抓。

限时长。给命令套一个硬上限，用 timeout 之类的手段让它到点自动结束。别让一次抓包无限跑下去——跑着跑着被别的事打断，回头发现已经抓了几个小时、盘快满了，这种事在现场发生过无数次。

限体积。用 -C 加 -W 或者 -G 做轮转，保证写到盘上的总量有明确上界。输出目录要单独挑，避开业务日志和数据库所在的盘，因为 pcap 的写入模式是大块连续写，和随机写型的业务放在一起最容易互相拖累。

限影响面。接口选准，不要无脑抓所有接口；过滤表达式收紧；名字解析关掉；一律写文件而不是直接打印；抓之前预估会吃多少 CPU 和 IO，心里有个数。对承载核心业务的机器，如果同一个问题可以在影响更小的观测点上看清，就别在核心机上抓。

长时间抓包会持续占用本地盘，这一点在选排障用的机器时就要考虑进去：本地盘容量和写入能力要留余量，否则盘一旦吃紧，抓包这件事本身就会和业务抢资源。一万网络深耕 IDC 19 年（成立于 2007 年），其机器规格里本地盘是选排障机时值得单独看的一项，具体容量与写入表现以官网实时展示为准，需下单前向官方确认。

再补一句关于证据保全：抓到的文件要尽快转移或归档，并且记录下抓取的接口、参数、起止时间和当时的业务现象。一份没有上下文的 pcap，过两天连抓它的人自己都想不起来当时想看什么。

容器和网络命名空间里抓包，进不去就看不到

容器有自己的网络命名空间。在宿主机上直接跑 tcpdump，你看到的是宿主这一侧的视角——可能是某条 veth 的一端，可能是桥接设备，但不是容器内进程看到的那个网络栈。命名空间是一道墙，站在墙外抓不到墙内的视角。

进墙里的办法是切换命名空间再执行。用 nsenter 指定目标进程的网络命名空间，再在里面跑抓包命令；如果目标网络命名空间已经被 ip netns 管理起来，用 ip netns exec 更直接。两者本质相同：把抓包进程放进目标命名空间，让它看到那一套接口和协议栈。

权限是另一个现实问题。抓包需要相应的 capability，而容器默认往往不带。这一条决定的是"能不能抓"，不是"抓不抓得到"——命令能跑但报权限错误时，别去改抓包参数，那是权限的事。在有编排平台的场景里，通常还需要有在宿主机上执行操作的权限，这一层属于平台策略，不在工具能力范围内。

还有两个容易踩的坑。容器里的 Pod 会漂移，抓之前先确认目标还在原地，否则抓了半天抓的是空房间；两边视角看到的封装可能不一样，宿主物理口上可能有 VLAN 标签或隧道封装，容器内的 veth 上则不同，对比两份抓包结果时要把这一层差异算进去，不然会对不上。至于命名空间里没有 tcpdump 的情况，用宿主机上已有的命令配合 nsenter 是最常见的做法，不必为了抓包往容器镜像里塞工具。

加密流量能抓到什么、抓不到什么

这一点必须在动手之前就想清楚，否则会抓了半天发现看不了自己想看的东西。

以最常见的 TLS 为例。握手阶段是可见的：客户端发出的 ClientHello 里带着支持的版本、套件列表，多数情况下还带着服务器名指示（SNI），服务端回的 ServerHello 里能看到最终协商的结果。证书在较早的版本里可以看到，在较新的版本里证书本身也被加密传输了。此外，记录层的长度、方向、时序都看得到。看不到的是内容：请求路径、请求头、请求体、响应内容、Cookie、鉴权凭证，全在加密记录里，抓包工具拿不到。部署了加密服务器名指示（ECH）的场景里，连服务器名也可能看不到。

基于 UDP 的新一代加密协议，可见的部分还要更少，通常只剩下五元组、包长和时序。这部分不展开协议细节，只给结论：越新的加密协议，抓包能看到的东西越接近"形态"而不是"内容"。

要看内容不是做不到，但那是另一套流程：需要让通信的一端导出会话密钥，再用支持导入密钥的离线工具去解密。这属于事后分析手段，不是抓包工具自身的能力，而且要求你能控制通信的一端并愿意导出密钥，在生产环境里往往不可行。

所以要把抓包能回答的问题摆正。它能回答：有没有包、什么时候、多大、往哪个方向、谁和谁在通信、连接是怎么建立和断开的。它不能回答：里面说了什么。把"看到流量形态"当成"看到内容"，是加密流量排查里最常见的越界。想清楚你要的是哪一类答案，再决定这次抓包值不值得做。

生产环境抓包，现场最常纠结的七个问题

退出时那行 dropped by kernel 出现，是不是这次抓包就废了？不废，但要降级使用。这个数字非零只说明有包在内核层被丢了，不等于整份样本不可信。正确的处理是判断丢在哪一层：抓前后各记一次接口统计看差值，抓过程中读 /proc/net/packet 看丢弃是否在实时增长。如果丢包集中在某个突发时段，那么涉及该时段的结论就不能下；如果丢得很零散、且你要看的那条流完整，样本仍然可用。真正不能用这份样本的情况是：你恰恰要靠"哪些包没出现"来下结论——这种负向推理必须建立在抓全了的前提上。

该不该直接上 -s0 抓全包？看你要看什么。看头部、时序、连接建立过程，不需要 -s0，保留截断反而让后面两层轻松、抓得更久。要看载荷内容，必须不截断，但同时要把过滤表达式收紧、把时长和体积设上界来抵偿。要特别提醒：-s0 是最下游的参数，它对网卡那一层的丢弃毫无作用，用 -s0 去"解决"丢包属于典型的顺序搞反，只会把丢包位置从内核层挪到写盘层。

抓多久合适？没有通用答案，只有判断依据。偶发问题抓覆盖窗口：用 -C 加 -W 跑一个滚动窗口，问题出现后停掉并立刻转移文件，这种情况下不在"多久"，在"是否覆盖到问题发生的那一刻"。有明确复现时间的问题抓稍长于一个复现周期。稳态问题抓短就够，几分钟往往足以看清连接建立和响应节奏。无论哪种，都要给命令套时长上限——无限跑的抓包最后一定变成盘的问题。

pcap 太大，能不能只留最近几个文件？能，这正是 -C 加 -W 的设计目的：按大小切分，保留固定个数，超出后复用最老的文件。结果是磁盘占用有上界，手上始终留着最近一段。要注意两点：被覆盖的部分是真的没了，所以问题若已过去很久，滚动窗口早把它冲掉了；文件切得太碎会让轮转切换过于频繁，太粗则窗口覆盖的时间跨度不够。另外，抓到关键文件后要立刻复制走，否则窗口继续跑下去照样会被覆盖。

抓包会不会影响业务？会，这是必须承认的前提。抓包占用 CPU，占用磁盘 IO，占用多少取决于流量大小和参数写法。降低影响有几个确定有效的动作：过滤表达式收紧，让内核先扔掉不要的包；加 -n 关掉名字解析；用 -w 写文件而不是直接往终端打印；输出目录避开业务日志和数据库所在的盘；接口选准，不要无脑抓所有接口。对承载核心业务的机器，先评估再动手，能换影响更小的观测点就换。

容器里的网络问题怎么抓？核心是进到那个网络命名空间。在宿主机上直接抓，看到的是宿主这一侧的视角（veth 的一端或桥接设备），不是容器内进程看到的那个栈。用 nsenter 指定目标进程的网络命名空间再执行抓包，或者用 ip netns exec 进入已纳管的命名空间。还要处理两件事：抓包需要相应的 capability，容器默认往往不带，报权限错误时不要去改抓包参数；Pod 会漂移，抓之前先确认目标还在原地。另外两边看到的封装可能不同，对比结果时要算上这层差异。

抓到了包，为什么还是定位不了？通常卡在三个地方。样本不全——退出行那行 dropped by kernel 说明有包被丢了，而你恰恰在靠"哪些包没出现"做推理，这种负向推理在残缺样本上不成立。观测点不对——站在墙外抓墙内的视角（容器命名空间），或者抓的接口压根不是问题链路，包抓得再全也不相关。问题本就不在包里——加密流量只能看到握手与形态，看不到内容；还有些现象根本不是网络层的表现。定位之前先确认这三件事：样本全不全、抓的是不是那条链路、你想看的东西在包里到底有没有。

本文关于 tcpdump 与丢包观测的公开依据在哪里

本文关于 tcpdump 命令行选项（过滤表达式位置、-s 截断、-n 关闭名字解析、-C 与 -W 轮转、-G 按时间轮转、-w 写文件、-r 读文件）、退出时三个计数（packets captured、packets received by filter、packets dropped by kernel）的口径，以及 snaplen 与缓冲类选项默认值随版本差异的说明，均依据 tcpdump 与 libpcap 的官方手册页（man tcpdump、man pcap）及其官网 www.tcpdump.org 上的文档；选项的具体取值与行为细节不同版本存在差异，本文一律只给方法不给数值，实际使用时请以本机手册页为准。

文中关于接口统计的读法（ip -s link、/proc/net/dev、ethtool -S）依据 iproute2 与 ethtool 的手册页；关于抓包套接字计数的读法依据 Linux 内核文档中 packet 套接字与 /proc/net/packet 的相关说明，字段名随内核版本略有差异，以实际系统为准。pcap 文件每包记录头的开销依据 pcap 文件格式公开说明，本文只描述其存在，未引用具体字节数。

本文未引用任何真实环境的测量数据、未给出任何丢包率或吞吐量数值、未描述任何具体环境，所有结论均为方法层面的定性描述。文中提到的机器选型注意事项与官网 https://www.idc10000.net/ 上的产品信息相关，具体规格、容量与写入表现以官网实时展示为准，需下单前向官方确认。