Shadowrocket 協定參考
參數、速度與耗電取捨

01 / CONNECTION LAYERS

連線分層：協定、傳輸與規則各自負責什麼

先釐清四個不同問題

在 Shadowrocket 中選擇協定類型，首先是在回答「用戶端應以哪種格式與伺服器通訊」。Shadowsocks、VMess、VLESS、Trojan 等類型，規定部分驗證與資料封裝行為；TCP、UDP、WebSocket 則關係到資料如何傳送。TLS 負責建立經過驗證的加密通道，規則則決定哪些要求會進入這條通道。這些層次可以組合使用，但不能彼此取代。只把類型改成另一個名稱，不會同步將遠端伺服器轉換成相應服務。

例如，現有設定同時包含伺服器位址、連接埠、UUID、WebSocket 路徑和 TLS 伺服器名稱，這不是五種獨立協定，而是同一條連線在多個層次上的約定。用戶端先找到伺服器，再依指定方式建立傳輸、完成必要的安全交握與身分驗證，最後轉送目標要求。任何一層不一致，都可能呈現為同一種「連線失敗」。因此，排查前應先記錄設定結構，而不是依錯誤提示任意切換類型。

速度與耗電不能只看協定名稱

開啟一個網頁，會經過網域解析、建立連線、交握、傳輸與應用程式處理。短請求通常更受往返時間與交握影響；長時間下載則更受可用頻寬、封包遺失與伺服器負載影響。某項設定下載時的傳輸量較高，不代表開啟許多小型頁面也更快；單次測試數值較低，也不能直接證明該協定不適用於目前裝置。應使用相同目標、相近時段與相同網路重複比較，並記錄失敗次數，而不只保留最佳結果。

在 iPhone 與 iPad 上，耗電也與無線網路狀態密切相關。訊號微弱時反覆重傳、連線中斷後持續重建，以及背景工作頻繁喚醒，都可能比加密演算法本身更明顯。Wi-Fi 與行動網路切換後，既有連線可能需要恢復；不同傳輸設計的恢復方式各異，但不能據此推算固定的省電百分比。合理的做法是先確保連線穩定，再觀察相同使用時間下的耗電與發熱情形，而不是尋找永遠最省電的協定。

從可用條件開始選擇

實際選擇順序應為：先確認現有伺服器提供哪些類型，再確認目前網路是否允許相應傳輸，最後比較使用體驗。如果伺服器只提供一種已確認的設定，完整匯入通常比手動改成另一種類型可靠。若有多種設定，請先保留原項，再分別建立容易辨識的名稱；每次只變更一個測試變數。伺服器位址與驗證資訊不同的兩個項目，不能視為只比較協定差異的嚴謹測試。

閱讀後續章節時，也要區分「協定能表達什麼」與「目前伺服器啟用了什麼」。只有用戶端與伺服器的實作和設定都支援，協定設計中的選用功能才會生效。訂閱可能省略預設值，也可能使用分享格式中的簡稱；遇到無法辨識的欄位，請核對設定來源的說明。請勿自行刪除未知欄位後繼續猜測，也不要將含有憑證的完整設定貼到公開頁面。需要操作順序時，請返回快速入門說明；需要判斷錯誤類型時，再參閱問答。

02 / SHADOWSOCKS

Shadowsocks：加密方式與密碼必須成對核對

設計重點是精簡的代理封裝

Shadowsocks 的設計出發點，是以相對精簡的方式在用戶端與伺服器之間轉送代理流量。它通常不像完整網路通道那樣先為裝置建立虛擬位址與路由關係，而是圍繞目標連線進行封裝。了解這一點，有助於理解為何設定的核心內容通常是伺服器、連接埠、加密方式與密碼，而不是一組通道網段。實際使用表現仍取決於伺服器實作、網路品質及採用的方式，不能只因設定較短就推斷速度。

