简而言之，答案是否定的，您通常不能根据 MA​​C 地址进行屏蔽。如果可以，那将毫无用处。要了解原因，您必须对互联网的运作方式有所了解。

设备之间的通信通常通过以太网协议 (wiki)完成，尽管源和目标由 IP 标识，但实际通信是按 MAC 完成的。想象以下网络：

如果客户端要向服务器发送数据包，它首先检查服务器是否在同一个子网中。不，服务器有一个 10.x IP，客户端有一个 192.168.x IP。然后客户端将它发送到他们的路由器 R1，希望它能够将它转发到目的地。数据包包含：

Source IP:       192.168.1.100     (belongs to: Client)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      01:01:01:02:02:02 (belongs to: Client)
Destination MAC: 02:01:01:02:02:02 (belongs to: R1)

然后R1就像“哦，那个IP在互联网上的某个地方”。它将源 IP 更改为公共 IP（以便服务器可以发回数据包），并将其转发给 R2。该数据包现在包含：

Source IP:       172.16.1.1        (public IP from R1)
Destination IP:  10.1.1.1          (belongs to: Server)
Source MAC:      02:01:01:02:02:02 (belongs to: R1)
Destination MAC: 03:01:01:02:02:02 (belongs to: R2)

如您所见，目标 IP 没有改变，但 MAC 地址在每次被转发（由路由器）时都会根据它被转发到哪个路由器以及它来自哪个路由器而改变。

展望未来，R2不会像以前那样篡改任何 IP R1，因为它不是 NAT 路由器（就像大多数消费者拥有的那样）。R2只会转发数据包。

最后，服务器将只能看到来自 R3 的 MAC 地址。为了使通信正常工作，除了来自R1. （当回复数据包返回时R1，其他事情会确保数据包找到到达客户端的方式。）如果您想知道为什么不是所有通信都简单地基于 MAC，请查看serverfault 上的这个问题。

一个例外是客户端与服务器位于同一 LAN 内。正如我所提到的，客户端首先将自己的 IP 子网与目标进行比较。如果相同（例如 192.168.1.101 和 192.168.1.44，在 /24 子网上时），则通信基于 MAC 地址。客户端将在 LAN 上广播一条消息，请求属于服务器 IP 的 MAC，然后将其发送到该 MAC。数据包仍将包含目标 IP，但两者之间没有路由器。（可能有，但它会充当交换机或集线器，而不是路由器。）但这可能不是您想到的场景。

如果你能确定 MAC，那将是一个相当大的隐私侵犯。由于您的 MAC 地址可以在全球范围内唯一标识您，因此广告网络可以毫无问题地跟踪您，也无需跟踪 cookie 或任何其他方法。

通过 MAC 阻止攻击者与通过 cookie 阻止攻击者相同，因为它是由客户端控制的。目前它几乎从未改变，因为几乎没有理由改变，但如果你可以通过 MAC 确定并阻止攻击者，他们可以简单地改变它。IP 地址必须被全球识别才能路由，但 MAC 没有这个问题。

此外，攻击者可以通过欺骗 MAC 地址然后触发阻止来阻止他们知道其 MAC 的客户端。真正使用该 MAC 地址的人将被禁止使用该服务。

结论：如果可能的话，这将是相当无效的，并且会引入 DoS 漏洞，但是由于您不能让客户端将 MAC 与 HTTP 标头或其他东西一起发送，因此在同一个 LAN 之外是不可能的。

不，原始发送者的 MAC 地址（实际客户端，而不是最后一跳）不包含在任何网络数据包标头中。不过，您可能需要检查：https ://panopticlick.eff.org/

源 MAC 地址（第 2 层）只会显示最后一个转发数据包的路由器。

我不确定这个问题指的是什么 - 在 Web 服务器上阻止 HTTP 请求？过滤对wifi点的访问？防火墙和路由？

但不管你是否可以基于 MAC 地址进行阻止，一个更好的问题是你是否应该阻止。
简单的答案是：不。

简而言之，MAC 地址很容易被更改和/或欺骗，并且完全由最终用户控制（好吧，几乎完全）。因此，尝试基于此实现任何类型的控制都是没有意义的。