Shadowrocket Hysteria2 是什麼?QUIC 傳輸特性與適用情境

了解 Hysteria2 如何透過 QUIC/UDP 傳輸、擁塞控制方式及弱網表現,並認識在 Shadowrocket 新增設定時 password、sni、obfs 等欄位的用途。

本文重點

本文適合已有服務提供者與設定,準備在 Shadowrocket(小火箭)使用 Hysteria2 的使用者。先釐清 QUIC、UDP 與業務流量的差異,再核對認證、憑證及混淆參數,最後在固定條件下測試連線。讀完後可判斷問題出在網路連通性、TLS、認證或規則分流,而非只憑一次延遲測試就更換協定。

Hysteria2 與 QUIC、UDP 的關係

Hysteria2 是以 QUIC 為基礎的代理協定。QUIC 以 UDP 傳送資料,並提供加密、可靠傳輸、擁塞控制及多路複用等機制。此處的「以 UDP 為基礎」指的是用戶端與伺服器之間的外層傳輸,不代表網頁請求都變成不可靠資料,也不表示使用者只能存取 UDP 業務。

在 Shadowrocket 選擇 Hysteria2 後,分流至該連線的 TCP 業務可透過 QUIC stream 轉送;UDP 業務則使用相應的封包轉送機制。網頁仍依原本的應用協定運作,使用者不必將瀏覽器改為 HTTP/3。伺服器必須支援 Hysteria2,不能只因位址與密碼相同,就將其他協定的設定改成 Hysteria2。

UDP
用戶端與伺服器之間的底層傳輸
TLS 1.3
QUIC 使用的握手與加密基礎
443/UDP
常見部署範例,實際連接埠以現有設定為準

連接埠號碼相同,不代表傳輸方式相同。例如伺服器監聽 443/UDP,但網路只允許 443/TCP 通過,仍無法建立連線。443 並非 Hysteria2 的指定連接埠;若填寫 8443 或其他連接埠,用戶端、伺服器監聽設定及防火牆允許項目都必須一致。

弱網表現與擁塞控制的限制

QUIC 的多路複用可減少不同 stream 因可靠傳輸排序而造成的隊頭阻塞:某個 stream 的資料需要重傳時,另一個 stream 已收到的資料不必等同一條 TCP 位元組串流補齊。不過,各 stream 仍共用路徑頻寬與擁塞控制;持續丟包、無線訊號不佳或上行壅塞,依然會影響所有業務。

Hysteria2 的擁塞控制方式包含依頻寬估算運作的 Brutal,以及可協商使用的 BBR。實際採用哪種方式,取決於用戶端實作、設定與伺服器協商結果。Brutal 需要合理的頻寬參數,並依丟包回饋調整傳送;它無法創造額外頻寬,也無法繞過網路對 UDP 的限制。

結論:先確認 UDP 是否可連通

若持續發生握手逾時,先核對現有設定中的位址、UDP 連接埠及目前網路限制;確認連線可建立並持續傳輸後,調整頻寬參數才有助於診斷。

password、sni、obfs 各自控制什麼

這些參數分屬不同層次,不能互相取代。新增前應向自己的設定提供者確認完整參數;欄位缺漏時,不要拿另一個密碼來補。下表中的英文是設定欄位名稱,Shadowrocket 表單可能會以相應標籤呈現;實際欄位是否出現,依所選 Type 與目前介面為準。

參數用途核對事項
server連線伺服器的網域名稱或 IP 位址。請勿將完整分享連結或含路徑的網頁網址填入位址欄。
port伺服器監聽的 UDP 連接埠。例如 443;必須與原設定一致,不要因網頁使用 HTTPS 就自行改成 443。
passwordHysteria2 伺服器的認證憑證。保留大小寫與符號;確認複製內容的前後沒有多出空格。
sniTLS 握手使用的伺服器名稱,用於核對憑證名稱。通常填寫網域名稱,不含通訊協定標頭、連接埠或路徑;依現有設定填寫。
obfs可選的傳輸混淆方式,例如 Salamander。伺服器啟用時,兩端設定必須相符;未啟用時,不要只在一端開啟。
obfs-password混淆功能使用的金鑰。這與認證 password 是兩項獨立設定;混淆金鑰錯誤可能導致握手階段就失敗。
up / down部分設定格式中的上傳與下載頻寬提示。先確認單位與方向,不要將測速結果中的 MB/s 直接視為 Mbps。

連線位址與 sni 可以不同。例如,現有設定以 IP 位址連線,但 TLS 名稱核對使用憑證涵蓋的網域。這不代表可以任意填入知名網站的網域:憑證鏈、憑證名稱及伺服器設定都必須相符。若出現憑證錯誤,應檢查 sni、裝置時間及伺服器憑證狀態,而不是直接關閉憑證驗證。

在 Shadowrocket 新增並核對連線

