Shadowrocket 協定參考

01 / FOUNDATIONS

協定分層與 iOS 效能判斷

將連線拆分成可逐項核對的層次

在 Add Server 中選擇類型，只能決定部分連線行為。一次代理請求還涉及伺服器位址、連接埠、身分驗證、底層傳輸、加密保護、目標位址解析與流量選擇。可以把協定理解為客戶端和伺服器約定的訊息格式，傳輸則是承載這些訊息的通道。同一協定搭配不同通道，連線建立流程、額外負擔與故障位置都可能不同；同一通道承載不同協定，也不代表驗證欄位可以互換。

例如 VLESS 可以搭配 TLS、WebSocket 等條件，但選擇 VLESS 後，這些條件不會自動成立。若伺服器要求特定路徑，客戶端無法只憑協定名稱推測路徑；若伺服器只接受一般 TCP，客戶端額外啟用另一種傳輸也不會因此相容。填寫前先將現有資訊分成「連線目標」、「身分驗證方式」、「傳輸通道」及「對端驗證方式」四類；缺少任何必要資訊，都應回頭核對原始設定。

吞吐量、回應時間與穩定性是不同指標

速度通常至少包含三個面向：首次開啟頁面的等待時間、持續下載時的吞吐量，以及通話或互動時的抖動。握手較多的組合，首次建立連線可能較慢，但長連線傳輸仍可維持穩定；頻寬較高的連線，也可能因排隊而造成互動延遲。Connectivity Test 有助於發現明顯無法連線的情況，但測試目標、連線是否重複使用、DNS 是否已有快取，都會影響結果，不能直接取代實際使用測試。

在 iOS 上，應用程式流量會經過系統網路延伸功能處理，效能不只取決於協定演算法，也受無線訊號、伺服器距離、伺服器負載與目標網站影響。Wi-Fi 訊號較弱時，鏈路重傳可能比加密運算更影響速度；行動網路頻繁切換時，重新連線的等待也可能比持續吞吐量更重要。因此，「某協定一定最快」缺乏可重現的技術前提，結論應限定在相同裝置、網路與測試項目下。

耗電量主要取決於連線的使用方式

耗電量不能只依協定名稱排序。行動網路模組喚醒、弱訊號下持續重試、大量短連線、過於頻繁的保活，以及背景持續傳輸，都可能增加耗電。握手較繁複但能穩定重複使用的連線，耗電量未必高於反覆失敗並重新連線的輕量連線。裝置發熱也須一併考量螢幕亮度、應用程式負載與充電狀態，不能只憑開啟客戶端前後的時間關係判斷原因。

測試耗電量時，先固定一段具代表性的使用情境，例如播放相同長度的影片或瀏覽相同文件，再查看系統電池頁面的活動時間與背景行為。不要在一組測試中持續執行 Connectivity Test，另一組卻維持待機。若兩次測試的訊號條件不同，參考價值就很有限；發現異常時，優先檢查背景是否有連線持續失敗、訂閱是否不斷重試，以及 On Demand 是否反覆觸發連線。

必須連同整條路徑確認協定能力

協定類型支援 UDP，不代表目前的伺服器、傳輸組合與目標都能傳送 UDP。客戶端入口、伺服器設定、網路對 UDP 的可達性，以及出口策略都必須同時符合條件。反過來說，能開啟某個網頁也不能證明 UDP 可用，因為網頁可能只使用 TCP。回報問題時應說明業務使用的傳輸類型，而不只是寫「網路正常」或「協定失效」。

本頁討論 iOS，是為了說明行動裝置上的使用取捨，並不表示其他平台缺少這些協定能力。實際欄位請以目前的 Shadowrocket 介面與伺服器設定為準；各平台的取得與安裝方式請見全平台下載。本頁不重複說明安裝步驟，也不根據裝置型號推測未經確認的相容條件。

02 / SHADOWSOCKS

Shadowsocks：共用憑證與加密方式

設計背景與適用範圍

Shadowsocks 的基本概念是讓客戶端與伺服器透過預先約定的憑證與加密方式交換代理資料，核心結構相對簡單。它不是可以任意替換底層欄位的通用容器：雙方必須理解相同的協定格式，並採用一致的加密方式。對使用者而言，重點不是記住名稱，而是確認訂閱中標示的類型、伺服器、連接埠、密碼與加密方式確實屬於同一個服務項目。

