Shadowrocket 協定詳解
類型選擇與參數核對

先確認連線兩端

在 Shadowrocket 中選擇協定，實際上是讓用戶端採用伺服器能辨識的通訊格式。Type 並非速度等級；伺服器提供 Shadowsocks 時，單純把用戶端改成 Trojan，並不會因此換成另一種連線。伺服器位址、連接埠、身分憑證、加密方式與傳輸條件共同構成可用的設定，任何關鍵條件缺漏，都可能在建立連線前失敗。既有訂閱通常會包含這些資訊，但成功匯入只代表資料已解析，不表示伺服器目前連得上。

理解連線時，可以把一次請求拆成三個部分：應用程式要存取的目標、Shadowrocket 連線的伺服器，以及將請求送往該伺服器的本機網路。目標網站的 HTTPS 與用戶端到伺服器之間的 TLS 並非同一層。瀏覽器顯示安全連線，只能說明目標連線的憑證驗證結果，不能據此推斷所選代理協定的外層也有加密。反過來說，外層採用 TLS，也不能取代應用程式對目標憑證的檢查。

協定類型不等於承載方式

Shadowsocks、VMess、VLESS 和 Trojan 描述的核心機制各不相同；TCP、UDP 是底層傳輸概念；WebSocket、HTTP/2、QUIC 則各有自己的工作階段與封裝方式。某個協定支援某種傳輸，不代表伺服器已啟用該功能，也不代表任意用戶端組合都能互通。閱讀資料時，應分別記錄協定類型、傳輸類型與 TLS 條件，不要把一長串名稱當成可以任意互換的同義詞。

以完整任務衡量速度與耗電

速度至少包含建立連線的等待時間、收到第一個回應的時間、持續傳輸吞吐量，以及中斷後的恢復情況。單次輕量測試只涵蓋其中一部分。TCP 建立連線快，不代表大型檔案傳輸也快；下載吞吐量高，也不代表頻繁的小型請求都能即時回應。行動裝置還會受到無線訊號、電信業者調度、伺服器負載與目標網站限制影響，因此本手冊不依協定名稱提供固定速度排名，也不把單次測試數字當成長期表現。

耗電量取決於完成相同任務所需的總工作量。加密運算、封裝、重傳、連線保活與喚醒無線模組都會消耗資源；訊號很弱時，無線通訊的耗能可能比協定差異更明顯。比較時應固定裝置、網路、伺服器與測試任務，觀察一段時間的完成狀況，而不是只看開啟連線後電池電量是否立刻變化。持續保活可以縮短部分恢復等待時間，卻也可能增加背景喚醒，須依使用方式權衡。

路由則屬於另一套判斷流程：即使伺服器資料完全正確，請求仍可能透過 Direct 直接送出。排查前先確認 Global Routing 的模式與實際命中的規則，再討論協定是否正常運作。設定、代理與直連分別對應介面中的 Config、Proxy、Direct；它們決定請求採用哪條路徑，不會把伺服器轉換成另一種協定。

設計背景與主要取捨

Shadowsocks 的設計重點，是提供相對輕量的加密代理轉送機制：用戶端將目標請求封裝後交給伺服器，再由伺服器連線至目標。它不是完整的虛擬網卡協定，不負責替裝置配置一整套遠端區域網路身分。對使用者而言，最基本的設定通常包括伺服器位址、連接埠、加密方法與密碼。欄位數量看起來較少，不代表可以省略加密方法，也不代表所有名稱相似的實作都能互相相容。

不同世代的加密方法，在金鑰處理與資料格式上各有不同。採用 AEAD 的方法會同時處理機密性與訊息完整性，較新的方法也可能改變金鑰材料的格式與長度要求。因此，資料中的方法名稱必須與用戶端實際支援的項目完全相符。不要因為名稱都含有 AES 就任意替換，也不要為了「更強」而改用伺服器未設定的方法；兩端格式不一致時，通常無法正確解讀彼此傳送的資料。

如何核對四個核心欄位

Server 可以是網域名稱或 IP 位址，填寫的是代理伺服器，而不是想要造訪的網站。Port 應使用伺服器提供的監聽連接埠，不要依協定名稱自行猜測。Method 指定雙方約定的加密方法，Password 則必須保留原始內容。複製密碼時留意前後空格、換行與相似字元；某些方法要求特定格式的金鑰材料，不應先自行編碼，再將結果填入欄位。

分享連結中的編碼只是資料的呈現方式，不會改變底層協定。連結可能將方法與憑證編碼在一起，也可能帶有附加參數。能從剪貼簿解析出名稱，不代表所有擴充參數都已完整還原。匯入後應開啟項目，重點核對 Type、Server、Port、Method 與 Password。若資料另有指定外掛或特殊承載條件，也必須確認雙方都支援；只保留四個基本欄位，可能不足以還原原始設定。

TCP 正常但 UDP 異常的原因

Shadowsocks 可用於轉送 TCP，也能在實作與設定相符時處理 UDP。兩條路徑需要分別驗證：伺服器開放 TCP 連接埠，不代表同一連接埠的 UDP 也已開放；網路允許網頁請求，不代表所有 UDP 資料都能通過。若網頁可用但某些即時任務失敗，先確認任務實際使用的傳輸方式，再檢查 UDP 條件，不要立刻更換密碼。DNS 的解析路徑也可能與其他流量不同，應分開觀察。

在 iOS 上，Shadowsocks 的資源使用情況會受加密方法、資料量與處理器能力影響。硬體加速某些演算法可能降低運算負擔，但不適用於所有裝置與方法。輕量封裝有助於減少部分額外處理，卻無法消除訊號微弱時的重傳或伺服器壅塞。如果任務涉及持續傳輸，應比較完成相同檔案所需的時間與穩定度，而不是只憑「層數較少」就推斷一定更省電。

排錯時先檢查位址解析與連接埠是否可連，再核對方法與憑證。基本通訊正常後，若特定應用程式仍有異常，應檢查規則、DNS 與 UDP，而不是反覆修改加密欄位。一次只變更一項條件，並保留可運作的原始項目，有助於區分路徑故障與認證故障。

兩種協定的職責不同

VMess 在協定中包含認證與資料保護機制，使用 UUID 等資訊辨識用戶端，並有不同世代的認證方式。VLESS 則採用較精簡的協定結構，本身不提供與 VMess 相同的內建資料加密機制，通常需要搭配安全傳輸來保護用戶端與伺服器之間的通訊。兩者都可能有 UUID 欄位，但 UUID 相同不代表協定可以互換；Type 必須與伺服器設定一致。

VLESS 追求精簡，不代表「任何情況下都比 VMess 快」。實際連線可能同時包含 TLS、不同傳輸方式、連線多工與伺服器轉送，整體組合才決定最終負擔。某些舊版 VMess 設定還涉及額外的相容性參數；若既有資料保留這些資訊，應依伺服器實際要求核對，不要套用統一數值。遇到不熟悉的欄位時，先確認適用的協定世代，避免將舊參數硬套到新的認證方式。

UUID、時間與安全層

UUID 是身分憑證，不是伺服器位址，也不是任意備註。貼上時應保留連字號與所有字元；即使用戶端會自動調整大小寫，也不代表能自動補回遺漏的字元。若 VMess 認證依賴時間窗口，裝置時間明顯錯誤可能導致認證失敗，因此應先啟用系統的自動設定日期與時間。時間正確後仍無法連線，再檢查 UUID、協定世代與伺服器狀態，不要把所有認證異常都歸因於網路無法連線。

若 VLESS 設定中的 Encryption 依資料指定為 none，不能直接解讀為整條連線一定沒有保護，也不能因此忽略外層 TLS。應分別檢查協定層欄位與安全傳輸欄位。反過來說，若外層沒有建立安全通道，也不能只憑協定名稱就認定資料受到同等保護。是否使用 TLS、採用哪種伺服器身分驗證，以及是否使用特定 Flow，都必須逐項與原始資料核對。

WebSocket、Host 與 Path 的關係

