Shadowrocket 協定詳解
與參數參考

一、協定選擇與連線層次

選擇協定時，首要依據不是名稱，而是伺服器實際支援的連線方式。Shadowrocket 中的協定類型必須與既有訂閱或伺服器資訊一致；將同一個位址改選為另一種類型，不會讓伺服器因此具備相應功能。只有伺服器同時提供多種連線入口，而且每組驗證與傳輸參數都完整時，才有比較選擇的空間。匯入後應先核對類型、位址與連接埠，再判斷是否需要調整其他設定，不要憑速度印象逐項嘗試修改。

將一次連線拆解為四個層次

第一層是本機網路，負責讓裝置連上 Wi-Fi 或行動網路，並能基本連通伺服器。第二層是傳輸與安全封裝，決定連線使用 TCP 或 UDP、是否建立 TLS，以及是否透過 WebSocket 等方式承載。第三層是協定驗證與資料格式，例如密碼、UUID 或公鑰身分。第四層才是用戶端路由與目標連線，決定要求透過所選伺服器傳送，還是直接連線。前一層發生問題時，修改後一層通常無法解決。

這也說明了為什麼「測得到回應」不等於「網頁能正常使用」。某項測試可能只驗證位址可連通、交握成功或指定目標有回應，並未涵蓋所有目標、DNS、UDP 與 App 行為。反過來說，單次測試失敗也可能是測試目標本身無法連線。解讀結果時，應一併記錄測試方式、目前網路、所選伺服器與路由模式，避免直接比較不同條件下的數值。

速度與耗電應在相同條件下比較

協定開銷只是影響速度的因素之一。伺服器距離、可用頻寬、壅塞、封包遺失、目標網站限制與裝置無線訊號，影響都可能遠大於加密演算法的差異。在相同網路、相近時段與同一目標下，分別觀察首次開啟、持續傳輸與閒置後恢復，才能區分交握耗時與穩定傳輸速度。不要把一次短時間測試的結果當成持續速度，也不要把多項工作同時執行時的體驗歸因於某一種協定。

在 iPhone 與 iPad 上，耗電也會受到無線模組喚醒、背景重新連線、訊號品質、螢幕亮度與前景工作影響。交握次數較少不一定更省電，積極維持連線也不一定更耗電；實際影響取決於使用頻率與網路切換情況。評估時應維持相近的使用時間，記錄裝置是否發熱、連線是否頻繁中斷，並區分 App 傳輸與系統背景工作。本文不依協定名稱提供固定的速度或耗電排名。

整理設定時，可以保留一份已確認可用的基準設定，每次只修改一個變數並記錄原因。驗證資訊、訂閱網址與私鑰都屬於敏感資料，不應放進公開截圖或診斷文字。協定欄位應以目前 App 實際顯示的內容及伺服器說明為準；若沒有顯示某個選項，不要拿名稱相似的欄位替代。系統需求一律以 App Store 頁面標示為準；本文不混為一談裝置相容性與協定效能。

二、Shadowsocks：共用金鑰與加密方式

Shadowsocks 的設計著重於輕量代理轉送，使用雙方事先約定的密碼與加密方式處理通訊。它不是透過憑證鏈確認伺服器身分的 TLS 協定，因此「密碼正確」與「加密方式一致」是建立連線的重要條件。這種設計取捨讓代理協定維持相對精簡，伺服器部署、帳戶管理與承載擴充則交由配套實作處理。對使用者而言，應將伺服器提供的設定視為一組完整配置，而非只保存位址與密碼。

位址、連接埠、Password 與 Method

位址可以是網域名稱或 IP 位址；網域名稱能否正確解析，是連線的前置條件。連接埠代表伺服器的特定入口；同一位址的不同連接埠可能使用不同密碼或加密方式。Password 必須完全一致，尤其要留意複製時是否包含前後空格、換行或全形字元。Method 決定如何處理加密資料，不是可以任意切換的效能模式；即使名稱相似，不同方法也不能互相替代。