部分較新的設定會使用具驗證功能的加密方式，讓接收端既能解密，也能偵測資料遭竄改或金鑰不符。不同方式對金鑰材料、資料組織及雙方實作有不同要求；名稱相似不代表相容。伺服器要求哪一種方式，用戶端就應選擇相同項目。不要因為某個名稱看起來較新，就直接替換原設定；替換後，也必須重新確認原密碼是否符合該方式的格式要求。

四個核心欄位的核對順序

先檢查伺服器位址是否包含多餘空格、協定前綴或路徑。位址欄位通常填入網域或位址本身，連接埠則另行填寫；把整段分享內容貼進位址欄位，不能取代匯入。接著確認連接埠是否屬於這項服務，尤其要留意同一部伺服器可能為不同協定配置不同連接埠。再核對加密方式與密碼，密碼中的大小寫和結尾字元都應保留，複製時不要順手刪除看似特殊的符號。

部分較新的方式對金鑰格式有特定限制，不能把一般記憶型密碼與編碼後的金鑰視為同一種輸入。如果服務資訊包含多段金鑰或額外身分資料，請依提供方說明匯入，不要自行拼接。現有訂閱若能正確辨識類型，請優先保留其欄位關係。手動建立時，可先記錄必要參數，確認連線成功後再了解選用項目，避免同時加入多個未確認的設定。

也要另外檢查 UDP 條件。某些應用程式會發出 UDP 要求，但伺服器是否處理、目前路徑是否允許，以及用戶端如何轉送，都需要相應支援。網頁能開啟，只能表示部分 TCP 要求成功，不能據此確認語音、即時互動或其他 UDP 情境正常。反過來說，即時應用程式異常也不能直接證明密碼錯誤；先區分驗證失敗與特定流量類型失敗，排查範圍會小得多。

如何在 iOS 上觀察實際表現

在 iOS 上，持續傳輸時的加密成本與處理器效能、方式實作及流量規模有關。日常瀏覽頁面時，建立連線與無線網路的耗電可能更明顯；傳輸大型檔案時，加密處理與持續無線活動才較容易觀察。測試時應分別記錄短時間瀏覽頁面、持續傳輸及鎖定螢幕後的恢復情形，不要只測一次下載。若裝置發熱，應先排除同時進行的備份、媒體處理與應用程式更新，避免把所有負載都歸因於代理協定。

無法連線時，先還原完整的原始參數，確認系統時間與網路正常，再以相同設定在另一種網路條件下重測。如果所有要求都失敗，優先檢查位址、連接埠、加密方式與密碼；如果只有部分目標失敗，再檢查規則、解析與目標本身。不要頻繁更換加密方式碰運氣，也不要把測試失敗後產生的暫存副本混入正式訂閱清單。為手動項目加上清楚註記，能減少日後選錯預設伺服器的情況。

適合選擇 Shadowsocks 的前提，是現有伺服器明確提供相符設定，而且測試結果符合實際用途。精簡的參數便於逐項核對，但不代表每項都能省略。如果設定額外要求外掛程式或其他封裝，而目前介面沒有相應功能，應先確認是否支援；不要把缺少的部分當成不重要的附註。最後應保留一份可重現的有效設定，而不只是記住協定名稱。

03 / VMESS & VLESS

VMess 與 VLESS：分別理解驗證、加密與傳輸

兩種協定不能只靠切換類型互換

VMess 與 VLESS 都常出現在含有多層傳輸選項的設定中，但兩者並非同一協定的顯示別名。VMess 在協定層包含身分驗證與資料保護相關設計；VLESS 的協定層結構較精簡，常搭配另外設定的安全傳輸。兩者經常使用 UUID 作為身分識別，因此容易讓人誤以為只要替換類型就能轉換。實際上，即使 UUID 看起來相同，伺服器也必須執行相應協定，並接受相同的傳輸組合。