較新的認證加密設計會同時處理資料機密性與完整性，避免只有加密、缺少可靠驗證所帶來的問題。不同世代或擴充功能可能需要不同格式的金鑰，不能把任意一般密碼貼到所有加密方式中。客戶端清單中出現某種方式，只代表客戶端提供相應選項，不代表現有伺服器已啟用。應優先沿用服務商提供的完整組合，不要只為了使用名稱較新的方式而單獨修改加密方式。

Server、Port、Password 與 Method 如何對應

Server 是代理伺服器的位址，可以是網域名稱或 IP；Port 是該服務監聽的連接埠，不是目標網站的連接埠。Password 會與所選加密方式一同決定驗證或金鑰資料；大小寫有別，尾端空格也可能影響結果。Method 必須與伺服器一致；選錯時常見情況是底層連線已建立，卻沒有有效的業務回應，而不是明確顯示「加密方式不符」。

匯入後若項目存在但無法連線，先將這四個欄位與原始資訊逐項比對。特別留意複製時出現的全形符號、換行、截斷，以及誤把管理頁面的連接埠當成代理連接埠。若設定要求特定編碼格式的金鑰，請保留原始編碼，不要自行重新計算或刪減字元。訂閱顯示名稱只是備註，名稱中寫著地區或協定，不能證明內部欄位正確。

額外參數不是預設必填項目

某些 Shadowsocks 項目還包含額外傳輸或其他擴充參數。這些參數不是看到開關就該啟用的強化功能，而是伺服器設定的一部分。若原始訂閱沒有提供相關內容，就不應照抄其他項目的設定。尤其是路徑、主機名稱與額外驗證資訊，通常與特定服務部署有關；填錯時，即使伺服器與密碼完全正確，整個項目仍可能無法使用。

手動建立項目時，建議先填入伺服器明確要求的必要欄位，再確認能否連線；需要擴充時，依照原始資訊逐項補齊。現有訂閱運作正常時，不必重新手動輸入來「最佳化」。若訂閱更新後欄位被改回，表示該項目仍由訂閱管理，應檢查來源設定，而不是反覆修改同一個自動更新項目。另存一個附有用途備註的測試項目，更方便比對與還原。

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

在訊號穩定、伺服器資源充足的情況下，Shadowsocks 較直接的資料處理路徑有助於控制額外負擔，但不能據此保證下載速度。選擇時更應考量現有服務是否穩定、是否需要 UDP、是否有頻繁短連線，以及實際網路的封包遺失情況。不同加密方式的運算成本可能不同，不過對多數日常操作而言，網路等待與伺服器負載通常更值得優先檢查。

若待機時耗電增加，先檢查是否持續重新連線、應用程式在背景同步，或有 UDP 保活，而不是立刻更換加密方式。若某項業務失敗、其他業務正常，應依目標與傳輸類型定位：可能與分流命中、目標解析或伺服器出口限制有關，不一定是 Shadowsocks 本身的問題。對於能穩定運作的既有設定，保留完整參數通常比自行拼湊另一種傳輸組合可靠。

03 / VMESS & VLESS

VMess 與 VLESS：分開理解驗證與傳輸

欄位相似不代表協定相同

VMess 將使用者驗證與代理訊息封裝結合，並有自己的資料保護機制；VLESS 更著重輕量的驗證與轉發架構，通常仰賴外部安全層保護傳輸。兩者可能都使用 UUID，也可能搭配相似的傳輸方式，但線上訊息格式並不相同。將同一個 UUID 從 VMess 項目複製到 VLESS 項目，不會讓伺服器自動相容；客戶端的 Type 必須與伺服器實際設定一致。

這種分工演進說明了一項重要取捨：拆分驗證、加密與通道，可以減少某些重複工作，但也增加了組合設定的責任。VLESS 的輕量設計不代表任意未加密的連線都具備機密性；VMess 內建保護，也不代表可以不核對外層 TLS。判斷安全邊界時，應分別確認「誰驗證使用者」、「誰驗證伺服器」及「哪一層保護資料」，不能把協定名稱當成完整答案。

UUID、Security 與時間條件

