从微软自家工具切入抓包这件事很多人第一反应是“干嘛不直接用 Wireshark”。这个想法本身没错但如果你日常主要泡在 Windows 环境里排查问题Microsoft Network Monitor以下简称 Netmon这套老工具反而有它不可替代的顺手之处。特别是它的抓包筛选器Capture Filter和显示筛选器Display Filter思路非常清晰配合 DNS、IP、ICMP 这三类最常见流量的过滤能在几分钟内从一堆乱糟糟的报文里把目标找出来。这篇文章不打算铺开讲全功能的界面操作而是围绕“筛选器”这个核心结合我多年用 Netmon 排障的经验把 Capture Filter 和 Display Filter 的差异、语法、实战套路、常见坑一次讲透。适合系统管理员、网络运维以及需要自己抓包分析协议栈的开发人员参考。无论你是第一次接触抓包还是已经用过 Wireshark 想换个工具这篇文章都能给你一套能直接抄的过滤组合。1. 抓包前先搞清楚Capture Filter 和 Display Filter 到底差在哪1.1 两类筛选器的本质区别很多新手拿着抓包工具就开抓抓到一段流量后直接在界面上筛选以为“筛选”就是搜索框。但实际上Netmon 提供了两个不同层面的筛选器它们生效的时机完全不同搞混了会在排障时浪费大量时间。Capture Filter捕获筛选器在数据包进入抓包引擎的那一刻就开始生效。它决定哪些包被写入 .cap 文件或内存缓存里哪些包压根不会被记录。这个动作发生在报文到达网卡驱动层之后、协议解析之前。换句话说如果你的捕获筛选器写明“只抓 ICMP 报文”那么所有 TCP、UDP、ARP 报文根本不会进入 Netmon 的捕获缓冲区你后续在显示区域里也看不到它们。它的价值是“源头节流”直接控制采集范围。Display Filter显示筛选器则完全不同。它是在数据包已经被完整捕获、完成协议解析之后作用于已捕获数据集的“视图过滤”。它不会删除、修改或影响已经抓下来的数据只是把不符合条件的帧暂时隐藏。你可以随时切换条件、随时撤销、反复对比。抓下来的原始数据一直在显示过滤只是改变了你看它的角度。用一个生活化例子来记忆Capture Filter 是单位门口的保安进门的时候查证件不符合条件的连门都进不了Display Filter 是屋里的秘书只要你已经进了屋秘书可以按你的需要把不同的资料从抽屉里挑出来摆在你面前资料本身没有消失。这个区别直接决定了你在什么时候用哪一种。如果目标是“我只关心 DNS 流量其他都不要”用 Capture Filter 可以大幅降低磁盘写入和解析压力。但如果你担心漏掉某些“意外”报文希望事后还能从完整流量里重新分析那 Capture Filter 就要慎用宁可让文件大一点也要靠 Display Filter 兜底。1.2 为什么 Netmon 仍然值得用先交代一下背景Microsoft Network Monitor 其实已经停止官方更新最新可用版本是 3.4发布于 2010 年。按说这类停更工具早该被历史淘汰可它在某些场景里依然有很硬的竞争力。最核心的一点是它运行在 Windows 原生环境不依赖 WinPcap/Npcap 这类第三方驱动安装起来非常省事。很多公司内网安全策略比较严格不允许随便装驱动级工具Netmon 反而容易过审。其次它对微软自家协议做了深度解析比如 SMB、RPC、LDAP、Kerberos、DCOM这些协议 Wireshark 虽然也能解析但 Netmon 的帧头布局和字段命名更贴近微软的代码习惯做 Windows 域环境或 Exchange 环境排障时对照事件 ID 和协议字段几乎可以无缝衔接。再加上它的筛选器语法设计得相当直观Capture Filter 和 Display Filter 使用的字段名高度统一学会了其中一个另一个基本是零成本迁移。这也是我今天愿意花篇幅专门讲筛选器的原因真正用熟之后它比在 Wireshark 里拼 display filter 字符串更顺手。2. Capture Filter 实战从源头把流量“瘦身”2.1 Capture Filter 语法基础先看一个最基础的语法格式Protocol.Property Operator Value例如IPv4.Address 192.168.1.100这条规则表示“只捕获源地址或目的地址为 192.168.1.100 的 IPv4 报文”。注意Netmon 的IPv4.Address是一个便捷属性同时覆盖源地址和目的地址写起来比分别写IPv4.SourceAddress和IPv4.DestinationAddress要省事得多。运算符支持、!、、、、也支持AND、OR、NOT。多个条件组合时最好用括号明确优先级避免不同 Netmon 版本解析顺序不一致带来的意外结果。比如(IPv4.Address 192.168.1.100) AND (ICMP)这条捕获规则会把所有“涉及 192.168.1.100 的 ICMP 报文”抓下来其他的都放掉。这里有个很关键的点Capture Filter 里能用的字段以“协议帧属性”为主不是每个在显示区域里能看到的属性都能直接用在 Capture Filter 里。原因在于捕获过滤器工作在一个比较早的解析阶段深层字段还没来得及被完整解析。所以我的建议是捕获阶段尽量用“粗粒度”条件比如协议类型、IP 地址、端口号把流量范围缩小到你关心的边界真正细的筛选交给显示过滤器去做。2.2 用 Capture Filter 只抓 DNS / IP / ICMP围绕标题里的三类流量我整理了几个可以直接抄的捕获规则都是我实际用过的组合。需求捕获筛选器写法说明只抓 DNS 报文DNS任何 DNS 数据包包括查询和响应都进缓冲区抓指定主机相关流量IPv4.Address 10.0.0.5源或目的为 10.0.0.5 的所有 IPv4 报文抓 10.0.0.0/24 网段IPv4.Network 10.0.0.0/24使用网络地址加前缀长度注意不是掩码写法抓 ICMP 但排除目标主机(ICMP) AND NOT (IPv4.Address 172.16.0.1)用 AND 组合再取反抓指定端口 TCP 流量TCP.Port 443源端口或目的端口为 443 都算这里有一个非常容易踩的坑Netmon 的 Capture Filter 里IPv4.Network的写法是10.0.0.0/24不是255.255.255.0那种子网掩码。我见过好几个同事抓了半小时发现一条包都没抓到最后检查过滤器才发现是把掩码格式写进去了工具没报语法错误但匹配结果为空。所以写完过滤器后先抓两三条已知流量验证一下再放大规模这是最基本的习惯。另一个坑是TCP.Port在 Capture Filter 里同样会同时匹配源端口和目的端口。如果你只关心目的端口 443 的入向流量得写成TCP.DestinationPort 443不要以为TCP.Port 443只匹配了端口 443它实际上把源端口 443 的报文也一并抓进来了这在分析服务器出站连接时会产生“假阳性”。同理UDP.Port也是一样注意区分。2.3 实战场景抓一次 Ping 不通的排查我举个实际场景。某天同事反馈服务器 A 到服务器 B 的业务端口通但 ping 不通。常规思路是抓 ICMP 报文来看请求是否发出、是否收到回包、有没有返回“目标不可达”。在 Netmon 的捕获设置里我直接写(IPv4.Address 10.10.10.10) AND (ICMP)这个过滤器的含义只要源地址或目的地址是 10.10.10.10且协议是 ICMP就捕获。然后让同事重新发起 ping抓到几秒后停止查看帧列表重点看有没有 ICMP Echo Request类型 8和 Echo Reply类型 0。如果只有请求没有回应问题多半出在 B 侧或中间链路的回包路径如果连请求都没有那就要去 A 侧排查看是不是本地防火墙把 ICMP 拦了或者 ping 命令走了其他网络出口。这种场景如果不用 Capture Filter整个抓包文件里全是心跳包、广播包、协议握手包动辄几百兆单是找 ICMP 就够费劲。用了过滤之后文件只有几十 KB定位快得多。顺便说一个 Capture Filter 的限制它无法在“帧的某个二进制偏移处”做任意字节匹配灵活性不算高。因此遇到需要按特定字段内容过滤比如“只抓 DNS 响应中某个标志位为 1 的报文”Capture Filter 做不到必须交给 Display Filter。3. Display Filter 实战抓完再精准筛选3.1 Display Filter 语法和常用字段如果说 Capture Filter 是“粗筛”Display Filter 就是“精筛”。它作用在已捕获、已解析的数据集上语法比 Capture Filter 丰富得多几乎所有的协议属性都能作为过滤条件。基本的显示过滤器写法同样是协议.属性 运算符 值但运算符和值的类型更丰富支持字符串、数字、布尔、IP 地址等类型。常见的运算符有、!、、、CONTAINS、IN等。例如DNS.Name CONTAINS contoso.com表示过滤出 DNS 字段中的名称包含 contoso.com 的报文。字符串值一定要加英文双引号数字值和布尔值不要加引号这个细节最容易引起语法报错。下面整理一张我在实际排障中高频使用的字段对照表需求显示筛选器写法说明只看 DNS 查询DNS.Flags.Response 0查询报文Response 标志为 0只看 DNS 响应DNS.Flags.Response 1响应报文只看某域名的解析DNS.Name www.contoso.com精确匹配域名看指定 IP 的双向流量IPv4.Address 192.168.1.1源或目的匹配只看 10.0.0.1 发往 10.0.0.2IPv4.SourceAddress 10.0.0.1 AND IPv4.DestinationAddress 10.0.0.2单方向条件只看 ICMP Echo 请求ICMP.Type 8ping 请求只看 ICMP Echo 回应ICMP.Type 0ping 回应只看“目标不可达”ICMP.Type 3常见排障类型只看“超时”ICMP.Type 11traceroute 或分片超时这里有个细节值得注意同一个含义的字段在 Capture Filter 里叫IPv4.Address在 Display Filter 里依然叫IPv4.Address两者统一这大大降低了学习成本。但在某些其他抓包工具里捕获过滤器和显示过滤器语法完全不同需要记两套。Netmon 这种“统一字段名”的设计确实是它的一大亮点。3.2 针对 DNS、IP、ICMP 的显示过滤组合技巧实际排障中单纯一个过滤条件往往不够需要组合。比如要排查“客户端 192.168.1.50 访问 www.contoso.com 时为什么解析慢”我一般会这么拆第一步先确认这组流量有没有被抓下来IPv4.Address 192.168.1.50 AND DNS这一步能看到该客户端相关的所有 DNS 查询和响应。第二步进一步限定域名IPv4.Address 192.168.1.50 AND DNS AND DNS.Name CONTAINS contoso.com这样能看到该客户端发出的对 contoso.com 域的查询。如果查询很多但响应很慢就要看响应报文的响应时间或者查报文的“TCP 重传”情况。比如 DNS 查询请求重试次数多往往是上游解析器响应慢或丢包。第三步如果怀疑是链路层问题我会把 ICMP 加进来做交叉验证IPv4.Address 192.168.1.50 AND (DNS OR ICMP)如果同一时间段里 ICMP 也有大量请求超时或延迟那就不用盯着 DNS 协议本身了先处理链路质量。这种层层递进的显示过滤方式比一次性写一个很长很复杂的表达式更容易定位问题也方便逐步验证假设。我特别要提醒一点在 Display Filter 里写 IP 地址时注意别把IPv4.SourceAddress和IPv4.DestinationAddress的方向搞反。服务器返回的响应源地址是服务器 IP所以你在过滤“服务器发给客户端的响应”时条件应该是IPv4.SourceAddress 10.0.0.53而不是IPv4.DestinationAddress 10.0.0.53。方向一错筛选结果就是空的很多新手在这里卡壳。3.3 过滤器保存与复用Netmon 的显示过滤器支持保存可以把它理解成“收藏夹”。当你把一条过滤器在顶部的 Filter 输入栏里编辑好并且确认它能正确过滤出想要的结果就可以点击 Display Filter 窗口里的保存按钮给它起一个有辨识度的名字比如“客户端DNS请求-192168150”。我自己维护了一套过滤器命名规范推荐你也这样用前缀代表协议或场景如DNS-指定域名、ICMP-网络探测、SMB-会话。中间部分写关键参数比如 IP 或域名。后面留出位置放时间批次或备注方便追溯历史版本。这样时间一长积累下来一套非常适合自己工作环境的“排障工具箱”。下次遇到同类问题直接套用过滤器不用重新回忆语法。对于需要长期监控的场景比如 DNS 故障、Exchange 邮件卡顿这套复用方式能节省大量重复操作。4. 实战演练一次 DNS 解析异常的抓包排查全流程理论说了一堆不如来一次完整的案例。这个案例是我在实际工作中处理过的一个典型内网 DNS 解析超时问题我用它来演示 Capture Filter、Display Filter、IP/ICMP 过滤怎么串联使用。4.1 设置捕获条件背景某办公网内的客户端反馈访问部分站点经常等很久才打开偶尔直接超时。初步判断是 DNS 解析变慢。内网 DNS 服务器是 10.10.1.53客户端是 192.168.10.88。我在客户端上启动 Netmon设置 Capture Filter(IPv4.Address 192.168.10.88) AND (DNS OR ICMP)这里为什么要把 ICMP 一并抓进来因为我想顺带确认网络路径是不是通。如果 DNS 解析慢的同时 ICMP 丢包率很高那问题很可能不在 DNS 服务器软件层面而在链路本身。举个例子如果 ICMP 测试显示丢包高达 30%那 DNS 查询超时大概率是网络质量造成的而不是解析器响应慢。接下来让同事刷新页面并重新触发解析几分钟后停止捕获。由于过滤条件已经把范围收得比较小文件不大大概只有几千个帧处理起来非常轻快。4.2 四步定位根因打开 Display Filter先看整体概况。我用DNS把所有 DNS 报文列出来。通过“Frame Time”列我发现到 10.10.1.53 的查询从发起到得到响应普遍在 2 秒以上而到公网 DNS 的查询却很快。这说明客户端侧的 DNS 配置没问题而是内网 DNS 服务器本身响应有问题。接着把范围缩小到客户端发往内网 DNS 的查询IPv4.SourceAddress 192.168.10.88 AND IPv4.DestinationAddress 10.10.1.53 AND DNS.Flags.Response 0再看对应的响应IPv4.SourceAddress 10.10.1.53 AND IPv4.DestinationAddress 192.168.10.88 AND DNS.Flags.Response 1通过时间戳对比我确认客户端发出查询后大约 200 毫秒内就收到了响应并不是 2 秒。那我看错了吗于是我再检查 TCP 层的情况因为 DNS 查询通常走 UDP但我注意到配置里 local DNS 有个 fallback 逻辑会先尝试 UDP没收到响应再走 TCP。我搜了一下有没有 TCP 53 端口流量TCP.Port 53结果发现客户端向 10.10.1.53 发起了大量 TCP 53 连接三次握手能成功但查询发起后对方迟迟不返回数据。这说明 UDP 53 被某个策略丢弃回落到 TCP 后又因为服务端 TCP 处理异常而卡住。到这里问题根因已经比较清晰不是链路不通也不是客户端配置错误而是内网 DNS 服务器的 UDP 响应策略有问题。4.3 用系统日志联动验证拿到这个结论后我没有立刻下最终判断而是把抓包文件里 DNS 查询的时间和客户端系统日志中的 Network Profile 事件做了对照。Netmon 在 Windows 环境下有个天然优势就是可以结合系统日志里的事件 ID 来缩小范围。查日志发现客户端曾有多次“网络连接从公用网络切换为域网络”的记录时间点刚好和 DNS 异常时段重叠。这进一步侧面验证了是 DNS 服务器端点或防火墙策略在接收特定网段的 UDP 53 请求时产生了误伤。把抓包文件和时间段信息交给 DNS 管理员对方很快定位到防火墙策略问题调整后恢复。这个案例里如果一开始不用 Capture Filter抓下来的文件会有办公网大量广播和 SMB 流量干扰极大。而 DNS、IP、ICMP 三类过滤器分别负责了协议维度的缩小、地址维度的定向和网络连通性验证配合使用效率很高。5. 常见问题与排查技巧实录5.1 高频问题速查表下面这节总结我遇到过的高频问题用表格形式给出方便直接对照排查。现象可能原因排查/解决办法Capture Filter 设置了但抓到的文件还是很大过滤器语法写错被忽略或网卡处于混杂模式抓了大量无关包检查过滤器是否生效先跑一个小规模采样测试确认网卡绑定的是有流量的接口用IPv4.Network 10.0.0.0/24抓不到包子网格式写错比如写成了 255.255.255.0确认前缀长度写法用IPv4.Address 10.0.0.1单独测试Display Filter 报语法错误属性名写错、值类型不匹配、运算符大小写问题对照协议属性窗口里实际的属性名数字型值不要加引号字符串值要加引号过滤DNS.Name CONTAINS abc没有结果大小写不匹配或属性名写成了DNS.Name但实际字段是DNS.QueryName先不加过滤直接看帧列表在“Details”窗口里查看实际字段名再调整抓包文件里没有 DNS 报文但业务确实有解析过滤器写成了DNS.Flags.Response 1在 Capture Filter 里用Capture Filter 不支持这种深层属性只能在 Display Filter 里用显示过滤器使用后帧数量为 0属性名或值不对或方向搞反先不加过滤直接看帧列表确认字段实际值再逐步加条件5.2 几条只有实战才会知道的技巧再说几个纯经验层面的技巧这些在官方文档里基本找不到。第一Netmon 的“Capture Settings”对话框里启动捕获前一定看清楚选择的网络接口无线网卡和有线网卡经常混淆。很多“抓不到包”的反馈最后都是发现选错了接口。在命令行里用netsh interface show interface提前核对接口名称比在 GUI 里猜要靠谱得多。第二抓包时尽量保持流量纯净。如果你需要分析 DNS最好在客户端上只保留需要的网络应用关掉后台更新、流媒体等大流量应用。虽然 Capture Filter 能挡掉大部分无关流量但应用层并发请求多的时候时间线错乱对排查是致命的。比如你正在等一个慢速 DNS 响应结果后台正在下载补丁那个时间段里的网络事件会非常杂乱。第三在显示过滤中用IN运算可以一次过滤多个 IP。比如同时关注隐患排查中的几台机器IPv4.Address IN (192.168.1.10, 192.168.1.11, 192.168.1.12)这个写法比连写一大串 OR 清晰得多也不容易漏条件。第四抓包完成之后先用“Summary”视图的协议分布统计过一遍再决定细化过滤方向。这个习惯能避免被某一个局部现象带偏。比如你本来想查 DNS结果统计里显示有大量的 TCP 重传那多半链路层就有问题先修基础网络再谈 DNS。第五关于 ICMP 过滤除了 Type 8/0 之外ICMP.Type 3目标不可达和ICMP.Type 11超时在排障里出现频率也很高。尤其是中间网络设备启用了 PMTUD大包 ping 不通但小包能通的时候重点抓 Type 3 的“Fragmentation needed”子类型直接能找到 MTU 瓶颈。6. 再交代一句工具本身的边界最后还是把丑话说在前面。Microsoft Network Monitor 3.4 毕竟是十多年前的工具对 TLS 1.3、QUIC、HTTP/2 等新协议的支持基本是空白解析出来的 TLS 层信息非常有限。如果你要深入分析现代加密流量或者需要跨平台抓包Wireshark 依然是最优解。但 Netmon 在 Windows 内网环境的价值并没有因此消失尤其是微软协议族和事件关联分析的场景它依然有不可替代的生态优势。很多朋友纠结“到底学哪个”我的建议是以 Wireshark 为主力把 Netmon 当 Windows 环境下的备用利器。两边筛选器思路其实是相通的你今天在 Netmon 里练会的 Capture/Display 两段式过滤逻辑挪到 Wireshark 里同样管用。我自己的习惯是处理纯 Windows 或微软协议栈问题时优先开 Netmon其余场景默认 Wireshark两者并不冲突。最后分享一个小习惯执行完一次抓包排查后记得把用过的过滤器表达式、当时的网络拓扑、结论一并记录到一个文档里。时间久了这套笔记会比任何教程都更贴近你的实际环境下次遇到类似问题时几乎可以照着文档直接复现整个排查流程。