Shadowrocket 協定技術參考

選擇協定前提：協定、傳輸與路由分層

在 Shadowrocket 中選擇協定，首先要選擇與伺服器相同的通訊規範，而不是替同一條連線貼上速度標籤。伺服器只接受特定協定時，用戶端就必須選用相符類型；只在 Add Server 中改選另一種類型，並不會讓伺服器增加新功能。訂閱匯入的項目通常已包含這些條件，手動編輯前應先保留原項目，避免把單一問題變成多項參數同時變動。

一條連線包含不同職責

可將連線資料分成四層來看：位址與連接埠決定連線至何處；協定與驗證決定對方如何識別連線；傳輸與加密決定資料如何送達；路由規則則決定哪些請求交由該項目處理。這些層彼此相關，卻不能互相取代。密碼正確不代表憑證正確；憑證有效不代表伺服器接受該帳號；規則指定 PROXY，也不代表目前選取的伺服器一定可用。分層核對有助於理解為何「已連線但網頁無法開啟」仍可能有多種原因。

協定名稱不一定能完整描述外層傳輸。VMess、VLESS 可搭配不同傳輸設定；Trojan 常用於 TLS 連線；Hysteria2 使用以 QUIC 為基礎的傳輸；WireGuard 則建立網路層通道。若協定欄位出現 WebSocket、Host、Path 或 SNI，表示還需核對外層條件。不能只憑名稱推斷這些值，也不要直接複製其他項目中看似相近的內容。

先確認條件，再比較表現

實際可選範圍，是既有伺服器提供且目前用戶端支援的設定組合。若只有一個有效項目，重點在正確填寫與驗證，而非追求名稱看起來較新。若有多個可用項目，應先固定本地網路、目標網站與測試方式，再觀察連線成功率、首次內容出現時間、持續傳輸與背景行為。伺服器位置、負載、頻寬及中間網路都可能掩蓋協定本身的差異，因此跨伺服器測試不能直接歸因於協定。

資料安全也需要分層判斷。協定連線受到加密保護，不代表所有目標 App 都會忽略自身的安全要求；目標網站的 HTTPS 仍負責端對端身分驗證。反過來說，使用一般 HTTP 或 SOCKS5 連線時，也不能假定代理連線這一段會自動加密。查閱資料時，應區分代理連線、目標網站與網域解析三個環節，確認每一段由何種機制保護，而不是只看鎖頭圖示或名稱。

Global Routing 不會改變協定

Global Routing 中的 Config、Proxy、Direct 屬於流量策略。Config 依設定規則處理請求；Proxy 讓流量依代理模式處理；Direct 則用於直接連線。切換這些選項不會把 Shadowsocks 轉成 Trojan，也無法補上缺少的驗證欄位。排查時可使用合適模式隔離規則因素，測試完成後再恢復日常設定，避免臨時設定一直保留。詳細操作順序請參閱教學中的規則說明。

本頁討論相容性與設計取捨，不為任何協定一概排名。協定可以改善特定網路條件下的傳輸方式，卻無法增加伺服器實際頻寬，也無法消除無線訊號不佳或帳號失效的問題。將「能否建立正確連線」與「連線後是否符合目前需求」分開看，後續各章的參數說明才有明確用途。

Shadowsocks：加密代理的參數範圍

Shadowsocks 著重以精簡的代理協定承載連線，透過用戶端與伺服器共用的驗證及加密資料來處理資料。它不是遠端網路介面，也不要求將伺服器所在網路的所有路由交由用戶端處理。對使用者而言，最重要的資料通常是伺服器位址、連接埠、加密方法與密碼；這些欄位看似不多，仍須逐一相符，尤其不能因為位址與密碼相同，就認為加密方法可以自行更換。

加密方法不是可任意調整的偏好設定

不同方法對應不同的資料格式與金鑰處理方式。常見的驗證加密設計會同時檢查資料是否遭到竄改，而不只是隱藏內容。用戶端應使用伺服器明確指定的方法；某些較新的方法還要求特定格式的金鑰，不能將其視為一般短密碼。若原始資料提供一整段編碼內容，請完整保留大小寫、符號與結尾字元，不要為了方便記憶而改寫，也不要自行加入空格或引號。

