个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化Microsoft Network Monitor 抓包筛选器实战Capture Filter 与 Display Filter、DNS/IP/ICMP 过滤本篇是今天学习抓包工具后的实践复盘。前面学习抓包时我们通常直接启动捕获然后面对几十、几百甚至更多的数据包逐条查找。流量一多这种方法很快就会失去效率。这次重点学习的是Filter筛选器在抓包前限制捕获范围或者在抓包完成以后从已有数据中筛选出真正需要分析的报文。本文以课程中使用的Microsoft Network Monitor 3.x为例分别测试 IP、DNS、ICMP、NOT 排除以及 Display Filter并整理一套可以直接用于后续网络故障排查的思路。Microsoft Network Monitor 抓包筛选器实战Microsoft Network Monitor 抓包筛选器实战Capture Filter 与 Display Filter、DNS/IP/ICMP 过滤1. 为什么抓包一定要学会使用筛选器2. 抓包筛选器和显示筛选器不是一回事2.1 Capture Filter决定“抓什么”2.2 Display Filter决定“看什么”3. 配置抓包筛选器4. 实验一只捕获访问百度产生的流量4.1 根据目标 IP 创建 Filter4.2 选择已经创建的筛选器5. 一个很容易忽略的操作先选择网卡6. 实验二创建 DNS 域名解析筛选器6.1 为什么有时候抓不到 DNS 查询7. Filter 中的 NOT排除不想捕获的流量8. 实验三只捕获 Ping 流量——ICMP9. 反向实验不捕获 ICMP10. 抓完之后再过滤Display Filter11. 实验四从已经抓取的数据中找出 Ping12. Capture Filter 和 Display Filter 到底应该怎么选场景一目标非常明确场景二只想验证 Ping场景三问题原因还不清楚13. 几个值得记住的 Network Monitor Filter13.1 查看某个 IPv4 地址13.2 只看源地址13.3 只看目标地址13.4 只看 TCP 某个端口13.5 只看 UDP 某个端口13.6 只看 ICMP13.7 只看 DNS13.8 只看 ARP13.9 同时限制服务器和端口14. 从“筛协议”进一步理解抓包排错第一步有没有发生 DNS 查询第二步域名解析到了什么 IP第三步TCP 有没有建立连接15. 一个完整的抓包排错思维16. 本次实验最容易犯的几个错误16.1 网卡选错16.2 Capture Filter 过滤得太狠16.3 把 Display Filter 当成“删除数据”16.4 认为域名永远对应一个 IP16.5 DNS 抓不到就认为 DNS 没工作17. 今天这节课真正需要记住什么18. 常用筛选规则速查表19. 后续学习方向1. 为什么抓包一定要学会使用筛选器抓包工具最容易出现的一个问题就是“包抓到了但是不知道该看哪个”。Windows 在正常运行时会持续产生大量网络通信例如 DNS、HTTPS、ARP、系统服务连接、浏览器后台请求以及各种应用程序流量。假设我们只想分析一次 Ping却把电脑当前所有网络流量全部抓下来很快就会看到大量与目标无关的数据包。真正需要的 ICMP 报文可能只占其中很小一部分。因此抓包时需要先回答一个问题我到底要找什么流量例如只看某个 IP 地址只看 DNS 域名解析只看 Ping 产生的 ICMP排除某种不需要分析的协议抓完以后再从全部数据中二次筛选。筛选器就是用来解决这些问题的。2. 抓包筛选器和显示筛选器不是一回事学习这一部分时最需要先区分两个概念类型英文什么时候工作是否影响实际抓到的数据抓包筛选器Capture Filter开始抓包之前是显示筛选器Display Filter数据已经捕获后否2.1 Capture Filter决定“抓什么”Capture Filter 在真正开始捕获之前生效。例如我们设置ICMP再启动抓包那么我们的目标就是把捕获范围限制到 ICMP 流量。这种方式的优点是数据量更小后续分析更容易长时间抓包时可以减少大量无关数据已经明确故障对象时效率很高。它的缺点也很明显过滤掉的数据并没有被保存。如果过滤条件一开始写错了需要的报文可能根本没有进入捕获结果。2.2 Display Filter决定“看什么”Display Filter 的逻辑不同。我们可以先不设置任何 Capture Filter把流量完整抓下来然后再输入ICMP此时工具只是从已经捕获的数据中把 ICMP 显示出来。其他数据仍然存在只是暂时隐藏。因此实际排错时我更倾向于这样理解Capture Filter ↓ 决定哪些数据进入抓包文件 Display Filter ↓ 决定当前界面显示哪些数据如果还不确定问题出在哪个协议先完整捕获再使用 Display Filter 通常更方便。3. 配置抓包筛选器进入抓包界面后可以为当前抓包任务配置 Filter。筛选器本质上就是一个条件表达式。只有符合条件的数据包才会进入我们关注的结果范围。比较常见的筛选维度有IPv4.Address TCP.Port UDP.Port ICMP DNS ARP后面会逐个测试。4. 实验一只捕获访问百度产生的流量第一组实验比较直观打开百度但只想观察与百度服务器之间的网络通信。这里首先会遇到一个问题www.baidu.com这是域名而真正的 IP 数据包主要依赖 IP 地址进行通信。因此可以先解析域名。Windows 中可以执行nslookup www.baidu.com也可以ping www.baidu.com从结果中找到当前解析得到的服务器 IP 地址。需要注意网站可能使用多个服务器、负载均衡或 CDN因此同一个域名在不同时间、不同网络环境下解析出来的 IP 可能不同。4.1 根据目标 IP 创建 Filter得到 IP 后就可以按照 IP 地址过滤。基本写法IPv4.Address 目标IP地址例如IPv4.Address 192.0.2.10这里只是演示语法实际实验时应替换成自己当时解析得到的目标服务器 IP。继续配置筛选条件4.2 选择已经创建的筛选器Filter 创建完成后还需要在抓包任务中真正选择并应用它。应用以后再访问目标网站可以看到捕获结果已经按照设置的条件进行了限制。这时数据量明显比“什么都抓”更集中。5. 一个很容易忽略的操作先选择网卡这次实验中有一个操作顺序需要特别记录下来先确认捕获网卡再配置和启动筛选器。电脑可能同时存在有线网卡Wi-FiVMware 虚拟网卡Hyper-V 虚拟交换机VPN 网卡蓝牙网络适配器。如果实际通过 Wi-Fi 上网却选择了一个 VMware 虚拟网卡即使过滤表达式完全正确也可能抓不到想看的流量。所以遇到“Filter 明明没问题但是一个包都没有”时第一件事不应该急着修改语法。先检查当前流量到底经过哪块网卡6. 实验二创建 DNS 域名解析筛选器第二组实验观察 DNS。DNS 的作用是把我们容易记忆的域名转换为网络通信需要使用的 IP 地址。例如www.baidu.com ↓ DNS 查询 ↓ DNS 响应 ↓ 得到一个或多个 IP 地址如果只想观察 DNS 流量可以创建 DNS Filter。DNS配置完成后重新访问域名就可以观察 DNS 请求以及返回的解析结果。6.1 为什么有时候抓不到 DNS 查询实际测试时可能会出现一种情况浏览器已经打开百度了但是抓包里没有新的 DNS 请求。原因之一是 Windows 或浏览器已经缓存了之前的 DNS 解析结果。此时系统没有必要再次向 DNS Server 查询。在测试环境中可以执行ipconfig /flushdns清理 Windows DNS Client Cache 后再重新访问目标域名。这样更容易重新产生 DNS 查询流量。这一点对于后续排查域名解析失败DNS Server 响应异常域名解析到错误 IP内外网 DNS 结果不一致都很有用。7. Filter 中的 NOT排除不想捕获的流量除了“我想看什么”实际抓包还有另一种思路我不想看什么这就需要排除条件。例如不需要 ICMP 流量时可以使用 NOT 的逻辑。Filter 中经常会涉及几种基本逻辑逻辑含义AND/两个条件都满足OR/ 满足其中一个条件NOT/!排除该条件掌握这几个逻辑以后就可以把简单 Filter 组合成针对实际故障的条件。例如DNS OR ICMP表示关注 DNS 或 ICMP。进一步限制某个目标地址时可以写成类似IPv4.Address 目标IP TCP.Port 443这样就比单纯按照协议过滤更精确。8. 实验三只捕获 Ping 流量——ICMPPing 是网络排错中最常用的命令之一。例如ping 192.168.1.1Ping 默认使用的是ICMP因此如果只想看 Ping 产生的报文可以直接创建 ICMP Filter。然后启动抓包并在 CMD 中执行ping 目标IP捕获结果中就可以看到对应的 ICMP 数据包。正常情况下最常见的是两类报文Echo Request Echo Reply可以简单理解为本机 │ │ Echo Request ▼ 目标主机 │ │ Echo Reply ▼ 本机Request 发得出去并且 Reply 能回来说明双方至少具备基本的 ICMP 网络可达性。9. 反向实验不捕获 ICMP为了验证 NOT 的作用再进行一次相反实验所有其他流量都可以捕获但是跳过 ICMP。创建“不捕获 ICMP”的筛选条件。启动抓包以后再执行 Ping。可以看到其他网络流量仍然存在但 ICMP 被筛选条件排除了。这一正一反两个实验非常适合理解 FilterICMP关注 ICMP。而NOT ICMP表达的是排除 ICMP 的思路。10. 抓完之后再过滤Display Filter前面的实验主要是在抓包之前限定范围。但实际故障排查中我们经常并不知道问题到底发生在 DNS还是 TCP还是服务器返回异常还是中间出现了 ICMP甚至不知道目标 IP 是哪个。此时一开始就设置非常严格的 Capture Filter反而可能漏掉关键数据。另一种方式是先完整抓包 ↓ 停止捕获 ↓ 再使用 Display Filter ↓ 逐步缩小分析范围这也是后续实际排错非常重要的一种工作方式。11. 实验四从已经抓取的数据中找出 Ping这次先不选择任何筛选器直接开始抓包。在抓包期间执行一次ping 目标IP然后停止捕获。此时数据列表里不仅有 Ping还会混杂大量其他网络流量。接下来进入 Display Filter。选择ICMP应用以后界面只显示 ICMP 数据。再结合数据包详情就可以继续查看 ICMP Request、Reply、源地址和目标地址等字段。12. Capture Filter 和 Display Filter 到底应该怎么选这次学习以后我认为两种 Filter 不能简单理解成“哪个好”而是适用阶段不同。场景一目标非常明确例如我只想知道客户端和某台服务器之间有没有通信。可以直接按照目标 IP 抓IPv4.Address 目标IP这种情况适合 Capture Filter。场景二只想验证 Ping已经明确只需要 ICMPICMP也可以直接在抓包前过滤。场景三问题原因还不清楚例如用户反馈“这个软件打不开。”此时可能涉及DNS ↓ TCP 三次握手 ↓ TLS ↓ HTTP/HTTPS ↓ 应用层响应如果一开始只抓 TCP 或只抓某个 IP很容易把真正的问题过滤掉。这种情况更适合先完整 Capture ↓ 保存原始数据 ↓ 使用 Display Filter 分析13. 几个值得记住的 Network Monitor Filter下面把本次学习以及后续排错常用的几个条件整理在一起。13.1 查看某个 IPv4 地址IPv4.Address 目标IPIPv4.Address可以理解为同时关注这个 IP 是否出现在通信双方中。13.2 只看源地址IPv4.SourceAddress 目标IP适合找哪些包是这台主机主动发出来的13.3 只看目标地址IPv4.DestinationAddress 目标IP适合找哪些流量正在发送给这台服务器13.4 只看 TCP 某个端口例如 HTTPSTCP.Port 443例如 HTTPTCP.Port 8013.5 只看 UDP 某个端口DNS 传统通信中经常涉及 UDP 53UDP.Port 53需要注意实际 DNS 环境并不能简单理解成“永远只有 UDP 53”分析问题时还是应该结合实际报文判断。13.6 只看 ICMPICMP适合分析 Ping、ICMP 错误消息等。13.7 只看 DNSDNS适合观察域名查询和响应。13.8 只看 ARPARP适合分析同一局域网内的 IPv4 地址到 MAC 地址解析过程。13.9 同时限制服务器和端口例如目标已经明确并且只关心 HTTPSIPv4.Address 目标IP TCP.Port 443这已经开始接近实际企业网络故障排查时使用 Filter 的方式。14. 从“筛协议”进一步理解抓包排错学习 Filter 以后我感觉抓包真正需要建立的并不是“背筛选器语法”而是一套逐步缩小问题范围的方法。例如用户反馈www.example.com 打不开可以按照通信过程分析。第一步有没有发生 DNS 查询筛DNS如果连 DNS Query 都没有就要先看本机缓存、应用行为或 DNS 配置。如果有 Query 没有 Response则继续排查客户端 ↓ DNS Server这一段通信。第二步域名解析到了什么 IP查看 DNS Response。假设获得203.0.113.10接下来就可以围绕这个 IP 继续分析IPv4.Address 203.0.113.10这样 DNS 和后续 TCP 通信就连起来了。第三步TCP 有没有建立连接如果访问的是 HTTPS可以继续关注TCP.Port 443此时就可以进一步学习SYN SYN ACK ACK也就是 TCP 三次握手。如果只看到SYN SYN SYN却始终没有服务器返回的 SYN ACK就可以继续排查网络路径、防火墙、目标端口或服务器状态。这已经比单纯执行一个ping能够看到更多信息。15. 一个完整的抓包排错思维把这次内容和之前学习的 TCP/IP、OSI 模型放在一起可以形成下面这条思路用户反馈网络故障 │ ▼ 确认问题对象 域名 / IP / 应用 / 端口 │ ▼ 选择正确网卡 │ ▼ 决定是否使用 Capture Filter │ ├── 问题明确 → 提前过滤 │ └── 问题不明确 → 尽量完整捕获 │ ▼ 复现故障 │ ▼ 停止抓包并保存数据 │ ▼ 使用 Display Filter 缩小范围 │ ▼ DNS → IP → TCP/UDP → 应用层 │ ▼ 查看 Request / Response │ ▼ 确认问题发生在哪一个通信阶段这套方法比“看到红色报文就认为那里有问题”可靠得多。16. 本次实验最容易犯的几个错误16.1 网卡选错这是最基础也最容易忽略的问题。尤其是在安装 VMware、Hyper-V、VPN 软件以后电脑可能同时出现很多网络适配器。先确认当前真正承担通信的接口。16.2 Capture Filter 过滤得太狠如果问题还没有定位不要一开始写非常严格的规则。否则关键报文可能根本没有被保存。16.3 把 Display Filter 当成“删除数据”Display Filter 只是改变当前显示结果。原始捕获的数据还在。清除 Display Filter 后其他报文仍然可以重新显示。16.4 认为域名永远对应一个 IP现在很多网站会使用CDN负载均衡多数据中心DNS 调度。所以域名 ≠ 永远固定的一个 IP如果按 IP 抓取网站流量应以当前实际解析结果为准。16.5 DNS 抓不到就认为 DNS 没工作还要考虑 DNS Cache。测试域名解析时可以先查看或者清理缓存再进行实验。例如ipconfig /displaydns查看缓存。测试环境需要重新触发解析时ipconfig /flushdns然后重新访问域名。17. 今天这节课真正需要记住什么这次学习以后几个知识点已经可以串起来。第一抓包不是“数据越多越好”。如果排查目标明确可以通过 Capture Filter 从源头限制数据范围。第二抓到的数据也不需要一次全部看懂。可以使用 Display Filter不断从全部数据 ↓ 某个协议 ↓ 某个 IP ↓ 某个端口 ↓ 某次具体通信逐步缩小范围。第三Filter 最终还是服务于网络通信过程。例如分析一次网站访问可以继续沿着DNS ↓ 获取服务器 IP ↓ TCP 建立连接 ↓ TLS / HTTP ↓ 服务器响应往下排查。这样前面学习的 OSI、TCP/IP、DNS、ICMP、TCP 三次握手就不再只是单独的理论知识而是可以直接在真实数据包中看到。18. 常用筛选规则速查表排查目标Filter 示例某个 IPv4 地址IPv4.Address 目标IP某个源 IPIPv4.SourceAddress 目标IP某个目标 IPIPv4.DestinationAddress 目标IPTCP 80TCP.Port 80TCP 443TCP.Port 443UDP 53UDP.Port 53Ping / ICMPICMPDNSDNSARPARP排除 ICMPNOT ICMP指定 IP HTTPSIPv4.Address 目标IP TCP.Port 443后续再学习 TCP、UDP、HTTP、DNS 故障分析时这张表基本都能继续使用。19. 后续学习方向完成这一部分以后下一步可以继续把抓包和具体协议结合起来。比较适合继续实验的内容包括1. 抓取并分析 ARP 请求和响应 2. 抓取 DNS Query / Response 3. 抓取 TCP 三次握手 4. 分析 TCP 四次挥手 5. 找 SYN 重传 6. 分析 TCP RST 7. 按 80 / 443 / 53 等端口筛选 8. 根据源 IP、目标 IP 判断数据流方向 9. 结合 OSI 模型判断故障发生在哪一层当能够从一堆数据包里快速找到谁发给谁 使用什么协议 访问什么端口 有没有收到响应 在哪一步开始异常抓包工具才真正开始具备排障价值。点击回到顶部 
长河君 · 2026/9/10 21:20:48 · 阅读 1.2k Microsoft Network Monitor 抓包筛选器实战：Capture Filter 与 Display Filter、DNS/IP/ICMP 过滤
个人主页杨利杰YJlio❄️个人专栏《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《IOS插件分析测试》《超简单用Python让Excel飞起来》让复杂的事情更简单让重复的工作自动化Microsoft Network Monitor 抓包筛选器实战Capture Filter 与 Display Filter、DNS/IP/ICMP 过滤本篇是今天学习抓包工具后的实践复盘。前面学习抓包时我们通常直接启动捕获然后面对几十、几百甚至更多的数据包逐条查找。流量一多这种方法很快就会失去效率。这次重点学习的是Filter筛选器在抓包前限制捕获范围或者在抓包完成以后从已有数据中筛选出真正需要分析的报文。本文以课程中使用的Microsoft Network Monitor 3.x为例分别测试 IP、DNS、ICMP、NOT 排除以及 Display Filter并整理一套可以直接用于后续网络故障排查的思路。Microsoft Network Monitor 抓包筛选器实战Microsoft Network Monitor 抓包筛选器实战Capture Filter 与 Display Filter、DNS/IP/ICMP 过滤1. 为什么抓包一定要学会使用筛选器2. 抓包筛选器和显示筛选器不是一回事2.1 Capture Filter决定“抓什么”2.2 Display Filter决定“看什么”3. 配置抓包筛选器4. 实验一只捕获访问百度产生的流量4.1 根据目标 IP 创建 Filter4.2 选择已经创建的筛选器5. 一个很容易忽略的操作先选择网卡6. 实验二创建 DNS 域名解析筛选器6.1 为什么有时候抓不到 DNS 查询7. Filter 中的 NOT排除不想捕获的流量8. 实验三只捕获 Ping 流量——ICMP9. 反向实验不捕获 ICMP10. 抓完之后再过滤Display Filter11. 实验四从已经抓取的数据中找出 Ping12. Capture Filter 和 Display Filter 到底应该怎么选场景一目标非常明确场景二只想验证 Ping场景三问题原因还不清楚13. 几个值得记住的 Network Monitor Filter13.1 查看某个 IPv4 地址13.2 只看源地址13.3 只看目标地址13.4 只看 TCP 某个端口13.5 只看 UDP 某个端口13.6 只看 ICMP13.7 只看 DNS13.8 只看 ARP13.9 同时限制服务器和端口14. 从“筛协议”进一步理解抓包排错第一步有没有发生 DNS 查询第二步域名解析到了什么 IP第三步TCP 有没有建立连接15. 一个完整的抓包排错思维16. 本次实验最容易犯的几个错误16.1 网卡选错16.2 Capture Filter 过滤得太狠16.3 把 Display Filter 当成“删除数据”16.4 认为域名永远对应一个 IP16.5 DNS 抓不到就认为 DNS 没工作17. 今天这节课真正需要记住什么18. 常用筛选规则速查表19. 后续学习方向1. 为什么抓包一定要学会使用筛选器抓包工具最容易出现的一个问题就是“包抓到了但是不知道该看哪个”。Windows 在正常运行时会持续产生大量网络通信例如 DNS、HTTPS、ARP、系统服务连接、浏览器后台请求以及各种应用程序流量。假设我们只想分析一次 Ping却把电脑当前所有网络流量全部抓下来很快就会看到大量与目标无关的数据包。真正需要的 ICMP 报文可能只占其中很小一部分。因此抓包时需要先回答一个问题我到底要找什么流量例如只看某个 IP 地址只看 DNS 域名解析只看 Ping 产生的 ICMP排除某种不需要分析的协议抓完以后再从全部数据中二次筛选。筛选器就是用来解决这些问题的。2. 抓包筛选器和显示筛选器不是一回事学习这一部分时最需要先区分两个概念类型英文什么时候工作是否影响实际抓到的数据抓包筛选器Capture Filter开始抓包之前是显示筛选器Display Filter数据已经捕获后否2.1 Capture Filter决定“抓什么”Capture Filter 在真正开始捕获之前生效。例如我们设置ICMP再启动抓包那么我们的目标就是把捕获范围限制到 ICMP 流量。这种方式的优点是数据量更小后续分析更容易长时间抓包时可以减少大量无关数据已经明确故障对象时效率很高。它的缺点也很明显过滤掉的数据并没有被保存。如果过滤条件一开始写错了需要的报文可能根本没有进入捕获结果。2.2 Display Filter决定“看什么”Display Filter 的逻辑不同。我们可以先不设置任何 Capture Filter把流量完整抓下来然后再输入ICMP此时工具只是从已经捕获的数据中把 ICMP 显示出来。其他数据仍然存在只是暂时隐藏。因此实际排错时我更倾向于这样理解Capture Filter ↓ 决定哪些数据进入抓包文件 Display Filter ↓ 决定当前界面显示哪些数据如果还不确定问题出在哪个协议先完整捕获再使用 Display Filter 通常更方便。3. 配置抓包筛选器进入抓包界面后可以为当前抓包任务配置 Filter。筛选器本质上就是一个条件表达式。只有符合条件的数据包才会进入我们关注的结果范围。比较常见的筛选维度有IPv4.Address TCP.Port UDP.Port ICMP DNS ARP后面会逐个测试。4. 实验一只捕获访问百度产生的流量第一组实验比较直观打开百度但只想观察与百度服务器之间的网络通信。这里首先会遇到一个问题www.baidu.com这是域名而真正的 IP 数据包主要依赖 IP 地址进行通信。因此可以先解析域名。Windows 中可以执行nslookup www.baidu.com也可以ping www.baidu.com从结果中找到当前解析得到的服务器 IP 地址。需要注意网站可能使用多个服务器、负载均衡或 CDN因此同一个域名在不同时间、不同网络环境下解析出来的 IP 可能不同。4.1 根据目标 IP 创建 Filter得到 IP 后就可以按照 IP 地址过滤。基本写法IPv4.Address 目标IP地址例如IPv4.Address 192.0.2.10这里只是演示语法实际实验时应替换成自己当时解析得到的目标服务器 IP。继续配置筛选条件4.2 选择已经创建的筛选器Filter 创建完成后还需要在抓包任务中真正选择并应用它。应用以后再访问目标网站可以看到捕获结果已经按照设置的条件进行了限制。这时数据量明显比“什么都抓”更集中。5. 一个很容易忽略的操作先选择网卡这次实验中有一个操作顺序需要特别记录下来先确认捕获网卡再配置和启动筛选器。电脑可能同时存在有线网卡Wi-FiVMware 虚拟网卡Hyper-V 虚拟交换机VPN 网卡蓝牙网络适配器。如果实际通过 Wi-Fi 上网却选择了一个 VMware 虚拟网卡即使过滤表达式完全正确也可能抓不到想看的流量。所以遇到“Filter 明明没问题但是一个包都没有”时第一件事不应该急着修改语法。先检查当前流量到底经过哪块网卡6. 实验二创建 DNS 域名解析筛选器第二组实验观察 DNS。DNS 的作用是把我们容易记忆的域名转换为网络通信需要使用的 IP 地址。例如www.baidu.com ↓ DNS 查询 ↓ DNS 响应 ↓ 得到一个或多个 IP 地址如果只想观察 DNS 流量可以创建 DNS Filter。DNS配置完成后重新访问域名就可以观察 DNS 请求以及返回的解析结果。6.1 为什么有时候抓不到 DNS 查询实际测试时可能会出现一种情况浏览器已经打开百度了但是抓包里没有新的 DNS 请求。原因之一是 Windows 或浏览器已经缓存了之前的 DNS 解析结果。此时系统没有必要再次向 DNS Server 查询。在测试环境中可以执行ipconfig /flushdns清理 Windows DNS Client Cache 后再重新访问目标域名。这样更容易重新产生 DNS 查询流量。这一点对于后续排查域名解析失败DNS Server 响应异常域名解析到错误 IP内外网 DNS 结果不一致都很有用。7. Filter 中的 NOT排除不想捕获的流量除了“我想看什么”实际抓包还有另一种思路我不想看什么这就需要排除条件。例如不需要 ICMP 流量时可以使用 NOT 的逻辑。Filter 中经常会涉及几种基本逻辑逻辑含义AND/两个条件都满足OR/ 满足其中一个条件NOT/!排除该条件掌握这几个逻辑以后就可以把简单 Filter 组合成针对实际故障的条件。例如DNS OR ICMP表示关注 DNS 或 ICMP。进一步限制某个目标地址时可以写成类似IPv4.Address 目标IP TCP.Port 443这样就比单纯按照协议过滤更精确。8. 实验三只捕获 Ping 流量——ICMPPing 是网络排错中最常用的命令之一。例如ping 192.168.1.1Ping 默认使用的是ICMP因此如果只想看 Ping 产生的报文可以直接创建 ICMP Filter。然后启动抓包并在 CMD 中执行ping 目标IP捕获结果中就可以看到对应的 ICMP 数据包。正常情况下最常见的是两类报文Echo Request Echo Reply可以简单理解为本机 │ │ Echo Request ▼ 目标主机 │ │ Echo Reply ▼ 本机Request 发得出去并且 Reply 能回来说明双方至少具备基本的 ICMP 网络可达性。9. 反向实验不捕获 ICMP为了验证 NOT 的作用再进行一次相反实验所有其他流量都可以捕获但是跳过 ICMP。创建“不捕获 ICMP”的筛选条件。启动抓包以后再执行 Ping。可以看到其他网络流量仍然存在但 ICMP 被筛选条件排除了。这一正一反两个实验非常适合理解 FilterICMP关注 ICMP。而NOT ICMP表达的是排除 ICMP 的思路。10. 抓完之后再过滤Display Filter前面的实验主要是在抓包之前限定范围。但实际故障排查中我们经常并不知道问题到底发生在 DNS还是 TCP还是服务器返回异常还是中间出现了 ICMP甚至不知道目标 IP 是哪个。此时一开始就设置非常严格的 Capture Filter反而可能漏掉关键数据。另一种方式是先完整抓包 ↓ 停止捕获 ↓ 再使用 Display Filter ↓ 逐步缩小分析范围这也是后续实际排错非常重要的一种工作方式。11. 实验四从已经抓取的数据中找出 Ping这次先不选择任何筛选器直接开始抓包。在抓包期间执行一次ping 目标IP然后停止捕获。此时数据列表里不仅有 Ping还会混杂大量其他网络流量。接下来进入 Display Filter。选择ICMP应用以后界面只显示 ICMP 数据。再结合数据包详情就可以继续查看 ICMP Request、Reply、源地址和目标地址等字段。12. Capture Filter 和 Display Filter 到底应该怎么选这次学习以后我认为两种 Filter 不能简单理解成“哪个好”而是适用阶段不同。场景一目标非常明确例如我只想知道客户端和某台服务器之间有没有通信。可以直接按照目标 IP 抓IPv4.Address 目标IP这种情况适合 Capture Filter。场景二只想验证 Ping已经明确只需要 ICMPICMP也可以直接在抓包前过滤。场景三问题原因还不清楚例如用户反馈“这个软件打不开。”此时可能涉及DNS ↓ TCP 三次握手 ↓ TLS ↓ HTTP/HTTPS ↓ 应用层响应如果一开始只抓 TCP 或只抓某个 IP很容易把真正的问题过滤掉。这种情况更适合先完整 Capture ↓ 保存原始数据 ↓ 使用 Display Filter 分析13. 几个值得记住的 Network Monitor Filter下面把本次学习以及后续排错常用的几个条件整理在一起。13.1 查看某个 IPv4 地址IPv4.Address 目标IPIPv4.Address可以理解为同时关注这个 IP 是否出现在通信双方中。13.2 只看源地址IPv4.SourceAddress 目标IP适合找哪些包是这台主机主动发出来的13.3 只看目标地址IPv4.DestinationAddress 目标IP适合找哪些流量正在发送给这台服务器13.4 只看 TCP 某个端口例如 HTTPSTCP.Port 443例如 HTTPTCP.Port 8013.5 只看 UDP 某个端口DNS 传统通信中经常涉及 UDP 53UDP.Port 53需要注意实际 DNS 环境并不能简单理解成“永远只有 UDP 53”分析问题时还是应该结合实际报文判断。13.6 只看 ICMPICMP适合分析 Ping、ICMP 错误消息等。13.7 只看 DNSDNS适合观察域名查询和响应。13.8 只看 ARPARP适合分析同一局域网内的 IPv4 地址到 MAC 地址解析过程。13.9 同时限制服务器和端口例如目标已经明确并且只关心 HTTPSIPv4.Address 目标IP TCP.Port 443这已经开始接近实际企业网络故障排查时使用 Filter 的方式。14. 从“筛协议”进一步理解抓包排错学习 Filter 以后我感觉抓包真正需要建立的并不是“背筛选器语法”而是一套逐步缩小问题范围的方法。例如用户反馈www.example.com 打不开可以按照通信过程分析。第一步有没有发生 DNS 查询筛DNS如果连 DNS Query 都没有就要先看本机缓存、应用行为或 DNS 配置。如果有 Query 没有 Response则继续排查客户端 ↓ DNS Server这一段通信。第二步域名解析到了什么 IP查看 DNS Response。假设获得203.0.113.10接下来就可以围绕这个 IP 继续分析IPv4.Address 203.0.113.10这样 DNS 和后续 TCP 通信就连起来了。第三步TCP 有没有建立连接如果访问的是 HTTPS可以继续关注TCP.Port 443此时就可以进一步学习SYN SYN ACK ACK也就是 TCP 三次握手。如果只看到SYN SYN SYN却始终没有服务器返回的 SYN ACK就可以继续排查网络路径、防火墙、目标端口或服务器状态。这已经比单纯执行一个ping能够看到更多信息。15. 一个完整的抓包排错思维把这次内容和之前学习的 TCP/IP、OSI 模型放在一起可以形成下面这条思路用户反馈网络故障 │ ▼ 确认问题对象 域名 / IP / 应用 / 端口 │ ▼ 选择正确网卡 │ ▼ 决定是否使用 Capture Filter │ ├── 问题明确 → 提前过滤 │ └── 问题不明确 → 尽量完整捕获 │ ▼ 复现故障 │ ▼ 停止抓包并保存数据 │ ▼ 使用 Display Filter 缩小范围 │ ▼ DNS → IP → TCP/UDP → 应用层 │ ▼ 查看 Request / Response │ ▼ 确认问题发生在哪一个通信阶段这套方法比“看到红色报文就认为那里有问题”可靠得多。16. 本次实验最容易犯的几个错误16.1 网卡选错这是最基础也最容易忽略的问题。尤其是在安装 VMware、Hyper-V、VPN 软件以后电脑可能同时出现很多网络适配器。先确认当前真正承担通信的接口。16.2 Capture Filter 过滤得太狠如果问题还没有定位不要一开始写非常严格的规则。否则关键报文可能根本没有被保存。16.3 把 Display Filter 当成“删除数据”Display Filter 只是改变当前显示结果。原始捕获的数据还在。清除 Display Filter 后其他报文仍然可以重新显示。16.4 认为域名永远对应一个 IP现在很多网站会使用CDN负载均衡多数据中心DNS 调度。所以域名 ≠ 永远固定的一个 IP如果按 IP 抓取网站流量应以当前实际解析结果为准。16.5 DNS 抓不到就认为 DNS 没工作还要考虑 DNS Cache。测试域名解析时可以先查看或者清理缓存再进行实验。例如ipconfig /displaydns查看缓存。测试环境需要重新触发解析时ipconfig /flushdns然后重新访问域名。17. 今天这节课真正需要记住什么这次学习以后几个知识点已经可以串起来。第一抓包不是“数据越多越好”。如果排查目标明确可以通过 Capture Filter 从源头限制数据范围。第二抓到的数据也不需要一次全部看懂。可以使用 Display Filter不断从全部数据 ↓ 某个协议 ↓ 某个 IP ↓ 某个端口 ↓ 某次具体通信逐步缩小范围。第三Filter 最终还是服务于网络通信过程。例如分析一次网站访问可以继续沿着DNS ↓ 获取服务器 IP ↓ TCP 建立连接 ↓ TLS / HTTP ↓ 服务器响应往下排查。这样前面学习的 OSI、TCP/IP、DNS、ICMP、TCP 三次握手就不再只是单独的理论知识而是可以直接在真实数据包中看到。18. 常用筛选规则速查表排查目标Filter 示例某个 IPv4 地址IPv4.Address 目标IP某个源 IPIPv4.SourceAddress 目标IP某个目标 IPIPv4.DestinationAddress 目标IPTCP 80TCP.Port 80TCP 443TCP.Port 443UDP 53UDP.Port 53Ping / ICMPICMPDNSDNSARPARP排除 ICMPNOT ICMP指定 IP HTTPSIPv4.Address 目标IP TCP.Port 443后续再学习 TCP、UDP、HTTP、DNS 故障分析时这张表基本都能继续使用。19. 后续学习方向完成这一部分以后下一步可以继续把抓包和具体协议结合起来。比较适合继续实验的内容包括1. 抓取并分析 ARP 请求和响应 2. 抓取 DNS Query / Response 3. 抓取 TCP 三次握手 4. 分析 TCP 四次挥手 5. 找 SYN 重传 6. 分析 TCP RST 7. 按 80 / 443 / 53 等端口筛选 8. 根据源 IP、目标 IP 判断数据流方向 9. 结合 OSI 模型判断故障发生在哪一层当能够从一堆数据包里快速找到谁发给谁 使用什么协议 访问什么端口 有没有收到响应 在哪一步开始异常抓包工具才真正开始具备排障价值。点击回到顶部