云clash节点
更新:2024-07-26 谷歌好像修复了这个 BUG,至少在 Chrome v127.x 的正式版测试,使用系统代理、smartproxy socks5等代理插件,对于首次翻译请求,也是全部走代理了
不想使用 Tun 模式的云clash节点,提供一个第三方扩展插件代替自带翻译,部分翻译引擎无需魔法(但翻译效果差),扩展插件名字叫沉浸式翻译,建议还是搭配魔法使用,效果十分不错,个人自用了半年了,谷歌网上扩展插件商店地址(需要魔法访问能力):
- 智能识别网页主内容区,区别于同类插件翻译整个网页所有的区域,这极大的增强了翻译后的网页阅读体验。类似浏览器的沉浸式阅读模式,所以该扩展被命名为“沉浸式翻译” - 双语显示,中文/英文对照着看(按照段落分割,或者自定义段落长度,自动为长段落按照每句话换行) - 为常用网站做了定制优化,比如 Twitter,Reddit,Discord, Gmail, Telegram, Youtube, Hacker News 等,这些网站并不是常规的内容网站,所以定制优化后,翻译的区域非常智能 - 支持 10+种常见的翻译服务,包括 Deepl, 谷歌, OpenAI, 腾讯翻译君,火山翻译,彩云小译等等. - PDF 文件双语翻译支持 - 配合 epub 在线阅读网站即可实现双语阅读国外电子书 - 多种译文样式可选择,个性化你的翻译体验
翻译前后对比,第一张翻译前,第二张翻译后,如果图片看不清,可以选择右键图片在新标签页打开查看大图
2022-09-28 谷歌翻译彻底关闭中国区域的翻译功能,有一个说法是 “提供API接口的googleapis被墙。这导致js文件和字体资源无法加载,官方懒得进行修复,所以干脆停掉了”
而不是官方说的使用率太少停掉退出中国,恰逢十月份开会期间曾出现过几天的大规模 DNS 污染,基本是期间被墙了,谷歌最后选择摆烂不修了
本文目的:让有梯子的,能够维持原来使用习惯,浏览器端无需任何配置和改变,继续使用谷歌翻译,原功能全部保持有效
谷歌浏览器自带的翻译使用到的域名,在使用翻译功能时,在对 域名首次 tcp 连接,是没经过任何代理插件处理(原因不明,基于谷歌浏览器的任意代理插件都无法记录到这首次请求,所以无法代理重定向给相应代理后端处理分流),在代理插件的视角:根本没有记录到首次请求连接 translate.google.com 的记录,在第2次及以后的 tcp 连接,才会走代理插件,首次该域名的 tcp 连接直连被墙域名,导致翻译失败。
在被墙之初,translate.google.cn 被 DNS 污染时,我就已经预见了接下来的最差后果,已经把所有 google 子域加入了 clash 代理策略里面,在谷歌官方关停 tralslate.google.cn 之后,发现即便有梯子也是无法使用
再加上 Clash 没抓取到相关记录(谷歌翻译或任意谷歌子域甚至任意域名记录),基本实锤是 谷歌浏览器的自带翻译功能(网页右键的翻译功能)没走代理,而是直连,并且该行为无法被 SwitchyOmega 代理,可能优先级比 SwitchyOmega 更高,或者说是内核源码直接写死了,谷歌浏览器自身请求某个谷歌 API 域名接口,并没有走浏览器访问
a 参考上面写的之前文章记录,使用该参数启动谷歌浏览器(注意需要在启动前谷歌浏览器后台进程全部关闭了才有效),此时是真●全局代理,谷歌浏览器所有流量均会被重定向到 Clash 的 7890 端口处理,无一遗漏
b 使用任意具备虚拟网卡驱动级别的全局代理软件/路由器层面的透明代理,如 Netch、Clash Tun 模式,下面以 Clash Tun 模式为例,Clash 策略组规则需要代理此项域名translate.google.com,并开启 Tun 模式,此时日志记录到了首次请求没有走 SwitchyOmega Proxy 浏览器代理插件接口,而是基于应用程序客户端级别的直接发起的联网请求(也就是没走浏览器)
同时使用 Tun 和 socks5 代理方式,方便对比,图中 socks5 类型都是 SwitchyOmeg 配置的 socks5 代理,转发给 clash,图中的 Tun 就是漏网之鱼,可以看到首次连接并没有经过 SwitchyOmeg ,而是谷歌浏览器作为普通客户端形式直接发起的网络请求直连到了该域名,被 Clash Tun 模式捕获。
Clash 策略组代理这个域名,并且同时使用 Tun 模式,就可以正常使用了,浏览器端无需额外设置
请问具体咋写代码?我看过目前代理组用的是域名,然后cfw截取到日志显示是个Google翻译的tun模式显示的是ip180.163.151.162,系统代理则是
我没用过第三方路由器系统,提供另一个思路,在第三方订阅转换,远程配置上传功能,编写自定义的clash规则策略,添加所需域名