UUID 是身分識別碼，必須完整相符。外觀相似不代表可以互用，複製時請保留原有字元與分隔格式。VMess 的 Security 等欄位應依伺服器提供的資訊選擇；某些舊設定也可能包含歷史相容欄位，不應憑經驗為所有項目填入相同值。VLESS 中與資料加密相關的選項，也不應套用 VMess 的含義；相同的英文單字在不同協定頁面中可能代表不同處理層。

VMess 的部分驗證流程會受客戶端與伺服器的時間差影響。若參數看似正確但驗證失敗，請檢查裝置是否已啟用自動設定日期與時間，並請服務商核對伺服器時鐘。調整時區顯示方式不等於校準實際時間，也不需要為了連線而把裝置改設為其他地區。時間正確後仍失敗，應繼續核對協定、憑證與傳輸設定，而不是反覆調整時間。

WebSocket、gRPC 與 TCP 的差異

TCP 提供可靠的位元組串流，協定訊息可直接透過它傳送；WebSocket 增加一層透過 HTTP 握手建立的訊息通道；gRPC 通常以 HTTP/2 機制為基礎，並具備相應的服務與串流處理語意。選擇哪一種，不是客戶端單方面的效能偏好，而是由伺服器的監聽方式與中間轉發條件共同決定。伺服器只接受 WebSocket 時，把客戶端改成 TCP 並不能省下額外負擔後繼續使用。

WebSocket 的 Path 與 Host 應依現有資訊填寫。Path 是通道路徑，不是伺服器位址，也不是訂閱連結；大小寫、斜線與附加部分都可能影響比對。gRPC 的服務名稱也必須精確相符，不能以網站首頁路徑取代。若有中間轉發，伺服器位址、HTTP Host 與 TLS Server Name 可能各有不同用途，應逐項理解，不要硬把三個欄位都改成相同值。

如何處理 TLS 與特殊串流參數

TLS 中的 Server Name 用來宣告預期的伺服器身分，也可能影響伺服器選擇憑證；憑證驗證則用來確認對端是否符合該身分。它與 HTTP Host 並非同一階段的欄位。若服務商提供獨立的 Server Name，請保留該值，不要因 Server 填的是 IP 就將它清空。ALPN 涉及應用層協定協商，只有在目前傳輸與伺服器要求明確時才應調整。

某些 VLESS 組合還要求特定串流參數或額外握手資料，這些不是通用的加速開關。應確認目前客戶端介面支援對應組合，且原始設定中的相關欄位完整；缺少必要資料時，不應拿另一個服務項目的值來補。匯入成功只表示文字格式已被辨識，不代表整套組合已通過伺服器驗證，也不代表業務流量一定走了預期路徑。

iOS 上的連線重複使用與耗電

額外的 HTTP 通道與 TLS 握手會增加建立連線時的工作量，但重複使用連線可能分攤這部分成本。行動網路切換後，舊連線可能失效，必須重新連線；若頻繁發生，可能表現為偶爾開啟頁面等候較久，不一定是持續下載速度變慢。測試時應分別觀察新連線與長連線，不要把兩種體驗混成單一速度分數。

多路複用也不一定總有幫助：共用外層連線可以減少重複握手，但外層鏈路若發生封包遺失、排隊或重設，多項業務可能同時受影響。若沒有明確的伺服器建議，先保留匯入時的設定，用相同業務比較連線穩定性，再決定是否調整。UUID 或傳輸欄位的基本問題，可搭配名詞解釋查閱；不要只因介面名稱相似就推斷相容性。

04 / TLS & GENERAL PROXIES

Trojan、HTTP 與 SOCKS5 的適用界線

Trojan：密碼驗證與 TLS 通道

Trojan 的典型設計是在 TLS 連線中進行代理驗證與轉發，運用成熟的 TLS 機制保護傳輸並驗證伺服器身分。對客戶端使用者而言，關鍵欄位通常包括伺服器、連接埠、密碼與 TLS 相關資訊。密碼用來驗證使用者是否有權使用服務，憑證則確認客戶端是否連到預期的伺服器；兩者職責不同，密碼正確也無法彌補憑證身分錯誤。

若 Server 使用 IP，而憑證是簽發給網域名稱，通常必須依原始資訊填入正確的 Server Name。不要把「位址可以連線」當成「身分驗證應該通過」。憑證過期、憑證鏈不完整、裝置時間錯誤，以及伺服器回傳其他網站的憑證，都可能造成連線失敗。應先確認錯誤屬於驗證、TLS 還是網路逾時，再向服務商核對，而不是不斷更換連接埠碰運氣。

