Shadowrocket 協定參考類型、參數與連線判斷

一、協定選擇：先釐清認證、傳輸與路由

Shadowrocket 中的協定類型決定用戶端如何與伺服器交換資料，不會決定伺服器所在位置、出口頻寬或服務品質。選擇時須以你已有的伺服器資訊為準：伺服器端提供哪種類型，用戶端就應設定哪種類型；不能只修改 Add Server 中的選項，就把一種連線變成另一種協定。訂閱連結請向你的服務商索取；匯入後仍應核對類型、位址和認證資訊。一次買斷用戶端 ≠ 線路方案，應分別管理 App 購買與連線服務；取得 App 請參閱App Store 正版核驗說明。

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

第一層是身分與訊息格式，例如密碼、UUID 或金鑰，以及伺服器如何解讀請求。第二層是承載方式，例如 TCP、UDP、WebSocket 或以 QUIC 為基礎的傳輸。第三層是安全連線，可能由協定本身加密，也可能仰賴 TLS 等外層機制。第四層才是路由：某次連線要選擇 PROXY 還是 DIRECT。四個層次會共同影響結果，但不能互相取代。將 Global Routing 改為 Proxy，可以改變流量的去向，卻無法修正輸入錯誤的密碼；啟用 TLS，也不會讓伺服器自動接受不相符的傳輸格式。

協定名稱相同，不代表所有擴充設定都一致。伺服器端可能要求特定傳輸方式、路徑、憑證名稱或附加參數，而用戶端也可能只支援其中部分組合。因此，看到 VMess 或 VLESS 時，還要確認外層傳輸；看到 HTTP 時，則應確認代理入口本身是否受 TLS 保護。介面提供的欄位會隨所選類型而變化，判斷時應以目前用戶端實際顯示的選項和伺服器說明為準，而非參照另一份設定截圖中的欄位位置。

速度、耗電與穩定性沒有單一排名

網頁載入速度通常包含 DNS 查詢、建立連線、認證、收到第一個回應及傳輸內容等階段。長時間下載則更容易受到出口頻寬、封包遺失後的恢復機制和伺服器負載影響。某種設定可能開啟小檔案較快，長時間下載卻沒有優勢。iPhone 和 iPad 的耗電也會受到行動網路訊號、螢幕亮度、無線電保持啟用的時間，以及背景重新連線影響。少一層封裝不代表一定更省電，較高的傳輸量也不代表整項工作更省電；必須在相近條件下比較。

網路切換也是獨立變因。裝置從 Wi-Fi 切換到行動網路時，本機位址和路徑都可能改變；既有連線能否恢復，取決於傳輸機制、伺服器行為及 App 本身的重試機制。不要把切換網路後短暫停頓直接判定為協定失效，也不應不斷切換多個開關來掩蓋問題。先固定一項可重現的連線操作，記錄失敗發生在建立連線之前還是傳輸過程中，再決定要檢查哪個層次。

本文僅說明用戶端的類型選擇與設定限制，不評價服務商。系統需求請以 App Store 頁面標示為準，實際支援的協定與欄位則以目前用戶端為準。若無法確認附加選項的來源，保留匯入時的設定通常比依名稱猜測更妥當；只有在了解該選項對應伺服器端哪項設定後，才進行修改。

二、Shadowsocks：輕量代理與加密方式的匹配

Shadowsocks 的設計重點是提供相對精簡的加密代理通道。用戶端將目標位址和資料交給伺服器，再由伺服器連線至目標，因此它屬於代理協定，而非在兩端之間建立完整私有網段的網路層通道。基本設定通常容易辨認：伺服器位址、連接埠、加密方式和密碼。但欄位少不代表可以省略核對，尤其加密方式是協定交握的一部分，不是用戶端單方面選擇的效能偏好。若與伺服器端設定不一致，連線可能逾時、立即中斷或認證失敗。

加密方式與密碼須成對核對

現代 Shadowsocks 部署常使用具認證功能的加密方式，讓接收端除了能解密，也能檢查資料是否遭到竄改。不同方式可能採用不同的金鑰長度與衍生規則；部分方式要求使用符合格式的編碼金鑰，而非任意文字密碼。匯入時應逐字保留方式名稱和密碼，不要先解碼編碼字串再貼上，也不要把結尾符號當成多餘字元刪除。若訂閱更新後連線突然失效，先確認密碼是否已更換、類型是否有變，再檢查網路層問題。