較早期的串流加密設計與後來的 AEAD 設計，在完整性保護、封包處理與重放防護等方面有所不同。AEAD 同時處理機密性與驗證，但這不代表名稱中含有某種演算法，就一定適用於目前的伺服器。不同方法對金鑰格式也可能有不同要求，有些方法所需的材料不能當成一般密碼看待。匯入後若出現一長串字元，應先確認它是否為規定格式的金鑰，不要自行刪短、重新編碼或改成容易記憶的文字。

匯入連結通常已包含類型、加密方式、密碼、位址與連接埠，但連結外觀精簡不代表資訊可以省略。先以原始設定建立基準；若需手動核對，再逐項比對 App 顯示的欄位。備註名稱只是本機辨識標籤，不能用來判斷協定或伺服器功能。即使訂閱中的名稱描述了某種網路特性，也不應據此啟用額外傳輸選項；實際入口仍以設定欄位與伺服器說明為準。

UDP 與額外承載不會自動相容

若需要即時影音或其他 UDP 服務，必須一併核對用戶端設定、伺服器轉送能力與中間網路。TCP 網頁能開啟，不足以證明 UDP 路徑可用。若設定包含額外承載或混淆參數，這些也是雙方約定的一部分；只設定主要協定而漏掉這些參數，可能會出現連線已建立卻沒有有效資料的情況。額外選項應依目前 App 支援情況填寫，不要拼湊其他入口的參數。

Shadowsocks 的實際資源消耗取決於方法實作、裝置硬體、資料量與連線數量。輕量封裝可能減少部分處理負擔，但在訊號微弱或封包遺失率高的環境中，無線傳輸與重試的成本仍可能占主導。若要判斷問題是否與協定有關，應比較同一伺服器提供的可用入口，避免把不同線路或不同負載伺服器的差異誤認為演算法差異。短時間下載後裝置升溫，也可能主要來自無線傳輸與儲存活動。

排除問題時，可以依序核對：位址與連接埠、Method 與 Password、額外承載，最後再確認 UDP 與路由。若原本可用的訂閱突然失效，先確認更新是否改變欄位，以及伺服器資訊是否仍有效，不要連續修改多個選項。更新訂閱前先記錄本機手動修改的內容，因為重新整理後可能會覆寫項目。若需重新執行新增流程，請參閱入門指南；本章用來說明欄位，不重複完整操作流程。

三、VMess 與 VLESS：驗證、傳輸與安全封裝

VMess 與 VLESS 都常以 UUID 作為使用者身分資訊，但兩者不是同一種協定的兩個切換選項。VMess 在自身設計中處理驗證與資料保護，VLESS 則採用更精簡的協定結構，通常搭配其他安全傳輸層使用。兩者的設計背景反映了不同取捨：一種在協定內負責較多功能，另一種則將部分功能交由外層處理。已有 UUID 不代表可以直接在兩種協定類型之間切換。

UUID 格式正確，只代表格式有效

UUID 的字元與分隔符號都要完整保留，複製時不要包含引號、空格或說明文字。即使格式正確，伺服器仍可能因帳戶停用、身分不符或入口設定不同而拒絕要求。使用 VMess 時，也應留意裝置時間是否準確；明顯的時間誤差可能影響驗證。啟用自動設定日期與時間有助排除這個變數；若時間恢復正常後仍無法連線，就應繼續核對伺服器參數，而非反覆重設時間。

VMess 設定中的加密相關選項應依伺服器約定填寫，不能因外層已使用 TLS 就自行推斷內部設定。舊設定可能包含不同的額外欄位，匯入後應以目前 App 實際解析的結果為準。若缺少某些舊欄位或出現預設值，應回頭核對原始設定與伺服器說明，而不是將網路上不同年代的參數拼湊在一起。協定演進與伺服器設定差異，不能只憑項目名稱判斷。

傳輸方式決定連線如何抵達協定入口

同一種協定可能透過不同承載方式傳輸。直接使用 TCP 連線、WebSocket 與其他受支援的承載方式，對路徑、主機名稱及伺服器處理方式都有不同要求。選用 WebSocket 時，Path 與 Host 等參數可能會參與要求路由，路徑中的斜線、大小寫與字元都必須正確。若伺服器端透過中間代理分配入口，只連上相同位址與連接埠，並不保證能抵達正確服務。

