2026-10-17 · 協定解析 · 約 10 分鐘

Hysteria2 是什麼？QUIC 傳輸為何快速、適用哪些網路情境

認識 Hysteria2 的 QUIC／UDP 傳輸與壅塞控制，了解它在高丟包、高延遲連線上的表現，以及在 Shadowrocket 設定節點時須核對的欄位。

本文概要

本文適合已經有自己的服務提供者與訂閱，準備在 Shadowrocket 使用 Hysteria2 的使用者。先說明 QUIC、UDP 與壅塞控制的關係，再核對位址、連接埠、驗證、TLS 和頻寬欄位，最後依連線狀況排查問題。是否適合自己的網路，應觀察 UDP 是否可連通、丟包型態與持續傳輸表現，而非只看單次延遲數值。

Hysteria2、QUIC 與 UDP 的關係

Hysteria2 是以 QUIC 為基礎的代理協定。Shadowrocket（小火箭）作為用戶端，連線至使用者自己的 Hysteria2 伺服器，再由伺服器轉送目標流量。購買 App 與連線服務是兩回事：購買用戶端不會自動取得伺服器位址、驗證資訊或訂閱。

UDP 是底層傳輸，QUIC 在其上實作加密、連線管理、可靠資料流與壅塞控制。不能將「以 UDP 為基礎」理解成「資料遺失也不處理」：承載 TCP 代理流量時，QUIC 的可靠資料流仍需要確認與重傳；代理 UDP 流量時，則採用符合資料報語意的傳送方式。

UDP
用戶端至 Hysteria2 伺服器的底層傳輸
TLS 1.3
QUIC 所使用的加密交握基礎
443/UDP
伺服器監聽設定範例，並非固定連接埠

此處的 443/UDP 僅為連接埠範例。伺服器也可以監聽其他 UDP 連接埠，用戶端必須填入實際值。某個網路允許 443/TCP，不代表同樣允許 443/UDP；瀏覽器能開啟一般網頁，也無法證明 Hysteria2 的傳輸路徑可用。

傳輸為何可能更快：多工與壅塞控制

QUIC 可以在同一條連線中承載多個資料流。某個資料流發生丟包時，不必像將多個業務資料流塞進單一 TCP 位元組流那樣，等同一條外層有序位元組流補齊後，才交付其他資料流的資料。不過，各資料流仍會共用鏈路容量與壅塞控制，單一可靠資料流本身也仍須按序交付。

Hysteria2 的另一個重點是以頻寬為基礎的 Brutal 壅塞控制。它會依設定的目標速率傳送，並補償丟包；在有隨機丟包、但鏈路仍有可用容量時，這種方式可能比遇到丟包就明顯降低速率的策略，更容易維持吞吐量。實際採用 Brutal 或 BBR 等路徑，取決於頻寬設定、協商結果，以及用戶端與伺服器的實作，不能只憑協定名稱判斷。

機制可能改善的狀況仍存在的限制
QUIC 多工不同資料流因外層有序傳輸而產生的等待所有資料流仍會競用同一條鏈路的容量
可靠資料流重傳丟包後恢復 TCP 代理流量的資料完整性補傳資料會耗費時間與額外頻寬
Brutal隨機丟包時持續傳輸速率下降目標頻寬設得過高可能加劇排隊與丟包
BBR 路徑依據鏈路估算調整傳送行為效果受路徑、實作方式與伺服器限制影響

判斷方式：先測可用容量，再設定頻寬

先記錄同一路徑的持續下載、上傳速率與回應延遲，再依實際容量設定頻寬；若提高數值後吞吐量沒有變化，網頁回應卻變慢，應調低設定並重新測試，而非繼續提高數值。

「快」不是協定的固定特性。高延遲會增加交握、請求往返與丟包復原所需的等待時間，QUIC 無法消除實際距離；伺服器出口、目標網站限速和本地無線干擾，也不會因切換協定而自動消失。本文不以未經測試的百分比承諾速度提升。

哪些網路情境適合，哪些應先排除

適合優先測試的情況，是 UDP 可連通、鏈路延遲較高、有一定程度的隨機丟包，同時仍有可用頻寬。若丟包源自佇列持續滿載，繼續提高傳送速率可能適得其反。應分別觀察「隨機丟包」與「壅塞丟包」，不能只根據單一丟包百分比做決定。

在 Shadowrocket 新增 Hysteria2：欄位核對順序

