Surge 常見問題

Surge iOS 可能產(chǎn)生的電量消耗由兩項組成：網(wǎng)絡(luò)通訊（基帶）電量消耗與 CPU 電量消耗。

當(dāng)開啟 Surge iOS 后，由于所有的應(yīng)用的網(wǎng)絡(luò)請求都由 Surge 所接管并轉(zhuǎn)發(fā)，使得 iOS 統(tǒng)計時，將所有網(wǎng)絡(luò)通訊所產(chǎn)生的電量消耗計算在 Surge 上，所以 Surge 的電量占用比例會很高。但實際上并未產(chǎn)生額外的電量消耗。

如果配置了加密的代理進(jìn)行流量轉(zhuǎn)發(fā)，由于進(jìn)行轉(zhuǎn)發(fā)時需要進(jìn)行加解密運算，將產(chǎn)生額外的 CPU 電量消耗。一般來說該額外開銷很低，基本可忽略不計，但是如果在長時間、高帶寬的場景下，可能產(chǎn)生較大消耗，如 iCloud 同步、App Store 應(yīng)用包下載等，但默認(rèn)情況下這些作系統(tǒng)通常是在連接電源時才會執(zhí)行。

如果配置了 cron 類型腳本，且觸發(fā)時間很頻繁，可能因為不斷喚醒 CPU 導(dǎo)致額外的電量消耗。

綜上所說，持續(xù)開啟 Surge iOS 對電量消耗的影響很小，據(jù)我們的測試，正常使用下 24 小時額外消耗不到 5%，不必?fù)?dān)心。

如果在 Dashboard 發(fā)現(xiàn)，所有 TCP 請求均以 IP 地址展示，不顯示域名，則說明 Surge 未能成功劫持 DNS。詳細(xì)原理請見：《Surge 官方中文指引：理解 Surge 原理 》

可能的原因和解決方法有：

首先請檢查設(shè)備的 DNS 設(shè)置是否為 Surge 的專用 DNS 地址：198.18.0.2，Surge 開啟增強模式時會自動修改當(dāng)前設(shè)備的 DNS，DHCP 模式下會自動為客戶端設(shè)備配置該 DNS。

部分作系統(tǒng)或瀏覽器帶有 DoH/DoT 或其他加密 DNS 協(xié)議支持，Surge 無法劫持此類 DNS 請求，請手動關(guān)閉該功能。

設(shè)備上裝有其他會劫持系統(tǒng) DNS 的軟件。

如果 Surge 請求查看器中不顯示請求，可按照以下順序進(jìn)行排查：

確認(rèn) Surge 已接管本地或另一設(shè)備的網(wǎng)絡(luò)：

開啟設(shè)置為系統(tǒng)代理選項可接管當(dāng)前設(shè)備的大部分 HTTP/HTTPS 請求。

開啟增強模式可接管當(dāng)前設(shè)備的幾乎所有請求。

可通過 Surge 主界面的客戶端與進(jìn)程列表確認(rèn)接管是否成功，如果有項目說明接管成功。

確認(rèn)請求查看器的過濾器設(shè)置

在 Surge 主程序的截取頁面中，可配置請求查看器截取過濾器參數(shù)，若該參數(shù)配置不當(dāng)，可導(dǎo)致請求查看器不顯示結(jié)果。

如果 Surge Mac 助手程序（Helper）異常，會導(dǎo)致無法設(shè)置系統(tǒng)代理和無法開啟增強模式。（使用 CleanMyMac 或其他清理軟件強行清理可能導(dǎo)致該問題）

請參照以下步驟修復(fù)：

打開 Surge Mac 的設(shè)置界面，選擇高級，點擊移除助手程序。

輸入你的系統(tǒng)登錄密碼。

點擊打開終端。

在終端窗口處再次輸入系統(tǒng)登錄密碼并回車。

重啟電腦。

打開 Surge，嘗試勾選設(shè)置為系統(tǒng)代理，輸入系統(tǒng)密碼重新安裝助手程序。

由于 macOS 是開發(fā)性系統(tǒng)，導(dǎo)致該問題產(chǎn)生的原因可能非常復(fù)雜，如果仍然不能正常工作，可能需要嘗試重置整個系統(tǒng)。

如果在 Surge 開啟時同時連接了其他 VPN，可能會出現(xiàn)問題，請嘗試關(guān)閉增強模式，如果開啟增強模式需要配合自定義 direct 策略強制綁定 interface，詳見手冊。

如果出現(xiàn)了訪問內(nèi)網(wǎng)域名無法解析的問題，請：

如果 VPN 正確配置了 Split DNS，那么只要由系統(tǒng)去進(jìn)行 DNS 解析即可拿到正確結(jié)果。使用 本地 DNS 映射功能直接將內(nèi)網(wǎng)的域名配置為 syslib 解析。

