这个问题应该是从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可以被系统监听到并响应吧…