有一次线上 Windows Server 的 DNS 解析间歇性超时业务方催得急。那台服务器不方便装第三方驱动我直接用系统自带的 netsh trace 抓了二十分钟网络包生成一个 ETL 文件后用 Microsoft Network Monitor圈里习惯叫 Netmon直接打开两分钟就确认问题出在上游递归查询超时而不是本地 DNS 服务器。这件事我一直记到现在。很多人提到抓包就只想到 Wireshark觉得 Netmon 是“老掉牙的微软工具”可它在 ETL 解码、微软私有协议解析这两件事上到现在也没有靠谱的替代品。它内置的 Capture Filter 和 Display Filter 两套筛选器逻辑清晰尤其是 DNS、IP、ICMP 这类常见协议的过滤用好了能省掉大量排查时间。这篇文章就把 Netmon 的筛选器从原理到实战彻底讲一遍先搞清楚 Capture Filter 和 Display Filter 到底差在哪再分别给出 DNS、IP、ICMP 过滤的具体写法和避坑经验。无论你是 Windows 服务器运维、网络管理员还是刚开始学抓包的新手都能找到直接抄的写法。放心里面没有教科书式的废话全是实际干活摸出来的经验。1. 很多老工程师还在用 Netmon因为这三个理由1.1 打开 ETL 文件这个手艺Wireshark 真不行我说一个很常见的场景。生产环境 Windows Server 上出问题不能随便装抓包工具也不方便停网卡。这时候系统自带的 netsh trace 是零依赖的解决方案它通过 ETW 内核会话抓包不需要安装额外的 NDIS 驱动管理员权限下直接执行netsh trace start captureyes tracefileC:\temp\dnstrace.etl复制代码然后正常操作业务复现问题后执行netsh trace stop就会生成一个 ETL 文件。这个文件既包含网络数据包也包含大量 ETW 事件。Wireshark 直接打不开这类 ETL需要额外转换工具而 Netmon 3.4 可以原生打开自动把里面的帧数据解析成可读的协议树帧列表、帧详情、十六进制视图一应俱全。光凭这一点Netmon 在我电脑上就永远有一个位置。我装了它不一定是用来抓包更多时候是为了随时打开别人丢过来的 ETL。补充一个实操细节用 netsh trace 抓包时tracefile路径最好放在非系统盘。ETW 会话默认占用内存和磁盘缓存较大抓到一半把 C 盘塞满是常有的事。另外执行netsh trace stop之后要等几秒让它把缓存写入文件再干别的别急着关机或删文件否则这份抓包就白费了。1.2 微软私有协议解析比第三方工具更细致Netmon 内置了解析器Parser体系对微软自有的协议格外友好。我在排查域内机器加域失败、SMB 访问慢、WinRM 会话异常时Netmon 能把 Kerberos 的预认证错误、SMB2 的协商细节、RPC 的调用失败信息直接挂在帧详情里字段拆得很细。Wireshark 当然也能解这些协议但对某些微软专有扩展字段的支持有时不够全关键报错会被吞掉或显示成 raw data。并不是说 Wireshark 不行而是说在纯 Windows 环境做排障时Netmon 的解析粒度常常能让你少走弯路。特别是 Windows 事件日志里的网络报错和抓包里的协议报错能对上号时Netmon 的字段命名与系统组件风格一致对照起来更快。有一次排查一个 SMB 慢的问题Wireshark 里只看到一堆 DCE/RPC 请求Netmon 里却能直接看到具体的 RPC 调用名和返回状态一下子就知道是哪个服务在拖慢会话。1.3 选 Netmon 还是 Wireshark一张对比表我电脑上长期常驻 Netmon 3.4 和 Wireshark两者不是替代关系而是互补。下面这张表是我个人经验的总结方便你快速做选择。对比项Microsoft Network Monitor 3.4Wireshark直接打开 netsh 生成的 ETL支持原生解析不支持需要转换微软私有协议字段解析细致命名与系统组件一致通常够用个别扩展字段不全过滤器语法相对简单字段路径和 Wireshark 不同生态大contains 等算子更强抓包驱动自带 NdisCap 驱动WinPcap/Npcap 驱动社区资源少微软官方已停止更新极多遇问题好查资料跨平台仅 WindowsWindows/Linux/macOS适合场景Windows 域环境、ETL 分析、微软协议排障通用协议分析、学习、跨平台抓包实际工作里我的原则是Windows 环境的网络排障以 Netmon 为主、Wireshark 为辅。如果环境允许且问题不涉及微软私有协议用 Wireshark 效率也不差。关键是先把两个工具的过滤器概念都弄清楚别在一棵树上吊死。2. 两个筛选器看着差不多工作机制隔着一个抓包过程Netmon 刚上手的人最容易把 Capture Filter 和 Display Filter 当成同一个东西看到工具栏上两个漏斗图标就随手点一个。实际上一个管“抓什么”一个管“看什么”工作时机和能力边界完全不一样。2.1 一个在数据落盘前一个在落盘后Capture Filter 发生在抓包会话开始之前它决定哪些帧可以进入捕获缓冲区、最终写入文件。一旦条件启用不符合条件的帧在驱动层面就被丢弃了后面无论怎么调显示样式都找不回来。Display Filter 发生在文件打开以后它只是在界面层对已经抓到的帧做筛选把不符合条件的帧暂时隐藏起来。注意是“隐藏”不是“删除”。原始文件里的帧一条不少去掉 Display Filter 后立刻恢复原样。打个比方Capture Filter 是大楼入口的安检穿着不符合要求的装备根本进不了门Display Filter 是事后去档案室查记录按条件抽出一批档案其余档案还好好躺在架子上。这个区别决定了你抓包前就得想清楚要什么不能指望抓完再用 Display Filter 变出当时没抓的数据。比如你抓包时忘了限制 IP文件 5GB结果想用 Display Filter 只看某一个 IP文件体积不会变小打开和滚动的卡顿一句都不少。2.2 能力边界一个到端口为止一个能钻到协议字段Capture Filter 工作的层级很浅它能直接在条件里引用的主要是链路层、网络层和传输层的通用属性比如以太网类型、IP 地址、TCP/UDP 端口。它做不了“我只抓 DNS 响应”这种协议级过滤因为帧进来的时候还没被解析成 DNS 协议树上层字段不存在。想抓 DNSCapture Filter 层面只能退而求其次用 UDP 端口 53 来近似。Display Filter 就完全不一样了。它工作在完整解码之后可以引用任何解析出来的字段DNS 的域名、响应标志、ICMP 的类型码、某条 TCP 流的序列号都能拿来当过滤条件。这也是很多人误以为 Netmon 不能过滤 DNS 的原因——他们是在 Capture Filter 里翻了个底朝天也没找到 DNS 字段其实应该切到 Display Filter。2.3 语法长得像属性名却各说各话两套筛选器都用属性名 操作符 值这种结构也支持、||、!、括号。但属性名的命名体系不完全一样。以端口为例Capture Filter 里可以写IPv4.Port 53而 Display Filter 里更常见的是UDP.SourcePort 53 || UDP.DestinationPort 53。再比如地址Capture Filter 用IPv4.Address指代源或目的地址Display Filter 里同样的逻辑也靠IPv4.Address但要区分具体方向就得写IPv4.SourceAddress或IPv4.DestinationAddress。这导致一个很经典的翻车现场把 Capture Filter 的表达式直接粘到 Display Filter 里或者反过来结果不是没效果就是报语法错误。正确姿势是——在哪个工具窗口干活就用哪个体系里的属性名不确定的时候让界面帮你填。Netmon 的显示筛选器输入框有智能提示输入DNS.之后会自动列出可用的子字段这个功能比死记字段名可靠得多。2.4 所以什么时候必须用 Capture Filter既然 Display Filter 能力更强为什么还要用 Capture Filter三个原因性能、磁盘空间、数据可控性。流量大的环境里如果所有包都落盘文件体积和 IO 压力都吃不消。用 Display Filter 只是界面不显示文件该多大还是多大处理起来照样卡。我在抓跨天流量做分析时习惯先写好 Capture Filter宁可条件保守一点多抓一些也比全量抓取然后等文件膨胀强。另一方面某些生产环境对数据采集范围有要求Capture Filter 在入口就把无关流量裁掉也避免了抓下来一堆不相干的业务数据。说到底Capture Filter 的价值是“少抓”Display Filter 的价值是“精看”。两者的定位从一开始就不同。3. Capture Filter 实战在一开始就把流量缩小3.1 入口和基本语法新建一个捕获窗口后工具栏上有一个漏斗图标点击后弹出 Capture Filters 对话框。里面有一个文本框写表达式旁边有一个启用开关。空白表达式表示抓全部流量。基本语法就是属性 操作符 值支持等于、!不等于逻辑上支持并且、||或者、!非和括号。注意它不接受引号包裹的字符串值直接写地址或端口数字即可。这个语法门槛很低难点在于属性路径好在你输入的时候工具同样会给提示哪怕记不全也能试出来。3.2 按 IP 过滤的几种写法最常用的是IPv4.Address 192.168.10.5IPv4.Address同时匹配源地址或目的地址意思是“和这台主机有关的帧都留下”。这对大多数排查场景已经够用。假设你只关心某台主机主动发出的流量不希望收到别人发给它的可以写IPv4.SourceAddress 192.168.10.5反过来只关心发往它的IPv4.DestinationAddress 192.168.10.5如果只想抓一个网段Capture Filter 层面没有 CIDR 写法。我常用的方式是列一组地址用||拼起来或者退一步只抓网关和几台关键机器的交互。要抓任意两台主机之间的流量直接把两个地址做 OR 即可IPv4.Address 192.168.10.5 || IPv4.Address 192.168.10.8这样抓下来的文件帧列表里会包含两台主机之间的双向流量也包含它们各自和其他主机交互的流量。如果只想看“这两台主机之间的通信”Capture Filter 里比较难优雅表达我通常会抓全一点然后用 Display Filter 在分析阶段收紧。3.3 按端口过滤抓 DNS 本质是抓 53 端口在 Capture Filter 里没法直接写 DNS因为它到不了协议层。但 DNS 流量基本都跑在 UDP 53 和 TCP 53 上所以用端口过滤就能达到目的。Netmon 的 Capture Filter 里有一个便捷属性IPv4.Port同时匹配 TCP 或 UDP 的源端口和目的端口。只抓 DNSIPv4.Port 53这样抓下来的文件里可能包含 UDP 53 和 TCP 53 的流量用 Display Filter 打开后再用DNS、TCP细分。想更精确一点可以加上协议类型。IPv4 的协议号TCP 是 6UDP 是 17ICMP 是 1。只抓 UDP 的 DNSIPv4.Protocol 17 IPv4.Port 53如果你的环境里 DNS 也走 TCP区域传送、大响应场景那上面这个条件会把 TCP 53 漏掉这种情况就改成IPv4.Port 53不要加协议类型限制。3.4 组合条件括号优先级不要想当然组合多个条件时优先级和常见编程语言一样高于||。但有括号的地方绝不省。比如抓“A 主机的 53 端口或者 B 主机的所有流量”IPv4.Address 192.168.10.5 IPv4.Port 53 || IPv4.Address 192.168.10.8不写括号也能按预期执行因为优先级高。但人眼读起来容易误解而且文件存档后别人接手也不好懂。我习惯给分组加上括号(IPv4.Address 192.168.10.5 IPv4.Port 53) || IPv4.Address 192.168.10.8这样逻辑一目了然也避免哪天你改了其中一个条件后运算顺序悄悄变掉。3.5 Capture Filter 的三个坑第一个坑条件写反导致抓不到包。我在排除某个网段问题时把!写成了结果启动抓包后界面里没有任何帧还以为是网卡选错了浪费了快半小时。排查这类问题的方法很简单临时把过滤条件清空抓几秒看看有没有流量。如果清空后有流量、加上条件就没有那大概率是条件本身写反了或值不对。第二个坑启用状态残留。Capture Filters 对话框里如果之前启用过某个条件下次新建捕获窗口时它可能还是启用的。你换了网卡、换了环境去抓包结果流量进不来反复检查接口都没用最后发现是上一次的IPv4.Address 10.0.0.5还挂在那儿。所以开始抓包前养成习惯先看一眼 Capture Filters 对话框是开着还是关着。第三个坑过度自信。Capture Filter 过滤掉的帧是真的没了不是躲起来。你要是想分析“当时这个端口上有没有别的报文”但抓包时把端口写得太死那就只能重抓。我的建议是抓包阶段宁可多抓Display Filter 留到分析阶段再做减法。4. Display Filter 实战DNS 过滤的四种写法4.1 入口打开文件以后再筛选打开捕获文件或 ETL 之后帧列表工具栏上有一个显示筛选器输入框。输入表达式回车帧列表立刻按条件刷新。它不修改文件随时可以清空这是和 Capture Filter 最大的区别。排查问题时我通常先把文件打开然后用 Display Filter 从不同角度反复切整个过程不会破坏原始抓包文件怎么试都放心。4.2 只留 DNS一个单词就够了最简单也最有效的过滤就是直接输入协议名DNS这样帧列表里只剩包含 DNS 协议解析结果的帧。注意有些帧可能既包含 DNS 又包含其他协议比如 UDP 报文里带着 payloadNetmon 会保留所有“包含 DNS 层”的帧。用这个基础过滤再配合时间排序就能快速看到一段窗口内所有的域名解析流量。实际排障时DNS这个单词往往是我输入的第一条过滤条件。因为不管问题是解析慢、解析失败还是解析到错误地址第一步永远是先把 DNS 流量从茫茫帧海里捞出来看看整体面貌。先把面缩小再谈精准定位。4.3 区分查询和响应DNS.Flags.ResponseDNS 帧里有标志位查询报文和响应报文在同一个标志字段的不同值上区分。Netmon 里对应字段是DNS.Flags.Response查询是 0响应是 1。只看查询DNS DNS.Flags.Response 0只看响应DNS DNS.Flags.Response 1这两个条件非常实用。排查“谁在发起域名解析”时只看查询排查“DNS 服务器有没有回应”时只看响应把查询和响应都显示出来再按时间对比中间的时间差就是解析耗时。有一次客户反馈域名解析经常失败我只用DNS DNS.Flags.Response 1一看发现响应数量明显少于查询数量说明确实有请求没有等到回应问题立刻从“客户端配置”转移到“服务端处理”上。4.4 按域名过滤查询DNS.Query.Name网络问题里有一类很烦某个程序疯狂解析一个不存在的域名或者某个域名解析结果不对。这时候需要按域名把帧筛出来。Netmon 的 DNS 解析器把查询里的域名放在DNS.Query.Name字段精确匹配写法DNS.Query.Name www.example.com注意值用双引号包裹和 Capture Filter 不一样。如果你只想看包含某关键字的域名Netmon 3.4 的显示筛选器没有 Wireshark 那种contains算子那么顺手我通常分两步先用DNS把流量缩小再在帧列表里用 CtrlF 搜索关键字或者在帧详情里搜索。对大多数排查场景精确匹配域名已经够用毕竟你要查的往往是明确的几个域名。4.5 过滤记录类型A、AAAA、CNAME查某个域名的 A 记录解析、还是 CNAME 链是排障时很常见的诉求。Netmon 的 DNS 解析器里查询记录的类型字段一般形如DNS.QRecord.Type应答记录的类型字段形如DNS.Answer.Type。比如只看查询 A 记录的帧DNS.QRecord.Type 1只看应答里出现 CNAME 的帧DNS.Answer.Type 5这里要说明一下不同版本 Netmon 解析器的字段路径不完全一致Type 的值也可能显示为枚举名或数字。最靠谱的做法是把一条 DNS 帧在帧详情里展开找到实际的字段路径再写。别硬背路径属性名是工具给的不是天经地义的。4.6 组合写法与右键取字段路径上面几种条件可以自由组合。比如只看某个客户端发出的对特定域名的查询IPv4.SourceAddress 192.168.10.5 DNS.Query.Name www.example.com只看某个 DNS 服务器返回的响应IPv4.SourceAddress 192.168.10.6 DNS.Flags.Response 1再说一个很省事的技巧在帧详情窗格里右键点击某个字段菜单里有“添加到显示筛选器”或类似的选项不同版本菜单名称略有差异点击后工具会自动把当前字段的完整路径填进筛选器。这个功能是学习字段命名的捷径。我每次不熟悉一个新协议时都是先翻帧详情右键取路径再改成需要的逻辑。这样几轮下来常见的 DNS、ICMP 字段路径基本就记熟了。5. Display Filter 实战IP 和 ICMP 过滤5.1 IP 地址过滤源、目的、任一方和 Capture Filter 类似Display Filter 里也有三个与地址相关的属性IPv4.SourceAddress 192.168.10.5 IPv4.DestinationAddress 192.168.10.5 IPv4.Address 192.168.10.5IPv4.SourceAddress只匹配发送方IPv4.DestinationAddress只匹配接收方IPv4.Address是源或目的任一方命中即可。第一次用 Netmon 的人容易把IPv4.Address当成“地址段的起始地址”来用其实它对应的就是“和这个地址相关的全部帧”。想同时看 A 与 B 两台主机的所有通信有一种写法是(IPv4.Address 192.168.10.5 IPv4.Address 192.168.10.8)但是在 Netmon 里这条表达式不一定返回你想要的结果因为IPv4.Address对源和目的分别存储一个帧要么源是 A 且目的是 B要么反过来。我实际测试下来最稳的写法是显式把两个方向都列出来(IPv4.SourceAddress 192.168.10.5 IPv4.DestinationAddress 192.168.10.8) || (IPv4.SourceAddress 192.168.10.8 IPv4.DestinationAddress 192.168.10.5)这种写法虽然长一点但语义清楚不管哪个版本的 Netmon 都不会误判。5.2 没有 CIDR 语法怎么办网段过滤的土办法Netmon 的显示筛选器不像 Wireshark 那样支持ip.addr 192.168.1.0/24的简洁写法。遇到“只看某个 C 段里所有主机的流量”时我一般用两种土办法。办法一地址范围比较。把IPv4.Address当作一个可比较的值用范围来逼近网段IPv4.Address 192.168.1.1 IPv4.Address 192.168.1.254这个写法能覆盖一部分场景但实际使用时我发现它不一定每次都把源和目的都包含进来结果可能漏。更保险的思路是显式写源和目的两侧(IPv4.SourceAddress 192.168.1.1 IPv4.SourceAddress 192.168.1.254) || (IPv4.DestinationAddress 192.168.1.1 IPv4.DestinationAddress 192.168.1.254)办法二干脆列出关键地址。排查问题时往往不是整个网段都有嫌疑而是集中在网关、DNS、某些应用服务器上。把明确的地址用||拼起来比硬塞一个网段条件更好读也不容易踩语法坑。Netmon 版本很老别拿现代工具的功能标准去要求它够用就行。5.3 ICMP 过滤ping 请求和响应怎么分开ICMP 没有端口的概念无法用端口过滤只能靠类型和代码。Netmon 里对应字段是ICMP.MessageType和ICMP.MessageCode。最常用的两个ICMP.MessageType 8 ICMP.MessageType 0Type 8 是 Echo Requestping 请求Type 0 是 Echo Replyping 响应。一个 ping 过程的完整链路就是“请求出去响应回来”。只想看某个主机发出的 ping 请求IPv4.SourceAddress 192.168.10.5 ICMP.MessageType 8只看某主机回给别人的 ping 响应IPv4.SourceAddress 192.168.10.5 ICMP.MessageType 0除了 Echo 之外还有几个类型在排障时很有用Type 3 表示 Destination Unreachable目的不可达里面再细分端口不可达、网络不可达等Type 11 表示 Time Exceeded超时traceroute 就是靠这个类型实现的。想单独看这些异常报文可以组合ICMP.MessageType 3 || ICMP.MessageType 115.4 ping 不通时用过滤组合快速定位ping 不通是最常见的网络问题也是过滤器最能发挥价值的场景。我在现场按下面几步来做。第一步用组合过滤看“请求是否已经发出”IPv4.SourceAddress 本机地址 ICMP.MessageType 8如果这里一条结果都没有说明 ping 请求根本没出网卡或者被本机防火墙拦了问题在本地。如果有请求但没有响应再看第二步。第二步专门找目的不可达IPv4.Address 目标地址 ICMP.MessageType 3如果能找到 Type 3说明某台中间设备在告诉你这个目的不可达直接看报错来源的主机地址就能知道是哪一跳出了问题。如果连 Type 3 都没有就要怀疑方向性问题。第三步区分“响应没回来”和“响应回来的路径不对”IPv4.DestinationAddress 本机地址 ICMP.MessageType 0如果能看到响应回来但 ping 客户端还是显示超时可能是本机防火墙丢弃了入站响应如果根本没有响应问题大概率在中间链路或目标主机的回包路径上。这套组合下来每次都能快速把 ping 不通的问题缩小到一个明确的方位。工具停更不可怕思路比工具版本值钱。6. 一次真实排查DNS 解析慢用过滤器层层逼近6.1 现场情况与抓包准备那台 Windows Server 运行着内部系统业务反馈访问某个外部域名经常要等好几秒。域名解析慢问题可能在客户端缓存、本地 DNS 服务器、上游递归服务器、权威服务器任何一段。逐层用 nslookup 试了半天时好时坏只能抓包。抓包方案是 netsh trace因为服务器上不想额外装驱动。在业务高峰期抓了 20 分钟导出 ETL。当时没有在 netsh 里写额外过滤参数全量先抓再说。实践证明ETL 文件大归大Netmon 打开后用 Display Filter 照样能很快缩小范围。6.2 先用 Display Filter 把 DNS 流量捞出来打开 ETL 后第一步直接输入DNS几万帧里立刻只剩一千来条 DNS 相关帧。这时候我注意到一个现象有大量对同一个外部域名的查询而且每次查询的客户端端口都不固定。这说明业务方确实在频繁解析这个域名不是缓存能覆盖的频率。再用时间排序间隔几秒的查询请求之间找对应的响应发现大部分查询在几十毫秒内就有响应但每隔几条就会出现一个超过 3 秒才响应的记录。这种“稳定快、偶发慢”的模式通常不是客户端的问题更像上游偶尔超时本地 DNS 在等递归结果。6.3 从查询响应间隔看出问题在哪一段稍微精细一点用组合条件把发给本地 DNS 的查询挑出来UDP.DestinationPort 53 DNS.Flags.Response 0再配合本地 DNS 服务器地址基本可以确定所有查询请求都正常到达了。真正关键的是响应那一侧。我用UDP.SourcePort 53 DNS.Flags.Response 1把所有从 53 端口返回的响应单独列出来按时间看响应报文之间的间隔。慢的几跳全集中在同一个外部域名上而本地 DNS 解析其他域名都快。到这里范围已经缩小到“本地 DNS 对这个特定域名的上游递归查询超时”而不是本地 DNS 整体故障。6.4 结论与处理最终建议业务方把部分高频外部域名加入本地 DNS 的转发器白名单指向另一个延迟更低的上游服务器问题当天就不再出现。整个过程里过滤器帮了大忙Capture Filter 在抓包阶段能省文件但这次因为是事后分析的 ETL主角完全是 Display Filter。事后复盘最有价值的一步并不是哪条过滤器语法写得多漂亮而是先用DNS把流量面缩到最小再逐步用DNS.Flags.Response、端口、时间轴去逼近慢的段。过滤器只是工具定位思路才是效率的来源。6.5 这个案例沉淀下来的排查思路这个案例沉淀下来的排查思路值得单独说说。遇到 DNS 类问题我的固定动作是先确认查询是否发出再确认响应是否回来最后看间隔和响应内容。每一类疑问都对应一条过滤器表达式表达式不会写就右键帧详情取路径。这套方法在 Netmon 上管用换到 Wireshark 上也一样成立只是属性名和运算符要跟着工具重新对一遍。还有两个小细节抓包期间最好把系统时间校准因为分析 DNS 延迟时要依赖不同帧的时间戳长时间抓包要留意磁盘剩余空间ETL 写满磁盘会导致抓包提前停止而且不会自动通知你。这些小问题如果提前注意现场能少很多麻烦。最后再分享一个操作习惯最后分享一个我用了很多年的操作习惯。抓包阶段尽量用 Capture Filter 把范围缩小到“地址 端口”级别分析阶段再用 Display Filter 去做协议字段级筛选两个漏斗各管一摊互不越界。很多新手觉得 Netmon 难用翻来覆去的原因就是没分清这两个筛选器在 Capture Filter 里找 DNS 域名或者抱怨 Display Filter 不能把文件变小。如果刚接触 Netmon建议打开一个历史捕获文件故意把帧详情里的各种字段右键添加为显示筛选器多试几次字段名和工具思维很快就熟了。工具停在 3.4 版本不更新不代表它没价值处理 ETL、解微软协议这些活儿它依然是最顺手的那把扳手。希望这篇实战笔记能让你在下次抓包排障时少走几步弯路。