TLS 的 Server Name 用於交握時的伺服器名稱指示及相關身分核對；傳輸層的 Host 則可能用於上層要求路由。部分設定中兩者相同，但用途不同，不能把其中一個欄位的值直接複製到另一個缺漏欄位。憑證驗證也不是連線失敗時應優先關閉的項目：應先查明網域不符、憑證鏈異常或系統時間錯誤等原因，否則只是把明確錯誤變成不易察覺的風險。

VLESS 結構精簡，不代表可以省略外層安全

VLESS 本身不負責與 VMess 相同的資料加密功能，實際保護程度取決於完整的安全方案。若既有設定指定 TLS 或其他受支援的安全參數，應完整保留。部分伺服器也會要求特定 Flow 或相關安全欄位；這些值會影響雙方的協定行為，不是一般備註。欄位是否可用、組合是否受支援，應以目前 Shadowrocket 實際介面與既有設定為準，不要為了消除錯誤而任意清空欄位。

在 iOS 上，首次連線的等待時間可能包括 DNS、外層連線與安全交握；持續傳輸則較容易受到路徑品質與壅塞影響。增加封裝可能帶來額外處理負擔，但也可能是伺服器正確接入所必需。若閒置後連線變慢、持續下載卻正常，應留意連線重建與網路切換；若全程都慢，再比較路徑與伺服器負載。判斷 VMess 或 VLESS 是否合適，應看既有入口能否完整配對，而非只看「精簡」或「加密」等單一描述。

四、Trojan、HTTP 與 SOCKS5：安全界線各不相同

Trojan 將 TLS 作為重要的外層，並搭配自身的驗證與轉送格式；HTTP 與 SOCKS5 則源自較通用的代理需求，主要用來告知代理伺服器應連線至哪個目標。將三者放在一起說明，是為了區分代理功能與安全通道：能轉送連線，不代表用戶端至代理伺服器之間的通訊已加密。選擇時不只要核對代理類型，也要確認既有入口是否提供相應的安全封裝。

Trojan：先確認 TLS，再確認 Password

Trojan 設定通常需要伺服器位址、連接埠、Password 與 TLS 名稱相關資訊。連線位址負責實際連上伺服器，Server Name 則與 TLS 交握和憑證身分核對有關；兩者可能相同，也可能因部署方式而異。若以 IP 位址作為連線目標，更不能直接推斷憑證應與該 IP 相符；應依既有設定保留名稱參數。通過身分驗證不代表後續轉送一定成功，還需另外確認目標是否可達。

憑證相關錯誤應依序核對系統時間、名稱是否相符、憑證鏈與伺服器部署情況。略過憑證驗證會降低伺服器身分確認能力，不適合當作長期的故障排除方式。若所在網路需要先完成網頁登入，應先處理本機網路條件，再測試代理。TLS 錯誤、驗證錯誤與目標連線錯誤分屬不同階段，最好保留原始錯誤訊息，避免中文概述掩蓋實際差異。

HTTP：CONNECT 可建立通道，但不能取代 TLS

HTTP 代理可以處理代理要求，也常透過 CONNECT 為目標建立位元組通道。若目標網站使用 HTTPS，網站本身的 TLS 通常會在 App 與目標之間建立；這不代表代理交握、驗證資訊與目標中繼資料也會自動受到用戶端至代理伺服器這段連線的保護。是否使用加密的代理入口，應依伺服器提供方式及 App 對應設定判斷，不能只看目標網址以 HTTPS 開頭就下結論。

HTTP 代理的使用者名稱與密碼可能和伺服器登入憑證完全不同，應使用伺服器明確提供的代理驗證資訊。驗證失敗時，先確認是否需要使用者名稱、是否包含特殊字元，以及匯入時是否正確還原。部分代理會限制目標連接埠、要求方式或帳戶使用範圍，因此可能出現連線成功但部分目標遭拒的情況。此時持續更改 DNS 或規則不一定有幫助，應先核對代理的存取範圍。

SOCKS5：協商目標與驗證，UDP 另有條件

