哪些浏览器扩展会破坏 Anubis 挑战页面以 JShelter 为例的排查与解决指南【免费下载链接】anubisWeighs the soul of incoming HTTP requests to stop AI crawlers项目地址: https://gitcode.com/gh_mirrors/anubis4/anubis本文面向部署或使用 Anubis以工作量证明机制拦截 AI 爬虫的 HTTP 反向代理的用户与运维人员系统梳理当前仓库文档中记录的、已知会破坏 Anubis 客户端代码的浏览器扩展——JShelter说明其破坏原理、故障症状并给出三种可操作的规避方案。读完本文你将能在自己的浏览器中快速诊断扩展导致的验证卡死问题并依据操作安全模型选择最合适的设置方案。背景挑战页面为何依赖浏览器扩展高抬贵手Anubis 的挑战机制与传统的验证码不同它不要求用户输入任何内容而是完全依赖浏览器内置的 JavaScript 能力自动完成工作量证明Proof of Work计算。这一点在仓库的 frequently-asked-questions.mdx 中有明确说明——为了让保护机制有效Anubis 不能给出类似恶意软件请把这段代码粘贴到运行框里的指引挑战必须通过 JavaScript 自动完成全程无需用户干预。因此任何过度干预 JavaScript 执行、Web Workers、网络请求或 DOM 的浏览器扩展都可能让挑战页面无法正常运转。仓库文档 known-broken-extensions.md 目前记录的、已知会破坏 Anubis 客户端代码的扩展是JShelter一个以指纹混淆与 JavaScript 防护为主的浏览器安全扩展其余扩展尚待社区持续补充。JShelter 为什么会卡住 AnubisWeb Workers 是核心矛盾JShelter 对 Anubis 的破坏并非偶然根源在于 Anubis 的挑战计算重度依赖Web Workers API。从源码看挑战页面启动时会先做依赖检查在 main.ts 中页面依次校验window.Worker与navigator.cookieEnabled一旦 Web Workers 不可用页面会直接切换到缺少功能missing_feature错误状态并显示拒绝提示根本不会开始计算。而 JShelter 默认会对站点开启JavaScript Shield防护其中包含对 Web Worker 的干预能力。JShelter 官方 FAQ 将 Web Workers 列为需要警惕的安全威胁理由是 Worker 中的代码脱离主线程运行、可能成为恶意脚本的隐蔽执行场所。当 JShelter 的 WebWorker 保护生效时Anubis 的挑战逻辑将出现以下典型故障链路挑战页面尝试通过 Worker 加载并运行工作量证明计算脚本如 sha256.ts 所示的 SHA-256 求解循环Worker 被扩展拦截、终止或篡改无法正常产出结果页面停留在计算中calculating状态进度条不再推进更严重时Worker 直接死亡。仓库的 worker.ts 实现了完整的 Worker 看护逻辑当所有 Worker 在产生任何输出前就死亡时会输出所有工作量证明 Worker 在运行时失败all proof of work workers failed at runtime并抛出错误页面随即转入错误提示。需要说明的是Anubis 并非可以简单绕开 Worker——从 frequently-asked-questions.mdx 可知Anubis 使用 Web Workers 有两个硬性原因其一挑战逻辑包含大量阻塞性数学运算在主线程执行会导致浏览器界面卡死、无法响应用户输入放入 Worker 可保持主线程流畅其二Worker 支持多线程并行使挑战计算能够横跨系统全部 CPU 核心并行执行从而尽可能快地完成挑战。也就是说Worker 既是性能需要也是无人值守自动过关这一设计目标的技术前提。故障症状如何确认是扩展在捣乱当访问被 Anubis 保护的站点时如果出现以下现象应优先怀疑 JShelter 等安全扩展挑战页面长时间停留在计算中/加载中进度条几乎不动或反复回退页面直接显示缺少 Web Workersweb_workers_error之类的报错文案浏览器控制台出现anubis: proof of work worker died或anubis: all proof of work workers failed at runtime等警告见 worker.ts 中的看护逻辑在无痕窗口未加载扩展中同一站点可正常通过挑战——这是排查扩展干扰最直接的对照实验。需要注意的是即使主脚本main.mjs加载成功Worker 层面的阻断依然会让挑战失败。仓库在 bootstrap.ts 中实现了对主脚本加载失败的看门狗与带抖动指数退避的自动重注入机制但这类机制解决的是脚本资源加载问题无法挽救被扩展拦截的 Worker。因此正确关闭对 Worker 的干预是让挑战跑通的必要前提。解决方案一针对单个站点关闭 WebWorker 保护这是影响面最小、最推荐的方案只对当前访问的站点生效点击浏览器工具栏上的JShelter 徽章图标点击Modify修改按钮展开JavaScript Shield设置点击Detail tweaks of JS shield for this site此站点的 JS 盾牌详细调整按钮找到WebWorker滑块向左拖动直到显示Unprotected不受保护刷新页面重新完成挑战。解决方案二针对单个站点关闭整个 JavaScript Shield如果方案一的细粒度调整不够用或找不到对应项可以直接关闭该站点的整个 JavaScript Shield点击 JShelter 徽章图标点击Modify按钮展开 JavaScript Shield 设置选择 Turn JavaScript Shield off关闭 JavaScript Shield刷新页面。:::note 安全提示 上述两种操作会移除该访问站点所有页面上的 JavaScript Shield 全部防护影响面超出 Anubis 本身。请结合自身的操作安全OpSec模型在通过挑战后重新审视并调整该站点的 JS 防护设置。 :::解决方案三在 JShelter 设置中为域名添加豁免列表如果你希望更持久、更精确地管理受保护站点可在 JShelter 的设置界面中维护豁免名单打开JShelter 扩展设置点击JS Shield detailsJS 盾牌详情输入一个由 Anubis 保护的网站域名选择 Turn JavaScript Shield off点击 Add to list添加到列表保存。之后访问该域名时将自动跳过 JavaScript Shield 的干预无需每次手动调整。:::note 安全提示 与方案二同理将该域名加入关闭列表后该站点所有页面的 JavaScript Shield 防护都将失效。请评估该站点是否值得承担这一防护豁免并在威胁模型变化时及时更新列表。 :::延伸排查与扩展无关的同类症状如果关闭 JShelter 后挑战仍然缓慢或失败还可以参考 frequently-asked-questions.mdx 中记录的两类常见诱因关闭了浏览器 JIT 编译Anubis 的挑战在紧凑循环中执行大量数学运算JIT 编译能将其加速到接近原生执行的水准关闭 JIT 后所有 JavaScript 都退回慢速解释器挑战会显著变慢。若出于安全加固而关闭了 JIT请注意禁用让 Anubis 变快的浏览器特性也会让 Anubis 变慢此时重新启用 JIT 是最直接的解决办法。浏览器版本过旧文档确认 Anubis 至少支持 Chrome/Chromium 75、Firefox 120、Safari 10、Pale Moon 33且优先针对这些浏览器进行开发。过旧的浏览器可能在 Worker、WASM 等能力上不达标建议升级后再试。若以上手段均无法解决且排除了扩展因素可按 FAQ 的建议提交包含操作系统、浏览器与硬件型号信息的 Bug 报告帮助项目组定位兼容性问题。小结目前仓库文档确认的、会破坏 Anubis 挑战的浏览器扩展为JShelter其核心冲突点是 JShelter 对Web Workers的干预三种官方给出的规避方案均可落地单站关闭 WebWorker 保护影响最小、单站关闭整个 JavaScript Shield、在设置中按域名维护豁免列表每种方案都会降低该站点上 JavaScript Shield 的防护强度请务必结合自身安全模型权衡后再操作若关闭扩展后问题依旧请从浏览器 JIT 状态与版本兼容性两个方向继续排查见 frequently-asked-questions.mdx并可参考 known-broken-extensions.md 关注后续新增的已知问题扩展清单。【免费下载链接】anubisWeighs the soul of incoming HTTP requests to stop AI crawlers项目地址: https://gitcode.com/gh_mirrors/anubis4/anubis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 哪些浏览器扩展会破坏 Anubis 挑战页面：以 JShelter 为例的排查与解决指南
哪些浏览器扩展会破坏 Anubis 挑战页面以 JShelter 为例的排查与解决指南【免费下载链接】anubisWeighs the soul of incoming HTTP requests to stop AI crawlers项目地址: https://gitcode.com/gh_mirrors/anubis4/anubis本文面向部署或使用 Anubis以工作量证明机制拦截 AI 爬虫的 HTTP 反向代理的用户与运维人员系统梳理当前仓库文档中记录的、已知会破坏 Anubis 客户端代码的浏览器扩展——JShelter说明其破坏原理、故障症状并给出三种可操作的规避方案。读完本文你将能在自己的浏览器中快速诊断扩展导致的验证卡死问题并依据操作安全模型选择最合适的设置方案。背景挑战页面为何依赖浏览器扩展高抬贵手Anubis 的挑战机制与传统的验证码不同它不要求用户输入任何内容而是完全依赖浏览器内置的 JavaScript 能力自动完成工作量证明Proof of Work计算。这一点在仓库的 frequently-asked-questions.mdx 中有明确说明——为了让保护机制有效Anubis 不能给出类似恶意软件请把这段代码粘贴到运行框里的指引挑战必须通过 JavaScript 自动完成全程无需用户干预。因此任何过度干预 JavaScript 执行、Web Workers、网络请求或 DOM 的浏览器扩展都可能让挑战页面无法正常运转。仓库文档 known-broken-extensions.md 目前记录的、已知会破坏 Anubis 客户端代码的扩展是JShelter一个以指纹混淆与 JavaScript 防护为主的浏览器安全扩展其余扩展尚待社区持续补充。JShelter 为什么会卡住 AnubisWeb Workers 是核心矛盾JShelter 对 Anubis 的破坏并非偶然根源在于 Anubis 的挑战计算重度依赖Web Workers API。从源码看挑战页面启动时会先做依赖检查在 main.ts 中页面依次校验window.Worker与navigator.cookieEnabled一旦 Web Workers 不可用页面会直接切换到缺少功能missing_feature错误状态并显示拒绝提示根本不会开始计算。而 JShelter 默认会对站点开启JavaScript Shield防护其中包含对 Web Worker 的干预能力。JShelter 官方 FAQ 将 Web Workers 列为需要警惕的安全威胁理由是 Worker 中的代码脱离主线程运行、可能成为恶意脚本的隐蔽执行场所。当 JShelter 的 WebWorker 保护生效时Anubis 的挑战逻辑将出现以下典型故障链路挑战页面尝试通过 Worker 加载并运行工作量证明计算脚本如 sha256.ts 所示的 SHA-256 求解循环Worker 被扩展拦截、终止或篡改无法正常产出结果页面停留在计算中calculating状态进度条不再推进更严重时Worker 直接死亡。仓库的 worker.ts 实现了完整的 Worker 看护逻辑当所有 Worker 在产生任何输出前就死亡时会输出所有工作量证明 Worker 在运行时失败all proof of work workers failed at runtime并抛出错误页面随即转入错误提示。需要说明的是Anubis 并非可以简单绕开 Worker——从 frequently-asked-questions.mdx 可知Anubis 使用 Web Workers 有两个硬性原因其一挑战逻辑包含大量阻塞性数学运算在主线程执行会导致浏览器界面卡死、无法响应用户输入放入 Worker 可保持主线程流畅其二Worker 支持多线程并行使挑战计算能够横跨系统全部 CPU 核心并行执行从而尽可能快地完成挑战。也就是说Worker 既是性能需要也是无人值守自动过关这一设计目标的技术前提。故障症状如何确认是扩展在捣乱当访问被 Anubis 保护的站点时如果出现以下现象应优先怀疑 JShelter 等安全扩展挑战页面长时间停留在计算中/加载中进度条几乎不动或反复回退页面直接显示缺少 Web Workersweb_workers_error之类的报错文案浏览器控制台出现anubis: proof of work worker died或anubis: all proof of work workers failed at runtime等警告见 worker.ts 中的看护逻辑在无痕窗口未加载扩展中同一站点可正常通过挑战——这是排查扩展干扰最直接的对照实验。需要注意的是即使主脚本main.mjs加载成功Worker 层面的阻断依然会让挑战失败。仓库在 bootstrap.ts 中实现了对主脚本加载失败的看门狗与带抖动指数退避的自动重注入机制但这类机制解决的是脚本资源加载问题无法挽救被扩展拦截的 Worker。因此正确关闭对 Worker 的干预是让挑战跑通的必要前提。解决方案一针对单个站点关闭 WebWorker 保护这是影响面最小、最推荐的方案只对当前访问的站点生效点击浏览器工具栏上的JShelter 徽章图标点击Modify修改按钮展开JavaScript Shield设置点击Detail tweaks of JS shield for this site此站点的 JS 盾牌详细调整按钮找到WebWorker滑块向左拖动直到显示Unprotected不受保护刷新页面重新完成挑战。解决方案二针对单个站点关闭整个 JavaScript Shield如果方案一的细粒度调整不够用或找不到对应项可以直接关闭该站点的整个 JavaScript Shield点击 JShelter 徽章图标点击Modify按钮展开 JavaScript Shield 设置选择 Turn JavaScript Shield off关闭 JavaScript Shield刷新页面。:::note 安全提示 上述两种操作会移除该访问站点所有页面上的 JavaScript Shield 全部防护影响面超出 Anubis 本身。请结合自身的操作安全OpSec模型在通过挑战后重新审视并调整该站点的 JS 防护设置。 :::解决方案三在 JShelter 设置中为域名添加豁免列表如果你希望更持久、更精确地管理受保护站点可在 JShelter 的设置界面中维护豁免名单打开JShelter 扩展设置点击JS Shield detailsJS 盾牌详情输入一个由 Anubis 保护的网站域名选择 Turn JavaScript Shield off点击 Add to list添加到列表保存。之后访问该域名时将自动跳过 JavaScript Shield 的干预无需每次手动调整。:::note 安全提示 与方案二同理将该域名加入关闭列表后该站点所有页面的 JavaScript Shield 防护都将失效。请评估该站点是否值得承担这一防护豁免并在威胁模型变化时及时更新列表。 :::延伸排查与扩展无关的同类症状如果关闭 JShelter 后挑战仍然缓慢或失败还可以参考 frequently-asked-questions.mdx 中记录的两类常见诱因关闭了浏览器 JIT 编译Anubis 的挑战在紧凑循环中执行大量数学运算JIT 编译能将其加速到接近原生执行的水准关闭 JIT 后所有 JavaScript 都退回慢速解释器挑战会显著变慢。若出于安全加固而关闭了 JIT请注意禁用让 Anubis 变快的浏览器特性也会让 Anubis 变慢此时重新启用 JIT 是最直接的解决办法。浏览器版本过旧文档确认 Anubis 至少支持 Chrome/Chromium 75、Firefox 120、Safari 10、Pale Moon 33且优先针对这些浏览器进行开发。过旧的浏览器可能在 Worker、WASM 等能力上不达标建议升级后再试。若以上手段均无法解决且排除了扩展因素可按 FAQ 的建议提交包含操作系统、浏览器与硬件型号信息的 Bug 报告帮助项目组定位兼容性问题。小结目前仓库文档确认的、会破坏 Anubis 挑战的浏览器扩展为JShelter其核心冲突点是 JShelter 对Web Workers的干预三种官方给出的规避方案均可落地单站关闭 WebWorker 保护影响最小、单站关闭整个 JavaScript Shield、在设置中按域名维护豁免列表每种方案都会降低该站点上 JavaScript Shield 的防护强度请务必结合自身安全模型权衡后再操作若关闭扩展后问题依旧请从浏览器 JIT 状态与版本兼容性两个方向继续排查见 frequently-asked-questions.mdx并可参考 known-broken-extensions.md 关注后续新增的已知问题扩展清单。【免费下载链接】anubisWeighs the soul of incoming HTTP requests to stop AI crawlers项目地址: https://gitcode.com/gh_mirrors/anubis4/anubis创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考