Hysteria2 是以 QUIC 為基礎的代理協定，並非能加速所有網路的開關。本文適合使用 iPhone、iPad 或其他平台上的 Shadowrocket（小火箭），且已有自己的服務商與訂閱的使用者：先確認 UDP 是否可連，再核對連線參數，最後在固定條件下判斷丟包、頻寬和規則各自造成的影響。
Hysteria2、QUIC 與 UDP 的關係
Hysteria2 使用 QUIC 建立用戶端與伺服器之間的傳輸連線，而 QUIC 是透過 UDP 傳輸。此處的 UDP 指的是兩端之間的外層傳輸，不代表網頁請求本身變成不可靠的資料傳送。QUIC 具備串流確認、重傳、流量控制與加密等機制，Hysteria2 再以此承載代理請求。
一般瀏覽網頁常會用到 TCP。透過 Hysteria2 轉送時，這些應用程式連線可以在 QUIC 串流中傳輸；應用程式產生的 UDP 資料也能依協定能力轉送。因此，「伺服器能接受 TCP 連線」和「Hysteria2 能成功連線」是兩回事，外層 UDP 路徑必須另外確認可用。
如果使用者現有伺服器的監聽連接埠是 443，防火牆就必須允許對應的 443/UDP；只開放 443/TCP 並不足夠。實際連線仍應使用服務商提供的連接埠，不能因為網頁常用 443，就把訂閱中的其他連接埠一律改成 443。
為何在高丟包環境中可能更穩定
資料封包遺失後，需要重傳的資料越多、等待復原的時間越長，下載就越容易停頓。傳統 TCP 的壅塞控制會根據網路回饋調整傳送速度；丟包可能源自實際壅塞，也可能是無線干擾等鏈路因素。這兩種情況都會降低傳送速率，未必能充分利用可用頻寬。
Hysteria2 的傳輸設計在某些非壅塞丟包、往返延遲較高的路徑上，能維持較積極的傳送節奏。QUIC 的獨立串流機制，也能減少不同串流因可靠傳輸順序而彼此阻塞的情況。不過，多條串流仍共用路徑和連線資源；丟包後的重傳、伺服器負載與出口容量依然存在，不能將它理解成「丟包越多，速度越快」。
- 無線干擾造成偶發丟包：在 UDP 可連通、鏈路仍有餘裕時，傳輸量可能比原本更穩定。
- 跨區域路徑延遲較高：頻寬利用率可能改善，但光纖距離與路由繞行造成的基本延遲不會消失。
- 接取線路已經壅塞：提高傳送量可能加劇排隊與丟包，反而降低網頁回應速度及通話品質。
- 本地訊號持續轉差：重傳仍會耗用無線資源，切換協定無法改善 Wi-Fi 覆蓋不足。
結論：先分辨丟包與壅塞
如果下載時連直接連線的網頁也明顯變慢，請先降低並行連線數、檢查本地鏈路與頻寬設定；不要預設提高傳送頻寬就能解決問題。
哪些網路不適合使用 Hysteria2
判斷是否適用，首要條件不是測速結果，而是 UDP 能否穩定收發。有些訪客網路、公司網路或公共熱點會限制 UDP；也有網路只允許部分 UDP 流量，或會限制長時間的大量 UDP 傳輸。能解析網域、開啟 HTTPS 網頁，甚至 ping 值很低，都不能證明目標連接埠的 UDP 可用。
| 可觀察到的現象 | 可能原因 | 下一步確認方式 |
|---|---|---|
| Wi-Fi 下連線逾時，行動網路可用 | Wi-Fi 出口限制 UDP，或兩條路徑的路由不同 | 維持相同設定，只切換網路並重試連線 |
| 短時間請求正常，持續下載後速度下降 | UDP 限速、伺服器壅塞，或本機溫度與訊號變化 | 記錄速度下降的時間，並檢查同一時段的直連狀況 |
| 小型請求正常，大型請求經常停頓 | 路徑 MTU、分片處理或丟包問題 | 先核對服務商提供的參數，再檢查路徑與記錄檔 |
| TCP 連接埠測試成功，Hysteria2 仍逾時 | 測試未涵蓋目標 UDP 連接埠 | 確認伺服器的 UDP 監聽設定與防火牆規則 |
不要只憑一次卡頓就判定是 MTU 問題。路徑中的某一段無法正常處理較大的資料報，確實可能造成特定請求停頓；但憑證錯誤、驗證失敗或 DNS 異常，也可能被概括成「打不開」。請先根據記錄檔區分握手失敗與傳輸中斷，再判斷是否需要請服務商協助檢查路徑。
在 Shadowrocket 中核對與測試
以下步驟以 iPhone / iPad 上的 Home、Config、Settings 介面為例。Mac、Windows、Android、Linux 使用者也可採用相同的參數核對與網路比較方式，實際控制項位置請以目前平台介面為準。操作前請保留現有可用設定，測試時只使用自己已有且有權使用的伺服器資訊。
-
更新現有訂閱
在 Home 找到現有訂閱並更新；新增訂閱時，使用 Home → “+” → Type → Subscribe，填入自己的訂閱網址並儲存。請勿將訂閱內容或存取憑證貼到公開截圖或討論中。
-
核對協定參數
在 Home 開啟目標項目的編輯頁面，確認 Type 為 Hysteria2，並逐項核對伺服器位址、連接埠、驗證資訊與 TLS 相關設定。Hysteria 和 Hysteria2 是不同類型，不能任意互換。
-
檢查憑證名稱
如果連線位址是 IP，但憑證是簽發給網域，請核對服務商提供的 SNI。使用混淆時，兩端的類型與密碼必須一致；不要以任意關閉憑證驗證來取代修正參數。
-
排除規則的影響
選取目標連線，暫時將 Home → Global Routing 切換為 Proxy，再連線並存取固定的測試資源。這可減少分流規則造成的干擾，但仍須檢查設定中是否有其他規則覆蓋。
-
還原日常設定
測試結束後，將 Global Routing 還原為日常使用的 Config，並確認 Config 中啟用的是原有設定。如果曾在 Settings → On Demand 調整自動連線行為以排查問題，也請一併還原。
訂閱更新成功只代表用戶端已取得並解析訂閱內容，不代表其中每台伺服器都能連線。服務商變更驗證資訊或憑證後，手動複製的舊項目也未必會隨訂閱同步更新；若驗證失敗，請先比對項目來源與更新結果，不要反覆修改無關規則。
如何選擇 Global Routing，避免誤判協定
Hysteria2 負責連線傳輸方式，Global Routing 則決定請求採用哪種路由模式，兩者屬於不同層級。Global Routing 中的 Proxy、Direct、Config、Scene 也不是四種代理協定。測試協定時，如果請求實際走的是 Direct，網頁開啟速度再快，也不能作為 Hysteria2 的測速結果。
Config：依設定檔執行
建議依照目前設定中的規則與策略決定流量去向。符合 DIRECT 的請求會直接連線；符合代理策略的請求則使用相應連線；未符合規則時如何處理，由 FINAL 等設定決定，不一定會直接連線。
適用：已有規則設定，需要日常分流的情境。
Proxy：排除分流干擾
將代理設為主要路由模式，短時間確認所選連線是否可用。測試時仍應確認請求實際的流向，以免受策略選擇或其他設定覆蓋影響。
適用：測試連線、排查「規則比對結果不如預期」。
Direct：建立直連基準
透過直連狀況檢查本地網路是否已經壅塞。只比較原本就能直接存取的相同資源，不要用無法直連的目標來判斷本地網路整體故障。
適用：比較 Wi-Fi 狀態、確認是否為代理路徑問題。
Scene 用來依已設定的情境套用路由安排，初次排查問題時不宜把它當成不確定變因。規則方面，DOMAIN-SUFFIX 比對網域後綴，IP-CIDR 比對 IP 位址網段，GEOIP 依 IP 地理資料庫判斷，FINAL 負責兜底。檢查規則順序與目標策略，比單純更換協定更能解釋「部分網站可用、部分網站失敗」的情況。
如何比較速度，而不是只看單次峰值
Hysteria2 的表現會受壅塞控制方式、可用頻寬與伺服器限制共同影響。如果連線設定涉及上行與下行頻寬，請依目前的網路環境與服務商要求填寫。上行是本機傳送至伺服器，下行則是伺服器傳回本機；也要分清 Mbps 與 MB/s，後者乘以 8 才是前者的基本單位換算。
不要直接把家用寬頻標示的下載速度，填成所有網路環境的傳送目標。切換到行動網路後，可用上行頻寬可能不同；目標設得過高，可能會占用確認封包與其他應用程式的頻寬。設得過低則可能限制傳輸量。是否需要填寫，以及參數如何生效，請以目前的連線設定和伺服器要求為準。
- 固定測試條件：使用相同裝置、相同網路與相同測試資源；伺服器位置與出口不同的兩條連線，不能只根據協定名稱歸因。
- 重複測量：每組連續測試 3 次，每次持續 60 秒，記錄穩定階段的傳輸量與中斷次數，不要只記錄最高瞬間速度。
- 同步觀察回應：下載期間開啟原本可直接連線的網頁，查看是否明顯排隊；速度提高但其他請求持續卡頓，不算全面改善。
- 分別記錄網路：Wi-Fi 與行動網路分組記錄，切換網路時重新建立連線，避免把舊連線的遷移過程納入結果。
- 記錄錯誤類型：記下逾時、驗證失敗或憑證驗證失敗等實際提示；分享記錄時，請遮蔽伺服器憑證資訊與訂閱網址。
結論：可連線比峰值速度重要
如果同一設定在目前網路上反覆發生 UDP 握手逾時，換網後卻能穩定使用，請先處理網路限制，或改用現有服務中適合該網路的其他連線方式；不要靠反覆調高頻寬數值來嘗試解決。
常見問題與處理範圍
Hysteria2 一定能降低遊戲延遲嗎？
不一定。遊戲延遲還取決於遊戲伺服器位置、代理出口位置、繞行路徑與排隊狀況。持續下載較穩定，不代表小型資料封包的往返速度也更快。請在實際遊玩時觀察延遲波動與丟包，不要只根據下載速度判斷。
連線失敗時，應該關閉 TLS 驗證嗎？
不應將關閉驗證當成一般修復方式。請先檢查裝置時間、伺服器位址、SNI 與憑證涵蓋的名稱，並確認伺服器憑證有效。憑證驗證可檢查伺服器身分；略過驗證會掩蓋設定問題，也會降低連線安全性。
開啟 On Demand 能解決 UDP 受限嗎？
不能。Settings → On Demand 管理的是按需求觸發連線的條件，不會改變電信網路對 UDP 的放行規則。自動重新連線可以再次發起連線，卻無法讓遭到封鎖的傳輸路徑變得可用。
選擇協定時，最重要的依據是目前路徑的可連通性、穩定性與可接受的資源使用量。Shadowrocket 是用戶端，連線參數來自使用者現有的服務；本站僅說明如何設定使用者已有的訂閱，不提供連線服務。若現有參數不完整，請向原服務商確認，不要將密碼、訂閱權杖或驗證欄位當成可以猜測的設定值。