请问大家注意到 Chrome 自带的翻译始终是直连而不走 pac,这是何种设计逻辑?

2015-06-24 18:47:03 +08:00
 cdy
有些小语种的资料要查,在配合 pac 的过程中,自带的翻译一直无法响应,不是一直卡在了 translating to English,就是 server error。我查了下资料,如下:

https://github.com/feliscatus/switchyomega/issues/264

https://www.v2ex.com/t/174873

请问除了系统级的方法(S*S的 global 90%几率失效,proxifier 单独添加 Google Chrome规则也无效),还有什么其他思路?
5301 次点击
所在节点    问与答
8 条回复
lonelygo
2015-06-24 18:53:42 +08:00
来个链接,我试试我这里。
cdy
2015-06-24 19:00:56 +08:00
yangxiongguo
2015-06-24 19:07:03 +08:00
可以用Google翻译的插件
lonelygo
2015-06-24 19:11:19 +08:00

ss+SwitchyOmega
几秒中就OK了
cdy
2015-06-24 19:16:40 +08:00
@lonelygo 我也正是这样的设置,SwitchyOmega走的是全局,S*S中PAC和Global都试过,效果一般,请问你的SO中的设置是?
lonelygo
2015-06-24 19:25:23 +08:00
MAC的SS客户端貌似不支持独立,而GoA的支持独立模式。所以,我用的GoA的SS,独立模式。
然后,Safari解决内事,Chrome+SO解决外事。
SO:Socks5 127.0.0.1 8***
cylin
2015-06-24 19:34:14 +08:00
proxifier添加chrome.exe是有效的
cdy
2015-06-24 20:15:16 +08:00
Proxifier在 无论是否开启 VPN,挂上SO会让网页的流量走1080(SS本地)端口,且在 Proxifier 中无Chrome 的流量纪录,只有 ss 的记录(要注意的是,此时有一条 Chrome direct connection 的纪录,无域名显示,我推测此条纪录正是谷歌翻译的请求,直接从 Chrome 发出);开启 VPN 且关闭浏览器的 SO 后,Chrome 会走3447的直连端口(会有所有 Chrome 的连接信息,且包含正访问的域名)。

这个结论也较符合谷歌翻译不走 SO 的推测。Proxifier 添加 Google Chrome.app 无效的可能原因在于:当流量走 SO 后,会忽略从Chrome直接发出去的请求(也就是translate的请求。但不知为何这条请求也被 SS 的 PAC 忽略了)。

PS:解决方案之一是,不开启SO,而是在 Proxifier 中添加 Chrome 走 SS 本地端口的规则(这样就被动忽略了 SO 自定义规则的功能)。Windows 逻辑也应相同。

@cylin
@lonelygo

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/200876

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX