Shadowrocket 協定技術參考

01 / 選擇架構

先分清協定、傳輸與路由

協定類型首先是相容性條件，其次才是效能選擇。伺服器使用 Trojan，用戶端就應選擇 Trojan；將類型改成 Hysteria2，不會讓同一個連接埠自動接受另一種連線。匯入訂閱時通常已包含類型、位址、連接埠與驗證資訊，手動編輯應以伺服器端說明為準。如果只有一組可用資訊，首要目標是正確還原，而不是在協定清單中挑選看起來較新的名稱。

一條連線至少涉及四個層次

第一層是位址可達性，包括網域解析、目標連接埠，以及目前網路是否允許相關流量。第二層是傳輸方式，例如 TCP、以 UDP 為基礎的 QUIC，或透過 TCP 承載的 WebSocket。第三層是協定驗證與加密，例如密碼、UUID、TLS 憑證或金鑰。第四層才是應用程式目標與路由策略。前一層失敗，後一層通常就無法執行；因此，規則命中正確也不代表伺服器交握成功。

這些層次可以組合，但不能任意互換。某些 VMess 或 VLESS 部署會另外設定 TLS 與 WebSocket；常見的 Trojan 部署依賴 TLS；Hysteria2 則以 QUIC 為基礎。匯入資訊同時出現 Type、TLS、Host 和 Path，不代表要從四種協定中擇一，而是同一條連線必須同時符合不同條件。欄位名稱相同也不代表含義相同，應依所屬協定判讀。

速度、耗電與隱私是不同指標

速度至少包含首次連線耗時、小型請求的回應時間與持續傳輸量。某種協定可能下載大型檔案很快，卻因交握、網域解析或路徑繞行，導致網頁首屏載入較慢。耗電也受到無線訊號、重傳、背景連線維持與裝置溫度影響。單次 Connectivity Test 的數值不能代表全天使用體驗，更不能只憑名稱推論固定的耗電排名。比較時應盡量維持相同的伺服器區域、網路與測試項目。

加密範圍也應分開理解。用戶端至代理伺服器之間受到保護，不代表代理伺服器至所有目標網站的連線也自動加密；網站本身的 HTTPS 仍然重要。伺服器可觀察哪些連線資訊，取決於協定、目標流量與 DNS 路徑。本文討論正確設定與可解釋的效能，不會將任何協定描述為適用所有情境的隱私保證。

在 Shadowrocket 中保留可還原的基準設定

修改前記下節點所屬訂閱、目前的 Type 與重要欄位，並備份 Config。訂閱項目可能在更新時重新產生，直接修改後應確認變更是否會被覆蓋；實驗用副本應與日常使用的項目分開。分享記錄或截圖時，請隱藏密碼、UUID、私鑰與訂閱網址；排錯資訊只需保留欄位名稱、錯誤階段及已處理的主機資訊。先建立確認可用的基準，後續比較才有依據。

02 / 密碼與加密方式

Shadowsocks：設定步驟較精簡

Shadowsocks 的設計初衷是提供輕量的加密代理：在用戶端與伺服器之間建立受保護的轉送，而非負責完整的虛擬網路管理。通常需要位址、連接埠、密碼與加密方式，設定流程相對直接。這裡的「輕量」指的是結構，不代表在任何網路下都更快，也不代表所有 Shadowsocks 部署都彼此相容。雙方仍須使用相同的加密方式，並確認擴充功能與 UDP 支援狀況。

Method 與 Password 必須配對確認

Method 決定資料如何加密與驗證，不是可隨喜好切換的效能選項。伺服器採用某種 AEAD 方法，用戶端就必須使用相同方法與密碼。AEAD 同時提供加密與完整性驗證；資料遭到竄改或金鑰不符時，連線可能直接失敗，而不是顯示明確的「密碼錯誤」畫面。若將交握中斷直接歸因於網路速度，就會忽略最基本的欄位檢查。

不同方法對金鑰材料的要求可能不同。有些方法會以一般密碼衍生金鑰，有些則要求特定長度、並以指定編碼表示的金鑰，因此不能把所有 Password 都當成可任意替換的短語。複製時應避免多出換行、全形符號或前後空格；若匯入連結含有編碼內容，應交由用戶端解析，不要依肉眼看到的字串重新組合。訂閱能正常解析，也仍須確認伺服器端參數沒有變更。

TCP 可用，不代表 UDP 也可用

Shadowsocks 的 TCP 與 UDP 轉送使用不同的資料路徑。網頁能開啟，只代表相應的 TCP 請求已完成；語音、遊戲或部分 DNS 請求仍可能因 UDP 轉送條件不足而失敗。需同時確認節點是否允許 UDP、用戶端相關設定、伺服器監聽狀態與網路是否放行。如果目前的工作不使用 UDP，測試結果本身就不足以評估 UDP 能力。

還要區分「應用程式使用 UDP」與「協定透過 UDP 連線至伺服器」。某些代理協定可以透過其他承載方式傳送應用程式資料，兩者並非一一對應。排查 Shadowsocks 時，應具體記錄是網頁無法瀏覽、UDP 服務失敗，還是所有流量都無法使用。只寫「節點不能用」會混淆不同問題，降低後續排查效率。

如何判斷是否適合在 iOS 使用

設定條件較少，通常代表手動填寫時需要核對的項目也較少；但行動裝置的使用體驗仍受伺服器負載與無線連線影響。若裝置具備適合該演算法的硬體能力，加密運算的負擔可能較低；不過日常耗電通常更受持續傳輸、訊號微弱與重傳影響。討論 CPU 演算法時，不要忽略同一個房間內行動網路訊號與 Wi-Fi 的差異。

若現有伺服器明確支援特定的 Shadowsocks 參數，且用途是穩定使用常見 TCP 應用程式，可以先以此建立基準。若閒置一段時間後的第一個請求失敗，應區分連線遭回收、網域解析變更與伺服器狀態，不要立刻更換 Method。若部署額外要求擴充功能，請確認目前用戶端是否提供對應欄位；若缺少欄位，應向自己的服務提供者確認，而不是直接套用其他協定的 Host 或 Path。

03 / 分開看身分與承載方式

VMess / VLESS：類型相近不代表可以互換

VMess 將使用者身分驗證、代理請求與資料保護整合在同一套協定機制中，並可搭配不同傳輸方式。VLESS 的協定層設計則更精簡，將較多連線保護交由外部安全層或相關部署方案處理。兩者常以 UUID 表示使用者身分，容易讓人以為只要修改 Type 就能互換；實際上，伺服器監聽類型與配套傳輸方式都必須一致，UUID 相同也無法解決協定不相容的問題。

UUID 不是伺服器位址，也不是傳輸設定

UUID 是用來識別使用者的驗證資料，應完整複製，不可因字元較長而刪改。Address 和 Port 決定連線入口；UUID 決定請求使用哪組身分；TLS、WebSocket 等設定則決定這些請求如何承載。排錯時將各項分開記錄，可以避免不斷重貼 UUID，卻沒有檢查實際連線的連接埠。

VMess 的驗證機制與時間有關，裝置時間偏差過大可能造成連線問題。應先啟用系統自動設定時間並檢查時區，不要任意修改驗證相關的進階設定。若訂閱包含額外欄位，應依伺服器目前設定保留；照抄其他時期教學中的預設值，可能導致匯入成功但連線失敗。VLESS 也不是「省略驗證」模式，仍須驗證身分，只是協定的組織方式不同。

WebSocket 的 Host 與 Path 為何重要

伺服器透過 WebSocket 接收請求時，Path 通常會用來比對入口路徑，Host 則可能用於 HTTP 主機路由。Path 的大小寫、開頭斜線與路徑內容都應符合部署設定；Host 也不是填入任意網站網域就能提升速度的參數。如果伺服器沒有使用 WebSocket，啟用它反而會讓原本正確的連線變成不相容的請求。

TLS 的 Server Name 通常用於伺服器名稱指示與憑證名稱驗證，不能預設它和 WebSocket 的 Host 相同。許多部署中兩者的值相同，但所在層次不同。Address 可以是 IP，而 Server Name 仍可使用憑證對應的網域；也可能三者都使用同一網域。應依伺服器明確提供的組合填寫，不要因為三處內容看起來重複就刪除其中一項。

應依實際組合評估速度與耗電

「VMess 的速度」不是一個固定數值。同一協定搭配直接 TCP、WebSocket 或額外中繼轉送時，交握次數與連線路徑都可能不同。若首次瀏覽較慢、連線建立後下載正常，通常更應檢查 DNS、TLS 與承載入口，而不是立刻認定加密演算法降低傳輸量。額外封裝通常會增加一些資料量與處理負擔，但在實際網路中不一定是主要瓶頸。

VLESS 的協定層較精簡，也不能因此保證更省電。若伺服器距離較遠、無線網路重傳較多，省下的協定處理成本可能完全被連線成本抵銷。比較兩者時，應盡量使用條件相近的伺服器與相同應用程式工作，分別記錄首次請求、連續瀏覽與背景恢復。連線前後各測一次，無法代表全天使用情況。

匯入後優先檢查哪些項目

在 Home 中開啟對應項目的編輯頁，依序檢查 Type、Address、Port、UUID，再確認傳輸方式、TLS、Host、Path 與伺服器要求的其他欄位。每次只修改一項，並重新建立連線，避免舊連線影響結果。若同一訂閱中的多個項目都驗證失敗，先確認訂閱是否已更新，以及裝置時間是否正確；若只有單一入口失敗，優先檢查該入口專用的路徑與憑證設定。

04 / 憑證與身分

Trojan：完整檢查 TLS 條件

常見的 Trojan 設計會透過 TLS 連線承載代理請求，再以密碼識別使用者。它利用成熟的 TLS 機制建立受保護的用戶端至伺服器連線，因此憑證、名稱與時間都是連線條件的一部分。設定畫面可能只有位址、連接埠與密碼，但不代表可以忽略 TLS。許多「密碼正確卻連不上」的問題，其實發生在伺服器驗證密碼之前。

了解 Address、Server Name 與憑證

Address 用來定位伺服器；Server Name 通常會影響 TLS 的伺服器名稱指示與憑證驗證。伺服器收到名稱後，可能會選擇對應的憑證與站點入口。用戶端則須確認取得的憑證是否可信、是否在有效期限內，以及是否涵蓋目標名稱。若直接將 Address 改成 IP，卻未保留正確的 Server Name，可能會連到正確的主機，仍然無法通過驗證。

憑證網域不符、憑證鏈不完整或裝置時間異常，都可能造成 TLS 交握失敗。排查時先確認錯誤發生在哪個階段：若 TLS 尚未完成，就不要反覆重設 Password。若 TLS 已通過但驗證遭拒，才檢查密碼、帳戶狀態與伺服器監聽類型。錯誤資訊不完整時，可在已知正常的網路環境中使用同一項目重測，判斷是網路路徑差異還是固定的參數錯誤。

不要把略過驗證當成一般修復方式

憑證驗證用來確認伺服器身分。略過驗證有時能暫時消除錯誤，但也放棄了這項確認，不能證明原本的設定已修復。若部署使用特定信任資料，應依伺服器提供的可信說明設定；一般使用者不應只為了讓連線按鈕顯示成功，就永久忽略名稱或憑證錯誤。記錄具體錯誤並確認伺服器憑證設定，通常比略過檢查更有助於診斷。

連線重用與網路切換的影響

TLS 交握需要成本，但已建立的工作階段與首次連線不能混為一談。瀏覽器與應用程式會重用部分連線，系統也可能快取網域解析結果，因此第二次開啟網頁往往比第一次快。這不代表某種協定特別加速。若要比較，應分別記錄冷啟動與連續瀏覽，避免拿新建的工作階段與已完成預熱的工作階段相比。

iPhone 從 Wi-Fi 切換到行動網路時，來源位址與原有連線狀態會改變。對 TCP 連線來說，既有連線通常需要重新建立，頁面短暫停頓可能是正常的恢復過程。On Demand 會影響何時觸發連線，但無法讓所有既有 TCP 工作階段跨網路切換後維持原狀。若持續無法恢復，再檢查系統網路權限、目前節點，以及應用程式是否正確重新嘗試連線。

適用條件與實際取捨

若既有部署提供明確的 TLS 名稱、有效憑證與密碼，Trojan 的檢查流程相對清楚，可列為一般網頁與應用程式流量的候選方案。使用 TLS 不代表它必然比其他方案快；存在交握也不代表一定更耗電。弱訊號下反覆重連、伺服器壅塞與背景連線維持，都可能比一次交握耗費更多資源。

若只有少數應用程式失敗，應繼續依各應用程式需求拆解問題，而不是立刻更換協定。有些應用程式需要 UDP，有些取決於不同的 DNS 結果，還有些請求實際上被 Rule 導向 DIRECT。先確認請求確實經過這個 Trojan 項目，再判斷伺服器是否支援相應服務。連線逾時的一般排查順序請參閱延遲測試、協定參數與系統時間排查。

05 / 通用代理介面

HTTP / SOCKS5：轉送能力與加密界線

HTTP 代理源自應用層轉送需求，常見於瀏覽器與組織網路；SOCKS5 則提供較通用的代理協商與轉送機制。兩者的優點是介面明確、適用軟體較多，而非預設提供完整加密。選擇時必須確認：用戶端至代理入口之間是否另有 TLS 或可信網路保護、使用何種驗證方式，以及是否需要轉送 UDP。只有使用者名稱與密碼，無法回答這些問題。

HTTP CONNECT 不等於代理連線已加密

HTTP 代理可以接收一般 HTTP 請求，也可以透過 CONNECT 建立通往指定目標的通道。瀏覽 HTTPS 網站時，網站的 TLS 通常會在該通道內建立，但用戶端與代理伺服器之間的協商是否加密，是另一項條件。目標網站使用 HTTPS，不代表代理驗證資訊在所有連線方式下都受到相同保護。應區分網站的 TLS 與連線至代理入口時使用的 TLS。

若伺服器明確提供受 TLS 保護的 HTTP 代理入口，應依其位址、連接埠、憑證名稱與驗證資訊設定，不要只因網站網址以 HTTPS 開頭就勾選相關選項。反之，一般 HTTP 代理入口也不會因用戶端任意啟用 TLS 就自動升級；雙方設定不一致時，常見結果是交握失敗或連線中斷。

SOCKS5 的驗證、DNS 與 UDP

SOCKS5 可協商驗證方式，並支援以網域或 IP 指定目標。網域由本機解析還是交由代理端解析，會影響解析結果與故障位置；但實際路徑也受 Shadowrocket 的 DNS 設定與路由行為影響，不能只看協定名稱。排查時應確認請求使用的是網域還是 IP，以及記錄中顯示的解析與轉送順序。

SOCKS5 標準包含 UDP ASSOCIATE，但不是每台伺服器、每個帳戶或每種網路都提供可用的 UDP 轉送。控制連線成功，不代表後續 UDP 連接埠在目前網路中也可連線。一般 HTTP CONNECT 通常用於 TCP 通道，不應視為通用的 UDP 能力。語音與即時服務應依伺服器實際功能進行驗證，不要只憑「支援代理」四個字推論支援範圍。

在行動裝置上的使用考量

若使用者已有組織網路提供的 HTTP 或 SOCKS5 入口，應優先依管理說明設定，不要只因協定名稱不同就自行替換。行動網路經常切換，組織入口也可能只允許特定來源網路；辦公室 Wi-Fi 可用、行動網路不可用，不一定是用戶端填錯密碼。應先確認入口開放範圍、位址解析與驗證條件，再比較協定處理成本。

這類介面的協商流程可能較簡單，但實際速度仍取決於伺服器與目標之間的連線。代理入口離裝置很近，卻需要繞道連至較遠的出口，仍可能導致回應時間較長。耗電方面也不能斷定「協定沒有額外加密就一定更省電」；持續斷線重試會造成額外喚醒，不恰當的連線維持策略也可能抵銷較少的運算工作。

若驗證失敗，依序檢查伺服器要求的驗證方式、使用者名稱格式、密碼與帳戶權限。若只有網域目標失敗、IP 目標正常，接著檢查 DNS 路徑；若只有 UDP 服務失敗，檢查轉送能力與網路連接埠。分別記錄這三種情況，通常比頻繁切換 Global Routing 更容易找出原因。

06 / 三層隧道

WireGuard：一併檢查金鑰、位址與路由

WireGuard 的設計目標是建立結構精簡的三層加密隧道，透過對等端公鑰識別身分，並以 UDP 傳輸 IP 資料。它與依請求轉送的應用程式代理不同，因此還需了解隧道位址、對等端與路由範圍。在 Shadowrocket 中使用時，也要區分 WireGuard 對等端設定與用戶端本身的 Rule；兩者作用於不同層次，不能互相取代。

Private Key 與 Public Key 的使用方向

Private Key 屬於目前的對等端，應妥善保密；Public Key 則可提供給需要識別該端的另一方。用戶端設定中的對端 Public Key 應指向伺服器，伺服器則需識別用戶端的 Public Key。若兩端公鑰填反，或修改私鑰後沒有同步對應公鑰，交握便無法建立。金鑰字串不是一般密碼，不能只因長度相近就互換。

若設定包含 Preshared Key，它是雙方額外共用的驗證資料，兩端必須一致。Endpoint 表示遠端可連線的位址與連接埠，不是隧道內部位址。介面 Address 表示裝置在隧道中的位址，也不應直接照抄 Endpoint。伺服器可能還會限制某個對等端可使用的來源位址，因此即使「交握成功但資料不通」，仍須檢查位址配置。

Allowed IPs 與 Rule 各自負責什麼

Allowed IPs 在 WireGuard 架構中會參與對等端選擇與接收來源限制，含義與一般代理的網域規則不同。流量是否進入隧道也取決於用戶端的整合方式，因此看到完整網段，不代表 Shadowrocket 的所有請求必然經過該隧道。先查看 Global Routing 與 Rule 選擇了什麼策略，再確認交由 WireGuard 處理的流量是否符合對等端設定。

若隧道需要存取內部網段，應確認這些網段沒有與目前 Wi-Fi 的本機位址衝突。家庭網路與遠端網路可能使用相同的私有位址區段，造成路由判斷混淆。調整時應依實際網路拓樸處理，不要簡單地將所有本機網段都送往遠端，否則區域網路裝置存取與本機 DNS 都可能受到影響。

Keepalive 與行動網路的耗電取捨

Persistent Keepalive 用來協助維持 NAT 對應，不是提升下載速度的開關。需要由外部主動連線，或網路很快回收閒置對應時，它可能派上用場；但更頻繁傳送保活封包，也會增加無線模組活動的機會。若只在前景發出請求，沒有證據顯示閒置後恢復異常時，不應將保活間隔設得過於頻繁。應先確認是否確實有閒置後無法恢復的問題。

WireGuard 可依有效的驗證資料更新對等端位址，能適應部分位址變化，但不代表所有上層應用程式工作階段都能毫無停頓地跨網路延續。Wi-Fi 與行動網路切換後，新的 UDP 路徑是否可達、NAT 對應是否更新，以及應用程式是否重新嘗試，都會影響恢復情形。先觀察交握與收發狀態，再判斷是隧道層還是應用程式層停滯。