HTTP 代理與 HTTPS 目標並非同一件事

HTTP 代理最初是為轉發 HTTP 請求而設計；存取 HTTPS 目標時，通常透過 CONNECT 建立通往目標的通道，再由應用程式與目標網站進行 TLS 通訊。「目標網站使用 HTTPS」和「客戶端到代理伺服器的通道使用 TLS」是兩回事。若代理入口本身是一般 HTTP，即使目標網站使用 HTTPS，也不能據此斷定入口鏈路上的代理驗證資訊與所有中繼資料都受到同等保護。

若目前介面與伺服器提供 HTTPS 代理入口，應依對應類型設定外層 TLS，不能只把一般 HTTP 的連接埠改成常見的 TLS 連接埠。使用者名稱、密碼、驗證方式與伺服器監聽設定都必須相符；有些服務還會限制 CONNECT 目標連接埠。若部分網站可用、某些連接埠不可用，應核對伺服器允許的範圍，不必先歸因於 DNS 或規則。應分別記錄應用層回傳的拒絕回應與底層連線逾時。

SOCKS5：通用代理協商，本身不加密

SOCKS5 提供通用的代理協商方式，可以指定目標位址，也可依伺服器設定使用使用者名稱與密碼驗證。協定本身不提供等同 TLS 的傳輸加密。使用者名稱與密碼驗證解決的是使用權限問題，不會自動建立加密通道。是否適合目前情境，必須一併考量所在網路、外層保護方式與伺服器部署，不能因為欄位較少就認為安全邊界也較簡單。

SOCKS5 協定定義了 UDP 關聯機制，但實際使用仍取決於客戶端支援、伺服器是否啟用及網路路徑。能透過 SOCKS5 開啟網頁，主要只能證明某類 TCP 請求成功，不能推論遊戲、語音或其他 UDP 業務也能使用。若伺服器只提供 TCP 轉發，就應將此視為服務條件，而不是在客戶端不斷切換 UDP 選項。客戶端也無法透過單一開關補上伺服器未實作的能力。

解析發生位置須分別判斷

HTTP CONNECT 與 SOCKS5 都可能使用網域名稱表示目標，但最後在哪裡解析，仍取決於客戶端處理方式、規則需求與伺服器實作。若客戶端為了比對 IP 規則先在本機解析，即使之後將網域交給代理，也不能簡單說成「所有解析都在遠端」。應分開看待伺服器位址解析、目標位址解析，以及規則比對觸發的解析，避免用「遠端 DNS」一詞概括整個流程。

在 iOS 上，這幾種協定的使用感受差異，通常來自是否增加 TLS 握手、連線是否重複使用、伺服器距離與實際負載。一般 HTTP 或 SOCKS5 欄位較少，不代表一定更省電；Trojan 使用 TLS，也不代表一定明顯耗電。若連線穩定，業務使用模式可能比協定差異影響更大。測試時也要確認身分驗證正確，不能為了少一次握手而改變必要的保護範圍。

選擇應以現有服務的實際類型為準。服務商提供 Trojan，就保留相應的驗證與 TLS 條件；提供受控網路中的 HTTP 或 SOCKS5，則先確認該入口的信任範圍與用途。不要把三者當成同一筆伺服器設定中可以互換的選項。基本操作問題可查閱常見問題；若遇到憑證或驗證相關錯誤，應提供已移除憑證資訊的錯誤訊息進行核對。

05 / WIREGUARD

WireGuard：金鑰身分與 IP 通道

不同於應用程式代理的運作模式

WireGuard 以加密 IP 通道為設計核心，透過公開金鑰系統識別身分，傳輸主要使用 UDP。它處理的是通道中的 IP 封包，不像通用應用程式代理只協商特定目標連線。因此，位址、路由範圍與對端金鑰都是設定中的關鍵。若直接套用代理協定的「密碼、伺服器、連接埠」思路，容易漏掉本機通道位址及允許經由對端傳送的目標範圍。

在 Shadowrocket 中使用 WireGuard 項目時，還須區分客戶端的流量選擇與 WireGuard 對端自身的路由限制。前者決定哪些業務使用此項目，後者則決定交給通道的封包是否屬於對端允許的範圍。兩層設定都正確，業務才有機會正常運作。選到可以握手的 WireGuard 項目，不代表任意目標位址都一定可達，也不代表既有分流規則會自動替換。

