@lindas 我也改过光猫上的防火墙，设置选项很简陋，我给能关的都关了。
至于桥接，我一直都是光猫桥接，路由器拨号。。。难道是我的路由器问题（也尝试过防火墙全关），路由器也是运营商今年送的，性能比我的旧路由器还差一些，但是因为支持 IPv6 ，所以我还是用上了。。。

@lcdtyph
@lindas
这么蛋疼的么，光猫也是前两年刚换的，当时换光猫要了 100 元，再换新光猫的话还要 100 元。。。

我的 IPv6 似乎不是公网？测试端口不通。。
难道是因为我有 IPv4 公网了所以就不提供 IPv6 公网了么。。。

@kltt22 嫌麻烦的也可以用别人搭建好的，比如这个项目作者自建的~

@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 这种。

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