在 Add Server 中手動輸入時，應先選擇 Shadowsocks，再依原始資料填寫。位址欄位只填主機名稱或 IP 位址，連接埠則另外填寫；不要將整段分享連結當作伺服器位址。如果資料包含外掛或其他封裝，還要確認目前用戶端是否提供相應選項，以及匯入內容是否完整。協定名稱相同，不代表不同外掛組合就能互通。無法確認附加參數時，應回頭查看既有設定的說明，而不是在幾個選項間隨機切換。

分別確認 TCP 與 UDP 是否可用

網頁通常透過 TCP 存取，但部分即時 App、語音和其他服務會使用 UDP。Shadowsocks 可涉及 TCP 與 UDP 轉送，伺服器端是否啟用、網路是否可連線，以及用戶端的處理方式都可能不同。網頁能開啟，只能證明某條連線路徑正常，不能證明 UDP 路徑也沒問題。反過來說，單一 App 無法使用也不一定是協定缺陷，還可能受到 DNS、規則或目標服務本身影響。診斷時先確認該 App 實際使用哪種流量，再查看相應請求是否有經過代理。

UDP 沒有 TCP 那種連線語意，網路設備可能很快清除閒置的對應狀態。App 在背景閒置一段時間後，第一次請求失敗、再次嘗試又恢復，有時與狀態逾期或路徑變動有關。不要立刻提高保活頻率，因為這可能讓行動網路持續啟用並增加耗電。先觀察問題是否只在長時間閒置後出現，或只發生於特定網路，再判斷是否需要調整。若持續傳輸穩定，只有喚醒後失敗，排查方向就應與一開始便無法通過認證的情況不同。

行動裝置上的效能評估

Shadowsocks 的基本封裝相對精簡，可能減少額外協定層的負擔，但實際速度仍受加密實作、裝置效能、伺服器出口與往返延遲限制。不同加密演算法在不同處理器上的表現可能有別；不能只因名稱中有較大的數字就推斷更安全或更快，也不應為了追求速度改用伺服器端未提供的方式。測試耗電時，應關注完成相同工作所需時間、重新連線次數和背景狀態，而非只比較某一瞬間顯示的傳輸量。

若已有相應伺服器，並希望以明確的位址和認證參數建立代理連線，Shadowsocks 可能適用。若需求包含私有網段互通、雙端金鑰身分或完整的網路層路由，請接著閱讀 WireGuard，而不是要求 Shadowsocks 承擔這些用途。兩者解決的問題不同，應先依存取模式選擇，再比較效能。對於訂閱中已穩定運作的項目，保留原始設定通常比為了統一類型而重新編輯更合適。

三、VMess 與 VLESS：分開看身分協定與外層傳輸

VMess 與 VLESS 常一起被提及，因為兩者都可能出現在包含使用者身分和外層傳輸設定的組態中，但不能互換。VMess 將使用者認證、請求格式與加密機制結合；VLESS 則採用較精簡的身分與請求表示方式，通常需要透過所選的外層安全機制保護傳輸。VLESS 不是把 VMess 換個名稱，也不代表在任何網路上都更快。選擇時先確認伺服器端提供哪一種，再核對完整組合；不能只複製 UUID 就認為設定已經完整。

UUID 是身分識別，不是伺服器位址

UUID 用於識別使用者，伺服器位址則用來指定連線入口，兩者屬於不同層次。手動填寫時，應保留完整 UUID 和連字號，並留意複製時是否混入空格或換行。伺服器端移除相應使用者、變更身分，或訂閱仍保留舊值，都可能造成連接埠可達但認證失敗。有些舊設定也可能包含歷史相容參數；這類值應依原始設定保留，不能根據無關教學統一設定，也不應將歷史欄位視為每種部署都必須填寫的項目。

VMess 的認證流程包含與時間相關的檢查；裝置日期或時間明顯不準時，可能導致持續失敗。先確認系統是否使用正確的自動設定時間，再排查其他參數，通常比反覆更換連接埠有效。VLESS 的身分與外層安全安排不同，不能直接套用 VMess 的所有排錯結論。通用的檢查原則是區分「無法連上入口」、「外層連線失敗」與「身分未獲接受」，並盡量從記錄或連線紀錄確認失敗階段，而不是只看連線開關的狀態。

