@kltt22 IOS 可以在自己的服务器上面搭建网页版，用浏览器去看，虽然没有 APP 用着舒服，但总比没有的强。

@fzdwx
开源的《阅读》 APP ，只有安卓版本，不过有个第三方 Fork 做的服务端版（即网页版）可以全平台使用。
https://github.com/gedoor/legado
https://github.com/hectorqin/reader

另外《阅读》只是一个空壳，相当于爬虫，需要导入书源规则才能用，我分享的有自写自用的书源：
https://github.com/XIU2/Yuedu

今天遇到一次，打开一个文件，想要复制一段内容时，发现选中不了，想要 Ctrl+F 搜索时，也特么没反应，整个网页都卡住了。。。

translate. googleapis. com 以前是解析到谷歌的国内服务器 IP 的，所以各种代理规则一般都是让其直连（当然这么多天过去了，各代理规则应该也都更新了，不再排除该域名了）。

9 月 29 日，谷歌关闭了谷歌翻译国内版，连带着这个谷歌翻译 API 接口的解析从国内改到国外 IP 了。

但此时还能通过修改 Hosts 来将其重新指向以前的国内服务器 IP ，直到 10 月 20 日，谷歌陆续移除国内服务器上的谷歌翻译 API 接口服务，因此改 Hosts 方案就此失效。

你代理规则更新了，也就正常让该域名走代理了。

测试了下，并不可以，没发现有什么变化。。。

“就是和以前一样挂梯子”

你是通过代理软件内部控制什么网站走代理，什么网站不走代理的吗？如果是这样的话，可能是规则更新了，将 translate. googleapis. com 改为走代理了（以前规则都是直连）。

当我想和你争论的时候，我就已经输了~

@xz410236056
“之前有 CN 域名的时候也是整天 DNS 污染”

额，我并没有见过，至少这几年谷歌翻译国内版一直很正常，指向的都是谷歌国内 IP ，没有 DNS 污染。
即使是现在，也只是 9 月底谷歌自行关闭了，翻译 API 接口域名并没有被污染 /阻断。


“虽然关了 CN 域名，IP 还是在的，直连 IP 还是能访问的，虽说迟早也会关”

你这是老黄历了。。。
谷歌国内服务器虽然还在，但是目前谷歌从 10 月 20 日 开始已经陆续移除国内服务器上的 谷歌翻译 API 接口服务了，Hosts 指向这些国内 IP 的已经无法翻译了。

目前谷歌翻译 API 接口域名只能指向可用的谷歌国外 IP 使用，或者走代理。

另外，Chrome 浏览器内置的谷歌全页翻译，使用 SwitchyOmega 等扩展是无法使其完全走代理的（不受扩展影响），只能被 系统代理设置、Hosts 等外部影响，至于为什么有兴趣的可以看一下我的研究结果：

「研究」 Chrome 浏览器自带 谷歌翻译 为啥不受扩展控制？
https://zhuanlan.zhihu.com/p/576932998

这文章是我写解决谷歌翻译失效问题时，发现的奇怪现象，于是抓包研究了下，确实比较奇葩。。。

@xz410236056 准确说是国内不能直接用了，包括谷歌翻译 API 接口。

还没完全开完，从 26 号起还有一场，好像要持续好几天

主要原因是，QQ 个人邮箱只是腾讯生态的补充，并没有放太多心思在上面，因此也懒得去研究用户需求来更新优化，目前状态是 “能用就行”。

再加上国内和国外的习惯是有差异的，国外对邮箱接触更早，更习惯使用，因此多少会更重视一点~

@brader 对，Chrome 在翻译前的那一次强制直连访问 translate. googleapis. com 时，虽然不受 SwitchyOmega 等扩展的控制，但却受浏览器外的如 系统代理设置、Hosts 的影响。

@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 "如果" => "全都"
这特么我也能打错字。。。