從連結匯入可減少手動輸入錯誤，但編碼的外觀不能取代核對。匯入後應確認協定類型、位址、連接埠與方法是否符合既有資料；遇到無法識別的連結，應先確認連結是否完整，以及是否包含需要額外支援的擴充功能。不要只複製瀏覽器顯示的一部分，也不要把顯示名稱當成驗證欄位。項目名稱只是方便辨認的備註，通常不會影響伺服器驗證。

TCP 與 UDP 必須分別確認

網頁連線通常依賴可靠傳輸，但即時通訊或部分 App 也可能使用 UDP。Shadowsocks 能否處理相關流量，取決於用戶端設定、伺服器支援與中間網路是否都符合條件。網頁可用但某項即時功能失敗時，不要立即判定是密碼錯誤；應先確認該功能使用的傳輸方式，再核對伺服器是否啟用相應轉送，以及本地網路是否允許該流量。一次網頁瀏覽成功，只能證明該次瀏覽使用的路徑可用。

有些資料會附帶額外的傳輸或外掛參數。這些屬於伺服器部署的一部分，並非所有 Shadowsocks 項目的通用要求。只有位址、連接埠與密碼，不一定足以重現包含擴充功能的連線。若目前介面沒有相應欄位，應回頭確認設定來源是否相容，而非尋找名稱相近的欄位勉強填入。支援協定與支援特定擴充功能是兩回事；成功匯入也不代表每項擴充功能都已實際使用。

如何理解 iPhone 上的效率

精簡的協定結構有助於減少額外處理，但不代表在所有環境下都更快或更省電。加密演算法的執行效率、伺服器處理能力、連線數量與無線網路重傳都會影響結果。瀏覽網頁與持續傳輸檔案的負載不同：前者更在意連線建立與小型請求的回應，後者更在意穩定吞吐量。若只比較一次大型檔案傳輸，可能會忽略日常 App 反覆連線時的實際體驗。

耗電方面，維持少量穩定連線與不斷失敗重連之間的差異，往往大於兩種正確設定之間的加密運算差異。若背景用量明顯改變，請先檢查項目是否反覆逾時、是否由 On Demand 持續觸發，以及切換網路後能否恢復連線。不能只因「Shadowsocks 參數少」就認定背景使用不耗電，也不能把系統記錄的所有網路活動都算成協定本身的耗電。

排查順序可簡單進行：先確認原項目尚未過期，再核對方法與密碼，接著檢查伺服器入口與本地網路，最後處理規則與解析差異。不要在一次失敗後同時更換方法、連接埠與 DNS；即使恢復，也無從得知真正原因。保留一份已確認的參考資料，日後訂閱更新時才能分辨是伺服器資料變動，還是本地編輯造成差異。

VMess 與 VLESS：分開檢視驗證與外層傳輸

VMess 與 VLESS 常見於採用多種傳輸組合的伺服器設定中，但兩者不是同一類型的不同名稱。VMess 定義自己的驗證與資料處理方式；VLESS 則著重精簡身分與請求描述，並將連線保護交由部署搭配的安全層處理。兩者都可能使用 UUID，卻不能只因 UUID 相同就互換。伺服器監聽的協定類型、傳輸方式與安全設定，都必須與用戶端完整相符。

為什麼要區分協定與傳輸

這些協定的使用情境包含多種傳輸組合與部署方式，因此一個項目不只描述「誰在連線」，也可能描述「透過哪種外層傳輸抵達」。兩個都標示 VLESS 的項目，外層傳輸可能完全不同。看到 WebSocket 時，還要核對 Host 與 Path；看到 TLS 時，還要核對與憑證身分相關的參數。任何一層不相符，都可能讓連線在進入真正的驗證階段前中斷。

