一、背景
進行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
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。