SOCKS5 可協商目標連線、支援不同驗證方式，並在協定層定義 UDP 轉送機制，但本身不保證資料加密。用戶端支援某項功能，不代表目前伺服器也已啟用。使用網域名稱作為目標時，解析位置仍取決於要求交給代理的方式與用戶端處理流程，因此需要一併檢查 DNS 設定，不能只從 SOCKS5 這個名稱推斷所有解析都會在遠端完成。

SOCKS5 的 UDP 轉送通常需要額外的關聯流程，並仰賴雙方及中間網路允許相關流量。若網頁可連線但即時服務失敗，應分別檢查 TCP 與 UDP，而非反覆更換使用者名稱。若使用者既有的是本機或受控網路中的一般代理入口，也應確認離開該網路後位址是否仍可連線。位址的可達範圍屬於部署條件，不會因為將項目儲存至用戶端而自動擴大。

比較這幾類入口時，應先排除設定差異，再考量交握、連線重用與路徑品質。Trojan 的 TLS 交握可能增加短連線的初始等待時間；一般代理的封裝較少，卻不代表整體速度更快或更合適。對 iOS 上的間歇性使用而言，連線能否穩定恢復也很重要。若只有單一目標失敗，先確認目標本身與伺服器存取限制；若所有目標都失敗，再回頭檢查位址、驗證與安全層。

五、WireGuard：金鑰身分與第三層隧道

WireGuard 是為網路層隧道而設計，與逐一協商目標的代理協定不同。它以公鑰辨識對端，承載 IP 封包，並透過 UDP 傳輸。這種設計將身分、隧道位址與可傳送的網段納入同一組設定關係。新增設定時，不能只拿伺服器位址和密碼直接套用；必須具備伺服器分配的完整資料，並了解哪些欄位屬於本機、哪些屬於遠端。

PrivateKey 與 PublicKey 的方向

PrivateKey 是本機身分的機密資料，不應公開、傳送至不明的診斷網頁，或出現在分享截圖中。對端設定中的 PublicKey 用於辨識遠端；伺服器通常也需要知道與本機私鑰相對應的公鑰。若更換本機私鑰，卻未同步更新伺服器認可的身分，即使設定看起來完整，仍無法正常通訊。複製金鑰時應保留完整編碼，避免連同備註或換行一起貼上。

若設定包含 PresharedKey，它是雙方額外共用的資料，不會取代公私鑰關係，也不能由使用者隨意填入一串文字。不同金鑰欄位即使看起來都是相似的字串，用途仍各不相同。不要因為 App 接受輸入就認定資料正確；格式檢查只能確認表示形式，無法證明遠端已有相應設定。排除問題時可以核對金鑰對應關係，但不應將完整私鑰放進回報內容。

Address、Endpoint 與 AllowedIPs

Address 通常是隧道內本機介面使用的位址，Endpoint 則是裝置用來連線至遠端的公開位址與連接埠。兩者不可互換：隧道位址不是可直接撥接的伺服器入口，遠端公開位址也不是本機隧道位址。若伺服器分配了特定位址，應照原值填寫，並留意前綴長度。自行改成另一個看似未使用的位址，可能破壞伺服器路由或存取控制。

在 WireGuard 中，AllowedIPs 會用來對應對端與 IP 範圍，同時涉及傳送選擇與接收來源驗證。它不是單純的網站網域清單，也不等同於 Shadowrocket 的網域分流規則。流量最終如何進入該項設定，還取決於用戶端的路由處理方式。不要直接套用其他環境的全域路由結論，應一併核對隧道允許範圍、伺服器轉送能力與目前的 Global Routing 設定。

MTU 與連線保持應有根據地調整

MTU 會影響隧道內單一封包的大小。外層封裝需要額外空間，路徑可承載的封包大小也可能不同；數值不合適時，可能出現小型要求正常、大量傳輸停頓的情況。但降低 MTU 並非所有連線問題的通用解法。應先排除位址、金鑰與路由錯誤，再以可重複的相同工作觀察修改前後的變化，避免同時調整多個參數而無法判斷原因。