Private Key、Public Key 與預共享資料

Private Key 是本機的身分祕密，Public Key 用來識別對端。客戶端填寫的對端 Public Key 應由伺服器提供，不能以本機產生的 Public Key 取代；伺服器也必須登記客戶端的公鑰。若設定另有預共享金鑰，它是雙方額外約定的資料，不能與 Private Key 混用。金鑰外觀可能相似，但欄位用途不同，複製時應依原始欄位名稱判斷，而不是看字串長度。

請勿將包含 Private Key 的完整設定貼到截圖、記錄檔或公開討論區。排錯時可以說明「金鑰是否由同一份設定匯入」及「對端是否已登記客戶端公鑰」，不需要公開實際值。重新產生本機金鑰會改變客戶端身分；若伺服器沒有同步登記，新金鑰不會自動取得存取權限。因此遇到失敗時應先核對對應關係，不要把反覆產生金鑰當成通用修復方式。

Endpoint、Address 與 Allowed IPs

Endpoint 是可連線至對端的外部位址與連接埠；Address 則是分配給本機的通道內位址，兩者不可互換。Allowed IPs 描述透過該對端處理的位址範圍，在常見實作中也會影響對端選擇與接收位址限制。範圍過窄，可能只能存取部分內部資源；範圍過寬，也不代表伺服器能轉發所有目標。應保留設定提供的範圍，不要憑「全域連線」的直覺一律擴大。

若握手成功但業務無法使用，先核對通道位址是否衝突、目標是否落在允許範圍內，以及伺服器是否具備轉發與回程路徑。內部 IP 可存取但網域名稱失敗時，通常應繼續檢查 DNS；只有某個網段失敗，則可能與路由或目標端權限有關。客戶端顯示連線已建立，只能說明某一層的狀態，不能跳過位址與伺服器出口檢查。把各層分開檢查，比只看開關是否開啟更有效。

MTU、保活與行動網路切換

MTU 定義通道中封包的大小上限。封裝會增加額外位元組；若實際路徑無法承載相應大小，又無法正確回報路徑資訊，就可能出現小型請求成功、大型頁面或傳輸停滯的情況。不要把任意較小數值視為通用最佳設定；應依伺服器建議與測試結果調整，並記錄原值。若調低 MTU 後只有某類問題改善，仍須繼續確認瓶頸，不要因此認定所有連線都應使用相同設定。

Persistent Keepalive 這類保活機制可協助維持某些 NAT 對應關係，不是頻寬加速選項。行動網路可能較快回收閒置對應關係，但過於頻繁的保活也會增加傳送次數與無線模組活動。是否需要應依伺服器存取方式、閒置後的恢復狀況與原始設定判斷。若沒有閒置斷線問題，就不必為了「保持連線」主動縮短間隔，更不要把持續握手測試當成省電設定。

WireGuard 對位址變更的處理有助於某些行動情境，但不能保證所有 Wi-Fi 與行動網路切換都不會中斷。切換後，UDP 路徑、系統網路延伸功能狀態與目標工作階段仍可能改變。測試時應分別觀察新請求能否恢復、舊業務是否需要重新建立；若只有舊通話中斷、新網頁仍可使用，應記錄為工作階段連續性問題，不要籠統判定整個通道無法使用。

06 / HYSTERIA2

Hysteria2：UDP 路徑與壅塞控制

為何採用以 QUIC 為基礎的傳輸

Hysteria2 採用以 QUIC 為基礎的傳輸設計。QUIC 通常透過 UDP 執行，並整合可靠串流、加密握手與連線管理等機制。其設計重點之一，是在不同品質的網路中管理傳輸，而不是把 TCP 封包換成 UDP 就能自動加速。UDP 提供的是承載條件，可靠性、壅塞控制與業務對應仍由上層實作負責，因此「使用 UDP」不代表不需要重傳或不受封包遺失影響。

與以單一 TCP 連線進行多路複用相比，QUIC 可在傳輸層為不同串流維持較獨立的交付狀態，減少某個串流的封包遺失直接阻塞其他串流交付的情況。不過，共用鏈路的頻寬、壅塞狀態與裝置資源依然有限，同一連線上的大量傳輸仍可能影響其他業務。實際效益取決於網路條件、伺服器設定與業務類型，不是所有網頁、下載與即時互動都會獲得相同程度的改善。