MTU 不是越大越好

隧道封裝會占用額外位元組，實際路徑允許的封包大小也可能小於本機介面的上限。MTU 不合適時，可能出現小型請求正常、大型回應卡住，或部分網站反覆載入的情況。先排除伺服器負載與封包遺失，再依部署說明有記錄地調整；一次只改一個值，並以相同工作重新測試。不要照抄不同網路的數值，也不要把所有大型檔案傳輸變慢都歸因於 MTU。

若已有完整的 WireGuard 設定，且用途包含明確的隧道網段或長時間連線，可依原設定建立基準。若只有一般代理訂閱，就無法憑空推導出金鑰、介面位址與路由。選擇依據應是伺服器的實際能力與工作需求，而不是把「三層隧道」理解成一定比應用程式代理更進階。

07 / QUIC 與壅塞控制

Hysteria2：先確認 UDP 路徑

Hysteria2 以 QUIC 建構代理傳輸，著重於封包遺失、往返時間較長等情境下的連線表現。QUIC 執行於 UDP 之上，並整合以 TLS 為基礎的安全交握與多路串流傳輸。這種設計提供不同於單一 TCP 位元組串流的處理方式，但實際效益仍取決於網路狀況。若目前網路不允許相關 UDP 流量，再好的壅塞控制也無法取代基本的連線可達性。

多路串流能減少哪類等待

在單一 TCP 連線中，前面的資料遺失時，必須補齊後續位元組才能依序交付。QUIC 可讓不同串流的資料較獨立地交付，減少跨串流的順序等待；但同一串流仍須符合可靠傳輸要求，不同串流也仍會共用底層網路頻寬。不能將「多路串流」理解成不受封包遺失影響，更不能因此保證所有網頁都會更快。

QUIC 仍須進行加密、壅塞控制與封包處理，行動裝置上的運算與喚醒成本取決於實作方式與工作內容。訊號微弱時重傳較多，耗電可能增加；部分高傳輸量工作若能更快完成，也可能縮短持續傳輸時間。因此應分別比較短請求、大型下載與待機後恢復，不要只看一次下載峰值就推論全天更省電。

分別檢查驗證、TLS 與混淆欄位

Hysteria2 項目通常包含伺服器位址、連接埠、驗證資訊與 TLS 相關條件。Server Name 應符合伺服器憑證與入口設定；密碼或驗證字串應完整保留。若部署另有混淆設定，用戶端與伺服器的類型及密碼也必須一致。混淆不是任何伺服器都能自行啟用的強化功能，雙方設定不一致會直接影響通訊。

協定世代也必須相符。名稱相近的不同世代不代表驗證格式與交握方式相同，不能只修改顯示名稱就完成轉換。應優先使用伺服器提供的可匯入資訊，並檢查匯入後的 Type 是否確實對應 Hysteria2。若訂閱解析後出現不熟悉的欄位，不要為了讓設定「看起來簡潔」就刪除，應先確認欄位用途與用戶端支援情況。

頻寬參數不等於購買到的速度

若設定包含上行、下行或壅塞控制相關欄位，應先了解欄位的實際單位與作用。有些設定是向演算法提供頻寬預估，並不會增加實際頻寬。填入過高的數值，可能使傳送量超出連線負荷，造成排隊、封包遺失或影響其他應用程式；填得過低則可能限制傳輸量。伺服器端限制與目前網路瓶頸依然存在。

行動網路的可用頻寬會隨訊號、位置與壅塞狀況變動，適用於固定寬頻的參數不一定適合行動網路。若下載速度快但網頁回應變差，應觀察頻寬是否持續被占滿，而不是繼續調高數值。對重視即時回應的工作而言，穩定的排隊延遲往往比峰值傳輸量重要；選擇協定時應以實際需求為準，而不是只看測速畫面中的單一結果。

