Hysteria2 是什麼？QUIC 為何快速，以及 Shadowrocket 適用哪些網路

Hysteria2 與 QUIC、UDP 的關係

Shadowrocket（小火箭）中的 Hysteria2 是一種代理協定。用戶端與伺服器透過以 UDP 為基礎的 QUIC 連線交換資料，再由伺服器連線至目標位址。此處的 UDP 指用戶端與伺服器之間的外層傳輸，不代表瀏覽器造訪的所有網站都改用 UDP，也不代表應用程式原有的 TCP 資料可以不經可靠傳輸便直接丟棄。

QUIC 整合可靠傳輸、串流管理與 TLS 握手。需要可靠送達的資料若遺失，仍須進行恢復；UDP 本身不負責重傳，相關機制由 QUIC 實作。Hysteria2 可承載 TCP 連線與 UDP 資料，但承載方式不同，不能把「外層使用 UDP」解讀為「所有業務資料都保證送達」。

QUIC 的多工可避免單一串流的資料遺失直接阻塞其他串流的有序交付，但各串流仍共用連線的壅塞與頻寬條件。連線嚴重壅塞時，所有業務都可能受到影響。QUIC 也不等同於 HTTP/3；HTTP/3 是建構於 QUIC 之上的應用層協定，不能只因兩者都使用 QUIC，就視為用途相同。

為何可能更快：壅塞控制與頻寬估算

長距離連線的往返時間較長，傳送端必須維持足夠多的傳輸中資料，才能有效利用現有頻寬。丟包會觸發可靠傳輸的恢復程序；某些壅塞控制演算法也會因此降低傳送速率。若丟包主要來自無線干擾，而非連線壅塞，過度降低速率可能導致吞吐量下降。Hysteria2 的設計重點之一，就是在這些條件下調整傳送行為。

Hysteria2 架構中的 Brutal 壅塞控制以頻寬目標為重要輸入，並根據回饋調整傳送，嘗試減輕丟包造成的影響。實際採用哪種控制方式，還取決於雙方實作、協商結果及頻寬設定。不能只看到 Type 為 Hysteria2，就認定一定啟用了某種控制方式，更不能把 QUIC 本身視為固定提升速度的保證。

• 頻寬目標設得太低：即使連線仍有餘裕，傳送速率也可能受設定限制，持續下載時會較早遇到速度上限。
• 頻寬目標設得太高：傳送量超出實際承載能力時，可能造成排隊、延遲增加與丟包，反而讓網頁回應或即時服務變差。
• 上下行不對稱：家用網路的上傳能力可能遠低於下載能力，不能直接把下載測速數值當成上傳目標。
• 單位不同：Mbps 表示每秒兆位元，MB/s 表示每秒兆位元組；例如 80 Mbps 在不計傳輸額外負荷時約為 10 MB/s，這只是單位換算，不代表速度保證。

「快」需要分開來看：首次開啟網頁的等待時間、持續下載吞吐量，以及即時服務的延遲抖動，並不是同一項指標。提高持續吞吐量，不一定能縮短 DNS 查詢時間，也不一定能改善目標網站伺服器的回應速度。跨區路由繞行、伺服器負載與目標網站限速，也可能成為瓶頸。

哪些網路適用：先確認 UDP，再比較實際表現

高延遲、容易隨機丟包，而且允許穩定 UDP 通訊的連線，是值得測試 Hysteria2 的情境。行動網路訊號波動或 Wi-Fi 忙碌時可能造成丟包，但「使用行動網路」本身不足以作為推薦某種協定的理由：不同地點、時段與接入網路對 UDP 的處理方式可能不同，應在實際使用地點反覆測試。

每輪測試可設定相同的觀察時間，例如持續傳輸 60 秒並重複 3 次，同時記錄網路類型及是否中斷。這是測試方式建議，並非本文的實測結果。不要同時切換伺服器、修改 DNS、變更規則再比較速度，否則無法判斷變化究竟來自哪個因素。

在 Shadowrocket 新增設定並核對欄位

以下操作假設使用者已持有自己的服務商與訂閱資訊。匯入訂閱可以減少手動輸入錯誤，但仍須檢查匯入後的協定類型與欄位是否完整。應用程式顯示的欄位可能隨目前介面而異，請逐項對照服務端提供的連線參數，不要以其他協定的設定內容取代。

1. 確認類型

   前往 Home → 右上角「+」→ Type，手動設定時選擇 Hysteria2。使用現有訂閱時，Type 選擇 Subscribe，輸入自己的訂閱網址並儲存，再返回 Home 更新訂閱；接著開啟匯入的項目，確認其類型。

2. 填寫位址

   依現有資訊填寫 Address 與 Port。Address 是伺服器主機名稱或 IP，不是訂閱網址；Port 填寫伺服器實際監聽的 UDP 連接埠。例如伺服器使用 443，就填 443；不能只因網頁常用這個連接埠，就自行改成該值。