UUID 是結構化識別碼，不是伺服器位址，也不是用來驗證網站憑證的名稱。核對時應檢查是否完整、是否混入空格，以及複製內容是否屬於目前伺服器。不要交叉組合不同設定中的 UUID、連接埠與路徑。VMess 的驗證也涉及時間條件，裝置時鐘明顯偏差時可能導致失敗；請保持系統時間自動設定。這只能修正時間問題，無法補救錯誤的身分識別碼或傳輸參數。

將傳輸欄位視為一組設定檢查

常見設定會在協定之外指定 TCP 或 WebSocket 等傳輸方式。選擇 WebSocket 時，路徑必須與伺服器接收位置相符；斜線、大小寫及附加參數都可能影響結果。Host 通常參與應用層要求或前端路由；TLS 中的伺服器名稱則參與安全交握與身分驗證。兩者可能相同，也可能因部署方式而不同。伺服器位址、Host 與 TLS 名稱各有不同用途，不應為了介面整齊而強行填成相同值。

如果網域背後有多層轉送，用戶端能連上前端連接埠，不代表要求已抵達正確的協定服務。路徑錯誤可能收到一般網頁回應，Host 錯誤可能被導向其他網站，TLS 名稱錯誤則可能在更早階段遭拒。確認連接埠可連，只完成了第一層檢查。應依序核對位址與連接埠、TLS、傳輸路徑及協定驗證，不要因為伺服器「在線」就排除設定問題。

不應將 VLESS 本身視為普遍提供負載加密的替代方案。若要保護用戶端與伺服器之間的內容，必須確認實際設定使用的安全層及其驗證方式。某些設定還包含專用流控或交握參數，這些不是通用加速開關；只有雙方約定相同組合才有意義。如果目前介面沒有顯示某個欄位，應先確認是否支援該組合，不能把未知值填入備註或其他無關欄位代替。

短連線成本與多工的適用範圍

在 iPhone 上，首次連線的體感可能同時受到網路往返、TLS 交握與額外傳輸封裝影響。將 VMess 或 VLESS 簡單排出速度快慢，並沒有可靠依據：伺服器距離、傳輸方式與連線多工策略各異，足以改變結果。多工在某些情境下可減少重複建立連線的成本，但也會讓多個要求共用一條底層通道。發生壅塞時，共用不一定更順暢；應依相同工作負載測試，而不是始終開啟所有選用項目。

觀察耗電也需要控制條件。若某項設定在網路切換後持續驗證失敗，反覆交握可能增加背景活動；修正路徑、時鐘或驗證資訊，比更換一個聽起來較輕量的協定直接。如果鎖定螢幕後重新開啟應用程式，只有第一次要求較慢，應區分正常的連線重建與持續重試。可記錄恢復所需時間、是否需要手動切換，以及錯誤是否反覆出現；不必把單次現象擴大解讀為該協定的固定特性。

實際選擇時，若現有 VMess 設定完整且運作穩定，就不必只因另一種類型較精簡而遷移。若使用現有 VLESS 設定，則應著重確認安全傳輸、驗證與選用流控之間的對應關係。維護多個測試項目時，請用註記標明傳輸方式與用途，不要改寫伺服器提供的協定欄位。若要了解如何選取預設項目並執行 Connectivity Test，請參閱首次連線與驗證說明。

04 / TROJAN & TLS

Trojan：分別檢查 TLS 身分驗證與協定密碼

透過成熟的 TLS 通道承載代理要求

Trojan 的重要設計取捨，是利用 TLS 提供加密與伺服器身分驗證，再於通道中完成協定驗證和要求轉送。因此，理解它不能只看密碼欄位，也需要了解憑證、伺服器名稱與連線目標之間的關係。TLS 是廣泛使用的安全傳輸機制，但採用 TLS 的協定不代表任何 TLS 伺服器都能接受 Trojan 要求。用戶端仍須連到正確連接埠，並向支援此協定的服務提供正確驗證資訊。