Server、驗證與 TLS 身分

Hysteria2 的伺服器位址、連接埠、驗證資訊與 TLS 條件必須來自同一份設定。驗證字串用來確認使用者權限，TLS 身分驗證則用來確認對端，兩者不可互相取代。若 Server 填寫 IP、Server Name 填寫網域名稱，請依原始資訊保留這種分工。遇到憑證錯誤時應核對網域、有效期限與裝置時間；不要為了觀察吞吐量而長期關閉驗證，否則比較的安全條件已不相同。

某些部署還要求額外的傳輸參數或混淆相關欄位。這些欄位必須在雙方一致；未填與空字串也未必相同。Hysteria2 不能只因名稱相近，就與其他世代依據相似欄位互用；匯入時應確認類型與伺服器實際採用的協定一致。若手動輸入後完全沒有回應，除了檢查密碼，也應先確認目前網路是否能連到所需的 UDP 連接埠。

頻寬參數不等於速度保證

部分設定提供上行與下行頻寬參數，用於特定壅塞控制模式的估算或限制。這些數值並非越大越好，也不代表伺服器會分配固定速率給使用者。填入明顯超過實際網路能力的數值，可能造成排隊、封包遺失與競爭，短時間下載速度看似提高，互動體驗卻可能變差。應先了解目前模式如何使用這些參數，並優先採用伺服器建議，不要照抄他人高速網路的數值。

也必須確認單位。頻寬與每秒傳輸的位元組數並非同一概念，不能依常見下載軟體的顯示方式猜測介面或設定所要求的單位。上行壅塞同樣會影響下行體驗，因為請求、確認與控制資訊都需要傳送。若下載一開始很快，之後延遲明顯增加，除了伺服器負載，也應檢查本機鏈路是否持續處於排隊狀態，不要只繼續調高下行參數。

如何取捨 iOS 上的速度與耗電

在有一定封包遺失或延遲變化的鏈路上，合適的壅塞控制可能改善持續傳輸；在品質良好、延遲低的網路中，額外效益未必明顯。主動占用鏈路的傳輸方式也可能增加資料處理與無線模組活動，因此不能把高吞吐量直接等同高能源效率。重視耗電的使用者，應比較完成相同任務所需的總時間、背景傳輸與裝置溫度，而不是只比較某個瞬間的峰值速率。

若目標是語音、互動或遠端操作，應優先關注抖動、斷線與排隊，而不只是下載速度。除非原本就是要測試並行使用情境，否則測試時不要讓大型檔案傳輸干擾互動測試。切換 Wi-Fi 與行動網路後，也應重新確認 UDP 路徑；一種網路表現良好，不代表另一種網路也有相同的封包大小限制、NAT 行為或閒置連線保留時間。

依既有條件選擇，不是取代所有類型

當伺服器明確提供 Hysteria2、目前路徑允許 UDP，且主要問題確實與鏈路品質或壅塞有關時，可以將它列為比較選項。若現有 TCP 類連線已穩定運作，便沒有必要切換。若業務失敗是因規則將目標導向錯誤策略，或 DNS 回傳無法到達的位址，改用 Hysteria2 也不會自動修正規則。應先確認問題屬於傳輸層，再評估協定的實際效益。

記錄測試結果時，應註明網路、業務、頻寬設定是否沿用原值，以及是否發生重新連線或背景活動。避免只留下「快」或「慢」的備註，因為條件改變後無法重現。保留原有項目，並為測試項目另取名稱；訂閱更新時再核對差異，避免把自動更新後的參數變化誤認為同一協定突然改變表現。

07 / ROUTING & DNS

Global Routing、DNS 與協定的交界

先確認流量是否確實使用所選協定

Global Routing 控制整體流量的選擇方式，不會把一種協定轉換成另一種。Config 模式依目前設定處理規則；Proxy 模式讓適用流量走代理路徑；Direct 模式則直接連線。介面模式與規則策略必須區分：Proxy 是介面模式，PROXY 是規則可使用的策略名稱，兩者相關但不是同一欄位，不能只憑字母相似就推斷目前請求實際使用的路徑。