UUID 是身分識別碼，不是網站位址，也不是可任意填寫的裝置名稱。請逐字複製既有資料，不要修改分隔符號，也不要換成另一個項目的值。VMess 驗證也要求時間正確，因此系統時間明顯錯誤時，應先恢復自動設定再重新驗證。時間錯誤也可能影響 TLS 憑證的有效期限判斷，因此並非 VMess 專屬的排查項目，但在這類項目中特別值得先檢查。

如何處理 VMess 相容性資料

舊資料可能包含額外的驗證相容欄位，新資料則可能採用不同的驗證規範。不要把舊教學中的固定數值當成所有伺服器的預設值，也不要為追求「新式設定」而自行修改原本有效的項目。優先使用目前伺服器提供的完整資料；若訂閱匯入與手動填寫結果不同，應比較實際欄位，而非顯示名稱。無法確認的選項，請向資料提供者詢問其在該伺服器上的用途。

VMess 的資料保護不應與外層 TLS 混為一談。是否使用外層傳輸、如何驗證憑證、是否經過中間轉送，都是獨立的部署條件。有些錯誤會顯示驗證失敗，有些則停在交握或路徑比對階段。若診斷記錄指出失敗階段，就先檢查該階段對應欄位；沒有明確記錄時，也應依位址、傳輸、憑證、驗證逐層縮小範圍，而不是反覆隨機更換加密選項。

VLESS 的精簡代表什麼

不應將 VLESS 理解為天生具備完整的連線加密。它減少了協定層承擔的部分職責，因此外層安全設定尤其重要。資料指定 TLS 或其他受支援的安全方式時，用戶端必須依該組合設定；不能只保留 UUID 與連接埠，就認為已還原整條連線。若出現 Flow 等附加欄位，也必須確認目前用戶端與伺服器確實支援相同組合；名稱相似並不能證明相容。

Host、SNI 與伺服器位址可能填入同一個網域，但用途不同。伺服器位址決定網路連線的目標；SNI 在 TLS 交握中提供服務名稱；Host 則可能參與外層請求的路由。Path 可能決定 WebSocket 請求抵達哪個處理入口。在多層轉送的部署中，這些值不一致未必代表設定錯誤，因此不能一律改成伺服器網域。應依原始設定中各欄位的用途填寫。

速度取捨取決於具體組合

直接傳輸、WebSocket 與額外的安全交握可能有不同的連線建立成本，但穩定連線可分攤一次性的成本。因此，包含許多小型請求的工作與長時間傳輸，可能得到不同結果。VLESS 的精簡不保證端對端一定比 VMess 快；伺服器負載、外層轉送與目標網站仍可能是主要限制。在 iOS 上應比較自己實際使用的完整項目，而不是依協定結構推測固定速度排名。

若既有資料明確指定某種傳輸組合，應先驗證該組合，不要先做效能最佳化。連線成功後，再分別觀察首次瀏覽、連續瀏覽與切換網路後的表現。調整安全參數前請保留原項目，尤其不要把關閉憑證檢查當成加速方法。相關名詞可參閱術語手冊；欄位設定仍應以既有伺服器說明與目前 App 提供的選項為準。

Trojan、HTTP 與 SOCKS5：代理入口的安全差異

這幾類協定都可用作代理連線方式，但安全層與驗證方式各不相同。Trojan 的設計以 TLS 連線承載代理請求，並使用相應密碼完成驗證；HTTP 代理透過 HTTP 語意建立或轉送連線；SOCKS5 則提供較通用的代理請求協商。選擇時應先確認伺服器實際提供哪一類入口，再確認連線區段是否加密；不能只因為它們都能轉送網頁，就視為完全相同。

Trojan：憑證驗證是連線條件之一

設定 Trojan 時，位址、連接埠與密碼只是基本資料，TLS 服務名稱同樣重要。伺服器位址可能是網域或 IP，但憑證通常是針對特定名稱簽發。SNI 用於在 TLS 交握中提示服務名稱；憑證驗證則進一步確認對端身分是否符合預期。兩者相關但並不相同；填入 SNI 不代表憑證必然可信，也不能任意填入網域作為通用值。請使用伺服器資料明確指定的名稱。

