@anoncat 对，在第一次访问到其他语言的网页时，浏览器就会强制直连访问一次 translate. googleapis. com ，我专门抓包看过了，在打开浏览器后第一次访问中文网页，则没有。

只有“这一次”的强制直连访问 translate. googleapis. com 成功，那么后续的翻译过程就完全受扩展控制，可以走代理 /重定向了，如果不成功，整个翻译功能流程就会 “卡住”，不再继续后续的步骤了（加载翻译所需的静态 JS 脚本什么的），NetWork 也看不到任何相关网络链接。

我研究这个不是给自己用的，我自己早就有完美解决方案了，不过因为一些原因只能自用，所以我才想要找个适合大众使用的低门槛解决方案。
最后想到的最简单方案，还是 Hosts 指向可用的谷歌国外 IP ，这样正常情况下就能翻译了，如果想要翻译速度更快、更稳定，那么可以再整个重定向到国内 CDN 加速地址。这样除了强制直连的那一次外，其他翻译过程中的网络请求都会被重定向。

@XIU2 #57 #58 做个最后总结吧！

Chrome 内置全页谷歌翻译，其实并不是完全不受扩展控制，准确来说是：
一部分不受扩展控制走直连（但受系统代理设置控制），一部分则可以正常受扩展控制走代理。

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

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

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

——————

在 Chrome 浏览器中点击 翻译 选项后的流程逻辑是：
（注意，只有强制直连那次访问成功，浏览器才会进行下面这些的步骤环节）
1. 浏览器加载翻译所需的静态文件（ JS/CSS 等）
2. 由刚刚加载的 JS 脚本发起 POST 翻译请求并处理

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

——————

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

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


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

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

——————

以上就是我这两天，断断续续抽空研究的成果（非专业，只是根据各种测试、抓包来判断）。

毕竟我既然发了文章教程，就要负责到底，熬夜写半天结果搞出个有缺陷的教程那就是在太亏了，而且还每天一群人评论区 /私信反馈说用不了来 “打我脸” ，属实把我搞烦的不行。。。

迫使我研究了一番，并重写了一下这个文章教程才终于舒服一点了~

@sunwang 他们说的不走代理，指的是不受代理管理扩展控制，如 SwitchyOmega 这种。

当然准确来说，是一部分不受扩展控制走直连（但受系统代理设置控制），一部分则可以正常受扩展控制走代理。具体我昨天研究过，你可以看看我上面发的，虽然就算知道了也没什么卵用~

@XIU2 #34 #38 再补充一下。

刚刚用 Wireshark 抓包看了下，发现我上面得到的结论中的第一次翻译步骤的第 1 条并不准确。

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

也就是，浏览器监测到网页语言不一样，就会去不受扩展控制的直连访问一次，然后持续到浏览器关闭都不会再这样直连访问了，因此只要这次直连访问走了代理，那么后续进行翻译都可以扩展控制去走代理了。

可惜即使研究到现在，还是改 Hosts 最简单，虽然需要自己扫可用的谷歌国外 IP ，而且无法保证长期可用多少有点蛋疼。。。

fe80: 开头的是本地链接 IPv6 地址。

你电脑有 IPv6 的话，你也能在网卡连接信息里看到这种 fe80: 开头的 IP 。

@AaronLee 嗯，这篇就是我写的文章，不过很奇怪的是有人行有人不行，把我也搞懵了。。。
于是我今天研究了半天，结论就是上面我发的内容（即整个翻译流程，一部分流量强制直连，一部分流量可以走代理）。关于你提到的这个，我也注意到了，我个人粗略的解释为：

Chrome 浏览器第一次翻译时：

1. Chrome 强制直连访问 translate. googleapis. com 获取了什么（即不受代理管理扩展控制）
2. 加载了几个翻译所需的静态文件（ CSS 、JS 啥的）
3. 刚刚加载并运行的 element_main.js 脚本发起 POST 翻译请求
4. 处理翻译结果，修改网站内容

