「研究」Chrome 浏览器自带 谷歌翻译 为啥不受扩展控制？

自从 9 月底的谷歌关闭翻译国内版，导致 Chrome 浏览器内置的谷歌全页翻译也跟着失效，于是当时我写了个改 Hosts 指向国内服务器的 IP 的教程文章。

结果在 10 月 20 日又因为谷歌陆续关闭国内服务器上的翻译接口服务而失效了，我研究两天才找到了一些合适的解决方案，又写了个新教程文章（即重定向，不过我在搞明白后就已经将下面这个文章重写了一遍，要看解决方法的就直接看下面这个教程文章即可）。

结果发现有人可以，有人却不行，这给我整迷瞪了，迫使我又研究了两天，才大概搞明白原因。这个文章就是我把这段时间的研究总结梳理并记录一下，就当备忘吧~

其实并不是完全不受扩展控制（如 SwitchyOmega 、Header Editor 扩展），准确来说是：

整个翻译过程中的网络请求，其中最初一部分不受扩展控制走直连（但受系统设置控制），其他部分则可以正常受扩展控制 走科技 或 被重定向。

如果你使用的是 谷歌翻译 独立扩展版 的话，则没有该问题，可以被扩展控制。
但记得配置：translate.googleapis.com、translate.google.com、translate-pa.googleapis.com 这三个域名走科技，后两个域名是用于扩展的 翻译此页面 功能（不好用，很多网站会因 CSP 而被阻止），如果你只用 划词翻译 那么只让第一个域名走科技即可。

是哪一部分网络请求不受扩展控制强制走直连？

打开浏览器后，第一次访问其他语言的网页时（即右上角提示翻译，但你还没有去点击翻译），浏览器就会访问一次 translate.googleapis.com，而这次访问是不受浏览器扩展控制的。

也就是，浏览器监测到网页语言不一样时，就会去不受扩展控制的强制直连访问一次 translate.googleapis.com，后续在浏览器关闭之前就不会再这样做了，因此只要这一次强制直连访问成功，那么后续进行翻译都可以由扩展控制 走科技 或 被重定向了。

而一些人之所以会出现明明手动访问 CSS/JS 等静态文件可以正常 走科技 或 被重定向，但依然无法翻译的情况，就是因为这次 Chrome 强制直连的链接没有 走科技 或 被重定向导致的，而另外一批成功翻译的人，其实就是因为这次强制直连因为某些原因访问成功了，所以后续的翻译请求才会正常 走科技 或 被重定向。

点击 翻译 选项后的流程逻辑是？

注意：只有强制直连那次访问成功，浏览器才会进行下面这些的步骤环节！

1. 浏览器加载翻译所需的静态文件（JS/CSS 等）
2. 由刚刚加载的其中一个 element_main.js 脚本发起 POST 翻译请求并处理

而这两个环节产生的网络链接都能正常受扩展控制，可以 走科技 或 被重定向。

为啥有人可以 有人不行？

我前几天写的教程，是依靠扩展把 translate.googleapis.com 重定向至 gtranslate.cdn.haah.net，结果评论区/私信中，有大量用户反馈依然不行，但是也有部分人反馈可以，这种奇怪的现象迫使我仔细研究了一番 Chrome 的翻译机制，才大致搞明白了，确实挺奇葩的，我也想不明白，为什么 Chrome 浏览器要这样做，而且还是内核中写死的。。。

现在想来，我之所以能重定向成功，就是因为当初测试效果时，我的 Hosts 文件中已经加的有将其指向可用的谷歌 IP 的内容了，而我当时还不清楚这么多弯弯道道，以为只靠扩展重定向就完美解决了，还很兴奋的第一时间熬夜写教程，结果第二天大量用户在评论区反馈不行。。。搞得我就很尴尬，刚才我又重写了这篇文章教程，这次应该没啥问题了~

如何验证呢？

想要验证也很简单，只需要在 Hosts 中将 translate.googleapis.com 指向一个不可用的错误 IP 并重启浏览器（刷新缓存），然后再去尝试翻译（已配置扩展 走科技 或 重定向），就会发现翻译失败了。

而一旦指向一个可用的 IP（我用的是谷歌国外 IP），那么翻译时就能在 F12 - NetWork（网络）中看到发起的 POST 翻译请求被扩展控制走了 走科技 或 被重定向（如果是前面那样将其指向不可用的错误 IP，那么这种情况下尝试翻译，会发现 NetWork 看不到任何翻译请求的网络链接）。