憑證過期、裝置時間錯誤、名稱不符或中繼憑證鏈不完整，都可能造成連線失敗。遇到這些情況，應核對系統時間與原始資料，必要時請伺服器管理者修復憑證。「允許不安全」之類的選項會改變身分驗證範圍，並非一般的相容性或加速功能。即使關閉驗證後一度成功連線，也只表示問題可能出在驗證環節，不代表問題已正確解決，更不應將此設定保留為日常使用狀態。

請依原始資料完整複製密碼，並留意尾端換行與空格。若伺服器還使用額外的傳輸封裝，相關路徑與請求參數也必須一併相符；不能假設所有 Trojan 伺服器都採用相同連線方式。若需要逐欄位說明，請參閱Trojan 密碼、SNI 與 TLS 參數說明。該文章說明填寫方式，不提供伺服器資料，也不能取代既有資料中的具體數值。

HTTP：區分代理連線與目標 HTTPS

HTTP 代理常見於明確管理的網路環境。對 HTTPS 目標，代理通常透過 CONNECT 建立通往目標位址的通道，目標 App 仍應執行自身的 TLS 驗證。但目標網站使用 HTTPS，不代表用戶端到代理的控制資訊也受到獨立 TLS 保護。若伺服器提供的是 TLS 代理入口，應確認目前項目的類型或安全設定確實符合該入口，而不是只把連接埠改成常見數字。

代理帳號與密碼不同於網站登入資料。驗證失敗時，先檢查是否需要使用者名稱、密碼是否正確，以及帳號是否允許目前來源連線。除非管理者明確說明，否則不要把瀏覽器登入頁面的憑證當成代理驗證資料。一般 HTTP 代理的功能也取決於實際部署，不能只憑能開啟某個網頁，就推斷它適用於所有 App 流量；需要 UDP 的工作尤其應另行確認是否適用。

SOCKS5：通用轉送不等於預設加密

SOCKS5 透過協商描述目標位址與請求類型，可支援網域格式的目標，並定義相關驗證與 UDP 轉送機制。不過，不應將協定本身視為加密通道。實際部署可能限制驗證方式、可連線目標或 UDP 功能；只有用戶端與伺服器都支援時，相應功能才會生效。只看到 SOCKS5 這個名稱，無法判斷伺服器是否允許特定流量，也無法得知連線本身受到何種保護。

由哪一端解析網域也是重要差異。即使協定可以傳送網域名稱，實際請求仍可能先由 App 或本地解析流程轉換為位址。排查時應一併考量 Shadowrocket 的 DNS 與規則設定，不宜只根據協定說明，就認定所有解析都會在遠端完成。若無法以網站名稱開啟，但直接輸入位址卻有回應，應檢查解析結果與規則命中情形，而不是立即更換代理帳號或把問題一概歸為驗證失敗。

日常使用應依既有環境選擇：若伺服器明確提供 Trojan，先完整核對憑證與密碼；若受管理的網路提供 HTTP 或 SOCKS5，先確認管理要求與安全範圍。不要為了看起來簡單而捨棄必要的 TLS，也不要為了嘗試不同名稱而批次改寫既有項目。在 iPhone、iPad 上，正確且穩定的連線方式，通常比反覆重試不相符的類型更有助於速度與耗電表現。

WireGuard：網路層通道與金鑰設定

WireGuard 與前述幾類面向代理請求的協定有一項重要差異：它描述的是透過加密通道承載網路層資料的方式。其設計採用相對精簡的協定與固定的密碼學組合，減少大量可協商選項。因此使用者不必在多種加密方法之間選擇，卻必須正確處理本地介面、對端身分與路由範圍。欄位看起來較少，不代表可以忽略網路規劃；位址、金鑰與允許範圍共同決定通道的功能。

Private Key 與 Public Key 的用途

