Hysteria2 是基於 QUIC 的代理協定，不是加速開關。本文適合已有自己的服務商、伺服器或訂閱的 iPhone/iPad 使用者：先了解傳輸機制與速度表現的差異，再核對 Shadowrocket 的連線欄位，最後從 UDP、TLS 和路由三個面向排查連線問題。
Hysteria2、QUIC 與 UDP 的關係
Shadowrocket（小火箭）中的 Hysteria2 是伺服器連線類型。QUIC 是採用的底層傳輸協定，UDP 則負責承載 QUIC 封包。此處所說的「使用 UDP」，指的是用戶端與伺服器之間的外層連線；這不代表瀏覽器的所有請求都變成不可靠傳輸，也不代表應用程式只能存取 UDP 服務。
QUIC 在 UDP 之上實作連線管理、可靠串流、丟包復原與壅塞控制，並使用 TLS 1.3 完成交握與加密。Hysteria2 再於此傳輸層之上實作驗證與代理轉發。伺服器必須支援 Hysteria2；不能只把 Type（類型）改掉，就拿原有的其他協定伺服器來連線。
連接埠號碼本身無法判斷協定。443/TCP 可用，不代表同一個位址的 443/UDP 也可用。伺服器的監聽設定、防火牆和目前使用的網路，都可能分別處理這兩種傳輸。本文中的 example.com 僅為教學用網域，不可點擊，也不對應可用服務。
為何可能更快：串流隔離與壅塞控制
首先要區分吞吐量與延遲。吞吐量是單位時間內傳輸的資料量，延遲則是一次互動需要等待多久。檔案傳輸速度較快，不代表每個網頁都會更早顯示。DNS 查詢、目標網站回應、伺服器負載和無線訊號，也都會影響頁面開啟時間。
QUIC 的多串流機制可減少傳輸層丟包所造成的不同串流間隊頭阻塞。某個串流缺少的資料需要復原時，其他已收到的資料仍可交付。但同一個可靠串流內仍須維持資料順序；丟包也依然會占用重傳頻寬。不能把 QUIC 理解成「丟包不用等待」。
- 串流隔離：主要是減少不同串流彼此等待的範圍，無法消除同一串流內的資料缺口。
- 丟包復原：傳輸層仍須偵測丟包並重傳可靠資料，鏈路容量不會因此增加。
- 壅塞控制：決定傳送端如何運用可用頻寬；實際策略取決於用戶端與伺服器的設定。
- 共用瓶頸：多個串流仍共用同一條接取鏈路；無線干擾或上行壅塞可能同時拖慢所有串流。
Hysteria2 的效能特性也與壅塞控制有關。其 Brutal 壅塞控制以頻寬目標為基礎運作；在有隨機丟包、但仍有剩餘容量的鏈路上，可能比遇到丟包便大幅降低傳送速度的策略更充分利用頻寬。伺服器也可能採用其他壅塞控制方式，因此「使用 Hysteria2」不代表「永遠採用相同的傳送策略」。
哪些網路適用？UDP 受限時會怎樣？
跨區連線、往返時間較長、鏈路有少量隨機丟包，都是值得測試 Hysteria2 表現的情境。前提是 UDP 能穩定通過，而且伺服器與接取網路都有足夠容量。在低丟包、低延遲的網路中，效能差異可能很小，不能只憑協定名稱判斷哪種連線較快。
| 網路狀況 | 可能出現的現象 | 檢查方向 |
|---|---|---|
| UDP 正常，偶有隨機丟包 | 長時間傳輸可能較穩定，但仍會發生重傳 | 固定伺服器與目標，重複測量吞吐量和互動延遲 |
| UDP 遭封鎖 | 交握等待後逾時，無法與伺服器建立連線 | 確認 UDP 監聽與防火牆設定，再更換接取網路重測 |
| UDP 遭限速 | 可以連線，但持續傳輸到一定速度後便不再提升 | 比較 Wi-Fi 與行動網路，檢查容量和限速條件 |
| 網路壅塞或無線訊號不佳 | 傳輸期間延遲升高，頁面互動變得卡頓 | 停止並行傳輸，調低頻寬目標後再測 |
UDP 不通時，Hysteria2 不會自動改用 TCP 連線。現有配置中的混淆選項，也無法建立一條已遭防火牆完全封鎖的 UDP 通道。若目前網路確實限制 UDP，請向自己的服務商確認是否有適用於該環境的其他既有連線配置，而不是一再修改密碼或停用憑證驗證。
結論：先確認 UDP 通道可用
同一份配置在行動網路可連線、在某個 Wi-Fi 上卻持續逾時時，請先檢查接取網路的 UDP 條件；保留原有驗證與 TLS 參數，避免同時修改多項設定而無法比較。
在 Shadowrocket 中匯入並核對欄位
優先使用自己的服務商提供的現有訂閱。訂閱通常包含協定、連接埠、驗證和 TLS 參數，手動重新輸入更容易漏掉欄位。更新訂閱後仍應檢查伺服器類型；更新清單不代表伺服器已通過連線測試，也不代表它已設為目前的預設伺服器。
-
匯入訂閱
開啟 Home（首頁）→ 點右上角「+」→ Type（類型）→ Subscribe（訂閱），輸入自己已有的訂閱連結並儲存。返回 Home 後下拉重新整理清單，請勿將訂閱連結傳給他人。
-
確認類型
在 Home 找到匯入的伺服器，點該列的資訊按鈕進入編輯，確認 Type 是否為 Hysteria2。若要手動新增，從 Home →「+」→ Type 選擇 Hysteria2，再輸入服務商提供的參數。
-
核對連線設定
逐項檢查 Address（位址）、Port（連接埠）與 Password（密碼）。位址欄只填伺服器網域名稱或 IP，不要填入訂閱連結、網頁路徑或完整分享連結。
-
核對加密設定
依現有配置檢查 SNI（伺服器名稱指示）與憑證要求；若有混淆設定，請核對混淆類型和密碼。不要將驗證密碼當成混淆密碼，也不要自行填入配置中沒有的值。
-
選取伺服器並連線
儲存後返回 Home，點選伺服器左側的圓點將其設為預設，再檢查 Global Routing（全域路由）。開啟連線開關；首次出現系統 VPN 配置授權時，請依系統提示確認，接著執行 Connectivity Test（連線測試）。
| 欄位或參數 | 核對內容 | 常見填寫錯誤 |
|---|---|---|
| Address（位址） | 教學範例為 example.com，實際使用時請填自己的伺服器位址 | 填入訂閱 URL，或包含網頁路徑的位址 |
| Port（連接埠） | 教學範例為 443，實際設定必須符合伺服器的 UDP 監聽連接埠 | 依常見連接埠猜測，未向伺服器端確認 |
| Password（密碼） | 依服務商提供的完整驗證字串填寫 | 漏掉分隔符號，或複製時一併帶入空格 |
| SNI（伺服器名稱指示） | 使用現有配置指定的 TLS 名稱，並確認憑證涵蓋該名稱 | 連線至 IP 時，也把憑證網域名稱改成 IP |
| 混淆參數 | 僅在伺服器端已啟用時填寫，兩端的類型和密碼須一致 | 只在一端啟用混淆，或使用錯誤的密碼 |
SNI 和 Address 可以不同：前者用於 TLS 名稱協商，後者決定連線目的地。憑證驗證失敗時，請先檢查系統時間、憑證名稱和服務商配置。Allow Insecure（允許不安全連線）不是一般的修復方式；停用驗證會改變伺服器身分驗證條件，不能用來取代正確設定。
區分協定連線與 Global Routing
伺服器可連線，只表示代理通道具備可用條件。某個網站是否經由代理通道，還取決於 Global Routing（全域路由）、目前的 Config（配置檔）和策略選擇。排查時先固定路由設定，不要同時切換伺服器、修改規則與頻寬參數。
Config（配置）
建議依目前配置套用規則。日常使用時，請確認目標符合哪條規則及其策略，並確認該策略最後指向要測試的 Hysteria2 伺服器；預設伺服器不一定會套用到策略群組的選擇。
適用：已有明確分流規則的日常連線
Proxy（代理）
以代理模式處理已接管的流量；確認預設伺服器後，可暫時用來排除規則影響。這不會更換伺服器協定，也無法修復 UDP 交握失敗。
適用：短時間測試伺服器通道，排除分流因素
Direct（直連）
直接連線，不經過所選的代理伺服器。此時網站可以開啟，並不能證明 Hysteria2 配置有效。
適用：檢查目標網站在目前網路中的直連狀態
Global Routing 中的 Scene（場景）會依已設定的場景條件選擇路由行為；測試前應先確認目前場景實際採用的設定。Settings（設定）→ On Demand（隨需連線）會在符合條件時控制系統啟動連線，不是協定加速功能，也不能取代伺服器驗證或規則比對。
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT上方的教學片段表示：網域為 example.com 及其子網域時使用 PROXY，其餘流量則由 FINAL,DIRECT 作為後備規則，直接連線。規則由上而下比對，只有使用相應的 Config 時才會生效。此處的 PROXY 是代理策略，不是 Hysteria2 的另一種寫法。
依現象排查，並記錄可比較的結果
將測試拆成「交握成功」、「目標可存取」和「持續傳輸表現」三件事。Home 中的延遲結果不能取代網頁與檔案傳輸測試；Connectivity Test 成功，也不能證明所有目標在所有時段都可用。以下說明如何判讀，並非任何線路的實測結論。
- 交握逾時：先檢查位址和 UDP 連接埠，再檢查接取網路與伺服器防火牆。只能解析出 IP，不代表連接埠可連通。
- 驗證失敗：確認完整的 Password 和伺服器端帳號狀態。一再調整 DNS 通常無法修正錯誤的驗證字串。
- 憑證錯誤：確認 SNI、系統時間和憑證有效性，不要放寬驗證來掩蓋問題原因。
- 已連線但網站無法使用：檢查 Global Routing、目前的 Config、目標網域解析結果和符合的策略，分辨是直連失敗還是代理失敗。
- 一開始很快，接著變卡：停止其他傳輸，檢查頻寬目標和無線訊號；不要把短暫峰值當成可持續容量。
需要比較時，固定裝置、伺服器、目標資源和路由設定，在同一個接取網路重複測試三次，再換另一個接取網路重做相同步驟。分別記錄交握是否成功、頁面是否載入完成、持續傳輸是否穩定，以及傳輸期間互動延遲是否明顯升高。每次只改一項條件，才能找出變化原因。