而后续再次翻译时，也只需要从步骤 2 开始，而因为 JS 等文件都被缓存了，所以相当于从步骤 3 开始了，直接由 JS 文件发起 POST 翻译请求即可（即相当于跳过了 1~2 步骤）。

这个第 1 条步骤，我也只是猜测，因为我只能通过实验判断翻译时，Chrome 直连访问了 Hosts 中指向的谷歌国外 IP ，以及 Chrome 访问了代理，但具体是什么我就不知道了。。。

折腾研究半天，给我搞晕了、烦了，本来是想研究下看看能不能找到完美解决方案写个适合大众的低门槛教程，结果最后也只得出这一堆模棱两可的答案。。。

@XIU2 "如果" => "全都"
这特么我也能打错字。。。

我写的 Go 也被 360 误报过，我各种渠道提交了几次误报申诉，如果石沉大海。。。
反倒是微软处理很及时，非工作日最多一天，还有个是国外麦什么还是哪个记不清了，发个邮件也很快回复了。

@cnfzv 可是我看 Chrome 浏览器直连访问了 Hosts 中指定的 IP ，而只可能是通过 translate. googleapis. com 域名，因为我只指定了这一个域名，其他域名不可能解析到这个 IP 的。

我用本地 DNS 程序记录了解析请求（重启了浏览器+刷新 DNS 缓存），也确实没见到其他域名。。。

@cnfzv 我刚刚在 Chrome 启动参数里加上了
--flag-switches-begin --flag-switches-end -enable-logging=stderr --v=1
来查看实时网络调试日志。

结果测试了好几遍，滚动日志里没发现有额外的网络链接。。。
依旧是依次：1 个 CSS 样式文件、2 个 JS 脚本文件、2 个 PNG 图片文件、4 个 POST 请求

和 NetWork 看到的一致，这就奇了怪了，难道我前面得出的结论是错误的么，但资源监视器里看确实是 Chrome 进程直连了 Hosts 中指定的可用谷歌国外 IP ，并且也走了代理。

还是说这条启动参数也看不到 Chrome 强制直连的那个网络链接？。。。

彻底蒙圈了~

我刚刚研究了半天，发现 Chrome 浏览器全页翻译的大概流程是（以下说的域名 /流量均指的是 translate. googleapis. com ）：

1. Chrome 强制直连访问 translate. googleapis. com 获取了什么
2. 加载了几个翻译所需的静态文件（ CSS 、JS 啥的）
3. 刚刚加载并运行的 element_main.js 脚本发起 POST 翻译请求
4. 处理翻译结果，修改网站内容

第 1 条，我搞不明白，但确定其直连访问了，完全不受扩展控制来走代理。
第 2 、3 条，都可以走代理，完全受扩展控制。

即整个翻译流程，一部分流量强制直连，一部分流量可以走代理。

复现方法：
1. 通过 Hosts 中将该域名指向可用的谷歌国外 IP 。
2. 浏览器中配置 SwitchyOmega 扩展让该域名走代理。
3. 打开 Win 自带的资源监视器，勾选代理、浏览器的进程（用来查看访问了哪个 IP ）
4. 浏览器打开测试网页，F12 打开开发者工具，选择 NetWork （网络）
5. 开始翻译当前网页，观察 NetWork 中结果，发现加载静态文件、发起 POST 翻译请求都走了代理
6. 观察 资源监视器 中结果，发现 Chrome 直连访问了 Hosts 中指向的谷歌国外 IP ，以及 Chrome 访问了代理。

我感觉我就是在瞎折腾。。。折腾的我头晕，如果犯了什么常识性错误勿喷~

@XIU2 #19 再次更新，我发的这条结论也不对，或者说不完全对。

我又研究了半天，发现 Chrome 浏览器全页翻译的大概流程是（以下说的域名 /流量均指的是 translate. googleapis. com ）：