以下步驟以 iPhone、iPad 的 Home 為起點,並假設使用者已有可用的 Hysteria2 設定。若已有 Subscribe 項目,請先更新並檢查匯入結果;手動新增適合核對單一連線,不應與訂閱管理的項目反覆互相覆寫。

  1. 確認參數

    準備伺服器位址、UDP 連接埠、password、sni,以及伺服器要求的 obfs 資訊。確認設定確實是 Hysteria2,而不是名稱相似但不相容的協定。

  2. 選擇類型

    前往 Home → 右上角「+」→ Type,選擇 Hysteria2。若透過分享資訊匯入現有設定,也要開啟項目確認 Type,不要只看備註名稱。

  3. 填寫參數

    依原設定填寫位址、連接埠及認證欄位;在相應的 TLS 與混淆選項中核對 sni、憑證驗證及 obfs。首次測試請保留原本的頻寬值,不要同時修改多個設定。

  4. 儲存並選取

    儲存後返回 Home,選取剛新增的項目。若 Config 使用策略群組,也要確認實際策略已選取該項目,避免測試到其他連線。

  5. 授權並測試

    開啟 Home 的連線開關,依系統提示確認 VPN 設定授權。先瀏覽已知可正常使用的 HTTPS 網頁,再檢查實際流量採用的策略與連線記錄。

Settings → On Demand 用於管理依條件觸發連線的行為,無法修復 Hysteria2 參數。排查期間應記錄此功能是否啟用,避免自動連線造成「剛關閉又連上」的誤判。Home 顯示已連線,也只代表本機 VPN 工作階段已建立,不等於伺服器認證、目標網站存取及所有規則路徑都正常。

使用 Global Routing 區分協定問題與分流問題

若連線已開啟,但某個網站無法存取,請先分辨「連線本身失敗」與「請求沒有經過該連線」。Global Routing 中的 Config、Proxy、Direct 是路由模式,不是三種 Hysteria2 參數。Scene 則依已設定的情境邏輯運作;排查前應確認目前情境的實際選擇,避免將切換情境誤認為協定不穩。

Config

建議

日常使用已核對的 Config,依規則選擇 DIRECT 或代理策略。檢查符合的 DOMAIN-SUFFIX、IP-CIDR、GEOIP 及 FINAL,確認最終策略指向預期的 Hysteria2 連線。

適用情境:已有明確分流需求,且已核對規則與策略群組的日常使用

Proxy

暫時讓用戶端接管的流量使用所選代理路徑,以減少 Config 分流造成的變數。此模式仍受系統流量接管範圍及協定能力限制,不代表裝置的所有流量都必然經過同一路徑。

適用情境:短時間確認連線是否可用,排除規則比對問題

Direct

使用直連路徑作為基準對照。此模式無法證明 Hysteria2 已正常運作,因為測試請求並未經過該代理連線。

適用情境:檢查本地網路及目標網站的直連狀況

結論:Proxy 可用後再檢查規則

同一目標在 Proxy 下可用、在 Config 下失敗時,保留連線參數,優先檢查符合的規則、策略群組及 DNS 結果;不要同時更換 sni、obfs 與連接埠。

依失敗階段排查,不要用單次延遲測試下結論

延遲測試的結果取決於測試方式與目標,不能代表所有業務。測試值較低的連線,在大量傳輸時仍可能受到 UDP 限速;測試逾時的項目,也應搭配實際網頁請求與連線記錄判斷。下表列出可觀察到的狀況,並非對任何線路的實測保證。

狀況優先檢查下一步
持續握手逾時網域解析、UDP 連接埠、目前網路限制,以及 obfs 是否相符。保持設定不變,在另一個可使用的網路重複相同請求,判斷是否與網路接入方式有關。
出現憑證相關錯誤sni、憑證有效期限、裝置時間及信任鏈。向自己的設定提供者確認憑證對應的網域,並保留憑證驗證。
出現認證失敗password 是否完整,以及認證資訊是否仍有效。重新複製原始憑證;不要用 obfs-password 取代。
小型網頁可用,大量傳輸時停頓UDP 限速、路徑 MTU、丟包、伺服器負載及頻寬設定值。先還原原本的頻寬參數,暫停並行傳輸,再以相同目標重新測試。
只有部分網站無法使用規則比對結果、策略群組選擇、DNS 結果及目標網站狀態。暫時使用 Proxy 對照,確認問題出在分流還是連線。

QUIC 路徑需要支援至少 1200 位元組的 UDP 負載;某些隧道疊加或異常路徑可能產生與封包長度相關的問題。不過,光是「網頁無法開啟」不足以判斷 MTU。有明確的路徑證據之前,不要任意修改系統網路參數,也不要把 Hysteria2 當成 WireGuard 的 MTU 欄位來處理。

保留一組可供複核的測試記錄

Hysteria2 的適用條件是:伺服器明確支援、UDP 路徑可用,且認證與 TLS 參數完整。是否適合弱網環境,應以可重複的連線結果判斷。若目前路徑限制 UDP,繼續提高頻寬值並非有效的最佳化方向;應先處理網路連通性,並使用使用者已有且適合該環境的設定。

App Store 下載先核對正版資訊