測試協定前，應確認目前已選取正確項目，並檢查相關請求命中的規則與最終策略。某網站在 Config 模式下直連成功，不能證明所選代理項目可用；在 Proxy 模式下失敗，也不能立刻判定協定參數錯誤，因為問題仍可能出在伺服器出口或目標回應。Direct 模式可協助判斷目標能否透過本機網路存取，但結果只適用於目前網路條件，不能作為所有連線的永久結論。

三種解析情況應分開看待

第一種是代理伺服器位址解析：若 Server 填寫網域名稱，客戶端必須先知道如何找到它，這是建立代理連線前的條件。第二種是目標網域解析：目標可能由本機流程解析，也可能以網域名稱形式交由遠端處理，取決於協定與設定。第三種是規則比對所需的解析：某些以 IP 為基礎的規則可能需要先取得位址。三種解析的時機不同，也不一定使用完全相同的路徑。

因此，所謂「DNS 正常」必須說明哪一種解析正常。伺服器網域能解析，不代表目標網站也能解析；目標解析成功，也不代表回傳位址可由目前出口連線。若只有 IPv6 目標失敗，應檢查目前網路與出口的 IPv6 能力，不要立刻關閉所有 DNS 功能。若 IP 可存取但網域名稱失敗，先檢查解析與身分欄位；同時也要留意 HTTPS 目標可能依賴網域身分，直接輸入 IP 並不能完全取代實際業務測試。

規則順序會影響測試結果

規則通常依由上而下的順序處理，第一條符合的規則會決定策略。DOMAIN-SUFFIX 比對網域後綴，GEOIP 依位址歸屬資料庫判斷，FINAL 則為未命中其他規則的請求提供預設處理。以下片段僅用來說明順序，不建議直接取代現有設定；其中的 PROXY 必須在實際設定中有有效定義，範例網域也只是教學文字，不代表需要存取的服務。

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

此片段先檢查網域後綴，再檢查位址歸屬，最後套用預設處理。若將 FINAL 提前，後續規則就無法發揮預期作用；若原本應走代理的目標先命中 DIRECT，協定測試實際上就會繞過代理。DOMAIN 與 DOMAIN-SUFFIX 也不能任意互換：前者表示精確網域，後者涵蓋後綴範圍。若需要更詳細的寫法與順序說明，請參閱自訂規則比對順序與 FINAL。

設定檔不等於訂閱項目

訂閱主要提供伺服器項目及相關參數；設定檔則可能影響規則、DNS 與其他處理方式。匯入新項目後，若仍使用舊設定檔，規則不會因協定名稱改變就自動重寫。反過來說，即使伺服器沒有變更，替換設定檔也可能改變連線路徑。記錄故障前，應確認這兩部分是否分別更新過，避免把同一天發生的規則變動錯誤歸因於某個協定。

編輯 .conf 後，請確認已儲存、已選取預期設定檔，並依介面提示重新套用相關狀態。測試時保留原設定檔，避免日常使用與測試修改混在一起。設定結構說明請參閱General、Rule、Host 與 URL Rewrite 分段解析；訂閱匯入位置請見Subscribe 與其他匯入方式。

分別觀察 On Demand 與協定連線狀態

On Demand 會依系統條件決定何時嘗試建立連線，但不會修復驗證、憑證或伺服器可達性問題。若網路切換時不斷出現連線動作，應分別檢查觸發條件與協定重新連線結果。關閉觸發條件後手動測試，有助於區分「系統反覆發起連線」與「單次連線本身失敗」；測試完成後請恢復原設定，避免忘記必要的連線條件。

最終記錄應包含目前的 Global Routing、設定檔名稱、所選項目、目標與命中策略，以及是否觸發 DNS 或 UDP。這些資訊有助於說明為何同一項目在不同使用者的裝置上表現不同。客戶端開關顯示已開啟，只表示網路延伸功能處於某種運作狀態；請求的路徑、解析位置與採用的協定，仍須配合目前設定與實際連線判斷。

08 / SELECTION & DIAGNOSIS

依使用情境選擇與逐層排錯

選擇順序：先確認相容條件，再考量效能偏好

第一步是列出現有服務實際提供的協定與完整參數，而不是先挑一個聽起來較快的名稱。第二步確認目前網路是否允許所需傳輸，例如 UDP 路徑是否可用。第三步再依業務需求判斷：短時間瀏覽看首次回應，持續下載看穩定吞吐量，通話與互動看抖動及中斷，存取內部資源則還須核對位址與路由範圍。前兩步都符合條件後，第三步的比較才有意義。

