ungoogled-chromium 无限验证循环怎么办：WebGL 信息改动惹的祸与完整绕过指南

【免费下载链接】ungoogled-chromiumGoogle Chromium, sans integration with Google项目地址: https://gitcode.com/gh_mirrors/un/ungoogled-chromium

用 ungoogled-chromium 133.0.6943.141 打开一个带网站验证的页面，第一次校验刚过，页面就开始不停刷新，验证永远走不完。这个 WebGL 验证循环是该版本特有的坑，根源在浏览器自己的隐私改动上，而不是网络问题。

谁会被卡住：受影响版本与平台对照

先把范围划清楚：

• 出问题的是 133.0.6943.141，134 版本会调整默认行为；
• NixOS、Windows 等平台都复现过，属于跨系统问题；
• 换成原版 Chromium 或 Chrome 打开，同一站点毫无问题。

也就是说，如果你发现某站点在官方浏览器里能正常过验证，基本可以把矛头指向这个项目的 WebGL 信息处理。

幕后原因：WebGL 厂商信息为什么被"改口型"

ungoogled-chromium 的定位是剥离 Google 集成、收紧隐私。其中一处改动动了 WebGL：网页通过 getParameter(UNMASKED_VENDOR_WEBGL) 查询显卡厂商时，本来会返回 "NVIDIA Corporation" 这类具体厂商名，项目把它替换成了更通用的字符串，目的是别让用户被硬件指纹定位。

好比你填表时把具体型号报成"某品牌显卡"，本意是省事，结果被风控系统盯上了。这次改动来自提交 3c764bf，开发者做代码回溯后确认，验证循环正是跟着它出现的。

验证系统是怎么"识破"的：三条检测逻辑 🕵️

现代网站验证不是单看一个字段，而是交叉比对：

1. 空字符串：厂商字段返回为空，直接判异常；
2. 属性互不匹配：厂商串和其他 WebGL 参数对不上，等于承认"在伪装"；
3. 和真实硬件对不上：返回信息与实际硬件不符，同样亮红灯。

一个通用字符串在这三条面前基本没有存活空间，这就是验证永远走不完的原因。

从临时绕过到默认根治：三条路线

应急手段：临时禁用 WebGL

打开 chrome://flags/#disable-webgl 把 WebGL 关掉，验证循环立刻消失。代价是依赖 WebGL 的页面（3D 内容、部分视频播放）全部罢工，只能当权宜之计。

折中方案：返回值换成单个空格

测试里挖到一个细节：把返回值设成单个空格 " "，既过得掉视频平台的检测，又不会触发验证失败——空格"不算空、也不像假的"，恰好卡在两条红线之间。其他备选字符串也在评估中。

134 版本默认行为变更：改为"选择加入"

134 里这项行为翻转为 opt-in：默认和官方 Chromium 使用同一套 WebGL 字符串，开箱即用不再卡验证；想保护隐私的用户可以手动打开新配置，自行选择屏蔽方式（相关改动见 add-flag-to-spoof-webgl-renderer-info.patch）。隐私保护没有取消，只是把开关交还给用户。

行动清单：你现在就能做的三件事

1. 最稳：等 134 更新，默认行为恢复后问题自动消失；
2. 等不及：临时禁用 WebGL 应急，更新后记得改回来；
3. 别乱动：不清楚风险的 WebGL 相关标志，不要自行修改。

给开发者的提示：写隐私补丁时把"多参数交叉校验"纳入测试用例——单看一个字段合理的字符串，往往过不了验证系统的组合拳。

延伸思考：平衡点还没定死 🧭

Google 也在逐步淘汰部分渲染实现，基于特定渲染器的处理办法，未来可能自己先失效。隐私和兼容从来不是单选题，把开关还给用户，是这次 WebGL 验证循环给出的务实答案。

【免费下载链接】ungoogled-chromiumGoogle Chromium, sans integration with Google项目地址: https://gitcode.com/gh_mirrors/un/ungoogled-chromium