伺服器位址決定用戶端要連往何處，連接埠決定要聯絡哪項服務；TLS 伺服器名稱則用於交握時的名稱宣告與憑證身分核對。憑證應涵蓋要驗證的名稱，且仍在有效期限內；憑證鏈也應受系統信任。若直接以位址連線，但憑證是簽發給網域，就需要依原設定正確指定驗證名稱。不要把「能解析到同一部機器」理解為「憑證可以驗證任何名稱」；網路位置相同不代表身分相同。

交握失敗不等於密碼錯誤

驗證通常在安全通道建立後才進行。如果憑證過期、裝置時間錯誤、名稱不符，或伺服器無法提供完整憑證鏈，連線可能還沒進入密碼驗證階段。此時反覆輸入密碼無法修復 TLS。應先檢查系統日期、網域拼字及憑證相關提示，再聯絡現有伺服器的維護者確認憑證部署。相反地，若 TLS 已成功但協定驗證遭拒，才應優先檢查密碼、服務類型與伺服器端權限。

密碼應完整複製，大小寫、特殊字元及首尾位置都必須保留。如果訂閱更新後密碼已變更，舊的手動副本可能仍會失敗；請確認目前選取的是訂閱中的新項目，而非名稱相似的舊項目。儲存密碼時，也不要把中文註解、引號或換行當成密碼內容。排查紀錄可以寫「密碼已與來源核對」，但不應在公開截圖或記錄說明中附上真實密碼。

有些設定會額外提供 ALPN 或其他 TLS 協商需求。ALPN 用於協商應用層協定，不是可任意選擇的速度檔位；是否需要填寫及可接受的值，應以伺服器端要求為準。不要為了讓表單看起來完整而複製其他地方的值。如果訂閱已帶入相關欄位，請保留其組合；遇到異常時逐項比對原始說明，不要一次清空所有安全選項再測試。

在 iOS 上留意交握與連線恢復

TLS 首次建立時需要交換交握資訊，網路往返時間會影響這段過程。連線持續建立後，實際傳輸量仍取決於傳輸路徑、壅塞與伺服器負載；首次開啟頁面的耗時不能等同於長期速度。條件符合時，工作階段恢復可能降低後續交握成本，但是否發生由實作與伺服器狀態共同決定，不應保證每次都會重用。測試時可分別觀察首次造訪與緊接著的再次造訪，避免把快取效果誤認為協定差異。

從 Wi-Fi 切換到行動網路後，既有底層連線可能需要重建；短暫等待不一定代表憑證失效。如果每次恢復都長時間失敗，再檢查目前網路能否連到伺服器連接埠及解析結果。就耗電而言，頻繁重建 TLS、連續失敗重試與弱訊號重傳，比穩定運作中的長連線更值得留意。應先排除錯誤重試，再比較正常使用時的耗電，不要為單一交握機制貼上固定耗電標籤。

適合選擇 Trojan 的情況，是使用者現有設定明確採用此類型，且 TLS 名稱、憑證與驗證資訊齊全。檢查設定時可依清楚的順序進行：先確認連線目標，再驗證安全交握，最後核對密碼與業務要求。若網頁仍異常但連線測試通過，應繼續檢查網域解析與規則，不能因為使用 TLS 就略過後續層次。選擇具體模式時，可搭配閱讀Global Routing 三種模式說明。

05 / HTTP & SOCKS5

HTTP 與 SOCKS5：代理介面不等於加密通道

兩種通用代理的設計背景

HTTP 代理源自應用層代理需求，能處理相應的 HTTP 要求，也常透過 CONNECT 方法為其他目標建立位元組通道。SOCKS5 則提供更通用的連線協商方式，由用戶端向代理宣告目標，再由代理建立後續通訊。兩者都是代理介面，但介面本身不會說明用戶端到代理之間是否加密，也不代表代理支援所有要求類型。選擇時必須一併確認傳輸保護、驗證方式與伺服器開放的功能。