若既有資料使用 WebSocket，用戶端會先依相應的 HTTP 升級流程建立連線，再透過該連線承載協定資料。Path 是伺服器或反向代理用來辨識請求的路徑，通常須保留開頭的斜線與原有大小寫。Host 是 HTTP 請求中的主機資訊，可能參與虛擬主機選擇；它可以與實際連線位址不同，但必須有伺服器設定作為依據，不要為了嘗試連線就隨意填入常見網域名稱。

SNI 則用於 TLS 交握，協助伺服器選擇憑證與網站設定。SNI 與 WebSocket 的 Host 分屬不同層，許多常見設定會使用相同網域名稱，但其中一個欄位不會自動代表另一個欄位。若 Server 填寫 IP，而憑證是簽發給網域名稱，通常仍須提供正確的伺服器名稱才能完成身分核對。只修改 Host 而未檢查 SNI，可能造成 HTTP 層正常、TLS 層卻仍然失敗。

在 iOS 上，外層 TLS 與承載層可能增加交握步驟；頻繁重建短連線時，等待時間會更明顯。連線多工可以減少部分重複建立的成本，也可能讓多個請求共用同一條傳輸連線，放大某些壅塞的影響。沒有固定的最佳開關，應從既有伺服器的相容條件著手，再觀察實際使用情況，不要同時啟用所有看似能提升速度的選項。

匯入長連結後，建議除了截圖，也記下欄位文字，特別保留 Transport、TLS、Host、Path、SNI 與 Flow 之間的原始對應關係。訂閱更新可能重新產生項目，直接修改由訂閱建立的項目未必能長期保留；需要測試時可複製成獨立項目並清楚標記用途，避免下次更新後誤以為設定自行失效。

Trojan 為何依賴 TLS 設定

Trojan 的基本設計是在 TLS 安全連線中完成認證與代理請求轉送。TLS 負責加密用戶端到伺服器的連線並驗證伺服器身分，Password 則用於協定認證，兩者不能互相取代。密碼正確但憑證名稱不符，連線仍可能在 TLS 階段中止；憑證正常但密碼錯誤，也可能在後續認證階段失敗。因此，檢查時應先確認安全通道，再核對協定憑證。

Server 決定實際連線的目的地，SNI 提供 TLS 交握所需的伺服器名稱，憑證則用來證明對端身分。若既有資料使用網域名稱，通常應保留該名稱，不要任意換成解析所得的某個 IP。網域名稱可能負責位址調度與憑證識別；即使改用固定 IP 暫時連得上，伺服器遷移後也可能失效。自有測試環境若使用特殊憑證，應依明確的信任關係設定，不要把略過驗證當成一般排錯步驟。

HTTP 代理與 HTTPS 目標是不同概念

HTTP 代理通常依請求目標轉送 HTTP 流量，也可透過 CONNECT 方法建立通往目標的位元組通道。存取 HTTPS 網站時，常見作法是先向代理請求 CONNECT，再於通道中與目標建立 TLS。目標 TLS 與用戶端到代理之間是否使用 TLS，是兩回事。如果代理本身使用明文連線，不能因目標網址以 HTTPS 開頭，就認為代理認證資訊所在的外層連線也受到相同保護。

在 Shadowrocket 項目中，Type、TLS 與相關認證欄位應依既有資料分別核對。Username 與 Password 可能用於代理身分認證，不應填入目標網站帳號。傳統 HTTP CONNECT 主要用於 TCP，不能據此推斷任何 UDP 任務都能透過代理。有些擴充機制可處理更多類型的流量，但只有在用戶端、伺服器與設定都明確支援時才成立；一般 HTTP 代理資料不應預設具備這些能力。

SOCKS5 能做什麼，不能做什麼

SOCKS5 是通用代理請求的協商協定，可指定連線目標、認證方式與 UDP 關聯等操作。基礎協定本身不負責加密資料。使用者名稱與密碼認證也不等於加密傳輸，選用時須了解所在網路與外層安全條件。它適用於受管理的網路或用途明確的代理連線，不應把「通用」理解為能自動適用任何伺服器，或自動保護所有連線。

