Hysteria2 是什麼？為什麼在「惡劣網路」常被提起
Hysteria2（常簡寫為 Hy2）是基於 QUIC 設計的代理傳輸實作，目標之一是在高延遲、高丟包、頻寬波動的環境中，仍維持可接受的吞吐與連線體感。與傳統「TCP 上再疊一層 TLS」的隧道相比，QUIC 將加密、多路徑復用與更現代的遺失恢復機制放在同一套堆疊裡，對於行動網路切換基地台、跨洲線路抖動、或擁塞時容易被中間設備「掐住」的情境，往往更容易展現差異。
Hysteria2 在協定層還會用到如 BRUTAL 這類針對代理場景調校的擁塞控制思路（實際啟用與效果仍取決於用戶端、伺服器版本與線路條件）。白話來說：當您的網路已經「不太聽話」時，Hy2 常見的優勢是比較不怕偶發掉封包、握手與重連成本相對可控，以及在高抖動下仍較有機會維持流暢的下載曲線。但它不是魔法：若出口本身頻寬很小、或對 UDP／QUIC 有明顯干擾，任何協定都會一起變慢。
閱讀本文時請一併記得：請在合法合規前提下使用代理技術，並遵守服務商與所在地規範。下文僅說明技術設定與觀念，不提供規避法律或濫用網路資源的指引。
與 TCP 類代理相比：您該有什麼期待
多數使用者熟悉的 VMess、VLESS 走 TCP（或再封裝 WebSocket／gRPC）時，一旦線路出現丟包，TCP 自己的重傳與擁塞控制會層層放大延遲，體感就是「網頁開一半卡住、速度時快時慢」。Hy2 走 UDP 承載的 QUIC，遇到單一路徑上的封包遺失時，較有機會在單一連線內完成更細緻的恢復，而不是讓整條 TCP 隧道一起陷入長時間等待。
另一方面，UDP 也代表中間防火牆或營運商 QoS可能對這類流量有不同策略：有些環境對 443／UDP 或 QUIC 相對友善，有些則會限制或干擾。實務上建議您把 Hy2 當成工具箱裡的一種選項，與 TUIC、Reality、傳統 TLS 隧道並存，依時段與線路實測切換，而不是認定「永遠最快」。
開始設定前：版本、權限與備份
在動手改設定檔之前，先完成下列檢查，通常能省下大量試錯時間。
1. 確認核心為 Mihomo（Clash Meta）且版本足夠新
Hysteria2 屬於較新的代理類型，請確認 GUI 所綁定的核心是 Mihomo，且為近期穩定版。核心過舊時，常見症狀是設定檔語法正確卻無法載入、或欄位名稱不相容。建議從本站下載頁取得已搭配測試過的用戶端與核心組合，降低版本落差。
2. 準備伺服器端提供的完整參數
Hy2 通常需要密碼（或服務商給予的等效憑證）、連線位址與埠號，以及 TLS 場景下的 SNI／憑證驗證相關設定。若服務商提供分享連結或訂閱，優先用「一鍵匯入」，手動謄寫最容易在密碼字元、埠號或 SNI 上出錯。
3. 備份現有 config
修改 config.yaml 前先複製備份。代理節點與 proxy-groups、rules 彼此引用，語法錯誤可能導致整份設定無法啟動。
name，並在代理群組裡用同一個名稱引用，避免之後合併設定時被覆蓋或搞混。
在 Mihomo 設定 Hysteria2 節點（YAML 範例）
將下列區段放入 proxies: 清單中（注意縮排與 -）。請將示範值替換為您的實際參數：
proxies:
- name: "HY2-Example"
type: hysteria2
server: hy2.example.com
port: 443
password: "your-strong-password"
sni: hy2.example.com
skip-cert-verify: false
alpn:
- h3
up: 50 Mbps
down: 200 Mbps欄位說明補充：password 須與伺服器端完全一致。sni 用於 TLS 握手時宣告的主機名，通常與憑證網域一致；若填錯會出現憑證驗證失敗。skip-cert-verify 原則維持 false；僅在短暫除錯且清楚風險時才可暫時改為 true，不建議長期開啟。
up 與 down 是 Hy2 用來向伺服器宣告本機預期頻寬的提示值，單位可寫如 50 Mbps、100 Mbps；實際速度仍受線路與方案限制，但填寫與您家裡或行動網路狀況過度脫節時，可能影響擁塞控制與體感，建議依實測逐步調整。
若伺服器啟用 Obfuscation，用戶端可能會多出 obfs 與 obfs-password（實際鍵名以您所用核心版本文件為準）。請一律以服務商或伺服器設定為準，不要自行猜測。
代理群組與規則：讓 Hy2 真的接到流量
新增節點後，務必把它加入 proxy-groups，並確認 rules 會把目標導向該群組。以下為最小示意（請與現有檔案合併）：
proxy-groups:
- name: "PROXY"
type: select
proxies:
- HY2-Example
- DIRECT
rules:
- GEOIP,CN,DIRECT
- MATCH,PROXY實務上大多使用者會搭配更細的規則與外部規則集。若您希望系統性理解分流與 DNS 的關係，可先閱讀站內使用文件，再回到自己的 rules 做調整。
DNS、UDP 與「連得上但網頁打不開」
Hy2 依賴 UDP 承載 QUIC。若您遇到延遲測試有數字、應用程式卻異常，可依序檢查：
- 本機或上游 DNS 是否一致：建議在 Mihomo 內完成 DNS 模組設定，避免真實解析路徑與代理預期不符。可參考站內其他 DNS 相關文章與文件中的觀念說明。
- 路由器或電信商是否限制 UDP：少數環境會對非 53 埠的 UDP 做限制，導致 QUIC 握手斷斷續續。可嘗試不同網路（例如行動熱點對照家用寬頻）縮小範圍。
- 防火牆與 TUN 模式：在桌面或行動裝置上，系統防火牆、其他 VPN 軟體、或 TUN 驅動衝突，都可能讓 UDP 路徑異常。可暫時關閉同類軟體交叉測試。
效能調校：務實期待與可重複的測試方法
調校時請以相同時段、相同測試站點做對照，避免只看單次峰值。建議記錄：首包延遲、下載曲線是否抖動、長連線是否頻繁重連。
1. 調整 up／down 宣告
若您明顯覺得「速度上不去」，可嘗試將 up、down 調整到更接近實際頻寬的量級，觀察是否改善；反之若網路極不穩，過高的宣告有時會讓體感變差，可略為下修再測。
2. 與其他協定並存
在 select 或 url-test 群組中同時放入 Hy2、TUIC、VLESS 等節點，依延遲與下載結果手動或自動切換，是多數進階使用者採用的做法。
3. 規則精簡作為除錯手段
當懷疑問題出在規則分流時，可暫時以全走代理測試（僅作診斷），確認無誤後再恢復精細規則，避免把協定問題誤判成 DNS 或規則問題。
常見錯誤與排查順序
建議依序檢查下列項目，通常能快速定位原因。
1. YAML 結構與縮排
確認 hysteria2 節點位於 proxies 清單內，子鍵縮排正確，且未混用 Tab 與空白。
2. 認證失敗
重新核對密碼是否完整複製；少數面板會區分「顯示用密碼」與「實際連線密碼」，請以伺服器端設定為準。
3. 憑證或 SNI 不符
錯誤的 sni、過期的憑證、或中間人替換憑證，都會導致 TLS 失敗。此時應修正名稱與信任鏈，而不是長期關閉驗證。
4. 只有 Hy2 無法使用、其他協定正常
優先懷疑 UDP／QUIC 被干擾或本地防火牆攔截，並對照伺服器埠與 Obfs 設定是否一致。
開源與核心專案
Mihomo 核心持續整合多種現代協定與規則能力；若您想查證實作細節、提交問題或閱讀更新日誌，可自行前往 GitHub 上的 Mihomo（原 Clash Meta）倉庫。安裝包取得與版本更新仍建議以本站下載頁為主，以便獲得與圖形介面搭配測試過的組合。
小結：把協定優勢變成日常可用的體驗
學會 Hy2 的參數意義後，您會更容易判讀訂閱內容、在惡劣網路下快速切換節點，也能在服務商更新線路時自行除錯。對多數人而言，穩定的用戶端更新節奏、清楚的 DNS 與規則觀念，以及多協定備援，往往比單一「最快協定」更能決定日常體驗。
若您希望省去手動拼湊核心與外掛的時間，建議使用已整合 Mihomo 並預先調校常見選項的用戶端；與從零散來源自行組裝相比，這類版本在錯誤提示與相容性上通常更一致。您可前往本站下載頁依平台取得安裝包，匯入訂閱後再依本文核對 Hy2 欄位是否解析正確。