常見的誤解是看到目標網站使用 HTTPS，就認為到代理的每一段資訊都受到同等保護。目標網站的 TLS 可以保護通道中的業務內容，但一般 HTTP 代理的 CONNECT 協商與代理驗證，不會因為目標使用 HTTPS 就自動獲得相同層級的保護。若透過 TLS 連線至代理，還必須另外驗證代理憑證。應區分「目標網站使用 HTTPS」與「用戶端以加密方式連線至代理」，兩者不能混為一談。

位址、憑證與解析位置

建立 HTTP 或 SOCKS5 項目時，先確認伺服器類型，再核對位址、連接埠、使用者名稱與密碼。伺服器可能允許不提供使用者名稱，也可能強制驗證；欄位留白是否有效，應由原始設定決定。使用者名稱與密碼是兩項獨立資訊，不能把含分隔符號的整段文字直接填入其中一欄。有些部署也會依來源網路限制存取；此時即使驗證資訊正確，切換到行動網路後仍可能遭拒，需向現有伺服器的維護者確認權限。

解析發生的位置也會影響使用表現。用戶端可以先將網域解析成位址再要求代理；協定也可能允許將網域交由代理解析。實際行為取決於用戶端設定、協定能力與伺服器實作。兩種路徑得到的位址可能不同，尤其是目標服務會依存取位置分配位址時。若出現「網域失敗、位址似乎可連」的情況，應檢查解析路徑與結果，而不是立刻更換代理類型。直接使用位址測試 HTTPS 也可能造成憑證名稱問題，不能視為完全等同的替代測試。

SOCKS5 協定定義了 UDP 關聯機制，但並非每種部署都會開放，也不能只看類型名稱就確認目前設定可用。伺服器可能只處理 TCP，相關防火牆也可能阻擋 UDP 資料返回。HTTP CONNECT 常見用途是建立 TCP 通道，不應預設它具備與 SOCKS5 UDP 關聯相同的能力。如果用途包含即時音訊或視訊，應針對所需流量進行測試，不能只因網頁成功開啟就判定全部符合需求。

情境選擇與 iOS 使用表現

如果現有的公司網路、實驗環境或自管伺服器提供通用代理介面，HTTP 與 SOCKS5 可用來連接現有服務。選擇依據是介面是否相符，而不是哪個名稱更高級。缺少額外加密，不代表適合在所有網路中傳送敏感驗證資訊；應先釐清連線保護範圍與方式。不要公開網路上的明文驗證資訊作為一般排查內容，也不要在不清楚存取權限時反覆提交憑證。

在 iOS 上，這兩種介面的速度同樣受代理距離、連線建立方式與目標回應影響。協定封裝較少不一定能彌補較差的路徑，也無法保證更省電。若不同應用程式的表現有差異，先確認它們是否使用不同目標、傳輸方式與解析路徑。若 TCP 測試通過但即時功能失敗，優先檢查 UDP 條件；只有驗證失敗時，才集中檢查使用者名稱與密碼，避免重複修改無關設定。

最後應為每種通用代理記錄三項結論：連線至代理的路徑是否受到保護、支援哪些傳輸方式，以及網域由哪一端解析。三項都釐清後，才能判斷是否符合自己的用途。如果只確認伺服器位址與連接埠，而其他資訊不明，應先向原設定來源查證；不要憑預設猜測補上安全條件。這樣能區分介面可用與實際適用，減少「連得上卻不符合預期」的情況。

06 / WIREGUARD

WireGuard：一併檢視金鑰、通道位址與路由範圍

以網路通道而非單一代理要求為出發點

WireGuard 是為加密網路通道而設計，透過對等端、公私鑰與路由範圍建立通訊關係。相較於逐一指定代理目標的協定，它更像是讓封包進入虛擬網路路徑。因此，設定中常會出現通道內部位址、對等端公鑰、端點及允許的位址範圍。理解這項差異很重要：端點能發起交握，不代表業務路由已正確設定；金鑰正確，也不能取代伺服器端的轉送與回程設定。