SOCKS5 的 UDP 轉送還涉及 UDP ASSOCIATE、伺服器回傳的中繼資訊與後續資料路徑。TCP 控制連線建立成功，不能單獨證明 UDP 中繼可用。伺服器權限、網路位址轉換與連接埠開放狀況都可能影響結果。也須區分由哪一端解析網域名稱：請求直接帶入網域名稱，與先在本機解析後提交 IP，會形成不同的解析路徑；實際行為仍取決於用戶端路由、DNS 設定與請求類型。

行動裝置上的 TLS 交握需要網路往返與憑證處理；重複使用既有連線可減少重複成本，但訊號微弱、頻繁切換網路或伺服器主動中斷連線，仍會觸發重新建立。不能只因協定「看起來像一般 HTTPS」，就斷言它比較省電。應比較相同任務下的連線完成率、背景恢復速度與裝置溫度變化，並排除螢幕亮度及應用程式本身活動的影響。

選擇時不必把三種協定排出高低。既有伺服器明確提供 Trojan，就確認 TLS 與密碼設定相符；若有受管理的 HTTP 或 SOCKS5 介面，先確認權限、外層保護與目標流量範圍。與伺服器正確配對，比只憑協定名稱追求更複雜的組合更重要。

從代理請求轉為 IP 封包

WireGuard 以加密 IP 隧道為主要模式，採用固定的現代密碼演算法組合與公開金鑰身分，而不是讓使用者從大量加密方法中挑選。相較於以目標連線請求為核心的代理協定，它更像是將 IP 封包交由指定對端處理。這種模式適用於已部署相應網路、位址與路由的環境，但設定時必須一併考量本機隧道位址、對端身分，以及哪些目標可以經由隧道傳輸，不能只填入伺服器位址。

WireGuard 通常使用 UDP 傳輸，避免將整條 IP 隧道固定封裝在可靠的位元組串流中。協定精簡有助於降低部分實作複雜度，但 Shadowrocket 的實際效能仍取決於用戶端整合、系統網路延伸功能、伺服器處理能力與網路路徑。不能直接將其他作業環境的測試結果套用到 iPhone，也不能只因演算法固定，就推斷所有任務都比其他協定省電。

Private Key 與 Public Key 的對應關係

Private Key 是本機的身分機密，不可放入公開截圖、記錄檔或求助訊息。Public Key 用來辨識對端，兩端必須正確對應金鑰：用戶端保存伺服器公鑰，伺服器登錄用戶端公鑰。若兩者填反，或誤用了另一台裝置的配套資料，都會造成交握問題。Preshared Key 是可選的額外共享密鑰，只有雙方設定一致時才能使用，不可只在單邊任意新增。

Address 是配置給隧道介面的位址，Endpoint 則是實際聯絡對端的公開或可連線位址與連接埠，兩者用途完全不同。將隧道內部位址填入 Endpoint，通常無法從外部網路建立初始連線。IPv4 與 IPv6 也應分別核對；既有設定若只提供一種位址族，不要為了補齊欄位而自行編造另一組位址。DNS 設定決定網域名稱如何解析，不能取代 Endpoint 位址欄。

Allowed IPs 不等於全域規則

在 WireGuard 架構中，Allowed IPs 會參與判斷對等端可處理的封包範圍，也常用來決定哪些目標應交給該對端。它不等於 Shadowrocket 的完整規則系統。應用程式請求能否進入此項目，還須查看 Global Routing 與設定策略。若隧道交握正常但無法連線至內部網路目標，應一併檢查目標位址是否屬於允許範圍、遠端是否能轉送，以及回程路由是否知道如何返回用戶端的隧道位址。

MTU 過大可能使某些較大的封包無法順利通過網路路徑，出現小型請求正常、載入大量內容卻卡住的情況。調低 MTU 有時有助於定位問題，但不是數值越小越好；過小會增加封包分割與處理負擔。應先使用既有設定，遇到可重現的大封包異常時再小幅調整，並記錄前後差異。若真正問題在 DNS 或遠端路由，修改 MTU 通常無法帶來穩定改善。