WebSocket、路徑與伺服器名稱

外層使用 WebSocket 時，用戶端與伺服器端必須設定一致的傳輸類型和請求路徑。路徑中的大小寫、開頭斜線和附加參數都可能影響比對；看似只是說明文字的內容，也可能是真正的設定值。HTTP Host 用於辨識請求層的主機，TLS 伺服器名稱則用於安全連線中的名稱處理；兩者可能相同，也可能因部署方式而不同。伺服器位址還可能是第三個不同值，因此不能一律將三個欄位都填成連線入口位址。

使用 TLS 時，應確認憑證是否符合預期的伺服器名稱。若連線目標是 IP 位址，但憑證簽發給網域，仍須依伺服器資料填寫相應名稱；關閉憑證驗證不能取代欄位匹配。若入口前方有轉送層，請求可能會先抵達該層，再轉交給實際服務。此時路徑或 Host 不符，請求可能抵達有回應的入口，卻沒有進入正確服務。這種情況和密碼錯誤看起來都像連線失敗，但檢查順序不同。

封裝的成本與限制

多一層傳輸通常會增加交握、標頭和狀態維護的負擔，但實際影響取決於連線重用、網路延遲和請求大小。大量短連線較容易受到建立連線成本影響；持續傳輸大量資料時，則可能主要受伺服器吞吐量限制。比較 VMess 與 VLESS 時，如果兩者使用不同外層傳輸或不同入口，測得的差異就不能全歸因於協定本身。至少應固定伺服器位置、網路、工作內容和測試時段，並在記錄中寫明傳輸組合，而非只記協定名稱。

在 iOS 上，頻繁重新連線、失敗重試和網路切換造成的耗電，可能比少量協定標頭更明顯。若項目顯示連線成功，請求卻一再無法完成，應優先檢查身分、時間、路徑和 TLS，再觀察是否持續重試。伺服器端要求的特殊流量控制或擴充參數，只有在目前用戶端確實支援且資料明確時才能使用。若訂閱解析出的項目缺少必要欄位，重新整理原訂閱或核對原始資料，會比手動新增名稱相似的欄位更可靠。

四、Trojan、HTTP 與 SOCKS5：入口能力與安全限制

Trojan、HTTP 和 SOCKS5 都可用於代理連線，但認證方式、傳輸保護和目標位址的表示方式各不相同。Trojan 的設計是在 TLS 保護的連線中傳送代理請求，通常以密碼驗證身分。HTTP 代理採用常見的請求和通道語意；SOCKS5 則提供通用的代理協商方式。後兩者的基本協定本身不會自動加密用戶端與代理入口之間的傳輸，因此設定時必須確認伺服器實際提供哪一種入口；不能因為最終瀏覽的是安全網頁，就忽略代理入口的保護方式。

Trojan：先確認 TLS，再核對密碼

Trojan 的常見設定包含伺服器、連接埠、密碼和 TLS 相關選項。TLS 連線會在認證請求前建立，因此憑證問題可能導致密碼根本無法驗證。若位址可連線但交握失敗，應檢查系統時間、憑證有效性、伺服器名稱和伺服器端安全設定。若憑證與名稱都正確但認證失敗，再確認密碼是否完整、是否已更換，以及是否複製到不可見字元。不要把所有失敗都當成密碼錯誤，也不要試圖透過修改路由模式處理憑證問題。

有些部署會在同一入口結合不同服務，因此名稱與請求處理方式尤其重要。連接埠有回應，只能表示該位置有服務，不能證明回應者就是預期的代理入口。在用戶端選擇 Trojan 後，還應確認匯入資料是否包含額外傳輸設定，以及目前用戶端是否支援該組合。沒有資料時，不要替密碼加上引號、編碼或前綴；表單通常需要原始欄位值，而非包含協定標記的完整分享文字。

HTTP：通道與入口加密是兩回事

HTTP 代理可以轉送一般請求，也可以透過 CONNECT 建立通往目標的資料通道。目標使用 TLS 時，目標內容仍可能在通道內保持加密；但用戶端傳給代理的協商資訊與認證是否受到保護，取決於連線至代理時是否使用 TLS。若將「瀏覽安全網頁」和「安全連線至代理入口」混為一談，就可能誤判認證資訊暴露的範圍。若資料明確指出代理入口使用 TLS，就應依實際類型與安全選項設定，不能只更換連接埠。

