官方手冊 · 協定技術參考
Shadowrocket
協定參數與選擇
先確認伺服器實際支援的協定，再核對傳輸方式、驗證資料與憑證。協定名稱不代表速度或耗電表現。
- Shadowsocks
- VMess / VLESS
- Trojan
- HTTP / SOCKS5
- WireGuard
- Hysteria2
本頁為系統性參考手冊，適合已備有訂閱或伺服器資料的使用者。第一次新增設定、允許 VPN 設定並建立連線，請先依使用說明完成基本操作；需要了解欄位、比較傳輸方式或排查協定問題時，再回到本頁查看相關章節。本網站不提供、不販售也不推薦節點、訂閱或連線服務。
Shadowrocket 是 Apple 平台上的閉源商業 App，主要供 iPhone、iPad 使用，唯一取得管道為 App Store。系統需求請以 App Store 頁面標示為準。App 一次性買斷 ≠ 線路方案；購買 App 不會取得伺服器位址或驗證資料。正版入口、開發者與 App ID 的確認方式請參閱App Store 下載說明。
- 選擇前提伺服器已支援
- 參數來源使用者現有設定
- 測試方式一次只改一項
01 / 分層判斷
協定、傳輸與規則各自負責什麼
先分清四個不同問題
在 Add Server 中選擇協定，是在指定用戶端如何與伺服器交換驗證資料和業務資料。填寫位址與連接埠，是指定連線目的地。選擇 TCP、WebSocket 或其他傳輸方式，是決定資料如何透過外層傳送。設定 TLS，則是決定這一層連線如何驗證伺服器身分並保護資料。這些欄位彼此相關，卻不是同一回事；只把 Type 改成另一個名稱，不會讓伺服器因此支援另一種協定。
規則分流屬於另一套判斷流程。Global Routing 使用 Config 時，用戶端會依目前設定判斷要求應採用哪種策略；要求交由代理處理後，所選伺服器的協定才會參與通訊。規則正確，不代表伺服器驗證也正確；伺服器能連線，也不代表每個網域都套用了預期策略。排查時應分別記錄「選用了哪個出口」和「出口能否完成連線」，避免反覆修改彼此無關的欄位。
不要混淆位址、身分與目標網域
伺服器位址是用戶端首先連線的目標，可以是網域名稱，也可以是 IP 位址。TLS 的 Server Name 通常用於伺服器身分驗證及交握時的名稱宣告。WebSocket 的 Host 和 Path 則是相關傳輸的要求資訊。有些設定中的三者相同，有些則不同。不要因為幾個欄位都能填網域名稱，就全部填成同一個值；應逐項依原始參數核對，並保留伺服器要求的大小寫與路徑格式。
使用者最後要存取的網站，是另一層的目標。代理伺服器負責連線至該目標，不代表應將目標網站名稱填入用戶端的 Server Name。同樣地，連線伺服器時進行的網域解析，與建立代理後存取網站時進行的解析，可能經過不同路徑。若網頁無法開啟，但 Connectivity Test 有結果，應先確認測試實際檢查了哪一段，不要據此認定所有解析與業務要求都已成功。
依設定模式界定檢查範圍
Global Routing 的 Config、Proxy、Direct 分別適合用來檢查規則分流、代理路徑與直接連線的差異。此處的「代理」不代表所有系統流量都一定經過同一路徑；本地網路、排除項目及 App 行為仍須依實際設定檢查。切換模式只是診斷方式，無法修正錯誤的密碼、憑證或連接埠。排查完成後，請還原原本需要的模式，避免將暫時測試變成長期設定。
| 層級 | 決定內容 | 常見檢查項目 |
|---|---|---|
| 規則 | 要求採用哪種策略 | Config、規則順序、最終策略 |
| 協定 | 驗證方式與資料交換格式 | Type、密碼、UUID、金鑰 |
| 傳輸 | 協定資料如何承載 | TCP、UDP、Host、Path |
| TLS | 外層加密與身分驗證 | Server Name、憑證、裝置時間 |
以下片段屬於 .conf 的 Rule 區段，用來示範分流順序，並非伺服器設定，也不能取代訂閱。第一條比對指定網域及其子網域，第二條比對相應的 IP 位址歸屬，最後一條處理未符合前述規則的要求。範例中的 PROXY 仍須對應實際可用的代理策略；複製規則前，請先確認目前設定採用的策略名稱與用途。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY規則會由上而下比對，符合後即停止。若將涵蓋範圍較大的規則排在前面，後續的精確規則可能就不會生效。排查協定問題時，盡量不要同時變更規則順序，否則存取成功或失敗可能同時受到出口與傳輸方式影響，難以判斷變化原因。更多關鍵字的適用範圍，請參閱規則關鍵字與比對順序；首次連線仍請依使用說明中的步驟操作。
先記錄原始設定，再一次只變更一個變數。名稱相同不代表欄位可以互換；測試有結果，也不代表整條業務路徑都已驗證。
02 / 對稱式加密代理
Shadowsocks：加密方法與密碼必須相符
設計重點是減少工作階段層級
Shadowsocks 將代理轉送與對稱式加密結合，讓用戶端和伺服器依照約定的加密方法與金鑰資料交換資訊。這與先建立標準 TLS 工作階段，再承載代理驗證的方案不同；基本設定通常包含位址、連接埠、加密方法與密碼。欄位較少不代表可以任意填寫；這些資料共同決定伺服器能否辨識資料，任何一項不一致都可能使通訊在連線初期中斷。
了解這項設計背景，有助於掌握它的使用範圍：Shadowsocks 主要處理代理要求，不會自動建立完整的私有位址網路，也不會因為名稱中有「加密」就具備網站憑證驗證。網站使用 HTTPS 時，應用層安全仍由網站連線負責；用戶端到代理伺服器之間則依 Shadowsocks 的具體加密方法處理。區分不同層級的保護，才能避免誤以為選定某種協定後，就可以忽略憑證或目標網站的提示。
Method 不是可單獨調整的速度檔位
匯入現有設定後，首先核對加密方法。不同方法在驗證、金鑰衍生及資料封裝上各有差異，不能只因某個名稱看起來比較新，就單方面在用戶端替換。採用 AEAD 的方法會同時處理機密性與完整性，但不同協定世代的金鑰格式和交握方式仍可能不同。伺服器提供哪種方法，用戶端就必須使用相符的方法；是否支援特定選項，請以目前 App 內提供的類型及既有伺服器資料為準。
密碼欄位也不一定接受任意短文字。某些方法要求特定格式的編碼金鑰，另一些則會透過密碼衍生金鑰。不要自行刪除結尾的等號、加入空格，或將編碼文字解碼後再貼回。手動輸入時，請特別檢查前後空白、全形標點與換行；從 QR Code 或分享連結匯入時，則要查看解析後的欄位，不要只核對清單上的備註名稱。備註可以任意修改，不能據此推斷驗證資料。
TCP 成功不代表 UDP 路徑也正常
網頁要求與即時 App 使用的傳輸方式可能不同。伺服器的 TCP 入口可連線，不代表同一連接埠已啟用 UDP 轉送，也不代表目前網路允許相關資料雙向傳送。若網頁能開啟，但語音或某項即時功能異常，請先確認伺服器是否支援相關 UDP 轉送，再檢查用戶端選項與網路路徑。不要直接把這種情況歸因於密碼錯誤，因為密碼完全不符時，通常連基本代理要求也無法完成。
同樣地，有些現有設定還包含額外的傳輸或混淆參數，但並非所有 Shadowsocks 伺服器都需要這些參數，不應照著其他設定補上。若訂閱匯入後可以正常使用，手動重建卻失敗，請比對兩筆設定中的加密方法、密碼、位址、連接埠和額外欄位，不要不斷切換 Global Routing。選用這些欄位的前提，是伺服器端已啟用相應功能；用戶端的開關無法替伺服器增加支援。
在 iPhone 上如何看待效能取捨
Shadowsocks 的實際運算負載，與使用的演算法、裝置硬體及業務資料量有關。外層交握較少，有時有利於短連線；但實際網頁還包含網域解析、目標網站回應與多個資源要求，不能只看協定層數判斷載入速度。長時間傳輸時，吞吐量也可能受伺服器頻寬、無線訊號或目標網站限制。如果瓶頸不在加密運算，改用另一種方法也不會自動提升業務速度。
評估耗電時，應將連線方式與無線網路環境一併納入考量。訊號較差時，重傳和無線模組持續運作的影響可能比演算法差異更明顯；頻繁測試、不斷重新整理訂閱也會增加活動量。比較時應固定使用同一網路、相同工作及大致相同的螢幕狀態，並區分閒置時維持連線與持續下載。系統電池統計中的 App 用電比例不能直接視為協定耗電率，因為統計期間與背景工作未必一致。
若現有伺服器明確提供相符的加密方法、欄位簡單且實際業務驗證正常，就適合繼續使用 Shadowsocks。需要調整時，先確認參數一致，再檢查解析與傳輸。若無法確認分享連結的前綴、編碼或密碼部分，可參考分享連結與訂閱格式說明判斷資料類型。不要把整條分享連結填入密碼欄，也不要把訂閱網址當成伺服器位址。
03 / 驗證與外層承載
VMess 與 VLESS：欄位相近，約定不同
UUID 相同不代表協定相同
VMess 將身分驗證、資料封裝及協定本身的安全處理結合，常見設定會使用 UUID 識別使用者。VLESS 採用較精簡的協定層設計，本身不提供與 VMess 相同的載荷加密機制，通常仰賴外層安全傳輸保護連線。兩者的設計重點不同，因此不能只保留相同的 UUID，再把 Type 從 VMess 改成 VLESS，就期待伺服器仍能辨識。
兩者經常搭配其他傳輸方式使用，這也是介面欄位較多的原因。協定類型處理驗證與格式，外層傳輸負責承載，TLS 等機制則提供相應的連線保護。實際部署可能只支援其中一種組合。若使用者現有資料已明確列出協定與傳輸方式，就應完整保留；若只有位址、連接埠和 UUID，資料可能不足以還原設定，必須從原始設定確認其餘條件。
先核對身分資料，再核對傳輸欄位
UUID 必須完整保留字元與連字號格式，不要把備註、訂閱群組名稱或伺服器網域填在此欄。VMess 設定也可能包含安全方式與歷史相容欄位；舊資料中的額外驗證參數並非新設定都要照填的預設值。不要為了比照舊說明圖片而自行加入數值。請以目前伺服器提供的設定及 App 實際可選欄位為準；若無法對應，先確認資料是否屬於同一種協定。
使用 WebSocket 的連線中，Path 是伺服器接受連線的路徑，通常以斜線開頭；Host 則是要求中的主機資訊。路徑是否區分大小寫、是否包含查詢字串，都由部署方式決定。清空路徑或只保留最後一段，可能會讓伺服器回傳一般網頁，而不是建立代理傳輸。如果位址解析正常、連接埠也可連線，但連線很快中斷，應優先確認這一層是否與伺服器設定一致。
TLS 開關、Server Name 與憑證驗證應分別核對。使用網域名稱連線時，伺服器位址可能與憑證名稱相同；若使用指定位址連線，Server Name 仍可能需要填寫憑證涵蓋的網域。TCP 已連線不代表可以略過身分驗證，也不應藉由關閉驗證來掩蓋名稱錯誤。若原始設定包含額外安全機制或 Flow 等條件，必須確認雙方都支援該組合，不要只憑協定名稱自行推斷。
外層傳輸會改變連線成本
WebSocket 會為代理資料增加一層符合特定服務架構的封裝，能配合既有的 HTTP 服務接入方式，但也會增加交握與影格處理。直接使用 TCP 時，層級可能較少，卻需要伺服器入口與網路路徑符合不同條件。沒有一種組合適用於所有裝置：參數完整、路徑穩定的設定，往往比理論上層級較少、實際卻頻繁失敗的組合更適合日常使用。
在封包遺失的環境中，疊加多個可靠傳輸層可能增加等待與緩衝；實際影響也取決於連線重用方式及伺服器實作。不能看到 WebSocket 就斷定速度慢，也不能看到 VLESS 就認為比較省電。iPhone 維持一條長連線與反覆重建多條短連線時，交握負擔所占比例不同；網路切換後能否順利恢復，也會影響無線模組的運作時間。應以相同工作的多次測試結果評估，而不是按名稱排序。
將故障定位到具體階段
若所有業務都失敗，先確認目前選取的 SERVER 記錄確實是正在編輯的那一筆，再核對協定、連接埠和 UUID。若只有部分網站可用，請分別檢查規則比對、解析及目標網站。若只在切換網路後出現異常，可以先停止再重新建立連線，觀察是否為舊工作階段恢復問題；不要立刻改寫身分欄位，因為同一設定先前曾成功，本身就是有用的排查線索。
VLESS 的精簡協定層，不代表整條連線沒有成本。TLS、傳輸、重新連線與業務要求仍會影響速度和耗電。
手動設定不應變成不斷嘗試填入欄位。較可靠的做法是先匯入一筆完整的原始記錄，保留可正常運作的基準，再逐項確認各欄位如何對應介面。若訂閱更新後欄位有所變動，應比較更新前後的記錄，不要把舊記錄中的部分欄位混入新記錄。設定檔的分流設定也應與伺服器記錄分開保存；結構關係請參閱.conf 各區段用途說明。
04 / TLS 身分驗證
Trojan：在 TLS 內進行密碼驗證
先建立安全連線，再交換代理資訊
Trojan 透過 TLS 建立受保護的連線，再於其中承載驗證與代理要求。它結合標準安全傳輸與代理協定，因此密碼正確只是必要條件之一，憑證、名稱及外層連線也必須相符。了解這個順序很重要：若 TLS 交握階段已失敗，修改代理密碼通常沒有幫助；若交握成功後驗證被拒，反覆更改憑證名稱也無法修正錯誤密碼。
這種設計與直接使用對稱金鑰保護代理載荷的方式不同。TLS 需要伺服器提供可驗證的身分，並協商連線所需參數。它能保護用戶端到伺服器之間的連線，但不會取代目標網站本身的 HTTPS 驗證，也不保證伺服器連往目標網站時的所有行為。查看錯誤訊息時，應先分辨是代理伺服器憑證問題，還是瀏覽器顯示的目標網站憑證問題；兩者屬於不同連線。
Server Name 應與憑證相符
伺服器位址負責將連線導向指定入口，Server Name 通常用於 TLS 名稱宣告及憑證驗證。若現有設定使用 IP 位址連線，卻為 TLS 指定網域名稱，不一定是填錯；伺服器可能正是以該網域提供憑證。反之，任意改填目標網站名稱並沒有幫助。判斷依據應是伺服器憑證涵蓋哪些名稱，以及原始設定要求使用什麼值，而不是哪個網域看起來比較熟悉。
憑證驗證會受到有效期限、信任鏈、名稱及裝置時間影響。裝置日期明顯不正確時，原本有效的憑證也可能被判定為異常。伺服器更換憑證或中繼憑證鏈不完整時，用戶端同樣可能拒絕連線。遇到憑證錯誤，請先檢查自動設定日期與時間、伺服器參數及憑證狀態；不要把允許不安全連線當成一般修復方式，因為這會改變身分驗證的前提，而不是還原原本正確的設定。
逐項核對密碼與額外參數
Trojan 的密碼是伺服器驗證資料，不是裝置解鎖密碼，也不是 App Store 購買資料。貼上時應保留完整內容，避免在文字末尾帶入換行。若密碼包含特殊字元，分享連結中的編碼與解碼可能影響顯示內容；匯入後應查看實際欄位，不要將已跳脫的文字再次手動跳脫。僅憑備註寫有 Trojan，無法確認連結內容與用戶端 Type 都已相符。
某些既有部署包含額外傳輸選項，這些設定必須與伺服器端相符。缺少說明時，不要自行新增 WebSocket、修改 Path 或加入不明的協商值。若外層入口要求特定主機、路徑或交握條件，漏掉其中一項可能使要求被其他服務接收。能開啟同網域的一般網頁，只能證明該網站入口可連線，不能證明代理驗證路徑與對應連接埠設定正確。
交握、連線重用與背景活動的取捨
TLS 交握包含密碼學運算與網路往返，因此建立新連線需要成本；已建立的連線可以承載後續資料，實際重用方式取決於協定與實作。偶爾開啟網頁時，建立連線所需的時間可能比持續吞吐更明顯；長時間播放或傳輸時，交握只占整個工作的其中一部分。不能只看一次 Connectivity Test 的數值，就推斷整段影片的體驗或全天耗電表現。
在 iOS 上，背景網路活動也會受到 App 工作、系統排程與目前網路影響。頻繁中斷再連線可能增加交握次數；長時間維持大量連線要求，也可能讓無線模組持續運作。合理設定不代表一律保持或一律中斷連線，而是依實際需求管理連線。On Demand 控制連線的觸發條件，不會改變 Trojan 的密碼或憑證，也不是能自動消除交握成本的開關。
若現有伺服器提供有效憑證、明確密碼與完整參數，Trojan 可作為依標準 TLS 身分驗證管理的選項。選擇時應重視憑證是否便於核對、錯誤訊息能否分層判斷，而不是把 TLS 字樣當成品質等級。憑證故障與網域解析故障可能有相似表象，建議一併參閱DNS 解析失敗排查，先找出問題發生在哪個步驟。
05 / 通用代理介面
HTTP 與 SOCKS5：轉送能力不等於連線加密
從 App 代理需求發展出的兩種方式
HTTP 代理最初用於轉送 HTTP 要求，也可透過 CONNECT 方法建立通往指定目標的通道。SOCKS5 則提供較通用的代理協商機制，讓用戶端向伺服器提供目標位址與連接埠；支援哪些命令及驗證方式，取決於雙方設定。兩者都能作為代理入口，但要求語意和交握格式不同，不能因位址與連接埠相同，就把 HTTP 入口當成 SOCKS5 新增並期待它能相容。
這類協定常見於使用者自行管理的網路環境，或明確提供通用代理介面的伺服器。它們著重代理轉送，並不預設提供與現代加密通道相同的連線保護。是否使用 TLS、如何驗證，以及是否允許存取特定目標，都需要另外確認。允許 CONNECT 的 HTTP 代理也可能限制連接埠或存取範圍，因此能瀏覽網頁，不代表所有 App 和目標都能透過該入口連線。
HTTPS 網站與安全代理不是同一回事
透過 HTTP 代理存取 HTTPS 網站時，CONNECT 建立的通道可以承載網站本身的 TLS。網站內容因此可能受到端對端保護，但用戶端與代理之間的代理交握及其他中繼資料，不會只因目標網站使用 HTTPS 就全部加密。請分別判斷「網站連線使用 TLS」與「連線至代理入口使用 TLS」；現有設定要求哪一種，用戶端就應選擇相符類型。
SOCKS5 本身也不等於加密傳輸。使用者名稱與密碼驗證用於辨識使用者，不代表驗證資料及後續內容會自動受到機密性保護。設定密碼不代表整段連線已加密；不了解網路環境時，也不應將敏感驗證資料當成一般備註傳送。連線是否適合目前用途，須一併考量底層網路、外層保護及伺服器存取控制。
驗證、解析與 UDP 是不同面向
HTTP 代理可能要求使用者名稱和密碼，也可能採用其他接入限制；SOCKS5 也有自己的驗證協商。驗證失敗時，先確認伺服器要求的方式是否受到目前設定支援，再檢查文字內容。TCP 連接埠可連線不等於驗證通過，因為連接埠連通只是連線初期的一個步驟。伺服器明確拒絕驗證與連線逾時不同；前者應檢查身分資料，後者還須確認位址、連接埠及網路路徑。
目標網域在哪裡解析，會影響連線能力及排查方向。SOCKS5 可在要求中傳送網域名稱或位址，但實際採用哪一種，也取決於用戶端解析策略及要求來源。不能只憑協定名稱就推斷每次解析一定由伺服器端執行。若部分網域無法連線、但直接使用位址正常，請檢查解析路徑與回傳結果；以位址取代網域測試時，也要留意 HTTPS 憑證名稱與虛擬主機可能因此不同。
SOCKS5 協定定義了 UDP 相關機制，但實際入口未必已啟用或允許相應轉送；一般 HTTP CONNECT 也不應直接當成通用 UDP 通道。對即時 App，請先確認原始服務說明是否包含所需功能。若網頁正常、即時功能異常，不要把 HTTP 與 SOCKS5 互換當成預設修復方式。兩種協定需要不同的伺服器支援，錯誤切換只會帶來新的交握問題。
如何判斷是否適合繼續使用
這類通用介面的優點是用途明確，許多受控環境已有相應服務，適合依既有網路設計使用。限制則是安全保護、驗證及轉送範圍可能需要其他機制補足。選擇時，先確認用途是少量網頁要求、特定 App 轉送，還是需要涵蓋更多業務，再核對伺服器實際允許的範圍。不要因為協定名稱較短，就認定它一定更快或更省電。
在 iPhone、iPad 上，實際負載也取決於連線數量、伺服器回應與無線網路。代理層級較少時，某些工作可能較簡單；但若目標限制造成頻繁失敗重試，整體活動量反而可能增加。檢查時應使用相同目標工作，分別記錄解析、驗證與內容載入結果。清單中的測試結果不足以證明目標業務可用；常見狀況及後續檢查方式，請參閱常見問題。
06 / 網路層通道
WireGuard：金鑰、位址與路由須一併理解
它不是只替換密碼的代理類型
WireGuard 用於建立網路層加密通道，透過公鑰身分與固定的密碼學設計建立對等連線。相較於只表示單次代理目標的協定，它還涉及通道內位址、對端及允許通過的位址範圍。因此，設定中的位址區段與金鑰並非多餘資料，而是描述網路關係的必要資訊。通常只憑伺服器位址和一組密碼，無法還原完整的 WireGuard 設定。
這種設計適合已有明確通道規劃的網路，但要求雙方對位址與路由有共同認知。使用者在 Shadowrocket 中以 WireGuard 作為出口時，仍須區分用戶端規則選擇與 WireGuard 設定中的位址限制。前者決定要求是否交由該出口處理，後者影響通道如何接收及轉送相關流量。兩層限制同時存在時，只檢查其中一層，可能得出互相矛盾的判斷。
Private Key 與 Public Key 不可互換
Private Key 是本端的身分資料，應妥善保管；Public Key 則供對端識別相應身分。用戶端需要知道伺服器的公鑰，伺服器也必須設定與該用戶端相對應的公鑰。不能把伺服器公鑰填成本端私鑰，也不能因為字元外觀看起來相似，就認為金鑰可以互換。若設定使用 Preshared Key，它屬於額外的共享資料，雙方必須一致；不可憑空新增，或只在其中一端自行產生後修改。
通道內位址不是伺服器的公網位址。前者用於通道內的網路關係，後者則用來找到實際接收 UDP 資料的 Endpoint。填寫位址時，應保留原始設定要求的前綴長度；若將通道內位址誤填為 Endpoint，用戶端可能根本無法從目前網路連線。連接埠也是 Endpoint 的一部分，不可依常見範例自行推定。若現有設定使用網域名稱，還須確保連線前可以完成該網域的解析。
Allowed IPs 與持續連線的範圍
Allowed IPs 用來描述與對端相關的允許位址範圍，也會參與路由選擇及來源限制；實際呈現方式取決於實作。範圍過窄，可能漏掉需要經由通道存取的目的地；範圍過寬，則可能與原有網路規劃衝突。不要為了「全部都能用」就任意覆寫原值。若需要存取私有位址，也應檢查本地網路是否已有重疊的位址區段；位址重疊可能導致流量走錯路，但並非金鑰驗證失敗。
Persistent Keepalive 用於在有需要時維持網路位址轉換對應，尤其適用於本端位於某些轉換設備之後、又需要接收對端資料的情境。它不是愈頻繁就愈可靠的通用設定。週期過短會增加閒置時的資料活動，在行動網路上可能影響無線休眠。若原始設定沒有要求，應先觀察是否確實有對應逾時造成的恢復問題，再依實際網路條件處理，而非無條件加入固定週期。
MTU 與「部分網頁卡住」
通道會增加封裝負擔，因此必須考量實際路徑可容納的資料封包大小。MTU 不合適時，可能出現小型要求正常、較大回應或特定網站卡住的情況。遇到這種狀況，不要立刻更換金鑰；應先檢查路徑與封裝條件。調整 MTU 時，應以原始值和可重複的測試為依據，小幅驗證並留下紀錄。隨意套用某個數值可能掩蓋問題，也可能在其他網路中造成新的分片或效率損失。
WireGuard 使用 UDP 傳輸，網路是否允許相關資料往返是基本條件。切換 Wi-Fi 與行動網路後，端點及對應狀態都會改變，恢復情況也受網路策略影響。UDP 無法連線時，增加持續連線設定也無法讓遭封鎖的路徑自動恢復。請先確認 Endpoint、連接埠與網路條件，再檢查交握及實際業務；只看到用戶端顯示已連線，不能據此認定通道內路由已正常運作。
在速度與耗電方面，較精簡的協定設計具有運算優勢，但裝置的總負載仍包括使用者空間處理、無線收發、持續連線與業務流量。這不代表它在所有情境下都優於應用層代理。若既有網路提供完整金鑰與位址規劃，可依該規劃使用；若只是要匯入一般代理分享連結，就不應勉強改用 WireGuard。選擇應以伺服器支援與網路目標為優先，而非欄位數量或協定知名度。
07 / QUIC 與壅塞控制
Hysteria2：先確認 UDP，再評估吞吐量
為網路狀況變化設計的傳輸方式
Hysteria2 以 QUIC 建立代理傳輸；QUIC 通常運行於 UDP 之上，並結合安全交握與可靠傳輸等功能。其設計重點包括在延遲與封包遺失變化時安排資料傳送，而非單純減少一個密碼欄位。UDP 是底層承載方式，不代表交付給 App 的資料都不可靠；QUIC 能在其上提供可靠串流，因此應分開理解底層資料封包與上層業務語意。
這項設計說明了為何值得在某些狀況變化較大的網路中測試，也說明它並非所有網路的預設選擇。網路必須允許相應的 UDP 路徑，伺服器也必須提供 Hysteria2 入口。若網路策略不允許該路徑，用戶端無法只靠調高頻寬數值建立連線。若業務本身受到目標網站限速，改用另一種壅塞控制方式也無法解除目標端的限制。
驗證、憑證與額外欄位仍是必要條件
基本參數包括伺服器位址、連接埠、驗證資料及 TLS 相關資訊。驗證文字應與原始設定相符；若伺服器使用特定組合格式，不要自行拆成使用者名稱和密碼。Server Name 必須符合伺服器憑證及部署要求，其用途與前文 TLS 章節相同。裝置時間不正確、憑證信任鏈不完整或名稱不符，都可能導致交握失敗；這類問題不應靠提高傳送速率處理。
部分設定包含額外的混淆資訊，只有伺服器啟用相應機制時才需要。填入錯誤的額外密碼，可能讓伺服器無法正確辨識初始資料。不能因為另一筆記錄有此欄位，就替所有 Hysteria2 記錄加上相同內容。匯入後應核對完整參數，並確認分享資料屬於 Hysteria2，不要只憑相近名稱判斷相容性；協定世代不同，驗證與封裝方式也可能不同。
頻寬參數不是測速結果
某些設定方式允許填寫上行與下行頻寬，這些數值可能影響傳送行為或相應的壅塞控制模式，並非伺服器承諾的速率。填入很大的數值，不會增加無線容量或伺服器出口容量，反而可能造成排隊、封包遺失與重傳。是否需要填寫參數、如何與伺服器協商，應以既有部署需求及目前 App 提供的選項為準；不要把某個範例數值當成所有網路的最佳值。
若要評估頻寬設定，應分別檢視上行與下行，並觀察其他業務是否受到影響。單次傳輸大型檔案看似更快，但同時開啟網頁卻明顯變慢，可能代表佇列累積，而不是整體體驗改善。行動網路容量會隨地點與負載變化，固定參數難以適用所有情況。較穩妥的做法是保留原始設定，採用保守且可驗證的調整，每次只改一個方向，再重複相同的一組工作。
封包遺失、網路切換與耗電
QUIC 的串流機制可以減少某些跨串流等待，但無法消除無線鏈路本身的封包遺失成本，也不能讓同一條可靠串流略過所有遺失資料。壅塞控制會依據回饋安排傳送，伺服器實作與網路條件都會影響結果。因此，「使用 UDP」不等於「任何情況下都更快」。若某個網路的 UDP 品質較差，傳統 TCP 路徑在實際業務中也可能更穩定，應以測試結果判斷，而非聽信口號。
在 iPhone 上持續高吞吐時，無線收發與裝置溫度可能是重要因素。過於積極的傳送造成重傳，會增加資料活動；頻繁重新連線則會增加交握次數。比較耗電時，應採用相同訊號、相近溫度及一致工作，避免拿一次長時間測速，與另一種協定的閒置狀態比較。裝置發熱或網路切換期間的短暫結果，只能反映當下條件，不能據此建立固定的協定耗電排名。
若只有 Hysteria2 在某個網路中失敗，而同一伺服器提供的其他已確認入口可用，請先檢查 UDP 路徑、連接埠與憑證，再核對驗證資料及額外欄位。不要同時修改 DNS、規則與頻寬參數，否則難以定位原因。若顯示連線成功但網頁載入異常，接著檢查目標解析、規則比對及實際業務要求。本節提供選擇與診斷方法，不保證特定連線速度，也不能取代伺服器端的參數說明。
先建立參數正確的基準，再觀察持續傳輸。宣告較高頻寬不代表實際可用頻寬較高。
08 / 選擇與複核
依現有條件選擇，再以實際業務驗證
先排除伺服器不支援的組合
選擇協定的第一步不是比較名稱，而是列出現有伺服器實際提供的入口。只有 Shadowsocks 參數時，就先核對相應的加密方法；已有完整 WireGuard 設定時，才適合進一步檢查通道位址與金鑰。訂閱中同時包含多種類型，也不代表每筆記錄都使用相同伺服器、相同路徑或相同資源條件。比較結果可能反映整體部署差異，不能全歸因於協定本身。
第二步是明確界定業務需求。以瀏覽網頁為主時，應重視首次載入、解析與短連線表現；持續傳輸時，應重視穩定吞吐量與裝置溫度；即時 App 還須確認 UDP 或相關轉送能力。若要存取既有私有網路，位址規劃與路由往往比單次延遲更重要。選擇時應以可驗證的工作為依據，而不是追求一份適用所有情境的排名。
| 現有條件 | 優先核對 | 不要據此推斷 |
|---|---|---|
| Shadowsocks 入口 | 加密方法、密碼、UDP 支援 | 演算法名稱決定所有速度 |
| VMess / VLESS 入口 | UUID、傳輸、TLS、路徑 | 相同 UUID 可跨協定使用 |
| Trojan 入口 | 密碼、憑證、Server Name | 連接埠可連線等於驗證成功 |
| HTTP / SOCKS5 入口 | 驗證、保護方式、轉送範圍 | 設定密碼等於整條連線已加密 |
| WireGuard 設定 | 金鑰、Endpoint、位址與路由 | 交握成功等於所有位址都可連線 |
| Hysteria2 入口 | UDP、TLS、驗證、傳送參數 | 宣告頻寬等於實際吞吐量 |
建立可重複的測試流程
先儲存目前可正常運作的設定，並確認測試期間選取了哪筆 SERVER 記錄。固定網路、Global Routing 模式和存取目標，並停止無關的大量資料傳輸。先檢查基本連線，再開啟實際網頁或 App，最後才進行持續傳輸。每一輪記錄是否成功、首次回應是否異常、是否在一段時間後中斷；不必追求單一的最低延遲數字。可重複出現的狀況，比偶然的最佳結果更有參考價值。
測試耗電時，應分開觀察閒置維持連線與持續使用。螢幕亮度、訊號條件和工作時間應大致一致，並留意裝置溫度。系統電池統計是觀察參考，不是實驗室功耗儀器；統計期間可能包含其他背景活動，耗電百分比也會受總耗電影響。若無法控制這些條件，就只記錄「目前工作下觀察到的表現」，不要將結果描述成某種協定的固定特性。
依故障階段選擇排查方向
完全無法連線時，先檢查伺服器位址解析與連接埠路徑，再確認協定類型、身分資料及外層傳輸。若出現明確的憑證錯誤，請檢查名稱、裝置時間與信任鏈；若驗證遭拒，則檢查密碼、UUID 或金鑰對應。連線後只有部分目標失敗，應檢查規則比對、DNS 結果及目標本身的狀態。若連線一段時間後失效，請記錄是否伴隨網路切換、對應逾時或持續大量傳輸，避免每次都從重新輸入密碼開始排查。
Connectivity Test 只能反映該測試實際檢查的項目，不能取代所有業務測試。若測試有結果但網頁無法開啟，可先比較不同網域，再檢查網域解析及最終策略；若只有在 Config 下失敗，可暫時切換至 Proxy 模式進行對照，判斷是否與分流有關。對照完成後請還原原始設定，只保留已確認有效的調整。需要逐步操作時，請回到快速上手使用說明，不要一次修改多個頁面的選項。
保留紀錄，避免設定逐漸偏移
訂閱更新可能會變更入口、參數或備註。更新後出現異常時，應先確認記錄是否已替換，以及目前選取的是哪一筆；手動編輯由訂閱產生的記錄，也可能在下次更新時被覆寫。可以保存不含敏感資料的測試筆記，記錄欄位類別與觀察到的情況，但不要公開完整密碼、私密金鑰或含驗證資訊的訂閱網址。分享頁面截圖前，也請確認沒有洩露這些資料。
最後應保留一套用途明確、參數可追溯且業務驗證通過的設定，而不是累積大量無法說明的測試選項。協定負責連線格式，傳輸負責承載，TLS 負責相應層級的保護，規則則決定出口選擇；任何一層都不能取代其他層。購買與還原問題請參閱已購項目還原說明；連線狀況請參閱常見問題；設定結構則請查閱相關日誌文章。依照各層分工檢查，才能讓每次調整都限於有依據的範圍。