連線保持功能可在特定網路條件下維持對應關係或提升可達性；間隔設得過於頻繁，會增加閒置傳輸與無線活動。是否需要設定、如何設定，應參考伺服器安排與實際網路狀況，不宜照抄固定數值。iOS 上前景使用、裝置鎖定與無線網路切換時的行為也各不相同；看得到交握不代表隧道內目標可達，仍須核對伺服器轉送、回程路由與 DNS。更詳細的欄位閱讀順序請見WireGuard 參數說明。

六、Hysteria2：QUIC、UDP 與壅塞條件

Hysteria2 使用 QUIC 與 UDP 承載代理通訊，著重於複雜傳輸條件下的資料傳送。QUIC 在 UDP 上實作安全連線、可靠傳輸與多路複用等機制，因此「以 UDP 為基礎」不代表所有服務都變成不可靠的資料傳輸。它與以 TCP 為基礎的入口有不同傳輸特性，但實際表現仍取決於網路是否允許 UDP、路徑壅塞程度、伺服器資源與參數是否合適，不能只憑協定名稱保證速度。

先確認 UDP 路徑，再談效能

本機網路可以瀏覽網頁，不代表能連上指定伺服器的 UDP 連接埠。部分網路環境會限制 UDP，或在長時間、大流量的 UDP 通訊下出現不同表現。若入口始終無法建立，應先核對位址、連接埠與網路條件；必要時可在另一個可信任的網路環境下進行比較。若切換網路後結果明顯不同，代表應繼續檢查傳輸路徑，而非優先更換驗證字串或憑證名稱。

QUIC 的連線與重傳機制能應付部分封包遺失與路徑變化，但無法消除實體頻寬、遠端壅塞或持續封包遺失的限制。封包遺失率高時，更多重試可能增加無線傳輸與裝置處理負擔。即使前景工作更快完成，耗電情況仍須搭配傳輸時間與閒置活動一起評估。對短訊息式的使用情境而言，首次交握與喚醒成本可能更明顯；對長時間傳輸，則應觀察穩定階段，而非只看開頭的單次峰值。

驗證、TLS 名稱與額外參數

Hysteria2 的驗證資訊必須符合伺服器約定，可能是密碼或特定格式的驗證資料。不要因欄位看起來像一般密碼，就刪除其中的分隔符號。TLS 相關名稱仍須正確核對，連線位址與憑證名稱的用途也依然不同。若原始設定包含特定安全或額外參數，應確認目前 App 支援並完整匯入；不可只靠重新命名，就將不同世代協定的項目互相轉換。

部分部署會要求額外的混淆參數或其他約定。這些內容既不是提升速度的通用選項，也不是可以任意省略的裝飾欄位。若伺服器有要求而用戶端未設定，可能在驗證前就無法完成有效通訊。匯入後應逐項比對原始資料與實際顯示值，特別留意特殊字元、編碼與參數名稱。若手動填寫的內容和訂閱匯入結果不同，應先釐清差異來源，再決定採用哪一組。

頻寬參數不等於速度保證

若目前設定提供上行、下行或壅塞相關選項，數值可能參與傳送行為或頻寬協商，不代表伺服器為帳戶分配了固定能力。上行與下行的方向、計量單位及伺服器限制都必須先確認。持續調高數值不會增加本機無線連線的實體容量，反而可能讓壅塞、封包遺失與延遲更加明顯。若沒有可靠依據，應保留原有的有效設定，不要依據某次速度測試的瞬間峰值填寫。

在 iPhone 上評估耗電，可以先觀察固定時間內的實際工作，再觀察相同時間的閒置連線，並記錄訊號狀態與是否發生網路切換。背景維持連線、頻繁重試與高強度傳輸都會影響結果；比較不同伺服器時，也會混入線路差異。裝置發熱時，應先停止重複的大流量測試，讓狀況恢復一致，否則後續結果可能受到裝置溫度與系統排程影響。