HTTP 代理常用於已有明確存取策略的環境，但不應預設它能承載所有 UDP 服務。若網頁正常、即時 App 卻無法使用，原因可能是入口不支援相應流量，而非用戶端規則設定錯誤。使用者名稱和密碼也可能受存取範圍、連線數或有效期限限制。遇到認證遭拒，應核對帳戶狀態和原始資料；若只有部分目標遭拒，則繼續區分入口策略與目標服務的回應。兩種情況都不應只靠反覆重新整理訂閱來取代原因分析。

SOCKS5：通用協商不等於內建加密

SOCKS5 可以傳遞目標位址和連接埠，也定義了身分協商與 UDP 轉送機制，但伺服器是否啟用認證、是否開放 UDP，都須分別確認。基本的使用者名稱與密碼認證本身不會加密內容，使用時必須具備符合需求的保護措施。以網域名稱或 IP 位址的形式將目標交給代理，也會影響 DNS 在哪一端進行解析。不能只因類型是 SOCKS5，就斷定所有網域查詢都會在遠端完成；還須檢查用戶端解析策略、規則需求和實際連線紀錄。

對這三種入口而言，選擇的重點是確認現有服務實際支援的功能，而非籠統比較快慢。Trojan 的安全連線需要建立成本，HTTP 通道可能受入口策略影響，SOCKS5 的 UDP 則可能受到網路設備限制。在行動裝置上，應分別檢查短時間請求、持續傳輸和閒置後的恢復情況。若存取範圍或安全需求不明，應先向自己的服務商確認欄位用途，不要關閉驗證、留空密碼，或改用相似類型試探。

五、WireGuard：金鑰、通道位址與網路層路由

WireGuard 以網路層通道和對等端身分為核心，設計著重於精簡協定與明確的加密組合。它不同於逐一代理請求目標的模式：進入通道的是網路封包，連線設定還須描述本機通道身分、對端位置和允許的位址範圍。因此，只有伺服器網域名稱和密碼並不足以設定 WireGuard，也不能將其他協定的密碼填入金鑰欄位。使用前應取得完整且適用於目前裝置的資料，並確認伺服器端已登記相符的公鑰。

Private Key 與 Public Key 的用途

Private Key 是本機的身分資料，應妥善保密；Public Key 則用於讓對端識別相應身分。用戶端填寫的對端公鑰應來自伺服器資料，而不是本機公鑰。伺服器端也須知道用戶端公鑰；若雙方設定不相符，即使 UDP 封包能抵達，也無法建立預期的安全通訊。若資料還包含預共享金鑰，它是額外的共同秘密，不能取代任一端的金鑰組。不要為了讓欄位看起來一致，就在多個位置貼上相同字串。

更換裝置時，應區分「還原設定」和「多台裝置同時共用身分」。兩台裝置若使用相同身分與位址，伺服器觀察到的端點可能反覆變動，造成連線不穩或流量轉到另一台裝置。是否允許共用取決於伺服器部署，不能因為檔案能匯入，就認為多台裝置一定可同時使用。排查時記錄目前有幾台裝置使用該身分，並依現有服務說明為各裝置配置獨立資料，通常比在用戶端反覆切換伺服器更有助於找出問題。

Endpoint、Address 與 Allowed IPs

Endpoint 指透過目前網路可連線的對端位址和連接埠；Address 指通道內的本機位址，兩者不可互換。Allowed IPs 在 WireGuard 協定模型中，與對等端相關的位址選擇和接收驗證有關；整合至用戶端後，還須連同 App 的路由機制理解。若未正確涵蓋某個網段，通道交握可能正常，目標卻仍無法連線。反過來說，範圍設定得太廣，也可能讓原本應在本機存取的流量走上不適當的路徑。

存取私有網路時，也要考量回程路徑。用戶端送出的資料抵達對端，不代表對端後方的裝置知道如何回應用戶端的通道位址；伺服器端轉送、回程路由和存取策略都可能影響結果。若只能連線至對端本身，無法存取後方網段，檢查重點應轉向伺服器端的網路設定，而不是重新產生用戶端金鑰。DNS 也是獨立問題：私有網域可能需要指定解析來源，但指定了解析器不代表相應位址已可路由。

