更新：2024-07-26 谷歌好像修复了这个 BUG，至少在 Chrome v127.x 的正式版测试，使用系统代理、smartproxy socks5等代理插件，对于首次翻译请求，也是全部走代理了

更新：2023-6-16 11:48:14
不想使用 Tun 模式的，提供一个第三方扩展插件代替自带翻译，部分翻译引擎无需魔法（但翻译效果差），扩展插件名字叫 沉浸式翻译，建议还是搭配魔法使用，效果十分不错，个人自用了半年了，谷歌网上扩展插件商店地址（需要魔法访问能力）：https://chrome.google.com/webstore/detail/immersive-translate/bpoadfkcbjbfhfodiogcnhhhpibjhbnh

如果没有魔法访问能力，我也搬运打包一份exe自解压离线插件，下载地址：

https://www.aliyundrive.com/s/vRbZYzavKnW
提取码: ib89
运行后选择解压目录，之后谷歌扩展插件打开开发者模式，选择解压的目录即可加载插件

插件简介：

- 智能识别网页主内容区，区别于同类插件翻译整个网页所有的区域，这极大的增强了翻译后的网页阅读体验。类似浏览器的沉浸式阅读模式，所以该扩展被命名为“沉浸式翻译”
- 双语显示，中文/英文对照着看（按照段落分割，或者自定义段落长度，自动为长段落按照每句话换行）
- 为常用网站做了定制优化，比如 Twitter，Reddit，Discord, Gmail, Telegram, Youtube, Hacker News 等，这些网站并不是常规的内容网站，所以定制优化后，翻译的区域非常智能
- 支持 10+种常见的翻译服务，包括 Deepl, 谷歌, OpenAI, 腾讯翻译君,火山翻译，彩云小译等等.
- PDF 文件双语翻译支持
- 配合 epub 在线阅读网站即可实现双语阅读国外电子书
- 多种译文样式可选择，个性化你的翻译体验

翻译前后对比，第一张翻译前，第二张翻译后，如果图片看不清，可以选择右键图片在新标签页打开查看大图

---

2022-09-28 谷歌翻译彻底关闭中国区域的 translate.google.cn 翻译功能，有一个说法是 “提供API接口的googleapis被墙。这导致js文件和字体资源无法加载，官方懒得进行修复，所以干脆停掉了”

而不是官方说的使用率太少停掉退出中国，恰逢十月份开会期间曾出现过几天的大规模 DNS 污染，基本是期间被墙了，谷歌最后选择摆烂不修了

本文目的：让有梯子的，能够维持原来使用习惯，浏览器端无需任何配置和改变，继续使用谷歌翻译，原功能全部保持有效

先说下有梯子（开启系统代理/配合代理插件的形式）也无法使用的原因：

谷歌浏览器自带的翻译使用到的 translate.google.com 域名，在使用翻译功能时，在对 translate.google.com 域名首次 tcp 连接，是没经过任何代理插件处理（原因不明，基于谷歌浏览器的任意代理插件都无法记录到这首次请求，所以无法代理重定向给相应代理后端处理分流），在代理插件的视角：根本没有记录到首次请求连接 translate.google.com 的记录，在第2次及以后的 tcp 连接，才会走代理插件，首次该域名的 tcp 连接直连被墙域名，导致翻译失败。

---

在被墙之初，translate.google.cn 被 DNS 污染时，我就已经预见了接下来的最差后果，已经把所有 google 子域加入了 clash 代理策略里面，在谷歌官方关停 tralslate.google.cn 之后，发现即便有梯子也是无法使用

之前我写过这篇文章：https://www.0z.gs/memo/chrome-proxy.html

此时我是推测应该是有 域名直连到了污染/关停的域名，Clash 日志还没抓取到详细日志

我是 Google Chrome + SwitchyOmeg + Clash 使用，其中 Clash 监听一个本地 7890 的socks5 端口，SwitchyOmega 将流量重定向转发给 Clash 本地端口，但是这个方式仍然无法使用谷歌自带的翻译功能

再加上 Clash 没抓取到相关记录（谷歌翻译或任意谷歌子域甚至任意域名记录），基本实锤是 谷歌浏览器的自带翻译功能（网页右键的翻译功能）没走代理，而是直连，并且该行为无法被 SwitchyOmega 代理，可能优先级比 SwitchyOmega 更高，或者说是内核源码直接写死了，谷歌浏览器自身请求某个谷歌 API 域名接口，并没有走浏览器访问

有 2 种解决方案

a> 参考上面写的之前文章记录，使用该参数启动谷歌浏览器（注意需要在启动前谷歌浏览器后台进程全部关闭了才有效），此时是真●全局代理，谷歌浏览器所有流量均会被重定向到 Clash 的 7890 端口处理，无一遗漏

示例：

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe" --proxy-server="socks://127.0.0.1:7890" --host-resolver-rules="MAP * ~NOTFOUND , EXCLUDE 127.0.0.1"

b> 使用任意具备虚拟网卡驱动级别的全局代理软件/路由器层面的透明代理，如 Netch、Clash Tun 模式，下面以 Clash Tun 模式为例，Clash 策略组规则需要代理此项域名 translate.google.com，并开启 Tun 模式，此时日志记录到了首次请求没有走 SwitchyOmega Proxy 浏览器代理插件接口，而是基于应用程序客户端级别的直接发起的联网请求（也就是没走浏览器）

同时使用 Tun 和 socks5 代理方式，方便对比，图中 socks5 类型都是 SwitchyOmeg 配置的 socks5 代理，转发给 clash，图中的 Tun 就是漏网之鱼，可以看到首次连接并没有经过 SwitchyOmeg ，而是谷歌浏览器作为普通客户端形式直接发起的网络请求直连到了该域名，被 Clash Tun 模式捕获。

下面是更完整的记录抓取，记录谷歌浏览器冷启动之后，翻译一个页面时期间的网络请求