杂收模式对应英文术语 `Promiscuous Mode`，也常被翻译为混杂模式。网卡进入这种模式后，不再只接收目的 `MAC` 地址与本机相符的以太网帧，而是把到达该网络接口、且网卡能够实际看到的各种帧交给操作系统或抓包程序。嗅探器正是利用这一机制获取原本并非发给本机的网络通信。

不过，选项中的响应并不是特别严谨的工程表达。网卡看到分组，并不代表它会向这些分组发送答复。更准确的说法应当是，网卡能够接收、捕获或者向上层提交流经该接口的所有分组。考试题沿用了传统教材的表达，因此仍应选择 **D**。

## 普通模式下网卡为什么会丢弃别人的数据

现代以太网中的每块网卡通常都有一个 `MAC` 地址。`MAC` 地址位于以太网帧头部，用来标识局域网范围内的发送接口与目标接口。

一张典型的以太网帧包含目的 `MAC` 地址、源 `MAC` 地址、类型或长度字段、数据载荷以及帧校验序列等内容。网卡接收到电信号或者光电转换后的数字信号时，会解析帧头并检查目的 `MAC` 地址。

普通接收模式下，网卡主要接受三类帧。

一类是单播给本机的帧，也就是目的 `MAC` 地址与网卡自身地址相同的帧。

一类是广播帧，其目的 `MAC` 地址为 `FF FF FF FF FF FF`。广播帧面向同一二层广播域中的全部节点，常见的 `ARP` 请求以及部分 `DHCP` 报文都会使用广播。

另一类是网卡已经加入相应组播组的组播帧。组播不是发送给全部设备，也不是只发送给某一台设备，而是发送给某个逻辑接收组。只有满足网卡过滤条件或者已加入对应组播组的流量，才会被正常提交给上层。

当一个普通模式的网卡收到目的 `MAC` 地址属于另一台主机的单播帧时，网卡通常会在硬件接收过滤阶段将其丢弃。数据可能已经到达接口电路，但不会继续进入操作系统协议栈。这样可以减少无关数据占用主机内存、总线带宽和 `CPU` 时间。