Persistent Keepalive 用於在有需要時維持網路位址轉換的對應關係，常見於用戶端位於 NAT 後方，而遠端需要主動聯絡用戶端的情況。保活越頻繁，無線網路活動越多，可能影響行動裝置待機耗電；完全關閉則可能讓閒置後的首次通訊等待更久。是否需要保活，應由網路拓撲與使用需求決定，不應將某個間隔當成所有裝置通用的建議值。

排查 WireGuard 時，應分開看待交握與有效資料傳輸。交握成功表示金鑰與部分基本路徑已正常，不代表 DNS、Allowed IPs、遠端轉送與目標回程路徑都正確。切換 Wi-Fi 與行動網路後若恢復較慢，可先觀察對端更新與 UDP 可連線性，再檢查保活策略；尚未確認身分欄位前，避免同時調整位址、路由與 MTU。

為何採用 QUIC

Hysteria2 使用以 QUIC 為基礎的傳輸方式；QUIC 運作於 UDP 之上，提供安全連線與多重資料流等機制。其設計著重於延遲、封包遺失或頻寬變動網路中的傳輸表現，並搭配相應的壅塞控制策略。這裡使用 UDP，不代表可靠性全由應用程式使用者自行處理：QUIC 本身會完成所需的確認、封包遺失偵測與重傳。不能簡單將「使用 UDP」理解成資料可以任意遺失，或一定比 TCP 快。

QUIC 的獨立資料流機制可減少不同資料流受到可靠位元組串流依序交付所造成的部分阻塞，但同一資料流仍有順序要求，所有資料流也仍受可用頻寬與壅塞影響。如果本機網路限制 UDP，或對 UDP 設有嚴格的速率與映射規則，協定優勢可能無法發揮。伺服器提供 Hysteria2，也不代表目前網路一定能建立連線；應優先檢查連接埠、UDP 路徑與身分參數。

認證、安全與附加條件

Server 與 Port 指向實際伺服器，認證欄位必須與既有資料一致。TLS 相關的伺服器名稱與憑證驗證仍須正確設定，不能因底層使用 QUIC 就省略身分核對。若資料包含混淆條件，也要確認是否啟用及相應密鑰是否一致；兩端設定不符時，通訊可能在更早階段就失敗。不要把混淆密碼、認證密碼與憑證名稱填入彼此的欄位，它們各自負責不同工作。

不能只因名稱相近，就混用 Hysteria2 與舊版協定世代。匯入後應檢查 Type 是否正確，確認分享連結的解析結果與目前資料指定的協定類型相符。若伺服器要求的 ALPN、憑證條件或其他擴充設定未在用戶端正確還原，也可能造成交握失敗。遇到無法辨識的連結時，應先查閱資料來源提供的欄位說明，不要刪除不理解的參數後反覆匯入。

頻寬參數不等於速度保證

部分設定會提供上行與下行頻寬提示，用來影響特定壅塞控制模式的行為。這些值是演算法參考條件，不是向網路申請頻寬，也不代表調高數值就能獲得相應吞吐量。填入遠高於實際線路能力的數值，可能增加排隊、封包遺失與重傳，反而拖慢互動請求。填得過低也可能限制可用吞吐量，因此應依用戶端與伺服器所用模式的定義核對，不要照抄其他網路的數值。

單位同樣重要。每秒兆位元與每秒兆位元組並非相同數值；電信業者標示的連線速率、系統下載顯示與設定欄位可能採用不同單位。還須區分上行與下行，行動網路的上下行速率往往不對稱。只測一次下載峰值，不足以推斷持續上傳能力；若任務包含視訊通話或檔案上傳，上行排隊也可能影響其他請求。調整前應先保存原始值，以便恢復基準設定。