是否適用，應回到既有資源判斷：伺服器明確提供 Hysteria2、UDP 路徑可用，且驗證與 TLS 參數完整，才具備測試條件。若同一伺服器也提供其他類型，可以保留另一組已確認可用的入口作為比較，但不應把單次失敗概括成協定永遠無法使用。若只有部分目標異常，應繼續檢查 DNS、規則與目標本身；入口層連線成功，並不代表後續各層都已通過驗證。

七、Global Routing、規則與 DNS 的關係

協定項目描述如何連線至伺服器，Global Routing 則決定要求是否使用這些項目，兩者屬於不同層次。設定／代理／直連分別對應介面中的 Config / Proxy / Direct：Config 依目前設定的規則處理，Proxy 讓一般要求依所選代理處理，Direct 則直接連線。實際連線還可能受到設定細節、系統處理方式與 App 行為影響，因此驗證時應查看實際要求記錄，不要只看 Home 上的狀態。

用三種模式縮小問題範圍

若 Direct 下目標可用、Proxy 下卻失敗，可優先檢查所選伺服器、協定驗證及伺服器至目標的路徑。若 Proxy 可用、Config 下卻失敗，應著重檢查目前啟用的設定與規則命中情況，特別是是否指向其他策略或遭到 REJECT。若三種模式都失敗，先檢查本機網路、目標服務與 DNS。這種比較方式是用來定位問題，不代表應長期以某種模式取代所有需求。

若同時存在多份設定檔，先確認目前生效的是哪一份。修改未啟用的檔案，不會自動變更目前使用的規則；訂閱中的伺服器更新，也不代表規則檔已更新。排查前記錄所選伺服器、Global Routing 與設定名稱，避免把三項獨立變化混為一談。恢復日常使用時，也要將用於測試的暫時模式切回原本需要的狀態。

規則順序與最終兜底規則

規則通常依序比對，前方符合條件的規則會影響後續規則是否有機會處理同一要求。DOMAIN 適用於精確網域名稱，DOMAIN-SUFFIX 適用於網域及其子網域範圍，IP-CIDR 與 IP-CIDR6 用於 IP 網段，GEOIP 依據 IP 位址資料庫判斷，FINAL 則提供兜底處理。選擇關鍵字時，先確認比對對象是網域名稱還是 IP，不要為了涵蓋更多要求而任意擴大範圍。

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

這段範例展示的是規則結構與順序，不是可直接取代現有設定的完整檔案。example.com 是說明用網域名稱；PROXY、DIRECT 代表處理方向，不可用中文文字取代。GEOIP 的結果取決於 IP 位址資料庫與實際目標位址，不保證等同於網站主體所在的地區。FINAL 應依自身需求決定，並放在兜底位置；變更它會影響先前未命中的要求，而不只是一個測試目標。

DNS 不是獨立的「加速選項」

DNS 會將網域名稱解析為位址；解析器的選擇、要求傳送路徑與回傳位址，都會影響後續連線。系統 DNS、自訂解析器與 DNS over HTTPS 各有其部署條件。DoH 以 HTTPS 封裝解析通訊，但是否透過代理、解析器本身是否可達，以及是否產生連線前置依賴，仍須搭配設定檢查。切換解析方式時，應確認新路徑可以正常建立，不要一次更改所有解析項目。

網域規則與 IP 規則也可能依賴不同階段的資訊。若只有網域名稱無法連線，直接使用位址測試只能確認部分路徑，因為憑證名稱、上層主機名稱與目標服務可能仍需要網域名稱。IPv4 與 IPv6 的回應不同，也可能讓同一目標在不同網路下呈現不同結果。不要只因某次解析得到一個位址就認為問題已排除；應查看失敗要求實際使用的位址類型與規則處理結果。

調整 DNS 後，既有連線與快取可能暫時沿用先前結果；應在可控條件下重新連線，再比較記錄。避免同時重新整理訂閱、更換解析器與修改規則，否則無法判斷是哪一項改變了結果。解析路徑的詳細取捨請參閱系統 DNS、自訂 DNS 與 DoH 說明；術語解釋請見概念速查。

八、依使用情境選擇與分層排除故障