UDP、MTU 與保活的實際影響

WireGuard 使用 UDP，當前網路能否傳送相應 UDP 流量是基本前提。若路徑的有效 MTU 不足，小型請求可能正常，大型回應或部分服務卻可能卡住，因為封裝會增加封包負擔。遇到這種情況，應先核對部署建議與路徑條件，再有依據地調整；不要將某個固定數值視為適用所有網路的通用答案。每次調整後，以同一個大檔案或固定請求驗證，並保留原始數值，以確認改善是否確實來自這項修改。

Persistent Keepalive 用於在有需要時維持網路對應狀態，不是越頻繁越穩定。在行動網路上，額外的定期傳輸可能延長無線電啟用時間；若不需要維持對應狀態，過度設定只會增加背景活動。WireGuard 的精簡設計有助於控制協定成本，但耗電仍取決於流量、訊號和重新連線情況。它較適合已有完整對等端資料、需要明確網路層位址關係的情境，而不是只因協定名稱就期待更省電。

六、Hysteria2：QUIC、擁塞控制與頻寬預期

Hysteria2 是以 QUIC 為基礎的代理傳輸協定，設計著重於在封包遺失或往返延遲較高的路徑上維持有效傳輸。QUIC 以 UDP 承載，並在其上實作安全連線、可靠傳輸等機制，因此不只是原樣轉送 UDP，也不能理解成完全不需要擁塞控制。使用前提是已有相容的伺服器資料，且目前網路能傳送相應的 UDP 流量。名稱相近的不同協定世代不保證互通，匯入時必須保留正確類型。

先確認 UDP 與 TLS 的使用條件

連線入口、連接埠、認證資訊和 TLS 伺服器名稱都必須相符。網路可以瀏覽 TCP 網頁，不代表同一位置的 UDP 入口也一定可用；部分網路會限制 UDP，或以不同方式處理持續傳輸。若所有請求都在建立連線階段逾時，應先檢查 UDP 是否可連線及伺服器是否正在監聽，而非立即調整頻寬參數。若連線回報憑證問題，應檢查系統時間、伺服器名稱和信任鏈，不能靠提高速率設定來繞過安全連線失敗。

伺服器資料可能還包含額外處理參數，必須確認目前用戶端是否支援並正確匯入。認證值涉及請求權限，不能用網站登入密碼或其他協定的密碼取代。若部署採用會變動的連接埠，也應完整核對伺服器說明與用戶端支援情況；偶爾有一個連接埠能連線，不代表整份設定都正確。資料不完整時應先停止猜測，補齊正確欄位後再測試效能，否則每次失敗都會牽涉多個不確定因素。

頻寬欄位不代表實際速度保證

某些設定組合會涉及上行與下行頻寬預期，這些數值可能影響傳輸行為或擁塞控制，但在用戶端輸入數值並不會增加線路容量。若將預期值設得遠高於實際可用頻寬，可能導致佇列堆積、封包遺失增加，並影響同一網路上的其他服務。數值過低則可能限制可用吞吐量。是否需要填寫、應如何解讀，以及如何配合伺服器端設定，都應依目前實作與既有服務說明判斷，不能套用任何固定數值。

也要分清方向：裝置送出資料與裝置接收資料是不同方向，不要因為測速頁面特別醒目地顯示下載結果，就把相同數值複製到兩個欄位。行動網路的可用容量也會隨位置、訊號和時段改變；在實驗室條件下合適的預期，未必適合移動途中。調整時先保留保守的基準設定，觀察工作完成時間和其他 App 是否受到影響，再逐步調整；若吞吐量增加但操作明顯卡頓，就不應視為整體表現改善。

封包遺失恢復的優勢與資源成本

QUIC 能在同一連線中管理多個資料流，避免不同資料流完全受到傳統有序位元組流交付限制的影響，但所有資料流仍共用底層路徑與擁塞資源。封包遺失時，仍須重新傳送相應資料，實際效益取決於工作內容與路徑狀況。在某些網路條件下，它可能優於其他傳輸方式；在穩定、低延遲的網路上，則可能看不出明顯差異。把單次測速結果延伸為所有情境的排名，會忽略伺服器設定和網路條件這兩個重要變因。