每個對等端都有自己的私鑰，並使用另一端的公鑰辨識對方。用戶端私鑰應留在自己的設定中；伺服器公鑰則取自伺服器設定，兩者不可對調填寫。選用的預共享金鑰是在既有金鑰關係上增加的一份共享資料，不是私鑰的別稱。若伺服器端沒有相關設定，用戶端單方面填入不會增加相容性，反而會造成驗證不一致。匯入後應完整保留金鑰關係，不要任意混用多份設定中的金鑰。

端點、位址與 AllowedIPs 各自的用途

端點是外部網路中用來聯絡對等端的位置，通常由網域或位址加上連接埠組成。通道內部位址則是在加密網路中使用的本機身分與定址資訊，不應填成端點的公網位址。AllowedIPs 同時涉及對等端的位址限制與路由選擇，但在特定用戶端中的實際作用範圍，仍須配合應用程式的整合方式理解。它不是可任意擴大、且永遠不影響其他要求的一般允許清單。

如果把路由範圍設得太廣，原本不需要進入通道的流量也可能被送入；設得太窄，目標網段就可能沒有相應路徑。伺服器端也必須知道如何將回應送回用戶端，相關轉送、內部網段與存取控制都應一致。交握成功但無法存取目標時，先判斷是只有某個內部網段失敗，還是所有業務都失敗，再核對位址範圍與回程路徑，而不是重新產生金鑰。

DNS 也應分開檢查。能存取通道內的某個位址，不代表內部網域一定能解析；若設定指定內部解析伺服器，該伺服器本身也必須有可用路徑。反過來說，網域能解析只代表取得位址，不代表目標服務的連接埠可連。排查時應分別記錄解析結果與目標連線結果，不要把兩個步驟合併成一句「網路正常」。涉及 IPv6 時，也應確認相應的位址族與路由都已完整設定。

UDP、保活與 MTU 的取捨

WireGuard 使用 UDP 傳送通道資料，目前網路必須允許用戶端與端點交換相應資料。在特定條件下，它可以適應端點變更，但連線恢復仍受網路位址轉換映射與伺服器可達性影響。某些環境需要持續保活以維持網路位址轉換映射；保活會定期傳送封包，不應為了「更穩定」就一味縮短間隔。在 iPhone 鎖定螢幕及行動網路情境下，額外喚醒可能影響耗電，應採用服務設定所需的最低必要頻率。

MTU 決定通道可處理的封包大小。封裝本身會占用空間；若路徑無法順利處理較大的封包，可能出現小型要求正常、大量內容停滯的情況。不過，這類症狀也可能由其他原因造成，不能一看到下載速度慢就修改 MTU。應保留原值，先確認問題是否與封包大小有關，再依伺服器及路徑條件測試調整。多部裝置共用設定時，也不要把某部裝置有效的數值直接當成所有網路的標準。

在 iOS 上評估 WireGuard 時，應分別觀察持續傳輸、長時間待機及切換網路後的恢復情形。它採用精簡的密碼學與交握設計，但裝置耗電仍可能主要受訊號品質與保活方式影響。沒有週期性背景負載的測試，不能直接與持續傳輸測試比較。若用途是存取現有內部網段，應優先確認網段涵蓋範圍與解析；若用途是一般要求轉送，還需了解它與 Shadowrocket 目前規則設定的配合限制。

選擇 WireGuard 的依據應是使用者已有明確的通道設定與存取目標，而不是只看某次傳輸量表現。記錄故障時，說明端點是否可連、是否完成交握，以及哪些位址範圍失敗即可；不要將私鑰放入公開資料。遷移設定時，也應確認伺服器端是否允許以相同身分使用，避免兩部裝置同時使用同一份設定，造成難以重現的連線變化。

07 / HYSTERIA2

Hysteria2：先確認 UDP 路徑，再討論傳輸量優勢

以 QUIC 與不穩定連線為核心的設計取捨

