· 協定解說 · 約 9 分鐘

Hysteria2 協定介紹:基於 QUIC 為何快速、適合哪些網路情境

解析 QUIC 傳輸與壅塞控制,說明 Hysteria2 在高延遲、易丟包網路中的表現、適用情境,以及在 Shadowrocket 的設定要點。

本文重點

Hysteria2 採用 QUIC;在 UDP 可通行的前提下,適合評估高延遲、隨機丟包鏈路的傳輸效能,但不保證所有網路都會更快。本文適合已向服務商取得連線參數的使用者,依序說明傳輸原理、網路限制、Shadowrocket 設定要點與對照測試方法,協助判斷問題出在協定、規則或線路瓶頸。

QUIC 帶來哪些改變

在 Shadowrocket(小火箭)中,Hysteria2 是一種代理協定選項,不是規則模式,也不是加速開關。它透過 UDP 上的 QUIC 建立加密連線,再傳送需要轉發的請求。此處的 UDP 指用戶端與伺服器之間的外層傳輸,不代表瀏覽器中的 TCP 請求會失去可靠性。

QUIC 在協定層自行處理確認、丟包偵測與重傳,並透過 TLS 1.3 完成安全握手。同一連線可承載多個彼此獨立的可靠串流:某個串流缺少資料時,其他串流通常不必等待相同傳輸層位元組序列補齊。這能減少跨串流的隊頭阻塞,但同一串流內的資料仍須依序傳遞,共用鏈路的壅塞也仍會影響其他串流。

UDP
Hysteria2 的外層傳輸需要網路允許 UDP 通行
TLS 1.3
QUIC 使用的安全握手機制
443/UDP
可用於部署的連接埠範例,並非固定連接埠

連接埠應以服務商提供的設定為準。即使某個網路允許連線至 443/TCP 的 HTTPS 網站,也不能據此判定它允許 443/UDP。這兩種傳輸協定的防火牆規則可能完全不同,因此「網頁正常,但 Hysteria2 握手逾時」並不矛盾。

為何高丟包時可能更快

影響效能的不只有 QUIC,也包括 Hysteria2 的壅塞控制與頻寬參數協商。傳統以丟包為依據的壅塞控制,可能將隨機丟包視為壅塞,進而降低傳送速率。在無線干擾等非壅塞丟包環境中,Hysteria2 的頻寬估算與傳送控制可能維持較高吞吐量;實際表現取決於用戶端、伺服器設定及雙方協商結果。

這不代表「忽略所有丟包」。若丟包是因鏈路已飽和,繼續增加傳送量只會加重佇列、重傳與延遲。高延遲網路需要更多傳輸中的資料才能充分利用鏈路,但協定無法縮短實際距離,也無法突破伺服器出口容量或方案速率限制。檔案下載變快,不代表遊戲的往返延遲也會同步降低。

結論:先確認 UDP,再調整頻寬

若切換至另一個網路後立即能連線,應優先檢查原網路是否允許 UDP 通行;若連線穩定,但滿載時延遲明顯升高,應降低頻寬目標並重新測試,而不是停用憑證驗證或反覆更改密碼。

哪些網路適合評估

判斷協定是否適用,需同時觀察連線成功率、持續吞吐量與互動延遲。跨區域鏈路、行動網路或無線環境若有隨機丟包,可評估 Hysteria2;在低延遲、低丟包且出口已滿載的網路中,改用它可能不會帶來明顯改善。若訪客網路限制 UDP,應先確認網路規則,而非把增加重試次數當成解決方法。

網路狀況判斷方向下一步
高延遲且有隨機丟包可能反映傳輸與壅塞控制的差異固定伺服器與目標檔案,重複測試吞吐量和延遲
丟包率低,現有連線已接近線路上限瓶頸可能不在協定保留穩定設定,檢查出口容量與本地頻寬
Wi-Fi 逾時,行動網路可連線原網路可能限制 UDP 或特定目的連接埠確認網路政策,並向服務商查詢伺服器狀態
連線成功,但下載時網頁明顯變慢可能有排隊延遲,或傳送目標設得過高降低頻寬參數,觀察滿載延遲是否下降
所有網路都顯示憑證或驗證錯誤優先檢查參數,而非線路效能確認 SNI、憑證網域、裝置時間與驗證資訊

不要只憑一次延遲測試判斷協定優劣。短時間探測主要反映當下的連線可達性與回應時間,無法代表持續傳輸的穩定度。測試期間應暫停其他裝置的大量傳輸工作,並記錄網路類型;否則 Wi-Fi 與行動網路之間的差異可能會被誤認為是協定造成的。

Shadowrocket 設定步驟

