Hysteria2 是 Shadowrocket（小火箭）支援的代理協定。若網路有隨機丟包或延遲波動，可能有所改善，但前提是網路允許 UDP，且伺服器參數相符。本文適合已持有服務商提供的設定或訂閱者，將依序說明傳輸原理、參數核對、匯入步驟與故障現象，協助判斷是否適用；本站不提供、不銷售，也不推薦節點或訂閱。
Hysteria2、QUIC 與 UDP 各自負責什麼
結論：Hysteria2 使用 QUIC 建立用戶端與伺服器之間的傳輸通道，QUIC 封包則透過 UDP 傳送。UDP 是底層承載方式，不代表所有應用程式資料都變成不可靠傳輸。QUIC 可在 UDP 之上提供加密、確認、丟包復原與可靠的串流傳輸。
應用程式連線至網站時，原始連線與代理傳輸通道屬於不同層次。例如，網站請求本身可以使用 TCP，而 Shadowrocket 與 Hysteria2 伺服器之間的外層連線仍使用 QUIC。排查防火牆或伺服器連接埠時，應檢查外層使用的 UDP，而非只確認相同數字的 TCP 連接埠是否開放。
QUIC 的多個串流可以各自推進：某個串流遺失的封包，通常不會阻塞其他串流已收到的資料。這能減少跨串流的隊頭阻塞，但同一個可靠串流中遺失的資料仍須復原；多個串流也仍會共用同一條網路鏈路。不能因此推論影片、網頁與檔案傳輸完全不會互相影響。
若設定指定使用 443/UDP，只確認 443/TCP 可連通，並不足以證明 Hysteria2 可用。應一併確認伺服器是否正在監聽、伺服器端防火牆設定，以及目前的網路是否允許對應的 UDP 流量。
為何可能更快：關鍵在壅塞控制，不只是 UDP
結論：Hysteria2 在部分高丟包鏈路上的優勢，與其壅塞控制及傳送策略有關，並非「UDP 天生比 TCP 快」。鏈路丟包可能源於壅塞，也可能來自無線干擾或其他隨機損失。若把所有損失都視為壅塞而大幅降低傳送量，可用頻寬便可能無法充分利用。
Hysteria2 的 Brutal 壅塞控制方式，會依據設定的頻寬目標並配合損失情況調整傳送行為。這種方式可能透過增加實際傳送流量來提高有效吞吐量。在支援頻寬協商的設定中，用戶端宣告的接收能力、伺服器限制與實際路徑容量都會影響結果。協定也有使用 BBR 等壅塞控制的情況，不能只看名稱就認定目前連線必定使用某種模式。
- 隨機丟包明顯，但鏈路容量仍充足：補償損失的傳送策略可能較容易維持吞吐量，但必須以相同任務重複測試確認。
- 出口確實壅塞：繼續提高傳送量可能加重排隊，導致檔案傳輸時網頁回應變慢。
- 丟包率低且延遲穩定：協定差異未必是主要瓶頸；伺服器負載、可用頻寬與目標網站仍可能左右速度。
- UDP 遭封鎖或嚴格限速：傳輸可能無法建立，或只能維持極低吞吐量；修改頻寬數值無法解除網路限制。
頻寬欄位也涉及單位。Mbps 代表每秒兆位元，MB/s 代表每秒兆位元組；按十進位單位計算，80 Mbps 的理論上限約為 10 MB/s，實際應用資料速率還須扣除協定負荷與重傳。設定參數時，請以應用程式欄位標示為準，不要直接照抄檔案傳輸工具顯示的數值。
結論：頻寬目標應先依可持續能力設定
若設定提供頻寬選項，請先使用服務商提供的數值；需要調整時，應以目前網路可持續的上傳與下載能力為依據。不要為了追求更大的數字，把短暫峰值或方案標示速度當成長期傳送目標。
Shadowrocket 中應核對哪些 Hysteria2 參數
結論：先將伺服器提供的資訊完整對應至應用程式，再調整效能選項。Hysteria2 與舊版 Hysteria 協定不能只靠更改名稱互換；匯入後應確認 Type 確實為 Hysteria2。以下列出的是參數說明，並非可直接貼入 Config 的設定語法。
| 參數 | 核對項目 | 常見錯誤與狀況 |
|---|---|---|
| 伺服器位址 | 使用服務商提供的網域名稱或 IP；hy2.example.com 僅為說明用的網域名稱。 | 位址輸入錯誤或解析異常，導致無法連線至正確的伺服器。 |
| Port | 逐一核對實際連接埠；例如服務商指定 443 時，外層應檢查 443/UDP。 | 將常見連接埠誤認為預設值，導致資料傳送至錯誤的監聽位置。 |
| 認證資訊 | 依服務商提供的完整認證字串填寫，保留大小寫與符號。 | 遺漏字元、複製到空格，或誤用其他設定的憑證。 |
| TLS / SNI | 依要求填寫伺服器名稱並保留憑證驗證；連線位址與憑證名稱不一定相同。 | 將 IP 直接當作憑證名稱，或填入憑證未涵蓋的網域名稱。 |
| Obfuscation | 僅在伺服器啟用時依要求設定；例如雙方使用相同的 Salamander 設定與密碼。 | 只有一端啟用，或密碼不一致，可能導致交握逾時。 |
| 頻寬選項 | 若目前編輯頁面提供相關欄位，請核對上下行方向、單位與服務商要求。 | 上下行填反、誤解單位或目標設得過高，可能造成連線不穩與額外排隊。 |
連線位址用來將資料傳送至伺服器；SNI 則是在 TLS 交握中提供伺服器名稱資訊，並用於常見的憑證名稱核對流程。兩者可以不同，但必須依據可信的設定說明。若出現憑證錯誤，應檢查名稱、裝置時間與伺服器憑證狀態，而非先關閉驗證。
- 欄位名稱、可見選項及進階設定，請以應用程式實際顯示為準；訂閱未提供某個選用參數，不代表應自行填入數值。
- 已有訂閱時，應優先透過更新訂閱取得修正後的參數。手動修改前請先記錄原值，以免下次更新後混淆兩套設定。
- 分享故障排除資訊時，保留錯誤類型與參數名稱即可；請遮蔽認證字串、訂閱位址中的權杖及相關密碼。
匯入與首次驗證：先確認連線，再檢查規則
結論：先在 Home 完成匯入與選取，再以單一測試請求驗證連線。Home 用於管理伺服器與連線狀態，Config 用於管理規則設定，Settings 用於管理應用程式設定。將傳輸失敗與規則選取錯誤分開處理，才能縮小排查範圍。
-
準備參數
向自己使用的服務商確認伺服器位址、連接埠、認證資訊與 TLS 要求。若使用訂閱，請確認其中確實包含 Hysteria2 項目，不要只憑備註名稱判斷協定。
-
匯入訂閱
在 Home 右上角選擇「+」，前往 Type → Subscribe，輸入自己的訂閱位址並儲存，再回到 Home 更新對應的訂閱。若位址包含認證權杖，請視同密碼妥善保管。
-
核對類型
開啟已匯入項目的編輯頁，確認 Type 為 Hysteria2，並依上表檢查參數。若要手動新增，請從 Home →「+」→ Type → Hysteria2 開始，依照現有設定逐項填寫。
-
驗證連線
返回 Home 選取該項目並啟用連線，依系統提示允許新增 VPN 設定。記錄開始連線後的實際結果：持續等待、明確錯誤，或能否開啟指定的測試頁面。
-
檢查分流
前往 Home → Global Routing 確認目前模式；若要暫時排除規則的影響，可使用 Proxy 測試同一個請求，再恢復日常使用的 Config，並核對目標網域實際套用的策略。
首次測試時也應查看 Settings → On Demand。若已啟用隨選連線，請記錄其狀態；進行中斷連線或切換網路測試時，可暫時關閉，測試後再恢復，避免自動連線影響觀察。On Demand 用於管理連線觸發條件，無法修復 Hysteria2 的認證、TLS 或 UDP 連通性。
更新訂閱可能會變更伺服器參數或項目清單。更新完成後，請確認目前選取的仍是預期項目，再測試同一個目標。不要同時更新訂閱、調整頻寬、修改規則與切換網路，否則無法判斷是哪項變更造成結果差異。
使用 Global Routing 區分協定問題與規則問題
結論：相同的 Hysteria2 項目在 Proxy 下可存取、在 Config 下無法存取時，應優先檢查規則命中與所選策略，而非立刻更換傳輸參數。以下比較僅針對 Global Routing 中用於本次驗證的三種模式；只有在目標原本即可直連時，Direct 才能作為基準。
Config
建議依目前啟用的 Config 規則選擇處理策略。目標可能命中 DIRECT、REJECT 或某個代理策略，因此必須確認請求是否實際使用待測的 Hysteria2 項目。
適用情境：日常依規則使用，以及完成連線驗證後檢查分流。
Proxy
由應用程式處理的連線會交由目前的代理策略處理，可短暫減少 Config 規則對測試的干擾。但這不保證系統中的所有流量都會交由應用程式處理，也無法繞過伺服器認證或網路限制。
適用情境：同一個請求在 Config 下異常時，用來排除規則選取這個變數。
Direct
由應用程式處理的連線會直接存取目標，不使用待測的 Hysteria2 通道。直連成功只能證明這條直連路徑可用，不能據此認定代理伺服器運作正常。
適用情境：為原本可直連的目標建立本地網路基準。
檢查規則時，請留意 DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依位址網段比對，GEOIP 依 IP 地理資料庫判斷，FINAL 則是前面的規則都未命中時採用的最終策略。規則依序處理；前面的 DIRECT 或 REJECT 命中後，後續代理策略便無法改變這次比對結果。DNS 解析結果也可能影響以 IP 為依據的判斷。
結論：先確認請求確實經過待測通道
只有確認目標請求實際使用所選的 Hysteria2 項目後，網頁載入時間與傳輸速率才適合用來評估該連線。若命中 DIRECT，應先修正規則與測試條件，不要將直連結果當成協定表現。
無法連線、測速偏低與連線中斷的分層排查方式
結論：依序檢查「是否到達伺服器 → 是否完成交握與認證 → 是否正確分流 → 是否存在吞吐量瓶頸」。單一延遲數值只能描述某一種探測結果，無法同時證明 UDP 可連通、認證有效及持續傳輸穩定；探測逾時也須搭配實際連線結果判斷。
| 觀察到的狀況 | 優先核對項目 | 下一步處理 |
|---|---|---|
| Wi-Fi 逾時，行動網路可連線 | 兩種網路的 UDP 策略、路由及位址解析差異。 | 保持項目不變，只切換網路重複測試，再確認 Wi-Fi 網路限制。 |
| 出現 TLS 或憑證錯誤 | SNI、憑證涵蓋名稱、裝置時間與憑證有效性。 | 依現有服務商資訊修正參數，保留憑證驗證，不要用吞吐量設定處理交握錯誤。 |
| 連線後顯示認證失敗 | 認證字串是否完整，以及伺服器端是否已更新憑證。 | 更新自己的訂閱或核對原始參數；不要將增加重試次數當成解決方法。 |
| 網頁可開啟，但大型檔案傳輸緩慢 | 伺服器出口、目標網站限制、本地頻寬、頻寬選項與持續丟包。 | 固定網路與項目，比較小型請求和持續傳輸，並記錄任務開始後的變化。 |
| Proxy 正常，Config 異常 | 規則順序、目標命中的策略與 DNS 結果。 | 檢查 Config 中相關規則，不要同時修改協定參數。 |
| 閒置一段時間後首次請求失敗 | 網路切換、UDP 對應逾時、連線重建與 On Demand 狀態。 | 記錄閒置時間與恢復過程，重新連線後再次測試，再區分接入網路與伺服器問題。 |
以上內容是故障判斷方式，並非本站實測結果。自行記錄比較時，可在同一網路下針對同一檔案連續測試三次，每次觀察 30 秒，分別記錄是否成功、穩定階段的速率，以及同時開啟網頁時的回應狀況。固定測試時間與目標，可減少快取、目標網站限速及瞬間網路波動造成的誤判。
- 每輪只變更一個變數：例如第一輪只切換 Wi-Fi 與行動網路，第二輪再核對頻寬參數。
- 同時觀察延遲與吞吐量：速率提高但互動明顯變慢，可能代表排隊加重，不一定是更好的設定。
- 留意流量用量：持續傳輸與丟包補償都可能消耗額外流量，測試前請確認自己的網路計費方式。
- 保留可供核對的紀錄：記下接入網路、所選項目、Global Routing 模式、測試目標與錯誤訊息；請勿公開認證資訊。
適用情境與使用前提
若 UDP 可用，且網路存在隨機丟包或延遲波動，值得使用現有設定測試 Hysteria2 的表現。若 UDP 受限、伺服器出口已飽和或目標本身限速，協定名稱無法取代對瓶頸的處理。長期使用時，應綜合評估成功率、持續吞吐量、互動回應與流量用量，而非只挑延遲最低的一次結果。
- 參數完整但交握失敗：先核對 UDP、TLS 與認證，不要先追求更高的頻寬數值。
- 交握成功但目標存取異常：先檢查 Global Routing 與 Config 規則。
- 可以使用但速度不穩：固定任務與網路重複測試，再判斷壅塞控制是否符合鏈路狀況。
Shadowrocket 是閉源商業應用，主要供 iPhone / iPad 使用，也可在 App Store 產品頁確認 Mac、Apple TV 與 Apple Vision 的相容性。系統需求、相容性及是否支援通用購買，請以 App Store 頁面標示為準。唯一取得管道為 App Store，開發者為 Shadow Launch Technology Limited，App ID 為 932747118；應用程式採一次性買斷，價格以商店顯示為準。
購買 Shadowrocket 取得的是用戶端，不代表已取得伺服器、頻寬或訂閱。本文所有匯入、參數與連線測試，均以使用者已持有自己的服務商設定為前提。