發生問題時先區分連線路徑與驗證

若同一裝置在某個 Wi-Fi 下無法連線，切換行動網路後立即正常，優先檢查 UDP 路徑與網路策略；若兩種網路都在相同交握階段失敗，再檢查類型、驗證、憑證與系統時間。若連線後大型傳輸異常，則繼續觀察封包遺失、伺服器負載與封包大小。保留問題現象與每次變更，才能判斷 Hysteria2 是否適合目前環境，不要把偶爾成功當成穩定可用。

08 / 實測與判斷

以相同工作比較，再依層次排查

選擇協定的最終依據，是同一裝置在實際工作中的可重複表現。先確認候選項目參數正確、伺服器狀態正常，再分別測試網頁首屏、連續瀏覽、長時間傳輸與閒置後恢復。每輪只變更協定或節點其中一項主要條件，並記錄網路、訊號與測試項目。不同地區、不同負載的伺服器不能直接用來證明某種協定天生更快。

分開設定 Global Routing 與協定類型

Global Routing 的 Config、Proxy、Direct 決定請求如何選擇路徑，不會改變伺服器協定。Config 依目前設定的規則分流；Proxy 將適用流量交由代理策略處理；Direct 則直接連線。暫時使用 Proxy 進行對照，有助於排除部分規則影響，但不代表所有系統流量、區域網路例外與 DNS 行為都會一併改變，仍須配合實際設定與記錄判斷。

以下僅為獨立的 Rule 語法範例，並非可直接取代現有檔案的完整設定。規則會由上而下判斷，FINAL 負責處理此前未命中的請求；此處的 PROXY 表示代理策略，DIRECT 表示直接連線。修改前應備份 Config，並確認目前設定中有可用的相關策略。

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

規則比對與 DNS 有關：IP 類規則需要相應的目標位址資訊，網域規則則需要請求保留可供比對的網域。若記錄顯示某項請求使用 DIRECT，應先檢查 Rule 順序，不要據此評估代理協定效能。更多比對對象與順序說明請參閱規則關鍵字入門。

建立四類測試紀錄

第一類記錄連線是否建立及失敗階段；第二類記錄相同小型請求的回應穩定性；第三類記錄持續傳輸是否明顯波動；第四類記錄鎖定螢幕、解鎖與切換網路後的恢復情況。Connectivity Test 可提供快速線索，但測試目標與方式不等於所有應用程式的實際表現。偶爾出現低延遲，不能抵銷連續請求失敗；單次逾時也不足以證明伺服器永久無法使用。

比較耗電時，應盡量維持亮度、訊號、溫度、應用程式與傳輸量相近，並觀察足夠長的使用時間。系統電池用量統計可能將部分耗電歸因於前景應用程式或網路相關程序，因此不應只看 Shadowrocket 的百分比。裝置發熱時，先排除大型檔案持續傳輸與訊號微弱等因素；測試條件不穩定時，不要替協定排出精確的耗電名次。

依失敗階段縮小排查範圍

完全逾時時，先檢查位址、連接埠、網路可達性與 TCP / UDP 條件；出現 TLS 錯誤時，檢查名稱、憑證與系統時間；驗證遭拒時，檢查密碼、UUID 或金鑰方向；連線建立後只有部分應用程式失敗，再檢查 DNS、Rule、UDP 能力與目標服務。每輪只修改一項，重新連線並重做相同測試；若問題沒有改善，就回到基準設定，避免錯誤層層累積。

日常瀏覽網頁時，先確認既有設定是否完整且穩定；明確需要 UDP 的應用程式，先檢查端到端能力；涉及內部網段的工作，確認隧道位址與路由；高傳輸量工作，再比較持續表現。若仍無法排查，請帶著已隱藏敏感資訊的現象紀錄查閱常見問題；需要重新整理操作步驟時，請返回入門指南，不要用頻繁切換協定取代分層檢查。