在 iOS 上，持續高吞吐量會讓無線網路與處理器保持活躍；以 UDP 為基礎的傳輸、使用者空間處理與封包遺失恢復也會增加工作量。但若能更快完成相同任務，有時可縮短無線網路活動時間，因此不能只看瞬間功耗來判斷總耗電量。應分別觀察短時間任務、連續下載與背景待機，不要直接比較全速傳輸與閒置狀態，再據此判定協定的耗電表現。

若網路對 UDP 的支援不穩定，應保留另一種既有可用組合供核對，不要反覆調高頻寬參數。網路路徑不通、憑證不符與演算法參數不合是三類不同問題，需要分層處理；先建立正確連線，再討論吞吐量最佳化，才能減少無效嘗試。

依欄位用途檢查匯入結果

匯入訂閱可減少手動填寫，但仍須核對。建議分四組檢查：位址組包含 Server 與 Port；身分組包含 Password、UUID 或金鑰；承載組包含 Transport、Host 與 Path；安全組包含 TLS、SNI 與憑證驗證。不同協定不會用到所有欄位，沒有出現的項目不必為了「完整」而自行新增。即使欄位名稱相同，也應依目前協定理解，尤其不要混用 Password 與各種附加密鑰。

位址中的網域名稱可能先由本機 DNS 解析，也可能受用戶端 DNS 策略影響；目標網站網域則可能採用另一條解析流程。伺服器網域解析失敗，會導致完全無法聯絡代理；目標網域解析異常，則可能出現代理已連線、特定網站卻無法開啟的狀況。兩者不能混為一談。先確認失敗的是哪個網域，再檢查相應的解析路徑，比直接更換所有 DNS 設定更容易找出問題。

三種模式決定請求是否經過該項目

Global Routing 的 Config 會依目前設定中的規則處理請求，Proxy 會讓可處理的請求採用代理路徑，Direct 則採用直連路徑。中文說明中的設定、代理、直連，分別對應這些介面用語。所謂「代理路徑」仍須有可用項目與策略選擇，不是切換到 Proxy 就會自動找到伺服器。使用 Config 時，請求可能被分流至 Direct，因此「網站能開啟」本身不足以證明選定的協定確實參與通訊。

規則通常依順序比對，較具體的條件應放在能正確表達意圖的位置。DOMAIN-SUFFIX 比對網域名稱後綴，GEOIP 依 IP 位址歸屬資料庫判斷，IP-CIDR 比對位址範圍，FINAL 則處理前面規則都未命中的請求。網域規則與位址規則使用的資訊不同，有些位址判斷需要先取得解析結果。資料庫涵蓋範圍、IPv6、目標實際位址與解析時機都可能影響比對結果；不要把規則關鍵字當成協定欄位。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

這段範例展示 Shadowrocket 設定中的規則列結構，並非可以直接取代整份設定的完整範本。PROXY、DIRECT 是此處使用的策略識別名稱，實際設定還需要有效的代理選擇與其他必要內容。第一行讓範例網域後綴採用代理策略；第二行將指定的私有位址範圍設為直連；第三行依位址歸屬判斷；最後一行則作為預設處理。不要將僅用來說明順序的片段，直接覆蓋尚未備份的個人設定。

設定檔與訂閱資料各有用途

訂閱通常用來更新伺服器項目，設定檔則可包含規則與其他設定，兩者不是同一種內容。既有訂閱更新後項目仍可用，但 Config 若指向舊策略，使用結果仍可能與預期不符。反過來說，規則檔正確但項目憑證已過期，也無法代理請求。排查時分別記錄「目前使用哪個項目」與「目前使用哪份設定」，不要只記顯示名稱，因為更新後可能沿用相同名稱。

IPv6 特別需要留意。伺服器網域名稱可能同時回傳 IPv4 與 IPv6 位址，目標網站也可能同時支援兩種位址族。如果本機網路其中一種位址族不完整，就可能發生連線時好時壞，或部分目標等待很久的情況。不要先認定是協定不支援；應查看實際連線選用的位址，分別驗證兩條路徑。規則中的 IP-CIDR 與 IP-CIDR6 也應依位址族使用，不能期待 IPv4 範圍規則同時涵蓋 IPv6。

