检测浏览器相关安全防护是否开启开启失败

打开浏览器控制台，检测输入 navigator.webdriver，浏览回车。器相全防返回 true，关安说明你被标记为自动化工具；返回 false 或 undefined，护否则一切正常。开启开启这个小小的失败属性，就是检测检测浏览器安全防护是否开启的入门钥匙。

但真正的浏览检测远不止这一行代码。我上周调试一个爬虫脚本时，器相全防明明设置了完整的关安请求头、随机 User-Agent、护否甚至模拟了鼠标轨迹，开启开启对方网站依然在第三次请求时把我拦了下来。失败排查了半天，检测问题出在 window.chrome 对象——真实 Chrome 浏览器里它应该存在且包含多个子对象，而我的脚本环境里它是个空壳。这种指纹层面的差异，靠肉眼根本看不出来。

更隐蔽的是权限 API 的状态。你可以在地址栏输入 chrome://settings/content/notifications 查看通知权限，但真正检测防护是否开启，要看 navigator.permissions.query({ name:'notifications'}) 的返回状态。正常浏览器会返回 prompt，表示用户尚未做出选择；如果返回 denied，说明浏览器自动拒绝了所有通知请求——这往往是某些安全插件干的好事。同理，geolocation、camera、microphone 这些权限的状态，都能反映防护策略的松紧。

还有个容易被忽略的检测点：navigator.plugins 数组。老版本 Chrome 里至少有 5 个插件条目（PDF 查看器、Flash 占位符等），而新版 Edge 或 Firefox 各有不同。如果你发现这个数组是空的，或者长度异常，基本可以断定浏览器做了手脚。我见过一个极端的例子——某安全软件把所有插件全部隐藏，结果导致视频网站无法播放 DRM 内容，用户还以为是网速问题。

说到失败，最常见的场景是用户手动关闭了防护功能。比如 Windows 的 SmartScreen 过滤器，它通过云查杀拦截恶意下载。你可以在 设置 → 隐私和安全性 → Windows 安全中心 里看到它的状态。但有些企业版系统会通过组策略强制关闭，这时候你即便在设置界面看到“已开启”，实际运行中它根本不生效。检测方法很简单：下载一个测试用的 EICAR 文件（无害的病毒模拟样本），如果浏览器直接放行，说明防护形同虚设。

移动端的情况更复杂。Android 的 Chrome 会检查 SafetyNet 认证，但某些厂商 ROM 会篡改系统签名导致认证失败。你可以在 chrome://net-internals 里查看 SSL 证书验证日志，如果频繁出现 CERT_VERIFY_FAILED，大概率是系统级代理或防火墙在捣乱。

最后说个实用技巧：想快速判断防护是否全面开启，直接在控制台运行 navigator.deviceMemory。正常浏览器会返回 0.5 到 8 之间的数字，如果返回 undefined 或 0，说明浏览器禁用了硬件信息接口——这通常是隐私保护插件所为。但注意，这个值也能被伪造，所以它只能作为参考，而非唯一依据。

防护检测的本质就是一场猫鼠游戏。你越是想隐藏自己的行为，越容易露出马脚。与其追求完美的隐身，不如学会阅读浏览器暴露的每一个信号。