優先使用自己現有訂閱中的完整設定，避免手動設定時漏掉 TLS 或驗證參數。Hysteria2 與舊版協定 Hysteria 不能只修改名稱就互換；匯入後應開啟項目，確認 Type 對應 Hysteria2。不同介面語言與 App 版本的欄位排列可能不同，以下依欄位用途核對，不要只憑相似名稱猜測數值。

  1. 確認來源

    準備自己現有服務的位址、UDP 連接埠、驗證資訊、TLS 與選用的混淆參數。匯入訂閱的步驟為 Home → 右上角「+」→ Type → Subscribe，接著填入自己的訂閱 URL 並儲存。

  2. 選擇協定

    手動新增時，前往 Home → 右上角「+」→ Type → Hysteria2。匯入訂閱後，則開啟對應項目核對 Type；不要改成其他協定後繼續沿用原有參數。

  3. 填寫連線資訊

    依伺服器提供的資料填寫位址與連接埠，再填入驗證資訊。位址欄只填主機名稱或 IP，不要連同網頁路徑、協定前綴或連接埠一起輸入；連接埠須另外填寫，例如伺服器明確提供 443，就填入 443。

  4. 核對加密設定

    檢查 TLS 的伺服器名稱 SNI 與憑證要求；若伺服器啟用混淆，再逐項確認混淆類型與密碼。驗證密碼與混淆密碼用途不同，不能互相替代。

  5. 儲存並驗證

    儲存後返回 Home，選取該項目並連線。記錄目前的 Global Routing 設定，使用已知可連線的目標進行驗證；測試結束後恢復日常設定，不要同時修改 DNS、規則與頻寬。

欄位意義填寫依據常見錯誤
伺服器位址伺服器提供的主機名稱或 IP誤填管理網頁位址或訂閱位址
Port實際監聽的 UDP 連接埠將其他服務的 TCP 連接埠誤當成此處的連接埠
驗證資訊伺服器指定的完整驗證字串內容遭截斷，或前後混入空格
SNITLS 憑證所對應的伺服器名稱使用 IP 連線時，誤以為不必核對憑證名稱
混淆參數伺服器是否啟用混淆及其對應參數只在用戶端啟用，或密碼不一致
上傳與下載頻寬用戶端方向的鏈路能力與伺服器限制上下行填反，或將 MB/s 誤當成 Mbps

請特別留意頻寬單位：1 MB/s = 8 Mbps，實際有效負載也會受到傳輸開銷影響。下載方向通常是伺服器至用戶端，上傳方向則相反；填寫前請以目前欄位說明為準。不要因為本地網路標示的接取速率較高，就認為遠端鏈路也能持續達到相同容量。

連線成功後：確認流量確實經過該項目

在 Home 選取 Hysteria2 項目，不代表每個請求都會經過它。Global Routing 中的 Direct 表示直接連線；Proxy 用於驗證代理路由；Config 會依目前設定檔中的規則處理；Scene 則須另外核對目前場景的具體設定。診斷時務必記錄模式，否則協定對照測試實際上可能走了不同路徑。

使用 Config 時，前往 Config 確認目前生效的檔案，再核對目標請求符合的規則。規則通常依序比對，以下僅用於說明語法，並非可直接取代現有檔案的完整設定；PROXY 策略必須存在於實際設定中，且指向預期路徑。

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

若測試期間連線狀態自行恢復，請檢查 Settings → On Demand 的現有設定，確認是否由按需連線觸發。On Demand 負責連線觸發條件，無法修正錯誤的驗證、連接埠或 TLS 參數。暫時調整前先記下原有設定，排查完成後再恢復。

Hysteria2 常見問題：依狀況排查

為什麼一直逾時，一般網頁卻能開啟？

先核對位址解析結果與實際 UDP 連接埠，再改用另一個可使用的網路，測試連線至同一項目。一般網頁可能使用 TCP，無法證明 UDP 路徑正常。若只在一個網路中失敗，優先檢查該網路的 UDP 政策；若兩個網路都失敗，再核對伺服器監聽設定、防火牆與服務狀態。

為什麼出現驗證或憑證錯誤？

驗證錯誤時，先比對完整字串與前後空格，不要用訂閱 URL 代替密碼。憑證錯誤則應核對裝置時間、SNI 與伺服器憑證；即使使用 IP 連線，仍可能需要填寫憑證對應的網域。混淆參數不符也可能造成交握失敗，請逐項核對伺服器設定。

頻寬設得更高，為什麼反而變卡？

目標速率超過鏈路容量時，排隊、重傳與補償流量都可能增加。請降低頻寬目標、暫停其他大量流量工作，並比較連續傳輸期間的網頁回應。若吞吐量沒有提高、回應延遲卻變大，應保留較低的設定，並核對伺服器是否限制實際可用速率。

已建立連線，為什麼有些網站仍無法開啟？

先在 Home 核對 Global Routing，排除 Direct 或規則指向其他路徑的情況；再檢查 Config 中的比對結果與 DNS 解析。若只在大型回應或特定網路下中斷，再檢查路徑 MTU、UDP 分片與中間網路限制。尚未找出原因前，不要同時更換 DNS、連接埠與混淆參數。

更新訂閱後，手動修改的內容怎麼不見了？

訂閱更新可能會重新寫入由訂閱管理的項目。請先記下修改內容，再確認上游訂閱是否已提供正確參數；長期設定應以自己服務的有效資料為準。訂閱更新、Config 更新與 App Store 的 App 更新是不同操作，不能互相取代。

保留最終設定時，至少記錄網路類型、伺服器項目、Global Routing 模式、頻寬設定，以及發生問題時的具體操作。比較同一項工作的多次結果，比單次速度峰值更有參考價值。若問題只發生在特定伺服器，請提供已移除敏感資訊的錯誤狀況，向自己的服務提供者確認；不要公開驗證資訊。

App Store 正版核對 →