微软的 `NDIS` 文档把这种过滤机制描述得很清楚。定向接收过滤器负责接收目的地址等于本机地址的帧，广播过滤器负责广播帧，组播过滤器负责匹配组播列表的帧，而 `NDIS_PACKET_TYPE_PROMISCUOUS` 会使协议驱动程序收到网卡实际接收到的全部分组，即使发送节点并未把这些分组定向发送给本机。[Microsoft Learn 关于当前分组过滤器的说明](https://learn.microsoft.com/en-us/windows-hardware/drivers/network/oid-gen-current-packet-filter)

由此也能看出，普通网卡并不是物理上完全接触不到其他帧，而是会按照目的地址进行筛选。所谓杂收模式，改变的正是这一层过滤策略。

## 杂收模式究竟改变了什么

当 `Wireshark`、`tcpdump`、`Npcap`、`libpcap` 或某些网络入侵检测程序启动抓包时，程序可以请求操作系统把指定网络接口切换到杂收模式。

进入杂收模式后，网卡不会再依据本机 `MAC` 地址提前排除所有无关单播帧。网卡实际收到的帧可以被送入驱动程序，再交给抓包机制和嗅探软件处理。此时可捕获的范围通常包括发给本机的单播帧、广播帧、组播帧以及目的 `MAC` 地址属于其他主机的单播帧。

Linux 的 `packet` 手册把 `PACKET_MR_PROMISC` 定义为在共享介质上启用全部分组的接收，而 `PACKET_MR_MULTICAST` 只绑定指定的物理层组播组，`PACKET_MR_ALLMULTI` 则接收接口到达的全部组播分组。三者的区别恰好说明，杂收模式的范围显著大于普通组播接收模式。[Linux packet 手册](https://man7.org/linux/man-pages/man7/packet.7.html)

`Wireshark` 官方用户指南也指出，启用杂收模式后，网络接口可以捕获它收到的全部以太网帧，不再局限于目的地址指向该捕获接口的帧。[Wireshark 用户指南](https://www.wireshark.org/docs/wsug_html/)

因此，题目中的核心逻辑可以压缩成一条非常清楚的判断链。

普通模式会执行目的 `MAC` 地址过滤，杂收模式会放宽这种过滤，嗅探器因而能够读取到达接口的更多帧，四个选项中只有 **D** 符合这一特征。

需要把一个容易误解的地方讲透。杂收模式只是允许网卡接收所有实际到达该接口的帧，并没有让网卡具备从整个网络中主动召回数据的能力。这里的所有分组存在一个隐含边界，即这些分组必须已经通过网络介质、交换设备或者虚拟交换设备到达该接口。

因此，杂收模式不是全网透视能力，而是取消本地网卡的目的地址过滤。

## 为什么选项 A 不正确

选项 **A** 表述的是只能够响应与本地网络接口硬件地址相匹配的分组。

这里的硬件地址通常就是 `MAC` 地址。如果网卡仅接收目的 `MAC` 地址与自身地址相同的单播帧，那么它仍然处在常规的定向接收状态，并没有体现杂收模式的特征。

进一步说，普通接收模式也不是真的只接收目的地址与本机完全匹配的帧。广播帧以及符合条件的组播帧同样可以被正常接收。因此，选项 **A** 不但不能描述杂收模式，对普通模式的概括也不够完整。

在网卡驱动层面，目的地址与本机地址匹配的接收类型通常被称为 `Directed`。杂收接收则是 `Promiscuous`。二者并不是同一种过滤级别。前者强调只接收定向给本机的单播流量，后者强调绕过普通的目的地址限制。

假定局域网中有主机甲、主机乙和抓包主机丙。甲向乙发送一个以太网单播帧，帧的目的 `MAC` 地址属于乙。丙的网卡在普通模式下会发现目的地址不是自身地址，于是将帧过滤掉。丙进入杂收模式后，只要该帧确实到达丙所在的网络接口，丙便可以把它提交给抓包程序。

这正是 **A** 与 **D** 的关键差异。**A** 保留了定向地址过滤，**D** 描述了杂收接收能力。

## 为什么选项 B 不正确

选项 **B** 表述的是只能够响应本网段的广播分组。

广播只是杂收模式可以接收的数据类型之一，绝不是其全部接收范围。普通模式下的网卡本来就能接收所在二层广播域中的广播帧，并不需要开启杂收模式。

以 `ARP` 为例，当主机需要知道某个局域网 `IPv4` 地址对应的 `MAC` 地址时，通常会发送 `ARP Request` 广播帧。目的 `MAC` 地址是全 `FF`，同一广播域中的网卡即使没有进入杂收模式，也会接收并检查这个帧。

`DHCP Discover` 也经常通过广播发出，因为客户端此时还没有获得稳定的 `IP` 地址，也未必知道 `DHCP` 服务器的位置。网络管理员使用 `Wireshark` 排查客户端无法自动获取地址的问题时，可以观察 `DHCP Discover`、`DHCP Offer`、`DHCP Request` 和 `DHCP ACK` 的交互过程。其中广播报文并不能证明网卡启用了杂收模式，因为普通网卡同样能够收到面向本广播域的广播帧。

杂收模式真正增加的能力，是接收那些不属于本机地址、也不一定属于广播或已订阅组播的帧。因此，**B** 把接收范围缩小到了广播这一种类型，与题意不符。

选项中出现的本网段也不够准确。广播是否能够到达某个接口，主要受二层广播域、`VLAN` 配置以及路由器边界影响，而不是简单由主机配置的子网掩码决定。路由器通常不会转发普通二层广播，所以不同广播域中的广播流量不会因为网卡进入杂收模式就自动跨越路由器来到本机。

## 为什么选项 C 不正确

选项 **C** 表述的是只能响应组播信息。

组播接收与杂收接收是两种不同机制。操作系统和网卡可以维护组播地址列表，只接收某些指定组播组的帧。还可以启用全部组播模式，使接口接收所有到达的组播帧。无论是哪一种，都不等于完整的杂收模式。

Linux 接口明确区分 `PACKET_MR_MULTICAST`、`PACKET_MR_ALLMULTI` 和 `PACKET_MR_PROMISC`。指定组播模式关注某个组播地址，全部组播模式关注全部组播帧，杂收模式则突破了组播范围，连其他主机的单播帧也可以接收。

组播地址的用途很多。`IPv6` 广泛使用组播完成邻居发现和路由器发现，一些流媒体分发、服务发现及路由协议也会利用组播。网卡接收这些报文时，通常根据组播地址和成员关系进行过滤。即使网卡支持组播，也不能由此推导出它可以接收所有其他单播通信。

**C** 中的只能二字把范围限制得非常窄，直接排除了单播与广播，因此显然不能描述杂收模式。

## 为什么选项 D 正确，却不能机械理解为全网所有数据

选项 **D** 表述的是能够响应流经网络接口的所有分组。按照计算机网络考试的标准语义，它准确抓住了杂收模式的核心，因此应当选择 **D**。

工程实践中需要给所有增加一个范围限定。这里不是指整个公司网络、整个校园网或者整个互联网的全部数据，而是指网卡实际收到的全部帧。

早期共享式以太网经常使用集线器。集线器工作在物理层，不学习 `MAC` 地址，也不建立转发表。某个端口收到的比特流会被复制到其他端口。在这样的共享介质中，一台计算机开启杂收模式后，确实可能观察到同一冲突域内其他计算机之间的大量通信。

交换机改变了这一局面。二层交换机通过学习源 `MAC` 地址形成转发表，并按照目的 `MAC` 地址把已知单播帧转发到对应端口。甲主机连接交换机的一号端口，乙主机连接二号端口，抓包主机连接三号端口。甲向乙发送已知单播帧时，交换机通常只把帧送往二号端口。三号端口根本没有收到这个帧，所以抓包主机即使打开杂收模式也无法捕获它。

这里没有发生网卡过滤，因为帧连抓包接口都没有到达。杂收模式只能控制网卡收到帧之后是否丢弃，不能改变交换机在帧到达网卡之前所作的转发决定。

在交换式企业网络中，若需要分析其他端口之间的流量，通常会配置 `SPAN`、端口镜像、远程端口镜像或者网络分光设备。交换机把目标端口或目标 `VLAN` 的流量复制到监控端口，抓包主机连接监控端口并开启杂收模式，才有机会接收和分析这些被复制的帧。

微软关于流量镜像的文档也将 `SPAN` 端口描述为把交换机接口上的本地流量镜像到另一个接口。这个机制解决的是流量如何到达监控接口的问题，杂收模式解决的是到达监控接口后网卡是否接受非本机目的地址帧的问题。两者处于不同环节，不能相互替代。[Microsoft Learn 关于流量镜像的说明](https://learn.microsoft.com/en-us/azure/defender-for-iot/organizations/traffic-mirroring/configure-mirror-hyper-v)

还存在几类可能到达普通交换机端口的非本机流量。广播帧通常会在所属 `VLAN` 内泛洪。组播帧在缺少有效组播侦听控制时也可能被泛洪。目的地址尚未被交换机学习的未知单播帧，往往会在相应 `VLAN` 内向多个端口泛洪。网络环路、错误配置、端口镜像以及部分攻击行为也可能使额外流量到达抓包接口。

所以，在交换网络里开启杂收模式后，`Wireshark` 仍能看到广播、部分组播、未知单播、本机收发流量以及由镜像机制送来的流量，但未必能看到其他任意两台主机之间的已知单播通信。

## 从网卡硬件到嗅探软件的数据路径

理解这道题，还可以沿着一帧数据的接收路径向下观察。

电缆上的物理信号到达网卡后，物理层电路完成信号恢复和位流识别。网卡的 `MAC` 子层逻辑识别以太网帧边界，检查帧格式，并依据硬件能力验证 `FCS`。随后，网卡使用接收过滤器判断这个帧是否应当进入接收队列。

普通模式下，过滤条件通常围绕本机单播地址、广播地址和已登记组播地址展开。不满足条件的帧可能直接在网卡侧被丢弃，操作系统不会为它分配后续处理资源。

开启杂收模式后，目的地址过滤被放宽。网卡会利用 `DMA` 把更多接收数据写入主机内存，并通过中断或轮询机制通知驱动程序。捕获驱动再把帧复制、映射或者投递给抓包程序。`Wireshark` 对这些帧进行协议解析，最终把以太网、`ARP`、`IPv4`、`IPv6`、`TCP`、`UDP`、`DNS`、`HTTP` 等协议字段显示出来。

整个过程体现了嗅探器的两个基础能力。一个是捕获原始链路层帧，另一个是按照协议格式解析帧中的字段。杂收模式主要服务于前一个能力，它负责扩大网卡愿意接收的帧范围。协议解析则由嗅探软件完成。

嗅探器并不会因为启用了杂收模式就自动解密所有内容。对于 `HTTPS`、`SSH`、`TLS` 或 `IPsec` 流量，抓包程序通常可以看到链路层地址、`IP` 地址、端口、长度、时序以及部分握手信息，但应用数据可能仍是密文。是否能解密取决于协议、密钥材料、会话参数和具体部署方式。

同样，网卡也未必把所有物理层异常完整交给抓包程序。某些存在校验错误的以太网帧会被网卡硬件直接丢弃。硬件卸载还可能改变抓包程序观察到的数据形态。常见的校验和卸载、分段卸载以及接收合并，都可能使主机上看到的数据与线缆上的原始帧存在差异。因此，专业网络分析常常需要同时考虑捕获位置、网卡能力、驱动实现和硬件卸载配置。

## 无线网络中的杂收模式与监听模式不能混为一谈

有线以太网中的杂收模式和无线网络中的监听模式经常被混淆。

在无线网卡已经关联某个无线接入点的情况下，杂收模式可以扩大数据接收范围，但受到无线网卡、驱动程序、操作系统以及接入点工作方式的限制。若需要捕获某个无线信道上的原始 `802.11` 管理帧、控制帧和数据帧，通常需要使用 `Monitor Mode`，也就是监听模式。

`Wireshark` 用户指南明确将两者分开。杂收模式允许接口捕获它收到的全部以太网帧，监听模式则针对 `802.11` 设备，使无线接口捕获接收到的无线帧。实际结果还受操作系统、驱动软件和无线硬件能力影响。

这一差异再次说明，考试题中的杂收模式主要围绕传统以太网接收过滤展开。不能把它扩展理解为对任何网络介质、任何信道和任何位置的无限制监听。

## 嗅探器在真实网络管理中的用途

网络嗅探技术本身是中性的。它既可以用于故障诊断和性能分析，也可能被攻击者用于信息收集。决定性质的是授权范围、部署位置和使用目的。

在企业网络故障处理中，`Wireshark` 经常用于检查三次握手是否完成、`TCP` 是否出现重传、`DNS` 查询是否超时、`DHCP` 地址分配停在哪个阶段、`ARP` 映射是否异常、服务器是否主动返回 `RST`，以及应用响应时间究竟消耗在网络还是服务端处理上。

排查客户端无法访问业务系统时，抓包记录可能显示客户端已经发出 `SYN`，但始终没有收到 `SYN ACK`。这类现象可以帮助我们把问题范围缩小到防火墙、路由、服务器监听状态或回程路径。若握手完整而应用请求迟迟没有响应，调查方向则会转向服务器线程、数据库查询和上游依赖。

安全监测设备也会利用镜像端口接收网络流量，并让采集接口工作在杂收模式。入侵检测系统可以从流量中识别端口扫描、异常连接、恶意域名访问、横向移动和协议违规。这里的接口一般只负责被动接收，不需要为观察到的每个分组作出网络响应。

虚拟化环境同样存在杂收模式。虚拟交换机默认会隔离各虚拟网卡的流量，虚拟机通常不能随意看到其他虚拟机的数据。部署虚拟防火墙、虚拟入侵检测系统或流量分析设备时，可能需要在虚拟交换机端口组上配置杂收、镜像或相应安全策略。操作对象虽然从物理网卡变成了虚拟网卡，基本逻辑仍然一致。

这些实际用途也能帮助我们纠正题干中的响应一词。嗅探器的典型行为是被动采集和分析，而不是主动回复每个经过接口的分组。若把响应理解为发送应答，选项 **D** 就容易引起困惑。按照题目意图，响应应理解为接受、识别并交给嗅探程序处理。

## 从安全角度理解杂收模式

共享式网络环境中，明文协议曾经给嗅探攻击留下很大空间。`Telnet`、传统 `FTP`、未加密的 `HTTP` 以及部分明文邮件协议可能直接暴露账户、命令和业务数据。攻击者一旦获得合适的捕获位置，并让网卡进入杂收模式，就可能读取这些通信内容。

现代交换机减少了普通端口直接看到其他端口单播流量的机会，但并未让嗅探风险彻底消失。攻击者可能利用 `ARP` 欺骗把自己置于通信路径中，也可能攻击交换设备、滥用端口镜像配置、控制网关或在终端内部直接抓取流量。采用 `TLS`、`SSH`、`IPsec` 和安全无线加密，能够在流量被截获时继续保护内容机密性。

企业管理中还会关注网卡是否异常进入杂收模式，因为它可能表明主机正在运行抓包工具或监控组件。不过，仅凭杂收模式不能直接认定存在攻击。运维诊断、终端安全软件、虚拟交换、容器网络和合法流量采集程序都可能合理使用这一能力。

Linux 系统中，开启原始分组捕获通常需要较高权限或相应的 `CAP_NET_RAW` 能力。Windows 环境中的 `Wireshark` 往往通过 `Npcap` 驱动完成底层捕获。这样的权限要求源于原始网络数据可能包含敏感信息，操作系统不能把完整捕获能力毫无限制地开放给任意进程。

## 用一句判断法锁定答案

遇到杂收模式类选择题，可以抓住一个判断标准。

普通模式按照本机 `MAC` 地址、广播地址和组播条件过滤帧。杂收模式取消或放宽目的地址过滤，将网络接口实际收到的全部帧交给捕获程序。因此，只有 **D，能够响应流经网络接口的所有分组** 符合题意。

**A** 描述的是目的 `MAC` 地址定向接收，**B** 只覆盖广播，**C** 只覆盖组播，三者的接收范围都小于杂收模式。

工程上还要补充一句边界，所谓所有分组，是接口实际收到的所有分组，不是整个网络中的所有分组。集线器会把流量复制到多个端口，交换机会依据 `MAC` 地址表定向转发。要在交换式网络中观察其他端口的已知单播流量，通常还需要 `SPAN`、端口镜像或网络分光设备。

所以，本题答案没有悬念，选择 **D**。杂收模式解决的是网卡收到帧以后不再因为目的 `MAC` 地址不匹配而丢弃的问题，它不能决定交换机是否把某个帧送到该网络接口，也不会自动突破加密、路由边界或无线信道限制。


杂收模式对应英文术语 Promiscuous Mode，也常被翻译为混杂模式。网卡进入这种模式后，不再只接收目的 MAC 地址与本机相符的以太网帧，而是把到达该网络接口、且网卡能够实际看到的各种帧交给操作系统或抓包程序。嗅探器正是利用这一机制获取原本并非发给本机的网络通信。

从网卡地址过滤到全帧捕获，彻底理解嗅探器的杂收模式

紫薇堂堂主

网络与通信

开发工具

安全

杂收模式指网卡取消目的MAC地址过滤，接收实际到达接口的所有帧，包括非本机单播、广播和组播。选项D正确描述此能力，但"所有"指物理到达帧，不含未送达流量。A、B、C分别限于定向、广播或组播，范围不完整。

入侵检测系统

路由器

大数据

防火墙

服务器

数据库

虚拟化

虚拟机

Windows

容器

路由

IPsec

Linux

DHCP

2026上云采购 | AI焕新·智启新局

nips

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从网卡地址过滤到全帧捕获，彻底理解嗅探器的杂收模式-腾讯云开发者社区-腾讯云

从网卡地址过滤到全帧捕获，彻底理解嗅探器的杂收模式

从网卡地址过滤到全帧捕获，彻底理解嗅探器的杂收模式

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