Hysteria2 基於 QUIC 協議（UDP），理論上在高延遲、高丟包網路裡比 TCP 類協議快得多。但很多人部署完發現速度一般，原因通常是頻寬引數沒配對或者擁塞控制演算法沒選對。
這篇文章專門講調優。假設你已經跑通了基礎部署（參考 Hysteria2 搭建教程），現在想把速度榨出來。
頻寬引數：最影響速度的配置
Hysteria2 的頻寬引數控制著它的傳送速率，沒配或配錯是速度差的最常見原因。
服務端 bandwidth
/etc/hysteria/config.yaml：
bandwidth:
up: 1 gbps # 服務端上行（客戶端下載方向）
down: 1 gbps # 服務端下行（客戶端上傳方向）
這裡填的是服務端（VPS）的實際頻寬上限，不是你家寬頻的速度。
常見 VPS 頻寬：
- DMIT HK/US Premium：1 Gbps 埠，但共享，實際峰值 200-500 Mbps
- AWS t3 型別：5-25 Gbps（burst）
- 低價 VPS：通常 100-500 Mbps
怎麼測 VPS 實際頻寬：
# 在 VPS 上安裝 speedtest
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install speedtest-cli -y
speedtest
根據測速結果填頻寬值。
客戶端 bandwidth
mihomo 配置裡：
proxies:
- name: "hy2-node"
type: hysteria2
server: 你的VPS_IP
port: 443
password: 你的密碼
bandwidth:
up: "50 mbps" # 你家寬頻上行
down: "200 mbps" # 你家寬頻下行
這裡填的是客戶端（你本地）的寬頻速度。
測你家寬頻速度：speedtest.net 或運營商測速頁面，取實測結果的 80% 填進去（留一點餘量）。
頻寬不匹配的後果
| 問題 | 原因 |
|---|---|
| 速度只有 10-20 Mbps | 客戶端 bandwidth 沒填，用了預設值（很小） |
| 速度忽快忽慢 | 客戶端頻寬填超了實際值，擁塞控制頻繁觸發 |
| 下載快、上傳慢 | up/down 填反了 |
擁塞控制演算法：BBR vs Brutal
Hysteria2 支援兩種擁塞控制：
BBR（預設）：Google 開發的 TCP 擁塞控制演算法，移植到 QUIC。會根據網路狀態動態調整傳送速率，保守但穩定。
Brutal：Hysteria2 自己開發的演算法，忽略網路擁塞訊號，按配置的目標頻寬強行傳送，類似"無腦狂推"。在丟包嚴重的網路裡效果很好，但會佔用更多頻寬資源。
什麼時候用 Brutal
- 網路丟包率高（超過 5%）
- 你的 VPS 線路走國際骨幹網，延遲高
- 想要穩定在某個速度（比如穩定 50 Mbps），不在乎偶爾丟包
Brutal 配置
服務端 config.yaml：
quic:
initStreamReceiveWindow: 26843545
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864
maxConnReceiveWindow: 67108864
maxIdleTimeout: 30s
keepAlivePeriod: 10s
disablePathMTUDiscovery: false
bandwidth:
up: 1 gbps
down: 1 gbps
客戶端（mihomo）開啟 Brutal 模式：
proxies:
- name: "hy2-brutal"
type: hysteria2
server: 你的VPS_IP
port: 443
password: 你的密碼
brutal-opts:
enabled: true
up: 50 # Mbps，目標上行速度
down: 200 # Mbps，目標下行速度
開了 Brutal 後，客戶端會強行以目標速度傳送，無論網路質量如何。
實際對比
我在廣州家寬測試，VPS 是 DMIT 香港（延遲約 25ms，輕微丟包）：
| 配置 | 下載速度 | 上傳速度 | 穩定性 |
|---|---|---|---|
| BBR，無頻寬配置 | ~15 Mbps | ~8 Mbps | 穩 |
| BBR，正確配置頻寬 | ~80 Mbps | ~40 Mbps | 穩 |
| Brutal，目標 100M | ~95 Mbps | ~45 Mbps | 有抖動 |
結論：BBR + 正確的頻寬配置，通常已經足夠好。Brutal 適合特定場景（高丟包、想要穩定速度保障）。
QUIC 視窗大小調優
QUIC 的接收視窗大小影響最大併發吞吐，預設值在高頻寬環境下可能是瓶頸。
推薦配置（高速環境，如 100 Mbps+）：
quic:
initStreamReceiveWindow: 26843545 # 25.6 MB
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864 # 64 MB
maxConnReceiveWindow: 67108864
這些數字是經驗值，適合 100-500 Mbps 的場景。如果你的頻寬更高，可以繼續調大（建議不超過總 RAM 的 10%）。
MTU 調優
UDP/QUIC 的包大小影響效率，預設 MTU 對 VPN 場景不一定最優。
檢視當前網路介面的 MTU：
ip link show eth0
# MTU 通常是 1500
Hysteria2 的 QUIC 包在 MTU 1500 的網路裡，實際有效載荷約 1200-1350 位元組（扣除各層頭部）。
對於大多數場景，不需要手動調 MTU。只有在某些企業網路或特殊 ISP 裡，如果發現速度異常低且有大量分片，才需要嘗試降低 MTU：
# 客戶端 mihomo
proxies:
- name: "hy2-node"
type: hysteria2
# ... 其他配置 ...
# 部分客戶端支援設定 mtu
mtu: 1200
埠選擇
Hysteria2 走 UDP，埠選擇影響被封機率：
| 埠型別 | 代表 | 被封風險 |
|---|---|---|
| 443 | HTTPS（偽裝） | 低，但 UDP 443 不常見 |
| 80 | HTTP（偽裝） | 中 |
| 隨機高階口（如 44563） | 無偽裝 | 高（容易被掃到） |
最佳實踐：用 443 或 853（DNS over QUIC），偽裝成正常協議。
# 服務端
listen: :443
# 偽裝成 HTTPS
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true
masquerade 配置讓普通 HTTPS 請求（非 Hysteria2 客戶端）打到這個埠時，返回 bing.com 的正常內容。
多節點負載均衡
如果你有多臺 VPS，可以配置 mihomo 的 load-balance 組同時使用多個 Hysteria2 節點：
proxy-groups:
- name: "HY2 Balance"
type: load-balance
strategy: round-robin # 輪詢，平均分配流量
proxies:
- hy2-us
- hy2-hk
- hy2-jp
url: "http://www.gstatic.com/generate_204"
interval: 300
或者用 fallback 模式（主節點掛了才切）：
- name: "HY2 Fallback"
type: fallback
proxies:
- hy2-us # 主節點
- hy2-hk # 備用
url: "http://www.gstatic.com/generate_204"
interval: 120
與 REALITY 的對比
選 Hysteria2 還是 REALITY，取決於你的網路環境：
| 場景 | 推薦 |
|---|---|
| 延遲敏感（<30ms），穩定線路 | REALITY（低延遲，無額外開銷） |
| 高丟包、不穩定線路 | Hysteria2（QUIC 重傳效率高） |
| 行動網路（4G/5G） | Hysteria2（QUIC 對行動網路更友好） |
| 需要繞過 UDP 封鎖的網路 | REALITY（純 TCP） |
→ 檢視 Hysteria2 搭建教程 → 檢視 Xray REALITY 服務端配置 → 檢視 VPS 選購指南
📷 封面圖 · Flux Schnell AI 生成 · panshi.io 品牌風格