驗證協定時，應使用明確會進入該策略的測試請求，再搭配連線記錄確認實際路徑。完成後恢復日常使用的 Config，並重新測試常用應用程式，避免把臨時測試模式當成最終設定。協定連通只是基礎，路由與解析正確才算完整可用。

先列出限制，再比較組合

選擇時第一個問題不是「哪種協定最快」，而是既有伺服器實際提供哪些完整組合。列出可用協定、UDP 條件、憑證要求與目標用途，再排除不相容的選項。若只有一種明確可用的設定，就先正確使用；若有多種組合，盡量在相同伺服器區域、相同時段與相同任務下比較，避免把伺服器效能差異誤認為協定效能差異。

在穩定的 Wi-Fi 下瀏覽網頁，通常較重視短請求、DNS 與連線建立；長時間傳輸檔案則較重視持續吞吐量與壅塞狀況。頻繁切換 Wi-Fi 與行動網路時，應留意恢復所需時間及應用程式能否重新建立連線；存取既有內部網路時，還須考量位址規劃、回程路由與權限。WireGuard 的 IP 隧道模式、通用代理的請求模式與 QUIC 的傳輸特性各有適用條件，不應只依名稱統一排名。

分六個階段縮小故障範圍

第一階段，檢查本機基本網路。在 Direct 模式下確認網路本身具備必要的連線能力，並查看是否需要先完成網路登入。第二階段，檢查 Server 的網域解析與連接埠條件，特別要區分 TCP 與 UDP。若根本無法聯絡伺服器，修改 UUID、Password 或規則順序通常無濟於事。此時應保留錯誤狀況，並使用另一個已知可用的網路進行比對，不要接連嘗試大量欄位組合。

第三階段，檢查 TLS 與憑證，包括系統時間、SNI、憑證網域與憑證鏈。第四階段，檢查協定認證，依 Type 分別核對方法、密碼、UUID 或金鑰配對。交握錯誤與認證錯誤在介面上都可能顯示為連線失敗，因此要依據記錄中明確的階段資訊判斷；若記錄沒有提供足夠證據，應說明目前無法確定，不要只憑「逾時」就認定密碼一定正確或一定錯誤。

第五階段，檢查路由與 DNS。確認測試請求進入選定策略、目標網域能得到合理的解析結果，相關位址族也能正常使用。第六階段，再檢查持續傳輸問題，例如 MTU、UDP 中繼、壅塞參數、伺服器負載或大量流量限制。只有前面各階段都正常後，調整效能欄位才有明確依據。若小型請求正常、大型請求失敗，應使用可重現的任務測試，而不是只重複執行一次 Connectivity Test。

如何進行有意義的耗電與速度比較

使用同一台裝置並維持相近的訊號條件，關閉與測試無關的大量流量任務，再分別完成相同的一組網頁瀏覽或同一大小的檔案傳輸。記錄任務從開始到完成所需時間、失敗次數、切換網路後的恢復情況，以及一段時間內系統電池統計的變化。不要拿不同螢幕亮度、不同訊號與不同前景應用程式的結果比較協定。瞬間溫度變化與單次電量百分比跳動都可能另有原因，必須重複觀察才有參考價值。

看待 On Demand 時，也應區分「依條件觸發連線」與「確保所有應用程式始終維持連線」。系統切換網路、應用程式暫停或遠端關閉連線，都可能觸發重新建立。更頻繁的保活能改善某些閒置後的恢復情況，卻可能增加待機活動；重複使用長連線可減少部分交握，但也可能讓多個請求共用一條壅塞路徑。先依原始設定使用，只有出現明確且可重現的問題時才調整這些條件。

最後保留一份已驗證可用的基準設定，再逐項嘗試最佳化。協定參數請回到本頁對應章節核對；首次連線流程請參閱使用說明；反覆發生的使用問題請查閱疑難解答；取得與首次安裝問題請參閱安裝放行說明。正確的結論通常是「這組設定在這個網路下完成了這項任務」，而不是替所有裝置與網路指定一種永遠最佳的協定。