請注意，server:syslib 參數(shù)在開啟增強模式時無法生效，可使用本地 DNS 映射功能直接將內(nèi)網(wǎng)的域名交給內(nèi)網(wǎng)的 DNS 進(jìn)行解析。

如果該域名本身也可以由外網(wǎng)訪問，這樣的配置可能引起問題。（可通過 DNS 腳本判斷環(huán)境解決）

Surge Mac 增強模式的原理是通過一個虛擬網(wǎng)卡接管所有流量。該工作模式下可能引發(fā)兼容性問題，表現(xiàn)可能有網(wǎng)速緩慢、Surge 被直接關(guān)閉、Surge 反應(yīng)緩慢等，以下列出部分已知的可能產(chǎn)生沖突的程序。

AdGuard

Viscosity

Little Snitch

配置中的 skip-proxy 參數(shù)由于命名問題可能被部分用戶錯誤理解，Surge iOS/Mac 只是在配置自身為系統(tǒng)代理時，將配置于 skip-proxy 參數(shù)中的內(nèi)容同時配置到系統(tǒng)的「跳過代理」設(shè)置中。與手動在系統(tǒng)的網(wǎng)絡(luò)代理中進(jìn)行配置相同。

如果 Surge Mac 僅勾選了設(shè)置為系統(tǒng)代理，未開啟增強模式，那么處于該參數(shù)中的主機名的請求將不會被 Surge 所接管，所有 Surge 的相關(guān)功能不會生效。

如果 Surge Mac 勾選了設(shè)置為系統(tǒng)代理，且開啟了增強模式，或者是在 Surge iOS 上。那么該參數(shù)將使對應(yīng)請求的接管模式由代理接管變?yōu)?Surge VIF 接管。Surge 的各項功能仍然生效但是會有細(xì)節(jié)上的區(qū)別。

所以，并非是配置在 skip-proxy 參數(shù)中的主機名就不會使用代理轉(zhuǎn)發(fā)，該參數(shù)只影響請求被 Surge 接管的方式。

關(guān)于接管方式的不同的具體區(qū)別，請參見 《Surge 官方中文指引：理解 Surge 原理 》。

部分 App 即使遵循系統(tǒng)代理設(shè)置，也可能忽略跳過代理中的內(nèi)容，具體取決于應(yīng)用的代理實現(xiàn)。

如果你的配置來源于其他人，這種情況下配置可能會隨著遠(yuǎn)程修改而自動更新（即托管配置）。

由于遠(yuǎn)程隨時可能更新并覆蓋本地的配置，所以這種情況下并不允許在本地對設(shè)置進(jìn)行調(diào)整，以避免沖突。

如果希望在原有托管配置的基礎(chǔ)上調(diào)整配置，可以

創(chuàng)建該托管配置的副本，這將使得新配置脫離原配置的自動更新，從而可以隨意進(jìn)行編輯。

以該配置為基礎(chǔ)，創(chuàng)建關(guān)聯(lián)配置（Linked Profile），僅從原配置中引用部分段（通常為 [Proxy] 和 [Proxy Group]），這樣可以自己編輯其他段的相關(guān)配置。詳見：配置分離

簡單來說，是當(dāng)網(wǎng)絡(luò)確實出現(xiàn)問題時才會給出該提示，此時網(wǎng)絡(luò)處于幾乎不可用的狀態(tài)。

技術(shù)細(xì)節(jié)上，當(dāng) Surge 檢查到 TCP 的握手時間超過 2000 ms，便會向當(dāng)前配置的所有傳統(tǒng) DNS 發(fā)送一個 DNS 請求，若在 2000ms 內(nèi)未收到應(yīng)答，則判定當(dāng)前網(wǎng)絡(luò)質(zhì)量差通過給于提示。

如果在網(wǎng)絡(luò)確實沒有問題的狀態(tài)下頻繁出現(xiàn)該提示，請檢查 DNS 服務(wù)器配置是否合理（比如在中國大陸使用 8.8.8.8/8.8.4.4 和 1.1.1.1/1.0.0.1 極易無法聯(lián)通）。

如果不希望收到該提示，可以前往 Surge 內(nèi)的通知設(shè)置中單獨關(guān)閉該通知。

默認(rèn)情況下，Surge 會根據(jù)代理類型自動決定是否允許轉(zhuǎn)發(fā) QUIC/HTTP3 流量，因為絕大多數(shù)代理并不適合用于轉(zhuǎn)發(fā) QUIC 流量，會產(chǎn)生嚴(yán)重的性能問題。

