Android开发中网络代理设置实用总结

一、背景

进行Android项目开发时，跟网络代理基本上天天都在打交道。通常情况下，至少有三个场景中经常用到网络代理：
1，经常通过Chrome访问Google等国外的技术网站，如通过SS工具等；
2，AS（Android Studio）中需要下载国外的aar或jar包等资源；
3，手机抓包时，电脑上开启Charles等抓包软件，手机网络连接电脑抓包软件对应的代理。

无论是使用SS，还是通过AS拉取资源，以及Charles抓包等，有时候我们都会遇到一些“莫名其妙”的网络问题。解决问题时，有时候可能莫名的又好了，有时候可能需要好久也没法解决。尤其当这三个工具同时使用时。原因在于对于网络代理这块整体流程没有摸清，且他们之间有可能是会相互影响的，这时候出现问题可能束手无策。

二、网络代理流程

项目开发过程中用到的浏览器也好，AS也罢，广义范畴上都是属于应用层软件。软件在实现的过程中，依据实际的情况，可能会对系统网络代理进行判断，如果有代理，走代理。甚至提供对外的设置项，例如AS、Chrome可以针对网络代理去进行单独的配置。一旦配置，将依据具体情况，结合软件自身配置和系统网络代理去走网络。当然，也有些软件，并没有对系统网络代理进行判断，这种情况下，不管系统网络代理是如何设置的，也直接走默认的网络过程。

同时，不同的网络代理配置，对软件的的影响也是不同的。例如，如果系统设置了FTP代理，则只可能对使用到FTP协议的相关软件造成可能的影响，对只是使用HTTP协议的软件是没有影响的。但是，如果系统设置了TCP代理，此时，位于TCP协议上层的应用层使用到HTTP协议的软件，也都可能造成影响。因为，HTTP层，最终还是要通过TCP层去进行网络传输的。

大体上，总的流程是这样的。

 

操作系统对网络代理设置了接口，代理软件通过对应设置，可以配置具体的网络代理信息。其他应用层的网络请求，达到操作系统后，会依据具体的网络代理设置，决定是否走网络代理、以及具体如何走网络的流程。

以SS（Shadow**Socks）为例，本机安装的SS，从对生效的其他应用层软件角度来说，属于Server层，因为所有原生Client的请求，最终都将通过SS进行转发。但另一方面，从SS代理总体架构上来说，本机安装的SS，只是属于SS Clinet，因为对应的还有一个远程的SS Server。原生Client的请求，经由本机SS Client转发后，将达到指定的SS Server，SS Server拿到请求后，解封，得到实际的请求信息，转发给 Remote Server， 并将得到的请求结果对应封装后响应到SS Client，对应的，处理后回传给原生Client应用。

因此，如果网络代理设置后出现问题，总体的判断流程是这样的：
1，有无网络代理软件设置了网络代理；
2，如有设置，具体的设置方式是怎样的，针对的又是何种网络协议设置；
3，网络代理软件设置后是否生效（可以从系统偏好 >> 网络 >> 高级 >> 代理去查看）；
4，其他应用层软件对网络代理的支持（取决于其他应用层软件自身是否有单独的网络代理配置，以及网络代理的协议层级）；
5，对其他应用层软件是否有预期中的影响效果。

这其中最关键的两点是：具体的网络代理设置及其他应用层软件对网络代理的支持。

三、网络代理实践

不同的网络代理软件，有不同的设置方法。例如SS可以设置PAC自动模式、白名单模式、全局模式等。PAC自动模式和白名单模式，针对更新下来的或配置的域名列表，去决定到底是否通过SS去转发原生的网络请求。全局模式则直接Socket层代理，对上层Http访问来说，都将生效。因此，如果设置的是全局模式，表现上将是无论是访问多内网站还是国外网站，都将通过SS去转发网络请求。但这里有个地方是需要注意的，全局模式设置，实际上默认对应的是系统Http代理、Https代理和Sockes代理，如果浏览器自身有独立的代理配置，例如配置成PAC的模式，那么实际访问网站过程中，走的流程将是PAC模式，甚至浏览器如果忽视系统网络代理，直接走直连模式，此时，网络代理设置是无效的。

可以实际测试下，系统开启SS全局代理，我们看下系统检测到的代理设置结果：

其中，来自澳大利亚的IP表明SS Server访问Remote Server的出口IP地址。

 

新开一个Chrom，通过SwitchyOmega选择走系统代理，访问ip检测网站得到的结果：

SwitchyOmega切换到PAC（需要对应配置好），结果显示：

 

此时，如果我们新打开AS，在Preference >> Http Proxy设置中，看到的结果是：

 

我们发现，此时SS的全局模式对系统网络代理的设置，对AS已经造成了影响（虽然AS自身此时并未设置代理）。例如下载内网下的aar资源等就会失败。

如果SS模式有所更改，此时需要重启AS，甚至杀掉java进程，才能看到上述警告消失（因为有缓存的存在）。

当然，Gradle也可以针对单独的项目或Gradle全局，通过在gradle.properties中配置的方式，设置网络代理。 如常见的：

systemProp.http.proxyHost=127.0.0.1
systemProp.http.proxyPort=1087
systemProp.https.proxyHost=127.0.0.1
systemProp.https.proxyPort=1087
复制代码

还有一个非常容易遇到的，但是被人忽略的点是，在开启Charles抓包软件时，默认情况下是启动系统代理，即Proxy >> macOS Proxy默认是勾选的。

此时，Charles相当于代理设置软件，在启动的时候自动设置了系统的Http及Https代理。此时，相当于本机上同时存在了多个网络代理软件，且同时进行了网络代理配置，最终的结果，将是覆盖的效果（后启动的如果与先启用的有针对同一个协议进行设置，以后启用的为准）。但不管怎样，此时对AS往往也会造成影响，例如找不到证书，或者aar资源下载失败等。

以前在AS开发项目时，正好遇到Charles抓包，导致的代理问题，费解了很长时间。

当然，Charles启动时默认开启系统代理是可以取消掉的。具体路径在Proxy >> Proxy Settings >> masOS下设置。

实际开发中，SS的设置对AS的影响一般都知道，但Charles抓包时默认开启的系统代理比较隐蔽，往往会造成困扰。

无论何种代理软件，设置何种模式的代理，设置同时启用，最终的代理效果都可以在系统偏好 >> 网络 >> 高级 >> 代理中去查看。但这过程中使用的其他应用层软件，可能会造成一些莫名的困扰。此时，设置正确的网络代理方式后，往往通过重启软件甚至删掉对应的进程等方式可以解决。

四、结语

不同的网络代理软件，可以设置出不同的网络代理效果，但总体上，网络代理流程都是类似的（当然，Charles作为网络代理时，实际上并不存在Proxy Server，只是作为中间人转发了网络请求）。

在本机存在多个代理软件同时使用的情况下，往往会对其他应用层的软件造成影响。此时，需要仔细梳理下最终网络代理设置的结果，以及其他软件自身的代理配置，去综合判断并处理。

end~

作者：HappyCorn
链接：https://juejin.im/post/5d6a2fa26fb9a06b102740eb
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。