怎么通过组策略关闭Chrome自动更新并锁定版本？

为什么必须“锁版本”——运营者的真实痛点

2026 年 4 月 Chrome 136 强制启用 Manifest V4，大量内部审计插件瞬间失效；若你的 300 台业务终端在周一早晨集体升级，等待你的不是“新功能”，而是工单爆炸。通过组策略关闭 Chrome 自动更新并锁定版本，是 Windows 域环境下唯一可复现、可回退、可审计的批量方案。

功能边界：组策略能管到哪一层

组策略（Group Policy）只能影响Windows 版 Chrome；macOS、Linux 需用 JSON 策略文件或打包管理器，移动端则完全不在讨论范围。策略生效后，用户侧仍能手动下载独立安装包覆盖，但会被下一次组策略刷新（默认 90 分钟）强行回滚，因此“锁”的是自动更新通道，而不是用户意志。

前置条件：下载并导入最新管理模板

1. 访问 https://support.google.com/chrome/a/answer/187202，下载 Google Update ADMX 与 Chrome ADMX 两个包。
2. 复制 .admx 到 \\域控\SYSVOL\domain\Policies\PolicyDefinitions，对应 .adml 放进 zh-CN 子目录。
3. 在 GPMC 中新建一条 GPO，命名为 Chrome-DisableUpdate，编辑即可看到“Google/Google Update”与“Google Chrome”两个节点。

最短可达路径：三步关闭更新

步骤 1 禁用 Google Update 自身

计算机配置 → 管理模板 → Google → Google Update → 应用 → Google Chrome → 更新策略覆盖 → 设置为“更新已禁用”。此条优先权最高，可阻断 Chrome 任何通道的更新请求。

步骤 2 指定允许的目标版本（可选但推荐）

同上路径，找到“目标版本覆盖”，填入你想锁定的完整四位版本号，例如 136.0.7100.86。留空则单纯禁用更新，不保证版本号恒定。

步骤 3 关闭后台定时任务与服务

计算机配置 → Windows 设置 → 安全设置 → 系统服务 → 找到 Google Update Service (gupdate) 与 Google Update Service (gupdatem)，启动模式设为“已禁用”。再转到“计划任务”节点，禁用 GoogleUpdateTaskMachine* 两项。

验证：如何确认策略已落地

在任意客户端打开 chrome://policy，若 UpdateDefault 显示 0 且状态为“OK”，说明已生效；再打开 chrome://version，对比“可更新版本”字段应提示 “更新已禁用 by your administrator”。经验性观察：策略刷新最长需 120 分钟，可运行 gpupdate /force 立即触发。

回退方案：快速恢复更新通道

将同一 GPO 中的“更新策略覆盖”改回“未配置”，并把服务启动模式设为“自动（延迟启动）”，下次组策略刷新后 Chrome 会重新加入更新队列。若需立即生效，可在 chrome://policy 点击“重新加载策略”，再手动启动 GoogleUpdate.exe /RegServer 完成注册。

副作用与取舍：锁版本不是银弹

• 0-day 风险：锁死后无法接收安全修复，经验性观察显示平均 45 天会出现一次被野外利用的高危漏洞。建议配套部署 EDR 或应用白名单。
• 兼容债：内部系统后续若强制要求新版 Chrome（如 WebUSB API 变更），需走紧急解锁流程，预留 2 周回归测试窗口。
• 合规审计：金融、医疗等行业需留存“版本锁定审批单”，否则等保/ISO 审查会被开不符合项。

离线安装包：如何与组策略配合

在锁定策略生效前，先用 Google 官方离线包（ChromeStandaloneEnterprise.msi）把目标版本装到基准镜像；MSI 安装器会尊重策略键值，不会后台偷偷升级。注意：离线包版本号必须与“目标版本覆盖”字段完全一致，否则 Chrome 首次启动会提示“无法更新到指定版本”，陷入无限重试。

常见分支：用户手动安装“双版本”怎么办

若用户拥有本地管理员权限，可再装一套“用户级”Chrome（安装在 %LOCALAPPDATA%\Google\Chrome），该副本不受机器级策略管辖。缓解办法：通过 AppLocker 或 WDAC 禁止执行 chrome.exe 未签名副本，同时把 Google Update 用户级计划任务也禁用（路径见 HKCU\Software\Google\Update）。

与 WSUS/SCCM 的协同

若公司已禁用外网，WSUS 不会同步 Chrome 更新（Google 不在 Microsoft 更新目录内）。此时可把 ChromeStandaloneEnterprise.msi 导入 SCCM，创建“必需”应用程序，版本号升序排列，组策略解锁后一次性推送，实现“可管控的升级窗口”。

适用/不适用场景清单

场景	是否推荐锁版本	理由
呼叫中心固定 Web 应用	✅ 推荐	应用仅支持 Blink 136，升级即瘫痪
研发开放环境	❌ 不推荐	需第一时间验证新 API，锁版本阻碍迭代
零售门店 POS 终端	✅ 推荐	终端数量大、业务窗口短，稳定性优先
远程办公 BYOD	❌ 不推荐	设备不在域控，策略无法落地

故障排查速查表

现象：chrome:///policy 空白或提示“未设置任何策略”
可能原因：ADMX 未复制到中央存储；GPO 未链接到对应 OU；客户端为 Windows 10 Home，不支持组策略。
验证：运行 rsop.msc 查看结果集是否包含 Google 节点。
处置：确认中央存储路径权限；提升客户端至 Pro 版。

现象：策略已生效，但“关于 Chrome”仍显示“检查更新中”
可能原因：Google Update 服务被安全软件拦截；代理返回 403 导致更新程序反复重试。
验证：查看 C:\ProgramData\Google\Update\Log\GoogleUpdate.log 是否出现 error 0x80040811。
处置：把 GoogleUpdate.exe 加入杀软白名单；在策略中配置 “更新检查覆盖”=“已禁用”，彻底阻断流量。

最佳实践 10 条检查表

1. 锁定前，用 Chrome Release Notes 确认目标版本无已知高危 0-day。
2. 在测试 OU 先应用 24 小时，自动化回归通过再推到生产。
3. 把“目标版本覆盖”与“更新已禁用”写在同一条 GPO，避免策略优先级错乱。
4. 每季度评估一次解锁窗口，安排在月度补丁日之后。
5. 离线包统一放在 \\文件服务器\ChromeRepo，命名含版本号与 SHA-256，便于审计。
6. 开启 Windows 事件转发，收集 Google Update 来源 ID 700~900，异常升级可秒级告警。
7. 对远程分支门店，提前下发 Delivery Optimization 缓存，减少解锁后带宽冲击。
8. 禁止本地管理员，防止双版本绕过；如必须给管理员，使用 AppLocker 补强。
9. 把策略键值写进 CMDB，解锁时同步更新，避免“幽灵策略”。
10. 每年至少一次灾难演练：解锁→升级→验证业务→重新锁定，全程计时并记录回滚点。

FAQ（结构化数据，便于搜索引擎抓取）

结语与下一步行动

通过组策略关闭 Chrome 自动更新并锁定版本，是 Windows 域环境下最可控、可审计、可回退的批量方案；但它把“安全债”从 Google 转移到你自己身上。读完本文，你可以：

• 立即在测试 OU 验证三步策略是否生效；
• 把离线包、SHA-256、回退流程写进变更单，等待季度窗口；
• 设置 EDR 与白名单，为锁死后的 0-day 空窗期买好保险。

下一步，打开 GPMC，新建一条 GPO，今晚就让 300 台终端先睡个“无升级”的安稳觉。