若服務商只提供一種協定，客戶端無法憑空改用另一種；即使提供多個項目，也可能對應不同伺服器與負載，不能把所有測試差異都歸因於協定。較嚴謹的比較應盡量使用位置相近的伺服器並維持相同網路條件，同時記錄無法維持一致的變數。對多數使用者而言，完整、穩定且符合業務需求的既有設定，比增加一套不熟悉的傳輸組合更容易維護。

由可達性逐層檢查到業務，不要跳步

完全無法建立連線時，先核對 Server 與 Port、目前網路及伺服器監聽狀況。網域解析失敗屬於入口問題；底層逾時則應優先檢查路徑與監聽設定，立即重填 UUID 通常沒有幫助。若網路連線已建立但出現明確的驗證錯誤，再檢查密碼、UUID、金鑰對應關係與時間條件。若錯誤指向 TLS，應聚焦檢查 Server Name、憑證與裝置時間，不要同時變更 DNS 和路由來掩蓋問題。

驗證通過但業務無法使用時，下一層應檢查傳輸參數、目標位址與伺服器轉發。WebSocket Path、gRPC 服務名稱、特殊串流參數或 WireGuard 路由範圍，都可能在基礎連線成立後阻止業務流量。若只有部分目標失敗，應檢查規則命中、目標解析與伺服器出口；若只有 UDP 業務失敗，則應依序確認客戶端、伺服器與網路各段的 UDP 狀況，而不是繼續用網頁測試證明「一切正常」。

短暫可用後中斷，應觀察狀態變化

閒置一段時間後失效，可能與 NAT 對應關係、保活或伺服器閒置策略有關；Wi-Fi 切換到行動網路後失效，則應觀察舊連線是否重新建立、UDP 路徑是否變更，以及 On Demand 是否觸發。大型請求停滯但小型請求正常，可進一步檢查 MTU 與路徑回報；只有高負載時失敗，則應檢查排隊、頻寬估算、裝置資源與伺服器負載。具體描述現象，比只說「一直斷線」更有助於定位。

不要一次修改多項保活、MTU、複用與頻寬參數。先記下原值，只調整與目前現象最相關的一項，再重複相同測試，最後還原或保留設定。若沒有改善就撤回，不要不斷疊加測試值。由訂閱管理的項目也要留意自動更新覆蓋；可另行複製測試項目並清楚註明用途，避免下次更新後無法分辨參數是手動修改還是來源變更。

耗電異常應以相同任務比對，不要憑協定名稱推斷

若主要目標是降低耗電，應先檢查背景持續活動、失敗重試、保活頻率與無線訊號，再比較協定。測試期間盡量維持相同的螢幕狀態、業務時間與網路條件，避免一組測試時充電、另一組卻處於低電量狀態。系統電池統計可作為線索，但短時間的電量百分比變化容易受溫度與估算影響，應搭配多次任務結果判斷。一次高速下載雖然較快完成，也可能比長時間低速重試更節省總活動時間。

待機測試不必持續傳送探測請求，否則會改變原本要觀察的狀態。若發現客戶端相關的背景活動增加，應確認是否有其他應用程式持續透過連線傳輸，以及規則是否讓原本可直接存取的高頻工作走上較長路徑。此時修正業務路徑可能比更換協定有效；但規則調整仍應符合實際用途，不要只為了降低電池統計數值而停用必要連線。

完成測試後，保留設定清楚且可還原

最終選擇應能回答三個問題：為何與伺服器相容、為何符合目前業務，以及失敗時如何還原。保留一份已驗證的設定，記錄必要參數的來源與適用網路，並移除已確認無效的測試修改。不要把測試時關閉驗證、暫時放寬範圍或極端頻寬值留作日常設定；若某項參數必須偏離原始設定，應註明原因並向服務商確認適用範圍。

若要回到操作流程，請繼續閱讀Shadowrocket 快速上手；若要確認取得方式，請前往全平台下載頁。Mac 提供 Apple 晶片與 Intel 兩種版本，其他桌面平台及 Android 的安裝系統提示也集中說明於下載頁。本頁並非建議永遠優先使用某一種協定，而是協助每次選擇都有條件可核對、每次失敗都有明確的下一步。