3. 確認驗證資訊

   填寫 Password，並確認大小寫、前後空格及複製內容是否完整。Hysteria2 的驗證資訊應由對應伺服器提供，不能把訂閱連結中的 token 當成連線密碼，也不能沿用其他協定的驗證欄位。

4. 檢查 TLS

   展開目前項目的 TLS 相關設定，依現有資訊確認 SNI 與憑證驗證所使用的名稱。若 Address 使用 IP，而憑證簽發給網域名稱，尤其要檢查名稱設定；遇到驗證錯誤時，應確認憑證、名稱與有效期限。

5. 儲存並測試

   儲存項目，返回 Home 選取該項目，再檢查 Global Routing 目前的模式並連線。先開啟一個明確的測試目標，觀察是否能完整載入，再進行持續傳輸測試；修改前先記錄原值，避免同時變更多個參數。

若伺服器啟用了 Salamander 等選用混淆功能，用戶端的對應設定必須與伺服器一致；混淆密碼與連線驗證密碼用途不同。伺服器未啟用時，不應自行加入。混淆也無法讓遭完全封鎖的 UDP 自動恢復連通。

• Address：決定先連線至哪一台伺服器；若使用網域名稱，也需要本機能解析該名稱。
• SNI：用於 TLS 握手中的伺服器名稱指示，應符合現有服務設定；不能將它當成通用的伺服器位址替代方式。
• 憑證驗證：確認對端身分是否符合預期。名稱不符時，應修正參數或憑證，而不是把略過驗證當成例行做法。
• 選用設定：頻寬、混淆及連接埠範圍等項目，只有在現有服務明確提供，且目前介面支援時才填寫；不要猜測預設值或大量嘗試連接埠。

連線後如何區分協定問題與分流問題

項目儲存成功不等於連線驗證成功；連線成功也不代表某個網頁已使用該連線。Shadowrocket 的 Global Routing 會決定流量選擇哪條路徑。排查時先確認目前使用的是 Config、Proxy、Direct 還是 Scene，再確認測試要求實際符合哪條規則或哪種場景設定。

使用 Scene 時，請查看目前生效場景的設定，不要將場景名稱視為固定的代理行為。使用 Config 時，規則由上而下比對，具體條件應放在前面，FINAL 放在規則段落末尾。以下僅示範語法關係，並非可直接取代原設定的完整配置，也不代表這些目標在目前網路中可以連通。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

其中 DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依位址範圍比對，GEOIP 依 IP 地理資料庫比對。若目標網域先符合較前面的 DIRECT 規則，切換至 Hysteria2 項目也不會改變該要求的直接連線路徑。應先確認要求採用的策略，再討論協定速度。

依症狀排查：逾時、驗證失敗、停頓與更新後失效

延遲測試顯示數值，只代表當時該測試操作有收到回應，不能取代完整的業務驗證。尤其是 TCP 連接埠探測，無法確認 Hysteria2 所需的 UDP 握手。遇到問題時依失敗階段逐項檢查，通常比反覆修改頻寬參數更有效。

1. 持續連線逾時：先確認 Address 和 Port，再確認伺服器的 UDP 監聽與防火牆規則。若使用網域名稱，檢查伺服器網域能否解析；接著改用自己可用的另一種接入網路進行比較。
2. 發生 TLS 錯誤：確認裝置時間、SNI、憑證名稱與有效期限。Address 使用 IP 時，尤其要確認憑證是否涵蓋驗證所用的名稱。
3. 驗證失敗：確認 Password 是否屬於這個 Hysteria2 項目，並檢查複製時是否帶入空格、憑證是否已變更，以及選用混淆設定是否與伺服器一致。
4. 已連線但網頁無法開啟：檢查 Global Routing、規則比對結果與 DNS。若只有部分網域無法使用，應優先查明解析或目標連通性，不要先認定整個協定都無法使用。
5. 傳輸一段時間後停頓：檢查 UDP 限速、無線訊號、伺服器負載與路徑 MTU 等因素。若設定了頻寬目標，先記錄原值，再降低目標進行單一變因測試。
6. 訂閱更新後出現變化：重新確認匯入項目的類型、連接埠、驗證資訊與 TLS 設定，並留意更新內容可能會取代手動編輯的值。請以目前已儲存的項目為準，不要只看項目名稱。

On Demand 控制的是依條件建立連線的行為，不是 Hysteria2 的壅塞控制開關。排查自動連線時，可前往 Settings → On Demand 確認相關條件；排查傳輸速度時，應先讓連線狀態與接入網路維持穩定，避免把自動重新連線造成的等待誤認為吞吐量下降。

最終應以實際使用情況判斷：確認 UDP 可連通、參數一致且規則比對正確後，再比較重複測試結果。若目前網路持續封鎖或嚴格限制 UDP，調整頻寬數值無法解決根本問題；若連線穩定且使用體驗符合需求，也不必只為追求單次測速峰值而不斷修改設定。