幾乎所有應(yīng)用都具備在 QUIC 不可用時自動回退到 HTTPS 的機制，所以不用擔(dān)心因為 QUIC-BLOCK 而導(dǎo)致某網(wǎng)站不可訪問或 App 無法使用。

相比 HTTP/2，QUIC(HTTP/3)協(xié)議只有微弱的性能改善，同時由于兩者都使用了 TLS/1.3 作為安全層，所以安全性幾乎完全一致。而由不合適的代理轉(zhuǎn)發(fā)導(dǎo)致的性能問題大幅超過了 HTTP/3 的改善，所以完全沒有必要為了追求使用 HTTP/3 而放行 QUIC 流量。

如果因為開發(fā)與調(diào)試需要使用 QUIC，請在對應(yīng)代理策略的設(shè)置中調(diào)整 QUIC Block 選項。

為什么大部分代理協(xié)議不適合轉(zhuǎn)發(fā) QUIC 流量？ TCP 協(xié)議和 QUIC 協(xié)議都是可靠的傳輸協(xié)議，這表示他們在傳輸數(shù)據(jù)時，如果發(fā)現(xiàn)某數(shù)據(jù)包丟包，會自動將該數(shù)據(jù)包重傳。

我們看一下在一個假設(shè)情形中，TCP-based 的代理中轉(zhuǎn) QUIC 會出現(xiàn)什么問題：

發(fā)送數(shù)據(jù)段 A，該數(shù)據(jù)段被封裝進(jìn)了 QUIC 的 UDP 數(shù)據(jù)包 B，通過 TCP-based 的代理中轉(zhuǎn)又被封裝進(jìn)了 TCP 數(shù)據(jù)包 C。

網(wǎng)絡(luò)出現(xiàn)抖動，C 包被丟包了。

TCP 協(xié)議檢查到丟包，重發(fā) C‘2 包。

QUIC 協(xié)議也檢查到丟包，重發(fā) B’2 包，B’2 包在 TCP 層看來是新的數(shù)據(jù)流，產(chǎn)生新的 TCP 數(shù)據(jù)包 D 包。

可以看到，本來單次丟包所導(dǎo)致的重發(fā)，在雙重可靠傳輸協(xié)議的嵌套下，產(chǎn)生了雙倍的重發(fā)包。這里舉例的是一個最簡單的情況，如果丟包情況嚴(yán)重，那么 QUIC 層將產(chǎn)生大量的重發(fā)包，而 TCP 層又要保證所有的 QUIC 層重發(fā)包都被送達(dá)（實際上他們包含的數(shù)據(jù)是一樣的），TCP 層再產(chǎn)生大量的重發(fā)包，導(dǎo)致?lián)砣闆r承指數(shù)級上升。

以上只提及了眾多問題中的一個，還會有雙倍的 ACK 包，擁塞算法失效的問題。

所以，應(yīng)當(dāng)盡量避免在 TCP-based 的代理上使用 QUIC。但是如果 TCP 代理本身線路情況良好，極少丟包，同時 QUIC 流量不大，那么用起來可能確實感受不到明顯問題。但是實際上也產(chǎn)生了不必要的額外開銷，性能遠(yuǎn)不如直接使用 TCP 層代理，所以除非是需要測試 QUIC 等開發(fā)者用途，請勿調(diào)整 block-quic 參數(shù)放行 QUIC 流量。

MITM 是用于解密 HTTPS 流量的工具，使用前應(yīng)先了解 MITM 的基本原理。可參考 Wikipedia。

首先應(yīng)確保完成 CA 證書安裝作（iOS/tvOS/visionOS 中除了安裝外還需要在系統(tǒng)設(shè)置中手動開啟開關(guān)）

在 Surge 中為特定主機名開啟 MITM，如 example.com。

打開 Surge 的 MITM 開關(guān)。

使用瀏覽器訪問 https://example.com/ 網(wǎng)站，觀察是否可以解密出完整的 URL 和 HTTP 方法。

如果順利，則表示 MITM 已正確配置并生效。

如果瀏覽器中的請求已經(jīng)可以被正確解密，但是一些 App 的請求卻顯示 MITM Failed，則說明該 App 使用了 SSL Pinning 機制阻止 MITM，請自行搜索相關(guān)關(guān)鍵詞了解詳情（一般來說 SSL Pinning 無法突破，強行繞過需要非常復(fù)雜的 hack 技術(shù)，如在越獄設(shè)備中注入 dylib 覆蓋相關(guān)驗證代碼。）

很多常見的應(yīng)用，如系統(tǒng)進(jìn)程發(fā)往 apple.com 與 icloud.com 的請求，F(xiàn)acebook，Instagram，X等等，都采用了 SSL Pinning 機制阻止 MITM。

Last updated 2 months ago