Hysteria2 以 QUIC 建構傳輸，QUIC 本身運行於 UDP 之上，並結合現代安全交握機制。其設計著重於在一定的封包遺失、延遲與頻寬條件下維持傳輸效率，同時承載代理要求。這不代表它在所有網路中都更快：UDP 是否可連、路徑是否限制 UDP 速率、伺服器負載與壅塞控制方式，都會改變實際表現。比較協定前，應先確認網路符合基本傳輸條件，再討論傳輸量。

QUIC 可在同一條連線中管理多個串流，減少部分傳輸層隊頭阻塞的影響，但所有串流仍共用實際路徑與壅塞預算。無線網路嚴重丟包時，任何可靠傳輸都需要復原遺失資料，協定無法憑空增加可用頻寬。持續傳輸表現良好，也不代表所有短請求的首次回應都更快。應區分「在某些條件下可能改善表現」與「保證任何條件下都領先」，不要只憑協定名稱下結論。

分別核對驗證、TLS 與選用的混淆設定

建立設定時，伺服器位址與連接埠用來找到端點，驗證資訊用來確認使用權限，TLS 伺服器名稱與憑證則用來驗證遠端身分。若原始設定還要求混淆類型與密碼，兩端也必須一致。混淆密碼不是驗證密碼的別稱，也不應填入憑證名稱欄位。缺少任何一組必要資訊時，都應回到現有訂閱或伺服器說明查證，不要依其他協定的慣例拼湊。

憑證驗證原則與其他 TLS 設定相同：名稱必須相符、憑證必須有效，裝置時間也必須準確。UDP 可連只是底層條件，不代表安全交握與驗證已成功。如果切換網路後連線恢復，應留意目前路徑是否仍允許相同連接埠的資料往返；如果所有網路都失敗，再檢查伺服器狀態與參數。不要因為此協定使用 QUIC，就認為可以略過憑證檢查，或把交握錯誤歸因於一般延遲。

部分部署會要求填寫上傳或下載頻寬資訊。這類參數可能參與壅塞控制與傳送行為，不是顯示給使用者看的裝飾數字，更不是任意調高就能解除限制的加速選項。應依實際連線能力與伺服器說明填寫，並留意單位。行動網路的可用頻寬會隨位置與訊號變化；估值過高可能增加排隊、封包遺失或與其他應用程式爭用，估值過低又可能限制傳輸量，應在穩定條件下審慎測試。

在 iPhone 上分別測試速度、發熱與網路切換恢復情形

評估持續下載時，應選擇大小與來源相近的內容，記錄完成時間及期間是否中斷。只看開始幾秒的瞬時速度，可能受到快取、突發傳送與無線網路排程影響。如果背景還有其他傳輸，結果也不能代表該設定本身。測試後再觀察日常網頁、訊息與媒體要求；不要為了大型檔案的傳輸量而犧牲實際使用的穩定性，也不要把單次成功視為長期可用的保證。

就耗電而言，較高的傳輸量可能縮短傳輸時間，但持續高負載也可能增加處理器與無線模組活動，最終結果取決於工作負載。網路狀況不佳時，頻繁重傳與重新交握也會改變耗電。應比較完成相同工作的時間、發熱與電量變化，而不是只比較單位時間內傳送多少資料。短時間的電量百分比變化較粗略，無法支持精確的協定耗能結論，適合觀察趨勢，不適合作為測量儀器。

QUIC 有關於連線遷移的設計，但實際恢復效果仍受雙方實作、網路映射與路徑變化影響。不要將它理解為從 Wi-Fi 切換到行動網路時絕對不會中斷。可在可控制的條件下切換一次，觀察現有業務是否恢復，以及新要求是否成功；若只有既有業務中斷，還需區分業務本身的恢復機制。避免連續快速切換網路，否則很難判斷失敗發生在哪次變更。