本地 Private Key 用於識別並保護本端身分，Public Key 則用於識別相應對端。兩者彼此相關，卻不能互換。複製設定時，不要將自己的 Public Key 填入對端身分欄位，也不要把對端 Public Key 當成本地 Private Key。若原始資料包含額外的預共享金鑰，雙方也必須保持一致；它不是備註欄位，更不是連線不穩時可以任意刪除的項目。

本地私鑰屬於敏感資料。排查時可以記錄「已與原始設定核對相符」，但不應將完整內容貼到公開討論區，也不要讓它出現在公開截圖中。更換本地私鑰通常也需要更新伺服器端對應的身分關係，不能只在用戶端重新產生金鑰，就期待原伺服器仍會接受。若裝置遺失或需要撤銷設定，應請既有伺服器管理者處理對端授權，而不是只修改顯示名稱。

Endpoint、Address 與 Allowed IPs

Endpoint 指向對端的連線位址與連接埠；本地 Address 則是通道內使用的位址，兩者用途不同。將公網連線位址填入通道位址欄，或把通道內部位址當成外部伺服器入口，都會破壞預期連線。位址類型也必須符合實際設定：資料只提供某一類位址時，不要自行補上另一類。DNS 欄位通常描述解析設定，也不能取代本地介面位址或伺服器端點。

Allowed IPs 與對端可承載的位址範圍相關，也會影響 WireGuard 的路由與來源驗證。在 Shadowrocket 的整體處理流程中，還需搭配 App 的流量策略理解實際流向，不能將其簡單視為網站網域規則。範圍過窄可能導致某些目標無法透過通道連線；範圍過寬則可能偏離原有網路規劃。請依管理者提供的設定保留，不要為了「全部都能用」而任意擴大範圍。

行動網路中的保活與恢復

WireGuard 使用 UDP。行動裝置在 Wi-Fi 與行動網路間切換後，網路映射可能改變。協定雖有因應對端位址變化的設計，實際恢復仍取決於新的通訊能否抵達、伺服器是否接受，以及本地網路是否允許。必要時可使用 Persistent Keepalive 維持部分網路映射，但會增加週期性通訊。沒有適用於所有網路的固定數值，應遵照既有部署要求，再觀察背景活動與切換網路時的表現。

不要為了追求穩定而無限制縮短保活間隔。無線網路中，即使少量週期性資料也可能影響裝置進入睡眠狀態的機會；若網路本身穩定，且不需要維持網路映射，增加保活未必有幫助。反之，若原設定要求保活，完全移除也可能導致長時間閒置後的首次請求失敗。正確做法是針對明確問題驗證設定，記錄閒置後恢復情形是否改善，並觀察系統電池用量。

MTU 與局部失敗的關係

通道封裝會占用額外空間，因此應留意路徑可承載的封包大小。MTU 不合適時，可能出現小型請求成功、較大傳輸卡住，或部分網站能開啟而其他網站持續等待的情況。不過，這些現象也可能由其他原因造成，不能一遇到卡頓就修改 MTU。應先核對原始值與伺服器建議，排除規則、解析及訊號問題後，再一次只調整此項，並保留還原依據。

驗證不能只確認是否完成交握。交握代表雙方已完成某個階段的通訊，還必須檢查目標網段、DNS 與實際業務請求。若交握成功但業務無法使用，應優先核對通道位址、允許範圍與伺服器端轉送條件，而非反覆重建金鑰。如此可區分身分問題與網路規劃問題，避免繼續更動已設定正確的部分。

Hysteria2：QUIC 傳輸與頻寬參數

Hysteria2 的設計目標之一，是在有丟包、延遲或波動的網路路徑上維持可用的傳輸表現。它採用以 QUIC 為基礎的傳輸，底層依賴 UDP，並搭配相應的驗證與安全機制。所謂「因應網路波動」是一種設計方向，不代表在所有網路都能保證有效；若本地網路不允許所需的 UDP 通訊，或伺服器入口無法連線，改用另一個協定名稱也無法繞過基本的連線條件。

