Hysteria2 的潛在優勢來自 QUIC 的傳輸機制與依據頻寬調整的壅塞控制，並非 UDP 本身能保證速度。本文適合已備妥服務參數或訂閱的使用者，依序說明連線條件、驗證與 TLS 參數、Shadowrocket 的設定步驟，以及如何分辨 UDP 無法連線、憑證錯誤和規則分流問題。先確認連線能否建立，再檢視傳輸量。
Hysteria2、QUIC 與 UDP 各自負責什麼
Shadowrocket（小火箭）中的 Hysteria2 是一種代理協定選項。它以 QUIC 為基礎，而 QUIC 的資料封包由 UDP 承載。這三個名稱並非同義詞：UDP 提供資料報傳輸，QUIC 在其上實作加密、連線管理與可靠資料流，Hysteria2 則定義代理驗證、請求轉送及相關傳輸行為。伺服器必須支援相應協定，不能只把現有記錄的 Type 改成 Hysteria2 就完成轉換。
UDP 本身不保證資料送達或順序，但這不代表透過 Hysteria2 瀏覽網頁時會遺失頁面內容。對於需要可靠傳輸的資料，QUIC 的資料流機制會負責確認與重傳；代理的 UDP 流量則可透過資料報機制承載，其傳輸語意與可靠位元組資料流不同。評估協定效能時，應區分外層傳輸與內部應用程式實際使用的連線。
連接埠應以使用者已有的服務參數為準。同一個數字的 TCP 連接埠和 UDP 連接埠屬於不同傳輸協定：伺服器的 TCP 443 可連線，不代表 UDP 443 也可使用。一般網頁能開啟，也只能證明目前網頁所用的連線路徑可用，不能取代 Hysteria2 握手檢查。
為何高延遲、封包遺失的連線可能受益
網路傳輸量不只取決於標稱頻寬，也會受到往返延遲、封包遺失、傳送視窗與壅塞控制影響。傳統以封包遺失回饋為基礎的控制方式，可能將無線干擾造成的隨機遺失也判定為壅塞，進而降低傳送速率。Hysteria2 的自有壅塞控制機制，嘗試在這類條件下更積極運用連線容量；是否採用該機制及實際成效，仍取決於用戶端、伺服器與頻寬協商設定。
QUIC 的多資料流機制可減少不同資料流之間的傳輸層隊頭阻塞：某個資料流等待遺失資料重傳時，不必因同一條有序位元組資料流出現缺口而直接阻塞所有其他資料流。但封包遺失並未消失，同一條可靠資料流仍須等待缺失資料補齊，多個資料流也仍共用連線容量與壅塞狀態。因此，不能由「使用 QUIC」推論「任何網路都會更快」。
- 高延遲且有隨機封包遺失：在 UDP 可連線、伺服器資源充足的前提下，較積極的傳送策略可能改善持續傳輸的傳輸量。
- 低延遲、低封包遺失：瓶頸可能已在接取頻寬、伺服器出口或目標網站，改用其他協定未必帶來明顯差異。
- 網路確實壅塞：繼續增加傳送量可能加劇排隊、延遲抖動與封包遺失，不能將所有封包遺失都歸因於無線干擾。
- UDP 遭封鎖或限速：可能出現握手逾時，或連線建立後持續傳輸受限；協定機制無法消除網路路徑的限制。
結論：先確認 UDP 可連線，再調整頻寬
如果連線一直停留在握手階段，請先確認伺服器位址、UDP 連接埠及目前使用的網路；不要試圖提高頻寬數值來解決連線問題。只有連線穩定建立後，才適合比較傳輸量與延遲。
設定參數前，先分清位址、驗證與 TLS
Hysteria2 記錄至少需要正確的伺服器位址、連接埠與驗證資訊。TLS 身分驗證、混淆及頻寬選項則須符合現有服務設定。訂閱中附帶的參數應作為核對依據，不要憑經驗一律覆寫。尤其要注意，伺服器連線位址、憑證名稱與驗證密碼是不同欄位，不能互相替代。
| 參數 | 設定與核對方式 | 常見誤判 |
|---|---|---|
| 伺服器位址與 Port | 依照現有參數填入網域名稱或 IP，以及對應的 UDP 連接埠；連接埠數值範圍為 1–65535。 | 以為所有服務都使用 443，或把 TCP 可連線誤認為 UDP 也可連線。 |
| 驗證資訊 | 保留大小寫與完整字元。若服務要求特定組合格式，請依原始格式填寫。 | 只填入組合驗證資訊的一部分，或複製時一併帶入空格、換行。 |
| SNI 與憑證 | 依服務設定填入 TLS 名稱，並確認它與憑證及連線目標之間的關係。 | 直接填入 IP 後遇到名稱不符，就關閉憑證驗證。 |
| 混淆 | 僅在伺服器要求時設定；例如使用 Salamander 時，兩端的類型與密碼必須一致。 | 自行新增混淆，或將混淆密碼誤認為驗證密碼。 |
| 頻寬 | 依實際可用的上行、下行頻寬及服務約定填寫，並確認介面使用的單位。 | 把數值當成加速倍率，或混淆 Mbps 與 MB/s。 |
例如，若現有設定以 IP 作為連線位址、以網域名稱作為 TLS 身分，位址欄位與 SNI 原本就可能不同。此時應核對原始參數，不要強行改成相同內容。若出現憑證錯誤，請先檢查系統時間、SNI、憑證效期與服務設定；保持憑證驗證開啟，避免略過驗證來掩蓋錯誤。
在 Shadowrocket 中新增記錄並完成初步核對
以下步驟以已取得自己的 Hysteria2 參數為前提。若使用現有訂閱，可在 Home 右上角點選「+」，將 Type 設為 Subscribe，輸入自己的訂閱連結並儲存；更新後確認產生的記錄 Type 與參數。取得訂閱失敗與 Hysteria2 握手失敗是兩回事：前者發生在取得設定的階段，後者則是在使用某筆記錄建立連線時發生。
-
核對現有參數
先備妥位址、UDP 連接埠、驗證資訊，以及服務要求的 SNI、混淆與頻寬設定。不要直接將舊版 Hysteria 協定參數視為 Hysteria2 參數。
-
新增記錄
在 Home 點選右上角的「+」，進入 Type 並選擇 Hysteria2。填入現有的伺服器位址與 Port，確認數字沒有漏填或多輸入一位。
-
填寫驗證資訊
複製完整的驗證資訊，並依原始設定填寫混淆選項。分別核對驗證密碼與混淆密碼，不要因為兩處都要求密碼就填入相同內容。
-
檢查 TLS
核對 SNI 與憑證驗證設定；頻寬選項則依介面單位填寫。若現有訂閱已設定這些參數，請先保留原值，避免初次測試時同時變更多個變數。
-
儲存並測試
儲存後返回 Home，選取該筆記錄，檢查 Global Routing，再啟用連線。首次啟用時，請依系統提示允許新增 VPN 設定，接著以實際網頁請求確認連線，不要只看延遲數值。
更新訂閱可能會變更由訂閱產生的記錄。為避免混淆，測試前請記下目前參數與訂閱更新時間提示；若曾手動調整，更新後要重新核對。分享疑難排解資訊時，請隱藏驗證內容與訂閱 token，只保留錯誤類型、網路類型及連接埠；不要在公開討論中貼出完整憑證。
疑難排解時如何選擇 Global Routing
協定連線、路由模式與規則比對屬於不同層面。在 Home 選取 Hysteria2 記錄，不代表每個請求都會經由它傳送；Global Routing 與 Config 中的策略仍可能讓請求走 DIRECT，或選擇其他策略。因此，排查特定記錄時，請先排除規則因素，再恢復日常設定。
Proxy：排除規則變數
建議短時間排查時使用 Proxy，並確認目前選取的正是要測試的 Hysteria2 記錄。這會讓交由用戶端處理的連線以代理模式轉送，方便減少 Config 規則造成的干擾；但仍須留意區域網路排除等獨立設定。
適用情況：初次確認參數、區分協定與規則問題
Config：確認日常分流
確認連線有效後切回 Config，檢查實際請求符合的規則與策略。DOMAIN-SUFFIX、IP-CIDR、GEOIP 等規則會影響連線去向；若未符合前面的規則，則由 FINAL 決定最後採用的策略。
適用情況：已有規則設定、需要依目標分流
Direct：確認直連基準
Direct 用來確認直連存取是否正常，不能用來證明 Hysteria2 記錄可用。若在此模式下可以開啟網頁，只能表示相應的直連請求成功，不能據此判定代理握手已完成。
適用情況：對照台灣本地接取網路與目標網站的直連狀況
若使用 Proxy 時可以存取，切回 Config 後特定請求卻失敗，請優先檢查 Config 中的規則順序與目標策略，不要立刻修改 Hysteria2 密碼。規則由上而下比對，較早出現的廣泛規則可能先於後續的細部規則生效；FINAL 應放在規則清單末尾。也請確認 PROXY 實際使用的記錄或策略群組與測試時相同。
常見故障：先確認發生階段，每次只調整一個變數
「連線開關已開啟」、「延遲測試有數值」與「目標網頁可以開啟」代表不同層面的狀態。系統顯示 VPN 已連線，不代表每條遠端連線都成功；單次延遲測試也不代表持續傳輸的表現。以下依可觀察到的現象進行排查，不預設故障一定來自協定。
Wi-Fi 一直逾時，換成行動網路卻能使用？
保持同一筆記錄、同一連接埠與同一個目標請求，只切換接取網路後再測試。若差異能重複出現，請優先檢查 Wi-Fi 路徑的 UDP 可連線性、限速或防火牆策略；不要先改密碼，因為相同參數已在另一條網路路徑成功連線。請留意行動數據用量。
出現憑證或 TLS 錯誤，需要關閉驗證嗎？
先確認裝置時間、記錄中的 SNI 與現有服務參數，再確認網域名稱是否解析到預期位址。名稱不符或憑證過期時，應修正相應設定；不要將關閉憑證驗證當作一般排查步驟，也不要把所有握手逾時都當成憑證錯誤。
小型網頁正常，大型檔案傳輸卻頻繁停頓？
先調低過高的頻寬設定，再於相同網路重複同一個請求。若現象仍持續，記錄停頓發生的時機，進一步檢查路徑 MTU、UDP 分片與限速條件。不要只憑這個現象就直接修改 MTU；也要排除伺服器出口與目標網站本身的限制。
手動連線正常，自動連線卻不如預期？
先到 Settings → On Demand 確認開關與已設定的網路觸發條件，並確認目前的 Wi-Fi 或行動網路環境是否符合預期。測試協定時先手動連線，避免自動中斷或重新連線影響判斷；確認協定與路由正常後，再單獨測試 On Demand。
若要比較效能，請固定裝置、接取網路、記錄、目標資源與測試時段，每一輪只調整一項參數。分別記錄握手是否完成、網頁是否出現第一個回應、持續傳輸是否穩定，以及負載增加時延遲是否明顯上升。不要拿不同目標網站的兩次下載結果，推論某種協定固定快多少。
- 先確認：位址、UDP 連接埠、驗證資訊、TLS 與混淆是否符合現有設定。
- 再排除干擾：使用手動連線與明確的 Global Routing 模式，排除自動連線及規則的影響。
- 最後比較：在可重複的條件下觀察傳輸量與延遲抖動，確認調整是否確實改善使用體驗。