在 iPhone 和 iPad 上，用戶空間中的協定處理、加密、持續高吞吐量，以及封包遺失後的恢復都需要資源。單次工作更快完成，可能縮短網路活動時間；但若持續讓連線處於高負載，也可能增加裝置發熱與耗電。評估時應同時觀察穩定性、工作完成時間、背景恢復情況和裝置狀態。長時間等待並反覆重試的連線，不適合作為耗電測試對象；應先修復連線問題。選擇協定是為了符合實際存取需求，而不是把某個參數調到最大。

七、核對參數：分開驗證協定連線與規則分流

協定參數負責連線至伺服器，Global Routing 則決定流量如何使用這條連線。兩者應分開驗證，否則容易把規則問題誤判為協定問題。先在 Home 確認目前選取的伺服器，再核對 Global Routing。Config 會依設定檔中的規則處理流量；Proxy 用於診斷時將流量統一導向代理；Direct 則用於直連。這些選項描述的是路由選擇，不會改寫伺服器的認證或傳輸能力。操作流程請參閱使用教學；三種模式的說明請見Global Routing 專題。

逐層核對位址、名稱與認證

伺服器位址可以是主機名稱或 IP 位址。使用主機名稱時，必須先解析連線入口；入口解析錯誤會發生在協定認證之前。TLS 伺服器名稱則用於安全連線中的名稱處理，不應與最終存取的網站網域混淆。連接埠必須填入相應服務正在監聽的值，改成常見連接埠不會讓伺服器自動提供另一種協定。使用者名稱、密碼、UUID 和金鑰分屬不同認證機制；空值、編碼變化或前後空格都可能改變內容，應依原始資料核對，不要自行重新解讀。

不要把完整分享連結直接填入單一參數欄位，也不要將訂閱連結當作伺服器位址。訂閱是取得一組項目的入口，裡面的每個項目才可能包含協定與認證欄位。更新訂閱後，舊項目可能被替換、重新命名或移除；手動修改也可能在之後更新時被覆蓋。若要長期驗證某項調整，應建立並清楚命名獨立副本，同時避免在名稱中寫入密碼。匯入方式的差異請參閱訂閱匯入說明。

規則只決定流量去向，無法修復伺服器

以下是用於說明匹配順序的 Shadowrocket .conf 規則片段，不包含伺服器設定，也不能直接取代你現有的完整設定檔。網域規則會先比對指定後綴；本機網段規則則處理相應位址；FINAL 為其餘請求提供預設策略。複製到現有設定前，應先了解原有規則結構和預設策略，以免覆蓋既有的私有網路設定。此處使用保留的示範網域，只用於展示語法，不代表任何連線服務。

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

規則通常依序比對；較寬泛的條件若放在前面，可能會遮蔽後續較精確的條件。DOMAIN-SUFFIX 依網域後綴判斷，IP-CIDR 則依位址網段判斷，兩者仰賴的資訊不同。有些位址判斷可能涉及解析，因此 DNS 結果會影響後續行為；但 DNS 解析成功本身不代表代理出口能連線至目標。排查時先用明確的網域規則確認流量去向，再檢查目前紀錄中的實際目標位址，不要同時新增多條彼此重疊的測試規則。

透過對照測試區分規則與協定問題

若同一伺服器在 Proxy 模式下能完成固定的存取操作，在 Config 下卻失敗，應優先檢查規則命中、策略引用和 DNS，而非立即修改協定。若兩種模式都失敗，再檢查伺服器參數與入口路徑。Direct 可用於確認目前網路的基本連線能力，但直連成功不代表代理伺服器可連線。測試結束後應恢復原本需要的模式，避免診斷設定長期改變所有流量的去向，導致後續觀察結果與日常設定不一致。

涉及 IPv6 時，還要確認目標解析結果、規則和伺服器能力是否相符。只處理 IPv4 的規則未必涵蓋 IPv6 請求；同一網域在不同網路解析出不同位址，也可能造成看似隨機的差異。不要只因部分請求失敗就直接改寫所有 DNS 設定；先記錄實際位址類型、命中策略和失敗時間，再逐項驗證。常見概念請參閱概念速查，避免將不同層次的術語誤認為同一個開關。