以下以 iPhone / iPad 上的 Home 操作為例,其他平台請以實際介面為準。節點、訂閱連結、驗證資訊、伺服器網域與連接埠,請向你的服務商取得。Hysteria2 與 Hysteria 的參數及協定不能直接混用,選擇 Type 時請確認名稱。

  1. 確認參數

    先確認協定為 Hysteria2,並準備 Server、Port、Password,以及服務商明確要求的 SNI、頻寬與混淆參數。連接埠例如可能是 443,但範例不一定是你實際使用的連接埠。

  2. 選擇類型

    前往 Home → 右上角「+」→ Type → Hysteria2,再填入連線資訊。即使同樣使用 TLS,也不要因此將 Type 選為 Trojan 或其他協定。

  3. 確認驗證資訊

    依照服務商提供的完整驗證值填寫 Password。若對方提供的驗證值包含分隔符號,請保留原始格式,不要自行拆成使用者名稱與密碼,也不要把訂閱連結中的 token 當成連線密碼。

  4. 檢查安全設定

    SNI 應與伺服器憑證及服務商說明一致。若 Server 使用 IP 位址,也可能仍需填寫網域作為 SNI。請保留憑證驗證;遇到憑證錯誤時,先檢查網域、裝置時間與憑證鏈。

  5. 儲存並測試

    儲存後返回 Home,選取該項目,在 Global Routing → Proxy 下進行短時間對照測試。確認請求確實經由所選連線後,再返回 Global Routing → Config 檢查日常分流設定。

若已有訂閱,可使用 Home →「+」→ Type → Subscribe,填入向服務商取得的訂閱連結,儲存後更新訂閱,並確認匯入項目的 Type。訂閱只是發佈設定的方式,不保證伺服器在線。訂閱更新失敗與某個 Hysteria2 項目連線失敗是兩種不同問題,應分別檢查訂閱網址與連線參數。

規則模式如何影響測試

Hysteria2 決定連線如何傳輸,Global Routing 則決定哪些請求交由代理處理,兩者屬於不同層次。項目能夠連線,不代表所有網站都會使用它。以下比較的是 Shadowrocket 本身的路由方式,不是協定效能排名。

Config

建議

依照目前啟用的 Config 規則與策略處理請求。請確認規則順序、比對結果,以及策略實際選取的項目,而不只看 Home 的選取狀態。

適用:完成連線測試後,日常依規則分流

Proxy

將由 Shadowrocket 接管的請求交由代理處理,減少一般分流規則對測試的干擾。這不代表裝置上的所有系統流量都一定會經過代理。

適用:短時間確認 Hysteria2 連線與目標網站是否正常

Direct

讓接管的請求直接連線,可作為同一目標的本地網路基準。此時目標網站能開啟,不代表 Hysteria2 已生效。

適用:比較本地網路的可達性與直連表現

Global Routing 中的 Scene 用來依情境設定路由行為,並非第四種代理協定;排查時應先確認目前情境的實際動作。Settings → On Demand 管理的是依條件觸發連線,不負責選擇 Hysteria2,也不會取代分流規則。若測試期間連線狀態自行改變,也要檢查是否有 On Demand 觸發條件。

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

以下僅為規則語法範例,並非完整的 Config。DOMAIN-SUFFIX 依網域後綴比對,IP-CIDR 依位址範圍比對,GEOIP 依 IP 位址所屬地區比對,FINAL 則作為最終兜底;通常會依序尋找符合項目。此處的 PROXY 是策略,不是 Hysteria2 的協定名稱;最後使用哪個連線仍取決於策略選擇。請在請求記錄中確認目標、符合的規則與實際策略,避免把直連測速誤當成協定測速。

透過可重現的測試找出問題

有效的對照測試應固定用戶端裝置、伺服器、目標資源與測試時段。若服務商提供可供比較的連線方式,請盡量使用相同出口;不同出口之間的速度差異,不能直接證明某種協定較佳。以下時間與次數是操作建議,不是效能保證或實測結果。

若要向服務商回報,提供網路類型、錯誤階段、發生時段及已隱去敏感資訊的記錄即可。請勿公開完整訂閱網址、Password 或包含 token 的連結。若同一設定只在某個網路失敗,請一併提供該網路與可用網路的對照結果,通常比反覆更改所有欄位更有助於找出問題。

結論:同時觀察穩定吞吐量與滿載延遲

只有在多次測試中吞吐量有所改善、連線中斷沒有增加,且互動延遲仍可接受時,才保留新參數;若只是瞬間峰值升高,但網頁變慢,應還原原設定並繼續找出鏈路瓶頸。

Shadowrocket 官方下載