本文最后一次在 2019 年 9 月 7 日更新,部分内容可能已经过时!
这个问题应该是从72版本开始的——如果我没记错的话。但是目测不会是Chrome的bug,因为到了76版本更加的变本加厉了…不过还好,办法总比困难多。

1、版本号≤75

具体来说应该就是72~75吧。这几个版本号还是比较容易解决的。只需要去往chrome://flags,将Enable Network Service给禁用掉即可。

究其原因(下面这些都是我猜的),大概就是从72开始,Chrome将网络服务作为独立进程执行。而系统监听的是Chrome这个进程,并没有相应真正发送网络请求的进程,所以Chrome的请求便直接发出去,不能经过代理了。而将这个选项禁用,也就是让Chrome的网络服务运行在程序内,那么网络请求便可以被监听到,PAC模式便也正常了。

2、版本号76+

76应该是最新的版本号了——至少在Archlinux里面是这样的。

即使之前你已经调整过,并且顺利解决了,但当你升级到了76这个版本号的时候,就能惊喜的发现:这个问题又复发了。

如果你还想按照75-的那种操作方法修正,那么很遗憾,Enable Network Service这个选项已经不存在了。

所以可以证明一件事:72~75出现的问题不能说是Chrome的bug,而是Network Service这个新特性导致的问题,而且Chrome大概是不打算修复这个问题的…

但总不能一直使用全局系统代理吧…国内网站绕一圈国外再回来…太慢了。

所以还是要想想解决方案,让PAC模式可以应用。

如果在Chrome://flags里边,以Network Serivce为关键字查找的话,会找到一项Runs network service in-process的选项。回顾一下刚刚说到的出现这个问题的原因,仿佛这个选项会管用?

很不幸,这个选项是没用的。所以暂时就不要想着能通过Chrome自己的设置来解决这个问题了。

好在Chrome的插件里边有一个神器——SwitchyOmega。通过它来判断是否需要使用代理就行了。


  • 从Chrome应用商店安装 Proxy SwitchyOmega
  • 进入插件设置页,新建情景模式(我这里名字叫做proxy),类型代理服务器
  • 在这个情景模式下,设置代理协议为SOCKS5,服务器和端口为127.0.0.1:1080(这两项应该与你代理软件内对应的本地设置相同)
  • 新建一个情景模式(我这里名字叫做auto switch),类型自动切换模式
  • 在这个情景模式下,添加规则列表,格式为AutoProxy,网址https://raw.githubusercontent.com/gfwlist/gfwlist/master/gfwlist.txt,对应这一条的情景模式选择刚刚创建的proxy。看图

  • 点一下立即更新情景模式,待正文框内出现内容,代理便设置完成

现在,点击Chrome地址栏边上的SwitchyOmega图标,选择auto Switch,问题便解决了。


其实这样设置之后,并没有通过系统的PAC,而是Chrome自己判断并决定是直接访问还是间接访问。也就是说,即使系统没有配置好全局的PAC,而仅仅是启动了一个代理服务,通过该方法同样可以让Chrome顺利跨越。所以,为了不荒废系统代理的作用,还是希望有朝一日Chrome的Network Service可以被系统监听到并响应吧…

仅有一条评论

  1. 希望下一期是《3N的游戏杂谈》,而且是《Minecraft编年史》系列。
    希望此系列的bgm:分享饭碗的彼岸的单曲《风居住的街道(Piano ver) (COVER:磯村由紀子)》: http://music.163.com/song/36897723/?userid=1863282066 (来自@网易云音乐) —— ScottLiu ScottLiu 发表。 回复TA

添加新评论