選擇協定應以可用設定與實際工作需求為依據。若只有一組完整的伺服器資訊，先正確使用這組設定，不要更換協定類型。若已有多個可用入口，應在相同條件下比較短時間要求、持續傳輸、閒置後恢復與網路切換，並保留一組穩定的基準設定。不同用途的理想結果可能不同：前景大檔案傳輸應觀察穩定傳輸速度，間歇瀏覽更在意首次等待時間，即時服務還需檢查 UDP、抖動與持續可達性。

選擇情境時先看限制條件

若不確定本機網路能否連通 UDP，應先確認路徑，再評估 Hysteria2 或 WireGuard；測試無法連通時，不要以提高頻寬或縮短連線保持間隔取代網路檢查。若既有設定依賴特定網域名稱、路徑與 TLS 名稱，應優先確保 VMess、VLESS 或 Trojan 的整組參數一致。若已有 HTTP 或 SOCKS5 入口，也須確認其可達範圍、安全封裝與存取限制。

若裝置經常在 Wi-Fi 與行動網路之間切換，應分別測試兩種網路，並觀察切換後的恢復情況。切換造成短暫中斷，不代表驗證一定失效；位址解析、對應關係與既有連線都可能需要重新建立。若鎖定螢幕後失敗、回到前景卻正常，應記錄鎖定時間、恢復方式，以及是否有 On Demand 條件參與。不要把按需連線規則的觸發行為，誤判為某個協定天生無法在背景使用。

連線失敗：由入口逐層檢查至目標

第一步確認本機網路可正常連線；必要時先完成網路要求的網頁登入。第二步核對伺服器位址、連接埠與協定類型，確認訂閱是否已更新，以及項目是否仍有效。第三步核對驗證、安全層與傳輸欄位，包括密碼、UUID、公鑰關係、Server Name、Host、Path 與可能的額外參數。每次只處理一個可驗證的問題，不要為了讓狀態改變而同時切換多項設定。

第四步區分交握、驗證與目標連線問題。保留 App 顯示的原始錯誤訊息，並透過目前可用的記錄或診斷功能確認失敗階段。第五步檢查 Global Routing、規則與 DNS，再以不同目標進行比較。若只有單一目標失敗，還須考慮伺服器至目標的路徑、目標限制與解析結果；若所有目標都失敗，就回頭檢查前面的共通層次，不必逐條修改網站規則。

速度慢：設計可重複的測試

測試前先關閉同時進行的大流量工作，選擇相同目標與相近的工作時間，並記錄使用的網路與伺服器。先比較直接連線與所需的代理連線，再比較同一伺服器提供的可用入口。Connectivity Test 的結果只代表當時條件與該測試方式，不應直接換算成下載速度。短時間內連續進行多次極限測試，會引入裝置發熱、網路壅塞與背景活動等變數；適度間隔有助於取得較易解讀的結果。

若只有首次開啟較慢，應著重檢查 DNS、交握與連線恢復；若開始正常、持續一段時間後變慢，則檢查壅塞、負載、裝置溫度與路徑變化；若小型要求成功但大量傳輸停頓，才進一步檢查 MTU 或分段相關問題。所有判斷都應使用相同工作重複測試。分層排查方式與測試結果解讀請參閱速度慢的分層排查，不要只憑一次數值就刪除所有設定。

還原基準設定並整理回報內容

修改項目過多時，應優先還原已確認可用的設定副本，再逐項加入必要變更。更新訂閱前先確認本機手動修改是否會被覆寫，不要把更新後的欄位變化誤認為用戶端隨機失效。回報問題時提供協定類型、網路條件、失敗階段、原始錯誤訊息與可重現步驟即可；請刪除完整訂閱網址、Password、UUID、PrivateKey 與可識別帳戶的資訊，不要為了方便重現而公開驗證資料。

本手冊無法取代伺服器設定說明，協定名稱也不代表品質保證。App 取得方式、已購項目回復與正版資訊請見正版核對；首次系統權限設定請參閱首次開啟與 VPN 設定權限；已知問題可至問答查詢。完成排查後，應記錄實際有效的設定關係，而不是只留下「換了某個協定就好了」的結論，這樣下次更新或更換網路時，仍可依層次逐一核對。