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

This topic created in 4062 days ago, the information mentioned may be changed or developed.

有些小语种的资料要查，在配合 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规则也无效），还有什么其他思路？

PAC

s＊s

Proxifier

8 replies • 2015-06-24 20:15:16 +08:00

lonelygo

Jun 24, 2015

来个链接，我试试我这里。

cdy

Jun 24, 2015

@lonelygo http://www.hochschule-rhein-waal.de/de/veranstaltungen/lange-nacht-der-studienberatung

请

yangxiongguo

Jun 24, 2015

可以用Google翻译的插件

lonelygo

Jun 24, 2015

ss＋SwitchyOmega
几秒中就OK了

cdy

Jun 24, 2015

@lonelygo 我也正是这样的设置，SwitchyOmega走的是全局，S＊S中PAC和Global都试过，效果一般，请问你的SO中的设置是？

lonelygo

Jun 24, 2015

MAC的SS客户端貌似不支持独立，而GoA的支持独立模式。所以，我用的GoA的SS，独立模式。
然后，Safari解决内事，Chrome＋SO解决外事。
SO：Socks5 127.0.0.1 8***

cylin

Jun 24, 2015

proxifier添加chrome.exe是有效的

cdy

Jun 24, 2015

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