為什麼不能認為 UDP 天生更快

UDP 本身不提供可靠且有序的傳輸，但上層協定可在其上實作可靠資料流、重傳與壅塞控制。Hysteria2 的表現來自完整的傳輸設計，而不是省略所有可靠性處理。丟包仍需處理，伺服器也有頻寬與處理能力限制。較高的吞吐量也可能伴隨更大的實際傳輸量，因此比較時除了看完成工作所需時間，也要留意是否明顯影響同一網路上的其他工作。

QUIC 可提供多個串流，減少部分跨串流阻塞問題，但在無線訊號不佳、上行壅塞或路徑持續變化時，各串流仍會共用有限的網路資源。不要把「支援多串流」理解成單一請求完全不受其他請求影響。日常瀏覽與持續下載在意的指標也不同：前者可能更依賴解析與交握，後者更受穩定頻寬影響。只展示一段持續下載速度，不能代表所有工作都適合相同設定。

驗證、SNI 與憑證仍須逐項確認

位址、連接埠與驗證資料決定基本連線能否建立；TLS 相關設定則決定對端身分驗證是否符合預期。資料指定 SNI 時應保留原值；若憑證異常，則依名稱、有效期限與信任鏈逐步排查。不要因為底層使用 QUIC，就認為可以略過憑證檢查。即使其他協定能連上同一個伺服器位址，也只能說明另一個入口可用，無法證明目前的 UDP 入口與相應驗證都正確。

部分伺服器也會要求額外的混淆參數。這類參數必須與伺服器設定一致，並非啟用越多越好。只憑「連線失敗」無法判斷是否缺少此項；應先查閱既有資料，確認是否明確要求。若目前用戶端介面沒有某項擴充選項，應確認支援範圍，或改用既有資料明確指出相容的設定；不要把擴充密碼填進一般驗證欄，也不要自行嘗試名稱相近的開關組合。

頻寬欄位描述的是條件，不是期望值

上傳與下載頻寬參數可能影響傳輸速率與壅塞控制，實際效果仍取決於雙方設定與協商結果。填寫時應留意單位與方向：上傳通常指用戶端向網路傳送，下載則相反；位元與位元組並不相同。應依伺服器說明與實際連線能力設定，不要只求數值越大越好。過高的預估可能加劇佇列累積與丟包，反而拖慢其他互動請求。

行動網路的可用頻寬會隨訊號、位置與網路負載改變；Wi-Fi 的外部連線能力也不等於路由器標示的無線連線速率。因此，不宜直接以單次峰值作為長期參數依據。若既有資料未要求手動設定，應保留合理的原始設定，先確認目前的協商方式。調整後應測試連續傳輸與互動工作，而非只看瞬間速度；只有在相近條件下能重複改善，結果才有參考價值。

iOS 耗電與適用情境

工作更快完成時，裝置可能更早回到低活動狀態；但持續高流量、重傳與維持連線也會增加處理及無線通訊成本。兩種影響同時存在，因此不能一概將 Hysteria2 歸類為省電或耗電。長時間傳輸可觀察總完成時間與裝置溫度；背景閒置時則留意是否持續通訊或重連。分開測試不同情境，才能避免混淆結論。

若既有伺服器提供此協定，且目前網路允許相應 UDP 通訊，可將它納入實際工作比較。若只在特定網路失敗，優先確認該網路條件；若所有網路都失敗，再檢查驗證、憑證與伺服器入口。更多速度問題的定位方法請參閱網速慢的分層排查；尚未建立正確連線前，不要先調整頻寬參數。

速度與耗電：建立可重複的比較方式

協定結構可以說明潛在開銷，卻無法直接排出某台 iPhone 的體驗名次。一次瀏覽至少會經過本地無線網路、網域解析、代理入口、伺服器轉送與目標服務。任何環節都可能成為瓶頸；連線測試顯示的數值也只涵蓋特定測量流程。因此，應將速度問題拆分為連線建立、首次回應、持續吞吐與失敗恢復，再依目前工作選擇觀察項目，避免用單一結果評價整條路徑。