適合嘗試 Hysteria2 的前提，是現有伺服器提供相符設定、目前 UDP 路徑可用，而且用途確實需要比較其傳輸表現。如果主要用於瀏覽輕量網頁，穩定性與恢復時間可能比峰值速度更重要。請保留一份已知有效的設定作為基準，逐項測試後再決定日常使用項目；不要因為某項參數看起來與效能有關，就在缺乏測量依據時同時調整多個數值。

08 / VERIFICATION & DIAGNOSIS

實際選擇：從協定核對到規則驗證的完整流程

先建立可還原的基準設定

開始排查前，保留原始訂閱項目或手動設定副本，並記錄目前網路、預設伺服器與 Global Routing 模式。確認現有訂閱已成功更新，並區分訂閱原項與舊的手動項目；名稱相同不代表參數相同。接著在 Home 選擇要測試的伺服器，依系統提示完成必要授權，再進行連線測試。一次只選一個明確項目，才能避免修改某項參數，實際測到的卻是另一部伺服器。

Global Routing 的三種模式分別為設定 Config、代理 Proxy、直連 Direct。Config 依目前設定中的規則處理要求；Proxy 讓適用流量經由選定的代理路徑；Direct 則直接連線。這些模式會改變要求的處理方式，不會轉換伺服器協定。排查時可以暫時比較不同模式，但測試後應恢復原本需要的模式。若 Direct 也失敗，應先檢查裝置網路與目標本身，而不是繼續修改代理密碼。

找出最早發生失敗的層次

先判斷伺服器位址能否正確解析，以及目前網路是否能連到相應連接埠。接著檢查 TLS 或其他安全交握，再核對協定驗證，最後檢查目標要求與規則。應優先處理最早失敗的層次；對後續層次暫時不要下定論。例如，憑證交握尚未成功時，不能據此判斷代理驗證有效；代理驗證成功，也不能證明某個內部網段已正確設定回程路徑。

Connectivity Test 可協助確認所選項目的某種連線結果，但測試不涵蓋所有目標、所有位址族或所有應用程式行為。測試通過但網頁異常時，應繼續檢查解析、目標憑證與路由；測試失敗時，也要確認實際業務是否同樣失敗，避免將單一測試目標的問題擴大成協定故障。正確的結論應說明測試範圍，而不是將一次成功寫成所有功能都正常。

分開驗證規則與協定

以下片段用於說明 Shadowrocket 設定檔中的規則結構，不含伺服器、驗證資訊或可直接使用的訂閱。網域採用範例值；實際部署前，請依自身用途檢查每條規則。規則會依序比對，前面的命中結果會影響後續處理；最後的 FINAL 負責處理先前都未命中的要求。此處的 PROXY 與 DIRECT 是處理動作，不是伺服器協定名稱，也不是將連線轉換成另一種協定的指令。

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

如果 Proxy 模式下可以存取目標，但 Config 模式下失敗，應優先檢查該目標由哪條規則處理、是否取得預期的解析結果，以及設定選用的代理路徑。不要立即更換協定，因為兩次測試可能根本沒有使用同一條路徑。GEOIP 依據位址歸屬資料庫進行比對，不能直接取代精確的網域規則意圖；網域規則與位址規則並存時，應檢查順序及解析條件，而不是只看是否出現某個關鍵字。

最後依情境選擇：一般網頁著重首次回應與穩定性，持續傳輸著重完成時間與重傳，即時業務著重 UDP 條件與延遲波動，內部網路存取則著重路由範圍與解析。只有在現有伺服器提供多種可用方案時，比較協定才有意義。沒有一套適用於所有網路與用途的固定排名，也不應把短期測試結果當成某種協定永遠較優的判斷。

需要尋求協助時，請整理協定類型、傳輸方式、發生問題的網路、錯誤階段及已完成的個別測試。請隱藏密碼、UUID、私鑰及訂閱中的身分資訊，只提供解決問題所需的設定結構。常見情況可繼續參閱問答；需要重新整理從匯入到連線的操作流程，則返回使用說明。建立一份可還原、可重現的有效設定，比反覆測試所有類型更有幫助。