JavaScript能在浏览器中直接获取MAC地址吗

一、为什么浏览器严密阻断前端读取 MAC 地址

MAC 地址（Media Access Control Address，介质访问控制地址）是烧录在物理网卡芯片（EEPROM）中的 48 位全局唯一硬件标识符。许多刚接触 Web 安全的开发者经常询问能否用几行 JavaScript 代码读取它，以作为设备绑定或防刷凭据。理解为何无法读取，需要从底层协议栈与安全设计两方面来看：

1. 网络协议层级阻断（二层与七层的鸿沟）：网页端 JavaScript 运行在 OSI 模型的应用层（Layer 7），其网络通信依托于 HTTP/HTTPS 或 WebSocket 协议。当网卡接收到数据后，操作系统内核驱动在数据链路层（Layer 2）就会验证并剥离以太网帧头中的 MAC 信息，向上仅交付 IP 数据报与 TCP 报文。浏览器本身并不会保存收发数据包的二层帧头，更没有权限穿透内核去读取物理网卡芯片。
2. 全网用户隐私与防追踪（Anti-Tracking）：MAC 地址具有硬件级唯一性和不可轻易更改性。如果网页脚本能够随时静默读取 MAC 地址，广告追踪商、恶意网站便能对用户实施跨站点、跨浏览器、跨隐私模式的“终身设备指纹追踪”，这直接摧毁了 Web 的隐私保护底线。
3. 多网卡与虚拟网卡的歧义性：现代 PC 或移动设备往往同时拥有多个网络适配器，包括有线以太网卡、Wi-Fi 网卡、蓝牙网络、LTE/5G 调制解调器，以及由 Docker、VPN 或虚拟机创建的数个虚拟网卡。即便开放硬件读取，单一的“当前 MAC”概念在多宿主环境下本身就缺乏确定性。

二、历史方案的回顾与淘汰（为什么旧代码不能用了）

部分开发者在搜索资料时，可能会发现一些声称“通过几行 JS 代码就能获取 MAC 地址”的历史片段。必须明确指出，这些代码均属于已被历史淘汰的陈旧技术，在如今的通用 Web 环境中均已失效：

1. 微软 IE 浏览器的 ActiveXObject 脚本（已彻底失效）

在二十年前的 Windows XP 与早期的 Internet Explorer 时代，开发者可以通过微软专有的 ActiveX 控件调用 Windows Management Instrumentation (WMI) 接口读取系统网卡信息：

// 仅供历史机制原理说明，现代浏览器均已彻底废弃不支持
try {
    var locator = new ActiveXObject("WbemScripting.SWbemLocator");
    var service = locator.ConnectServer(".");
    var properties = service.ExecQuery("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE IPEnabled = True");
    var e = new Enumerator(properties);
    for (; !e.atEnd(); e.moveNext()) {
        var p = e.item();
        console.log("MAC Address: " + p.MACAddress);
    }
} catch (err) {
    console.error("ActiveX 仅在老旧 IE 且手动调低安全区域时生效，现代浏览器中抛出 ReferenceError");
}

该方案存在极其严峻的安全漏洞，允许网页任意执行宿主命令。随着微软在 2022 年彻底终止支持 Internet Explorer、Edge 浏览器转用 Chromium 内核，ActiveX 技术已退出历史舞台。任何非 IE 内核的现代浏览器都会在第一行抛出 ActiveXObject is not defined 异常。

2. NPAPI 插件体系（Flash / Java Applet / Silverlight）

早年间一些银行 OA 系统采用签名的 Java Applet 或 NPAPI 插件，向用户申请本地桌面特权后获取硬件信息。随着 Chrome 在 45 版本、Firefox 在 52 版本完全移除 NPAPI 支持，Flash 也在全球范围内停服，基于第三方浏览器插件嗅探硬件的途径已完全被封死。

3. WebRTC“泄露硬件”的常见误解

有些网帖误传“WebRTC 可以探测真实 MAC 地址”，这是对 WebRTC 机制的误读。WebRTC 在建立 P2P 连接（ICE 协商）时，确实可能会在 SDP 报文中包含本机的局域网私有 IP 地址（如 192.168.1.100），但绝对不会泄露网卡 MAC 地址。此外，现代浏览器（Chrome、Safari 等）早已全面推行 mDNS（多播 DNS）匿名化机制，将本地内网 IP 替换为形如 xxxx.local 的随机 UUID，连局域网 IP 也无法直接探测。

三、企业内网场景下获取 MAC 地址的工程解决方案

虽然标准公网网页无法获取 MAC 地址，但在某些特定业务中（例如银行柜员系统、政企内网准入、军工办公网、机房监控），确实存在基于硬件地址进行设备准入审计的硬性合规要求。在拥有终端管理权限的前提下，行业内通常采用以下三种工程实践方案：

