说实话在 2025 年还要专门写一篇文章讲 Microsoft Network Monitor连我自己都有点意外。但前阵子帮朋友排查一台老 Windows Server 的 DNS 超时问题系统环境限制装不了新工具最后就是靠它救场的。那台机器上还留着 Network Monitor 3.4虽然微软早就停止更新但它的抓包筛选器在 Windows 环境里做网络排障依然称得上顺手。尤其是 Capture Filter 和 Display Filter 这两套筛选逻辑加上 DNS、IP、ICMP 三类高频过滤场景用好了能省下大量时间。这篇就当一份实操笔记写给那些还在 Windows 老环境里挣扎、或者想换个思路看抓包的工程师。1. 为什么这年头还要用 Microsoft Network Monitor很多新入行的同事一听这个工具名就皱眉觉得 Wireshark 已经是默认答案。但现实环境没那么理想某些企业内网的生产机器停留在 Windows Server 2008 R2 甚至更老的版本驱动签名、系统组件限制导致新版抓包工具装不上去还有一些隔离网段根本不允许随意安装第三方软件机器上恰好预装了 Netmon 3.4它就是唯一能用的抓包入口。另外一个被低估的点是Netmon 本身对微软系协议的处理相当细致。它解析 RPC、SMB、Kerberos、DNS 这些 Windows 环境下高频出现的协议时帧树结构很清晰字段名直接对应协议头定义不绕弯子。对做 Windows 网络排障的人来说这种“所见即字段”的呈现方式反而比 Wireshark 那种冗长的协议树更直白。Netmon 3.4 是微软在这个产品线上的最终版本后续接棒者 Microsoft Message Analyzer 也已在 2019 年被归档。所以现在讨论这个工具本质上是讨论一个已经冻结但依然可用的经典方案它的语法、解析器、过滤器逻辑都固定了学过的知识不会因为版本更新而失效。这也意味着网上能找到的教程和经验依然适用不会过时。2. Capture Filter 和 Display Filter先是两套完全不同的逻辑标题里把 Capture Filter 和 Display Filter 并列确实是因为这两个概念太容易混淆。两者的关键字都是 Filter看起来像同一套规则实际上一个是“录制端的闸门”一个是“回放端的筛子”。2.1 一个管“录什么”一个管“看什么”Capture Filter 在开始抓包之前设置它决定哪些帧会被写入抓包文件哪些直接在采集阶段就被丢弃。它的作用是控制抓包文件的大小避免磁盘被无意义流量塞满也让后续分析不用在一堆噪声里翻找。但也因为是在采集阶段过滤它的判断深度有限只能基于能快速识别的帧头、协议类型、端口、IP 地址这些浅层信息做判断。Display Filter 则完全不同。它作用于已经抓完的帧数据无论当初抓进来多少无关流量都可以在展示层随时过滤只把符合条件的帧显示出来。它不删除任何原始数据只是改变你的“视图”所以想怎么筛就怎么筛筛错了改一条表达式重新执行就行。2.2 支持范围、生效时机和适用场景从语法形式上看这两套过滤器的表达风格确实有相似的地方但实际能力差距明显。Capture Filter 支持到端口、地址、协议类型这一层再往应用层字段深入比如按 DNS 查询名称过滤、按 HTTP Host 头过滤它做不到。Display Filter 则能访问解析器提供的几乎所有字段灵活性强得多。对比项Capture FilterDisplay Filter设置位置Capture Settings 窗口的 Filter 页主界面的 Filter 窗口生效时机抓包开始前任意时间随时可改作用范围影响写入文件的数据只影响当前显示结果支持字段深度协议头、端口、地址等浅层字段几乎所有解析器暴露的字段对文件大小的影响直接缩小抓包文件不影响文件大小适用场景长时间抓包降噪、限制磁盘占用事后分析、逐步缩小问题范围这里有一个非常实用的经验除非你对现场流量情况非常有把握否则别把 Capture Filter 调得太狠。我见过不少人为了“只想抓 DNS”在 Capture Filter 里只写了UDP.DstPort 53结果忘了 DNS 响应是从服务器的 53 端口回来的客户端发出去的请求确实抓到了响应全被过滤掉了整个分析样本残缺不全。更稳的做法是先全量抓包再用 Display Filter 筛选除非抓包文件会大到无法处理才考虑用 Capture Filter 做粗粒度降噪。2.3 表达式不能互拷因为支持能力不同Capture Filter 里能写的表达式基本上都能在 Display Filter 里找到对应写法但反过来不一定成立。把一条复杂的 DNS 字段过滤表达式直接粘贴到 Capture Filter 里很可能会得到语法错误或无法生效。我建议把两者当成互补工具先用 Capture Filter 把“可能相关”的流量圈进来范围宁可大一点再用 Display Filter 一步步精确缩小找到真正有问题的帧。这个“先粗后细、先录后筛”的思路几乎适用于所有抓包排障场景。3. Netmon 过滤器的基本语法协议.属性 和几个符号Netmon 的过滤表达式核心就是“协议点属性”这种结构比如IPv4.SourceAddress表示 IPv4 协议的源地址字段。这种写法和 Wireshark 的ip.src类似但 Netmon 是直接用协议解析器里的字段名大小写不敏感可读性相对更强。3.1 字段引用与取值规则一条基本表达式形如“字段 操作符 值”。字段名必须存在于帧的解析结果中否则过滤器会报错值则需要区分类型数值字段直接写数字比如端口TCP.DstPort 443、ICMP 类型ICMP.Type 8。字符串字段要用双引号或单引号包起来比如DNS.DnsQuery.QName www.contoso.com。IP 地址字段直接写地址比如IPv4.SourceAddress 192.168.1.100。比较操作符支持、!、、、、逻辑组合使用、||、!。复杂场景可以加括号分组比如!ICMP (IPv4.SourceAddress 192.168.1.100 || IPv4.DestinationAddress 192.168.1.100)这条表达式的意思是排除 ICMP 流量只看源地址或目标地址为 192.168.1.100 的帧。括号让逻辑关系更明确建议在组合条件较多时养成加括号的习惯。3.2 CONTAINS、通配符和模糊匹配除了精确等于Netmon 的 Display Filter 还支持CONTAINS操作符和通配符这对不知道完整域名、只记得一部分特征的情况非常有用。DNS.DnsQuery.QName CONTAINS microsoft DNS.DnsQuery.QName *.contoso.com第一行会显示所有 DNS 查询名称里包含 microsoft 的帧第二行用*匹配前面任意内容。*代表任意长度的任意字符?代表单个字符。对于 DNS、HTTP 这类包含大量可变字符串的过滤需求这两个操作符使用频率很高。3.3 字段名记不住怎么办Netmon 的字段名体系不如 Wireshark 那样有简洁缩写初次接触最头疼的就是记不住字段名。我的解决办法是直接从帧详情里抄选中一帧在 Frame Details 窗口里展开协议节点单击某个字段时Filter 窗口会自动显示该字段对应的表达式前缀你只需要补上操作符和值。比如点开一帧 DNS 查询帧展开“DNS DnsQuery”找到“QName”字段单击后就能在 Filter 窗口看到DNS.DnsQuery.QName这个字段名直接照着写即可。这个方法屡试不爽比死记字段名高效得多。4. DNS 流量过滤从抓包入口到查询失败定位DNS 排错是网络管理员的日常。Netmon 处理 DNS 过滤时Capture Filter 和 Display Filter 各有用武之地下面按实际流程拆开讲。4.1 用 Capture Filter 把 DNS 流量单独圈出来DNS 查询默认走 UDP 53查询响应也是从 53 端口回来当响应数据较大时可能走 TCP 53。所以在 Capture Filter 里最稳妥的写法是同时考虑 UDP 和 TCP 的 53 端口且不区分源和目标端口UDP.DstPort 53 || UDP.SrcPort 53 || TCP.DstPort 53 || TCP.SrcPort 53如果想限定某台机器可以再加上 IP 条件(UDP.DstPort 53 || UDP.SrcPort 53 || TCP.DstPort 53 || TCP.SrcPort 53) (IPv4.SourceAddress 10.10.1.5 || IPv4.DestinationAddress 10.10.1.5)不要只写UDP.DstPort 53否则会漏掉所有响应帧和分析查询来源时可能需要的关键信息。4.2 用 Display Filter 按查询名称锁定目标抓完包之后最常用的操作是按域名定位。比如应用在启动时会解析db.internal.contoso.local直接过滤DNS.DnsQuery.QName db.internal.contoso.local如果记不全域名用CONTAINS模糊搜DNS.DnsQuery.QName CONTAINS contoso.local想排除内部域名产生的干扰可以用!取反!DNS.DnsQuery.QName CONTAINS internal.contoso.local注意某些版本的 Netmon 在响应记录里显示的字段名可能会略有差异比如响应部分的记录名可能是DNS.Record.RName。不同版本对 DNS 协议解析的字段命名不完全一致最可靠的方法还是看 Frame Details以本机实际显示的字段名为准。4.3 从响应状态码判断解析失败原因DNS 排错不能只看有没有响应还要看响应里携带的状态码。在 Netmon 中选中一条 DNS 响应帧在 Frame Details 里找到 DNS Flags 或 Response Code 字段根据值能快速判断响应码含义常见原因0NoError正常解析1FormatErrorDNS 报文格式错误2ServFailDNS 服务器内部处理失败3NXDomain域名不存在可能就是拼写错了4NotImpDNS 服务器不支持该查询类型我曾经在一个案例里看到大量 NXDomain当时第一反应是 DNS 服务器配置问题后来把查询名称拉出来一看是客户端程序把主机名拼错了多了一个多余的点。这种时候 Display Filter 里按 QName 排序很快就能看清问题域名的全貌。5. IP 与 ICMP 过滤远程排障的日常操作DNS 之外IP 地址和 ICMP 是最常用的两类过滤条件。一个解决“流量是不是来自某台机器”一个解决“这台机器到底通不通”。5.1 IP 地址过滤的标准写法只看某个 IP 作为源或目标产生的流量最明确的写法是同时列出源和目标两个条件IPv4.SourceAddress 192.168.1.100 || IPv4.DestinationAddress 192.168.1.100这个写法虽然长一点但不会产生歧义在任何版本里都能用。如果你想排除某台机器的流量可以在前面加!!(IPv4.SourceAddress 192.168.1.100 || IPv4.DestinationAddress 192.168.1.100)另一种常见需求是过滤广播包和多播包。广播地址是 255.255.255.255组播段是 224.0.0.0/4Netmon 不像 Wireshark 那样在所有版本里都直接支持 CIDR 写法稳妥的办法是逐个排除常见广播地址IPv4.DestinationAddress ! 255.255.255.255 IPv4.DestinationAddress ! 224.0.0.251这个场景常用于查看抓包里 ARP 之外的协议流量让视线从广播风暴里解脱出来。5.2 ICMP 类型过滤与 ping 不通排查ICMP 在 Netmon 中的字段体系很直接ICMP.Type表示类型ICMP.Code表示代码。日常用得最多的是ICMP.Type 8Echo Request也就是 ping 请求。ICMP.Type 0Echo Reply也就是 ping 响应。ICMP.Type 3Destination Unreachable目标不可达。假设你怀疑某个 IP 的 ping 请求没有响应可以这样过滤(ICMP.Type 8 IPv4.DestinationAddress 10.10.1.53) || (ICMP.Type 0 IPv4.SourceAddress 10.10.1.53)第一段看发出去的请求第二段看回来的响应。如果只有请求、没有响应说明请求丢了或对端没回如果返回的是ICMP.Type 3就得继续看ICMP.CodeType 3 的 Code含义0网络不可达1主机不可达2协议不可达3端口不可达比如数据库客户端报“连接超时”但你通过抓包看到有一堆ICMP.Type 3且 Code 为 1 的帧说明目标主机虽然在线但路由路径上的某个节点宣告主机不可达这和防火墙直接丢弃的行为又不一样。5.3 给抓包文件快速“瘦身”的小技巧如果你是用 Display Filter 找到了问题帧想把这个子集保存下来发给别人分析不要在原始抓包里直接截取屏幕。Netmon 另存为时支持按当前过滤结果导出只保留符合条件的帧文件体积会小很多对方打开也更轻松。这在处理大型抓包文件时尤其有用几百兆的抓包经过过滤后可能就剩几兆。6. 一个真实排障片段DNS 超时问题如何被筛选器步步锁定把前面这些技术串起来看一个完整场景。某天接到反馈一个 Windows 应用启动时总是卡顿需要登录很久。应用日志里没报错但明显有“解析某个内部域名”的环节。我到了现场直接在那台机器上用 Netmon 抓包整个过程用筛选器逐步缩小范围。6.1 第一步先粗粒度圈定 DNS 流量启动抓包之前Capture Filter 设成UDP.DstPort 53 || UDP.SrcPort 53 || TCP.DstPort 53 || TCP.SrcPort 53因为只捕获 DNS 相关流量文件不会膨胀可以放心跑一段时间让应用启动流程完整走一遍。抓完先不做任何精细筛选直接在抓包文件里看 DNS 帧的数量和分布。6.2 第二步用 Display Filter 锁定具体域名应用日志里提到了file.internal.contoso.local这个域名所以直接过滤DNS.DnsQuery.QName file.internal.contoso.local结果发现一帧查询请求发出后过了大约 300 毫秒才有第一帧响应紧接着又出现一次重发的查询请求。300 毫秒对一次内网 DNS 解析来说太慢了正常应该在 10 毫秒以内。6.3 第三步用 ICMP 过滤验证网络路径为了排除“是不是 DNS 服务器本身不可达”我在同一抓包里加过滤条件查看该 DNS 服务器 IP 的 ICMP 可达性(ICMP.Type 8 IPv4.DestinationAddress 10.10.1.53) || (ICMP.Type 0 IPv4.SourceAddress 10.10.1.53)结果 ICMP 响应几乎都是立刻返回说明网络链路没问题问题出在 DNS 服务器对这条查询的处理上。换了一台 DNS 服务器验证后应用启动恢复正常问题定位完成。这个案例里从抓包入口到最终定位只用了三条筛选器没有在茫茫帧海里逐条翻看。Capture Filter 负责减少存储噪声Display Filter 负责按字段精确代入ICMP 过滤负责排除链路因素——整套流程靠的就是这一层一层剥洋葱的思路。7. 常见坑和我绕坑的经验工具再老用得好不好还是看细节。下面几条都是实际踩过的坑列出来供参考。7.1 安装和权限问题Netmon 3.4 在较高版本的 Windows 上安装时可能遇到驱动签名或兼容性提示不一定能正常启用抓包。建议在管理员权限下运行必要时以兼容模式安装。如果机器上已经装过其他抓包驱动插入 Netmon 抓包网卡时也可能冲突需要在网卡选择界面确认实际绑定的会话是 Netmon 的驱动而不是别的工具残留的驱动。7.2 解析器没加载时字段名几乎不可用如果你打开抓包文件后发现 DNS、HTTP 等协议在 Frame Details 里显示为未知或未解析状态先别急着写过滤器。解析器没有加载DNS.DnsQuery.QName这种字段根本识别不了Filter 窗口也会提示错误。这种情况多半是安装不完整或抓包来源包含 Netmon 无法识别的链路类型重新安装/修复解析器或者换一台完整安装的机器打开文件。7.3 别把 Display Filter 表达式硬塞进 Capture Filter我反复强调过这一点因为真的有人直接把一条复杂展示过滤表达式粘到 Capture Filter 窗口然后发现抓包文件是空的。Capture Filter 对字段的支持面窄很多遇到 DISPLAY 专用字段会直接报语法错误或者静默地匹配不到任何帧。建议在拿不准时先在有数据的环境里验证表达式在 Display Filter 里能跑通再考虑是否能在 Capture Filter 里简化使用。7.4 与 Wireshark 语法的快速对照如果你从 Wireshark 切换过来下面这张对照表能省去不少翻文档的时间过滤目的Wireshark 写法Netmon 写法源/目标 IPip.addr 192.168.1.100IPv4.SourceAddress 192.168.1.100 || IPv4.DestinationAddress 192.168.1.100DNS 查询名dns.qry.name contains microsoftDNS.DnsQuery.QName CONTAINS microsoftICMP Echo 请求icmp.type 8ICMP.Type 8TCP 目标端口tcp.dstport 443TCP.DstPort 443排除某协议!icmp!ICMP7.5 把常用筛选器保存下来Netmon 的 Filter 窗口支持把当前表达式保存起来下次从下拉列表直接调用。我习惯按场景保存几个固定模板DNS 全流量、指定 IP 双向流量、ICMP 探测、ARPMAC 地址查询等。换了一台机器后只要重新输入这几个常用表达式就能快速恢复自己的排障节奏。这个习惯让我在 Netmon 老掉牙之后依然没有放弃它反而成了老环境排障时的首选工具。