1. Chrome 强制直连访问 translate. googleapis. com 获取了什么
2. 加载了几个翻译所需的静态文件（ CSS 、JS 啥的）
3. 刚刚加载并运行的 element_main.js 脚本发起 POST 翻译请求
4. 处理翻译结果，修改网站内容

第 1 条，我搞不明白，但确定其直连访问了，完全不受扩展控制来走代理。
第 2 、3 条，都可以走代理，完全受扩展控制。

即整个翻译流程，一部分流量强制直连，一部分流量可以走代理。

复现方法：
1. 通过 Hosts 中将该域名指向可用的谷歌国外 IP 。
2. 浏览器中配置 SwitchyOmega 扩展让该域名走代理。
3. 打开 Win 自带的资源监视器，勾选代理、浏览器的进程（用来查看访问了哪个 IP ）
4. 浏览器打开测试网页，F12 打开开发者工具，选择 NetWork （网络）
5. 开始翻译当前网页，观察 NetWork 中结果，发现加载静态文件、发起 POST 翻译请求都走了代理
6. 观察 资源监视器 中结果，发现 Chrome 直连访问了 Hosts 中指向的谷歌国外 IP ，以及 Chrome 访问了代理。

我感觉我就是在瞎折腾。。。折腾的我头晕，如果犯了什么常识性错误勿喷~

请忽略 #26 这条内容。。。
不存在该问题，只是我测试不仔细，没注意到 SwitchyOmega 其他规则顺序导致覆盖了 translate .googleapis .com 规则，致使该域名没走代理。。。
再加上昨天折腾期间，搜索看到别人提到了一些类似字眼，一结合就下意识的得出了这条错误结论~

@A01514035 我又研究了下，最终发现是 SwitchyOmega 中的其他规则因为顺序问题覆盖了我添加的 translate. googleapis. com 规则，导致该域名没有走代理。。。

再加上昨天折腾的时候，看到别人提到了一些类似字眼，一结合我下意识的就给问题定性了。。。

又犯这种低级错误了。。。

@TcDhl
是啊，
谷歌刚关闭网页版时，Chrome 内置翻译 API 接口 translate .googleapis .com 还能通过 Hosts 重新指向国内服务器 IP 继续使用，不过从 20 日开始就不行了（我也是这天下午发现的，因为我那篇文章的原因，也是从这天开始每天有几十个人跑知乎问我。。），似乎谷歌已经移除了国内服务器上的谷歌翻译服务。

我也是昨天折腾半天才发现。。。
浏览器的代理管理扩展，如 SwitchyOmega 是无法控制 translate .googleapis .com 域名走代理的（显然是 Chrome 的限制），只有通过系统代理设置，让浏览器走系统代理才行。

不过说实话，目前还是能找到个别该域名能用的谷歌国外 IP ，虽然延迟比国内高很多，翻译速度明显慢一截，但也能凑活着用。而且这次是谷歌自己关闭的，域名也没有任何污染 /阻断，所以改 Hosts 依然可用。

另外，忘记说了。

浏览器的代理管理扩展，如 SwitchyOmega 是无法控制 translate .googleapis .com 域名走代理的，只有通过系统代理设置，让浏览器走系统代理才行。

谷歌翻译没有被墙，是谷歌官方自己关闭了国内版，域名都好好的没有任何污染阻断，只是解析 IP 从谷歌国内服务器切换到了谷歌国外 IP ，而这些谷歌国外 IP 早十年前就被墙了，导致 Chrome 内置翻译不能用了。。。

刚关闭网页版时，Chrome 内置翻译 API 接口 translate .googleapis .com 还能通过 Hosts 重新指向国内服务器 IP 继续使用，不过从 20 日开始，就不行了，似乎谷歌已经移除了国内服务器上的谷歌翻译服务。

@paradoxs 楼主说的是 Chrome 浏览器自带的全页翻译功能，调用的这个翻译接口 API