方案一：部署本地中继守护服务（Localhost Daemon / Agent）

这是目前政企系统与高安全 Web 平台最通用的方案。管理员在用户工作站上预先安装一个轻量级的受信任原生守护进程（可由 Go、C#、C++ 或 Rust 编写），该程序开机自启并在本地回环地址（127.0.0.1）开启监听服务。

// 前端向本地受信任代理服务获取经过防篡改签名的设备硬件报文
async function requestDeviceHardwareCredential() {
    const challengeNonce = crypto.randomUUID();
    try {
        const response = await fetch("http://127.0.0.1:18080/v1/hardware-info", {
            method: "POST",
            headers: {
                "Content-Type": "application/json",
                "X-Requested-With": "EnterprisePortal"
            },
            body: JSON.stringify({ nonce: challengeNonce })
        });

        if (!response.ok) {
            throw new Error("本地硬件中继服务响应异常: " + response.status);
        }

        const data = await response.json();
        // 示例响应结构: { mac: "00:1A:2B:3C:4D:5E", nonce: "...", signature: "..." }
        console.log("成功读取并验签硬件参数：", data.mac);
        return data;
    } catch (error) {
        console.warn("未能连接至终端本地安全组件，请确认驱动程序已安装并运行。", error);
        throw error;
    }
}

方案二：将 Web 页面打包为桌面客户端（Electron / Tauri）

如果业务系统允许以桌面应用的形式交付，可以使用 Electron 或 Tauri 将网页包装为独立客户端。在这些桌面框架中，主进程运行在拥有完整操作系统权限的原生环境（Node.js 或 Rust）中，可以无限制地调用系统底层 API 查询网卡物理地址，再通过进程间通信（IPC）机制无缝传递给前端渲染层。

// 在 Electron 的主进程 (main.js) 中提取物理网卡真实 MAC
const os = require('os');

function getPrimaryPhysicalMacAddress() {
    const networkInterfaces = os.networkInterfaces();
    
    for (const interfaceName in networkInterfaces) {
        const interfaces = networkInterfaces[interfaceName];
        for (const iface of interfaces) {
            // 过滤回环地址与虚拟网卡
            if (!iface.internal && iface.mac && iface.mac !== '00:00:00:00:00:00') {
                // 筛选实际活跃的物理网络接口
                return iface.mac.toUpperCase();
            }
        }
    }
    return null;
}

// 通过 IPC 主进程通道将结果传递至前端渲染页面
const { ipcMain } = require('electron');
ipcMain.handle('get-device-mac', async () => {
    return getPrimaryPhysicalMacAddress();
});

方案三：网络层网关联动（基于 ARP 表与 802.1X 准入）

在企业园区网络中，还有一种对客户端最友好的方案：无需前端 JS 或本地安装任何程序。终端连接企业交换机或网关路由器时，数据链路层必然会通过 ARP 协议与网关通信。路由器和核心交换机本身维护着内网 IP 与物理 MAC 的映射表。通过在网络出口部署 802.1X 认证系统或 Web 认证门户（Captive Portal），由网关在网络层提取客户端真实 MAC 地址，并在反向代理中以 HTTP Header（如 X-Client-MAC）的形式直接透传给后端业务服务器。

四、公网环境下无需 MAC 的合规替代技术

对于绝大多数公网 Web 开发者而言，试图获取 MAC 地址往往是因为“需要唯一标识一台终端设备，用于防刷、风控、多账号识别或设备锁”。在现代 Web 标准下，完全有更加优雅合规、不侵犯隐私的成熟方案：

五、常见认知误区与排查清单

在实际开发和需求沟通中，经常会遇到产品经理或安全审计人员提出不切实际的要求。开发团队可以根据以下清单进行技术对齐与排查：

• 误区一：把 IP 地址当成硬件凭证。用户公网 IP 是动态由运营商分配的，可能随时变动，多个用户在 NAT 局域网下对外表现为同一公网 IP，切勿使用 IP 单独作为设备唯一标识。
• 误区二：轻信 npm 上所谓的“免插件读取 MAC 库”。凡是在前端浏览器中引入的任何 JavaScript 库，其运行权限严格受限于浏览器沙箱。如果某个库声称无需用户授权或后台服务就能直接读取 MAC，该库要么仅能在 Node.js 服务端运行，要么是挂羊头卖狗肉的虚假实现。
• 误区三：认为 MAC 地址绝对不可伪造。在数据链路层，网卡的 MAC 地址在操作系统驱动层面是可以被用户随意修改（MAC Spoofing）的。在安全风控设计中，即便在桌面端获取到了 MAC，也必须配合非对称签名与时间戳挑战，切勿将明文 MAC 作为系统唯一安全信源。