Hysteria2 能否帶來效能提升，取決於 UDP 是否可連通、封包遺失原因及頻寬設定，並非換用協定就一定會變快。本文適合已有服務商提供的設定或訂閱資料的使用者，依序說明 QUIC 傳輸、壅塞控制、參數檢查，以及在 Shadowrocket 中測試分流，協助判斷問題來自協定限制、設定錯誤或網路瓶頸。
一、Hysteria2 與 QUIC、UDP 的關係
Hysteria2 是代理協定，QUIC 是其底層傳輸基礎，而 UDP 則是承載 QUIC 封包的傳輸層協定。這三個名稱描述不同層次，不能把 Hysteria2 簡化成「將所有要求改用 UDP」。應用程式原本發出的 TCP 連線，可以透過 Hysteria2 的 QUIC stream 轉送；應用程式的 UDP 流量則會使用相應的資料報轉送機制。
QUIC 以 TLS 1.3 建立加密連線，並提供彼此獨立的 stream。某個 stream 發生資料遺失時，不必像在單一 TCP 位元組串流上多工傳送多個要求那樣，讓其他 stream 一起等待遺失的位元組。不過，同一個 stream 內的資料仍須依序傳送；多個 stream 也共用路徑容量與壅塞控制，因此不能據此推論封包遺失完全不會影響其他要求。
Hysteria2 的外層連線依賴 UDP。網頁使用 HTTPS，不代表網路一定允許代理連線通過。網路可能允許 TCP 443，卻限制 UDP 443；即使使用相同的連接埠號碼，兩者的可連通性仍須分別驗證。
二、壅塞控制如何影響高封包遺失鏈路
壅塞控制會決定傳送端何時傳送資料，以及傳送速率。傳統以封包遺失為依據的演算法，通常會將封包遺失視為壅塞訊號並降低傳送速率；但無線干擾、鏈路不穩等因素也會造成封包遺失。如果封包遺失並非路徑容量已滿所致，過度保守地降速可能讓剩餘容量無法充分利用。
Hysteria2 可使用 Brutal 壅塞控制，依據設定的頻寬目標與觀察到的封包遺失情況調整傳送節奏。它並非忽略封包遺失，而是嘗試補足遺失的資料量，讓有效吞吐量接近目標。QUIC stream 的可靠性仍仰賴確認與重傳等機制，不能將「壅塞控制補償」理解為遺失資料不必復原。
- 隨機封包遺失但仍有剩餘容量：若頻寬目標設定合理，Brutal 可能比高度依賴封包遺失來降速的演算法維持更高吞吐量。
- 實際壅塞：如果瓶頸鏈路已滿，繼續提高目標速率可能增加排隊、封包遺失與互動延遲。
- 容量變動：行動網路的可用容量會隨訊號與負載改變，固定目標可能在某個時段合適，在另一個時段卻過高。
- 演算法協商：Hysteria2 也有使用 BBR 的運作方式；實際使用方式會受客戶端實作、頻寬設定與伺服器協商影響，不能只憑協定名稱判斷目前使用的演算法。
也要區分 Mbps 與 MB/s：前者通常表示每秒兆位元，後者表示每秒兆位元組。以十進位單位換算，80 Mbps 約等於 10 MB/s，且尚未扣除協定開銷。設定前先確認欄位要求，不要直接把檔案下載工具顯示的 MB/s 數值當成 Mbps。
三、在 Shadowrocket 中檢查現有設定
Shadowrocket（小火箭）中的 Hysteria2 設定應來自使用者現有的連線資訊。先在 Home 開啟對應項目的編輯頁面，確認協定類型與伺服器參數；若項目由訂閱產生，手動修改前請先記下原有數值，因為之後更新可能會覆蓋本機修改。介面呈現方式可能有所不同，以下英文名稱用於辨識參數用途，不代表每個版本的欄位排列都完全相同。
連線與驗證
- Type
- 選擇 Hysteria2，不能只修改項目名稱。
- Server
- 填入現有設定中的主機名稱或 IP。
- Port
- 連接埠須與伺服器監聽的 UDP 連接埠一致，例如 443。
- Password
- 驗證資訊須與伺服器設定一致，不要自行加入空格或換行。
連接埠範例不是可用的連線資料，實際值以使用者現有設定為準。
加密與傳輸
- SNI
- 應與憑證驗證所需的網域相符。
- Certificate
- 保留憑證驗證，先檢查網域、有效期限與裝置時間。
- Obfuscation
- 若設定要求使用 Salamander，兩端的模式與金鑰須一致。
- Bandwidth
- 確認上行與下行方向及單位，並依實際容量設定。
不要以略過憑證驗證來掩蓋 SNI 或憑證設定錯誤。
Server 與 SNI 的用途可能不同：前者決定連線目的地，後者會在 TLS 握手中提供伺服器名稱指示，通常也會用於核對憑證名稱。若使用 IP 作為連線位址，仍可能需要設定憑證對應的網域。遇到憑證錯誤時，應先確認裝置時間與網域是否正確，而非反覆更換連接埠。
- 在 Home 確認目前選取的確實是要測試的 Hysteria2 項目，避免編輯了一個項目，實際連線卻使用另一個項目。
- 暫時在 Global Routing 選擇 Proxy，減少規則分流對測試的干擾；記下原設定，測試完成後再還原。
- 建立連線並連至同一個測試目標，分別記錄是否能開啟、首次回應時間及持續傳輸的表現。
- 若有訂閱更新，更新後請再次確認協定類型、連接埠與頻寬欄位，確保測試使用的是預期設定。
四、先確認路由，再判斷協定是否生效
項目支援 Hysteria2，不代表每個要求都會經過它。Global Routing 中的 Direct 不會使用代理出口；Config 會依目前設定的規則處理要求；Proxy 可用於代理路由測試；Scene 則須配合目前的情境設定檢查。疑難排解時應先固定路由方式，否則「更換協定後速度沒有變化」可能只是要求仍然直接連線。
以下是用來說明比對順序的最簡規則片段，並非完整連線設定。其中 PROXY 是策略目標，不是名為 Hysteria2 的規則關鍵字；實際使用哪個出口，須依目前選取的項目與設定判斷。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY會比對 example.com 及其子網域。此處使用保留的範例網域，僅用來說明語法。IP-CIDR規則會讓指定的私有位址範圍直接連線；no-resolve可避免為了比對這條規則而主動解析網域。GEOIP,CN,DIRECT會依據 IP 地理位置資料庫進行比對，結果取決於目標位址及資料庫內容，並不等同於網域的所屬地區。FINAL,PROXY是前面的規則都未符合時使用的預設規則。規則會由上而下比對，較具體的例外應放在預設規則之前。
Settings → On Demand 用來設定自動連線的觸發條件，不會為網域選擇 Hysteria2，也不會變更上述規則的順序。若要觀察可重複的連線流程，可先記下 On Demand 設定，再手動完成測試，避免網路切換觸發的自動重新連線與參數問題混在一起。
五、適合測試的網路，以及可能限制效能的條件
測試 Hysteria2 的前提是目標 UDP 連接埠可連通，而且使用者已有相符的伺服器設定。高延遲、存在非壅塞所致封包遺失但仍有剩餘頻寬的鏈路，值得觀察其吞吐表現。若瓶頸在本機 Wi-Fi、伺服器出口或目標網站限速，協定本身無法突破這些限制。
- 固定比較條件：使用同一部裝置、同一個網路與同一個目標檔案，並在相近時段測試；不要同時更新訂閱或切換多項參數。
- 區分建立連線與持續傳輸：記錄握手是否完成，再記錄持續下載的表現。連線測試只能說明某種探測成功，不能取代完整的吞吐量測試。
- 觀察負載下的延遲：下載時同步檢查網頁回應。如果吞吐量略有提升，互動卻明顯卡頓，應考慮目標頻寬過高或佇列壅塞。
- 更換接入網路複測：同一設定在 Wi-Fi 失敗、行動網路成功，表示差異可能來自接入網路的 UDP 策略、NAT 或路徑品質，但不足以證明設定一定正確。
- 每次只調整一項：先處理可連通性，再檢查驗證與憑證，最後調整頻寬。每次變更後，請恢復相同的測試條件。
六、常見問題與建議檢查順序
為什麼其他連線可以使用，Hysteria2 卻一直逾時？
先在 Home 確認 Server 與 Port，再確認伺服器對應的 UDP 連接埠是否可連通。TCP 連線成功並不能證明 UDP 已獲允許。保持設定不變，改用另一個接入網路重新測試；若結果隨網路改變，優先檢查網路策略，再檢查驗證資訊與伺服器監聽狀態。
頻寬設定越高，速度就越快嗎？
不是。先確認欄位的單位與上、下行方向，再依據使用者自行穩定測量的結果逐步調整。若提高目標後延遲明顯增加，有效吞吐量卻沒有提升，應退回上一個設定，而不是繼續調高數值。
已經連線，為什麼存取結果仍像是直接連線？
在 Home 確認選取的項目，再檢查 Global Routing。暫時使用 Proxy 建立測試基準；若切回 Config 後行為改變，請到 Config 檢查目標是否先符合 DIRECT，以及 FINAL 是否套用預期策略。
切換網路後連線中斷，需要重新填寫所有參數嗎？
不必先修改參數。先確認新網路可以正常連線，再重新建立通道，並檢查 Settings → On Demand 的觸發條件。QUIC 具備連線遷移相關能力，但能否持續連線仍取決於實作、NAT 與路徑策略，不能把協定能力視為切換網路時不中斷的保證。
總結來說，應先確認 UDP 可連通，再檢查驗證資訊、憑證與路由，最後才評估壅塞控制及頻寬目標。只有在相同測試條件下記錄吞吐量、延遲與失敗情況，才能判斷 Hysteria2 是否適合目前的路徑。Shadowrocket 是閉源商業應用，客戶端一次買斷不等於線路方案；本站不提供、不銷售也不推薦節點或訂閱。