固定變因，才有比較意義

選用相同裝置、相同網路與相同目標，在相近條件下比較已確認可用的項目。開始前暫停與測試無關的大量傳輸，避免照片同步、系統更新或其他 App 占用頻寬。若兩個項目使用不同伺服器，應明確記錄差異；結論只能比較兩種連線方案，不能稱為單純的協定比較。若目標內容有快取，也應註明，否則後一次瀏覽可能只是在讀取不同位置的快取。

不要為了讓資料看起來整齊而連續、高頻率地執行所有診斷。測量本身會消耗流量、增加伺服器負載，也會改變裝置活動狀態。先重現實際使用情境，再用少量有針對性的測試補足原因，通常比不斷重新整理測試清單更有效。第一次結果異常時，可在相同條件下再次確認，但不應只保留最佳結果。記錄成功、失敗與切換網路的條件，通常比記下一個峰值更有助於定位問題。

Connectivity Test 能說明什麼

Connectivity Test 的意義取決於測試方式與目標。結果正常可說明當時的測試路徑完成了預定步驟，但不保證所有網站都能使用，也不能證明持續頻寬充足。結果逾時也不一定代表伺服器完全停止服務：測試目標、解析、驗證或本地網路都可能影響結果。應搭配實際網頁或業務請求解讀測試記錄，不要只按清單排序來判定協定優劣。

若網頁等候很久才開始顯示內容，優先檢查解析與交握；若很快開始但持續傳輸緩慢，再檢查頻寬、壅塞與伺服器負載；若只有特定目標失敗，則檢查規則命中、目標本身狀態與解析差異。若需要完整的逐項排除順序，請參閱節點逾時與連線失敗核對清單。相同症狀可能來自不同層，測試應用來縮小範圍。

電池用量需搭配活動情況解讀

iOS 電池用量頁記錄一段時間內與 App 相關的活動，百分比也會受其他 App 的用量影響，並非單獨測量協定耗電的工具。若一段時間內進行大量下載、連線測試或背景傳輸，用戶端相關用量上升並不意外。比較時應盡量維持工作內容、時間長度、螢幕狀態與網路條件接近，同時觀察裝置是否發熱、是否反覆連線失敗，以及耗電發生於前景操作還是背景閒置。

無線訊號較弱時，通訊成本可能明顯增加；穩定 Wi-Fi 與不穩定的行動網路環境不宜直接比較。加密運算固然會消耗資源，但許多行動工作中，無線通訊、持續傳輸與反覆喚醒也同樣重要。減少無效的失敗重連，往往比修改已相符的演算法欄位更實際。不能只憑協定參數多寡推斷耗電影響，也不能保證固定幅度的續航改善。

On Demand 與保活並非同一件事

On Demand 決定在符合條件時如何觸發連線；協定保活通常用來維持現有通訊關係或網路映射。前者無法修復伺服器驗證錯誤，後者也不能取代正確的按需規則。如果失效項目持續符合觸發條件，可能反覆嘗試連線；若保活過於頻繁，閒置時也可能持續通訊。排查時應分別觀察觸發條件與連線後的行為，不要同時修改兩組設定。

背景問題可進一步參閱On Demand 與背景耗電排查。最終選擇應符合自己的常用工作：連線穩定、切換網路後能恢復、閒置行為合理，再考慮持續傳輸速度。對於很少執行的大型檔案工作表現出色，不一定是日常瀏覽的最佳設定；保留在不同情境下已驗證的項目，比追求單一排名更實用。

填寫與驗證：從原始資料到日常 Config

將前述原理用於實際操作，可分為「保存原始資料、確認類型、核對欄位、驗證連線、恢復規則」五個階段。本章不重複首次開啟時的所有介面操作，詳細點選順序請參閱快速入門教學。本章適用於已能新增項目，但不確定匯入是否完整、某個欄位能否留空，或為何代理連線正常而日常規則仍然失效的情況。

匯入後先核對，不要立刻批次修改