八、情境選擇：以可重現流程判斷結果

選擇協定時，首要條件是符合你已有的伺服器端設定，其次才是工作內容與網路條件。已有穩定設定時，不必為了追求某個協定名稱而更換。日常瀏覽網頁與收發訊息，較重視首次回應、背景恢復和連線成功率；持續傳輸則更重視吞吐量與長時間穩定性；存取私有網路時，應先確認位址關係和回程路徑；依賴 UDP 的服務則須確認整條 UDP 路徑正常。只有在伺服器端確實提供多種相容選項時，同條件比較才有意義。

建立可重複的測試紀錄

先固定裝置、網路、目標和測試工作，關閉會影響結果的其他測試設定，並保留目前設定的副本。記錄協定與外層傳輸、Global Routing 模式、是否剛切換網路，以及失敗發生在哪個步驟。測試網頁時使用相同目標和相近內容；測試持續傳輸時固定檔案和時間，並留意快取影響。不能直接比較新連線的建立時間與另一條已重用連線的請求，也不能把不同時段的伺服器負載差異全算在協定上。

Connectivity Test 可協助判斷所選項目的可連線性或測試請求表現，但單次成功不代表所有服務都正常，單次數值也不代表完整吞吐量。應搭配實際目標的存取結果與連線紀錄，區分入口連通、認證通過、請求送出和回應完成。首次連線的具體操作請見首次連線檢查清單。若連線開關已啟用但網頁仍無法開啟，先不要同時更新訂閱、修改 DNS 和切換協定，否則無法判斷哪一步造成影響。

依失敗階段縮小排查範圍

1. 入口之前：檢查本機網路、伺服器網域解析、位址與連接埠，並確認目前選取的項目就是測試對象。
2. 建立連線：檢查協定類型、TCP 或 UDP 條件、TLS 名稱、系統時間與憑證問題。
3. 認證階段：檢查密碼、UUID、金鑰和伺服器端登記狀態，確認訂閱沒有保留已失效的資料。
4. 請求階段：檢查 Global Routing、規則命中、目標解析、UDP 支援和位址類型。
5. 持續傳輸：檢查封包遺失、有效 MTU、伺服器負載、頻寬預期和閒置對應狀態的變化。

判斷階段不是要求一定要看到某種固定錯誤訊息，而是將證據放在正確的位置。若入口完全沒有回應，檢查密碼通常沒有幫助；若交握已完成，只有特定網段失敗，應檢查路由與回程路徑；若所有目標都能開始載入，卻在收到較大回應時停住，則應考慮路徑和封包大小。若紀錄只顯示一般逾時，可透過對照測試補充證據，例如在相同網路和模式下測試另一個已確認可用的項目，而不是立刻認定協定不適用。

耗電比較應涵蓋背景運作與網路切換

耗電比較應以完成同類工作和相近使用時段為基準，並盡量維持螢幕亮度、訊號、背景 App 和測試時間一致。記錄是否發熱、是否頻繁重新連線、閒置後能否恢復，以及從 Wi-Fi 切換至行動網路後的表現。短時間內電量百分比的變化較粗略，不能據此宣稱某種協定固定省下多少電。若連線持續失敗並不斷重試，應先排除失敗原因再比較；若工作提前完成，也應把後續閒置時間納入觀察，才更接近日常使用情況。

需要長時間維持背景連線時，保活與 On Demand 應依實際需求設定，不要一律開啟。保活可能維持網路對應狀態，也可能增加網路活動；On Demand 負責依條件觸發連線，無法修正認證或規則錯誤。若每次切換網路都需要手動恢復，應分別檢查系統觸發條件、傳輸重建和伺服器狀態。單次網路切換測試只能提供線索，最好在相同條件下重複確認，並保留恢復前後的連線紀錄。

下結論前，先寫明適用條件

合理的結論應說明「在這台裝置、這個網路、這項工作和這套伺服器設定下，哪種組合較穩定」，而非宣稱某種協定永遠最快。日常使用應優先選擇參數明確、恢復可靠且容易維護的項目；需要特殊網路功能時，再選擇符合需求的類型。保留一項已確認可用的基準設定，定期透過原有入口更新自己的訂閱，並避免同時維護多份用途不明的副本。更多問題請參閱常見問答或連線後無法上網的逐項排查。