我完全理解这种情况有多闹心——明明已经在Google Workspace Admin里禁用了Chrome的内置DNS和DoH，而且是全局最高优先级的配置，结果还是有员工遇到Chrome绕开私有DNS、把内网站点跳转到公网页面的问题。结合我在企业环境里的实操经验，给你几个能彻底锁死Chrome DNS路由的方案：

一、先确认Workspace Admin的策略是否真的完全生效 #

有时候看似设置了全局策略，却可能因为同步延迟或者配置细节不到位没起作用：

• 先检查策略应用范围：确认出问题的用户/设备所属的组织单元（OU）没有被排除在全局策略之外，也没有更低层级的OU设置了DNS相关的覆盖策略。
• 细化DoH和内置DNS的配置：不要只停留在“禁用”开关，在「Devices/Chrome/Settings/Users & Browsers」里找到「DNS over HTTPS mode」，强制设置为Disabled；同时把「Allow Chrome to use built-in DNS client」也设为Disabled，确保Chrome完全依赖系统的私有DNS设置。
• 验证策略同步：让出现问题的员工打开chrome://policy页面，搜索DNS相关的策略（比如DnsOverHttpsMode、BuiltInDnsClientEnabled），确认这些策略的状态是「强制」，而不是「未设置」或「用户可控」。

二、用组策略/MDM补充本地层面的强制锁（针对Windows/macOS/Linux） #

如果是域管理的设备，仅靠Workspace的云策略可能不够，需要结合本地组策略加固：

• Windows环境：打开组策略编辑器，定位到「计算机配置>管理模板>Google>Google Chrome>网络>DNS」，把以下两项都设为「已禁用」：
  • Enable DNS over HTTPS
  • Allow Chrome to use built-in DNS client
• macOS/Linux环境：可以通过配置Chrome的偏好文件或者MDM推送自定义配置，强制禁用Chrome的自有DNS功能，确保它完全遵循系统DNS配置。

三、禁用Chrome实验性DNS功能 #

有些员工可能误开了Chrome的实验性DNS选项，导致绕开企业策略：

• 通过Workspace Admin或组策略，强制关闭chrome://flags/#dns-over-https和chrome://flags/#built-in-dns-client这两个实验项，设置为「Disabled」，不让员工有修改的权限。

四、清除DNS缓存并验证实际DNS请求 #

有时候旧的DNS缓存会导致异常跳转，需要强制清理：

• 让员工打开chrome://net-internals/#dns，点击「Clear host cache」清除Chrome本地的DNS缓存；同时可以在这个页面查看「Current DNS servers」，确认Chrome正在使用的是你的私有DNS服务器。
• 必要时可以在设备层面清除系统DNS缓存（比如Windows用ipconfig /flushdns，macOS用sudo dscacheutil -flushcache;sudo killall -HUP mDNSResponder）。

五、排查第三方干扰因素 #

最后要排除是否有其他软件干扰DNS设置：

• 检查员工设备上是否安装了未经授权的VPN、代理工具或浏览器扩展，这些工具可能会强制Chrome使用它们的DNS服务器。可以通过企业策略限制这类软件的安装，或者强制Chrome使用系统代理/设置。

如果做完这些还是有问题，建议让出现问题的员工提供chrome://policy和chrome://net-internals/#dns的截图，这样能更精准定位哪里出了漏洞。

备注：内容来源于stack exchange，提问作者Dan