使用自己的 Subscribe 資料時，應保留原始來源，並檢查更新後的項目是否位於預期群組。顯示名稱只是備註，不能據此判定協定與伺服器是否相同。手動修改由訂閱產生的項目，也可能在下次更新時被覆蓋，因此應先了解其管理方式。若要測試欄位，優先保留原項目並建立容易辨認的測試記錄，不要同時替換整個訂閱群組中的位址、連接埠或安全選項。

訂閱位址可能包含存取憑證，即使看起來只是一般連結，也應視為敏感資料。不要將完整位址貼到公開截圖或錯誤回報；若需說明格式，請使用明顯的範例值。本頁不需要使用者提交任何真實設定。核對資料時，可逐項確認類型、驗證、外層傳輸與安全欄位是否完整，再檢查是否因複製而帶入換行、空格或遭到截斷的內容。

依失敗階段選擇檢查方向

若連伺服器入口都無法連上，先檢查位址、連接埠與目前網路；若出現 TLS 或憑證錯誤，檢查時間、名稱與信任鏈；若進入驗證階段後失敗，再檢查密碼、UUID 或金鑰。若已建立連線但無法開啟目標，則應檢查 DNS、規則、伺服器轉送與目標本身的狀態。這個順序不保證每筆記錄都會清楚指出失敗階段，但能避免明明是憑證錯誤，卻反覆修改密碼。

若只在某個網路失敗，使用同一項目分別測試兩種網路；若只在某個目標失敗，使用同一網路檢查不同目標。一次只變更一項條件，結論才方便複查。若系統提示與 App 記錄互相矛盾，先確認測試時間與目前實際選取的項目。多次編輯後，顯示名稱相近的副本容易混淆；請透過欄位與群組確認項目，不要只憑清單位置判斷。

用簡短規則驗證策略，不要堆疊設定

協定連線正常後，再將 Global Routing 恢復為日常所需的 Config。以下是 Shadowrocket 設定中可查閱的簡短規則片段，僅用於說明順序與策略，並非完整設定。範例網域不是服務推薦；PROXY、DIRECT 的效果仍須搭配實際選取的項目與目前設定驗證。不要把片段加到不明位置後就認為已生效，請在 Config 中確認使用的是預期檔案。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

第一條依網域後綴比對，第二條依地理 IP 條件比對，最後一條則為未符合前述條件的請求指定最終策略。規則通常依序處理，因此較具體的條件應放在能正確覆蓋的位置。此處使用 FINAL,PROXY 只是展示語法，不代表所有使用者都應讓其餘流量走代理。若只想處理指定網站，應重新確認最終策略，並參閱指定網站的 DOMAIN-SUFFIX 設定說明。

確認結束條件與還原方式

一次完整驗證至少應涵蓋實際工作、規則命中、閒置後恢復，以及常見的網路切換情況。不必為了證明設定正確而瀏覽大量無關目標，也無須長時間連續測試。確認能穩定完成自己的工作後，就停止試驗性變更，恢復必要的日常策略，並記錄保留的設定。若測試失敗，先還原剛修改的項目，再沿著下一個方向檢查，避免不斷疊加臨時調整。

向既有服務商或伺服器管理者回報時，提供協定類型、失敗階段、網路條件及刪減後的錯誤描述即可；請移除真實密碼、私鑰、完整訂閱位址與個人存取內容。若問題與購買、已購項目還原或商店相容性有關，請前往已購項目還原說明及該頁常見問答，不要將帳號購買問題與協定驗證混為一談。系統需求與是否支援通用購買，請以 App Store 頁面標示為準。

協定參考的用途是將問題定位到正確的層級，而非鼓勵反覆更換名稱。位址與驗證負責連線，安全層驗證對端，傳輸方式影響資料如何送達，Config 則決定請求流向。沿著這條流程逐層確認，就能把「看起來相同的連線失敗」拆解為可檢查的小問題，也能在訂閱更新或更換裝置後，保留清楚且可還原的使用方式。