Hysteria2 與 TUIC 協定：高丟包網路下的速度救星

如果你用過 Shadowsocks 或 VMess 協定，大概率經歷過這樣的場景：節點顯示延遲只有 80ms，但實際下載速度只有 2MB/s，看影片頻繁緩衝。問題往往不在節點本身，而在傳輸協定。傳統代理協定基於 TCP，在高丟包、高延遲的網路環境下效能急劇下降。Hysteria2 和 TUIC 作為基於 QUIC 的新一代協定，正是為解決這一痛點而生。

為什麼 TCP 代理在高丟包網路下很慢

TCP 是可靠傳輸協定，每個封包都需要確認（ACK）。當網路丟包率上升時，TCP 的壅塞控制演算法會降低傳送速率，觸發重傳，形成惡性循環。更糟糕的是，TCP 的「隊頭阻塞」問題：一個封包丟了，後面所有封包都要等待重傳完成才能被處理。

對於代理場景，TCP 的劣勢更加明顯：

• 代理流量經過額外封裝，每個 TCP 連線都是「TCP over TCP」，雙重壅塞控制互相干擾
• 國際線路丟包率常在 5%–15%，TCP 在此環境下吞吐量可能不到頻寬的 30%
• 高延遲放大了丟包的影響——每個重傳都要等待一個 RTT

這就是為什麼同樣的節點，用 SS 協定可能只有 5MB/s，換成 Hysteria2 卻能跑到 50MB/s 以上的原因。

QUIC：現代傳輸協定的基石

QUIC（Quick UDP Internet Connections）是 Google 提出的基於 UDP 的傳輸協定，現已成為 HTTP/3 的標準傳輸層。相比 TCP，QUIC 的核心優勢：

• 0-RTT 連線建立 — 重複利用之前的連線參數，二次連線無需交握
• 無隊頭阻塞 — 每個資料流獨立傳輸，一個流丟包不影響其他流
• 使用者態壅塞控制 — 不受作業系統 TCP 堆疊限制，可以更積極地利用頻寬
• 連線遷移 — 網路切換（如 Wi-Fi 切 4G）時連線不中斷

Hysteria2 和 TUIC 都建構在 QUIC 之上，但設計理念和最佳化方向不同。

Hysteria2：暴力美學

Hysteria2 的核心思路是盡可能佔滿可用頻寬。它使用 Brutal 壅塞控制演算法——不依賴丟包訊號來調節速率，而是根據客戶端與伺服器協商的頻寬上限直接傳送。這在高丟包、高延遲線路上效果極為顯著。

Hysteria2 的主要特點：

• 基於 QUIC，內建 TLS 1.3 加密和混淆
• Brutal 壅塞控制，在高丟包環境下仍能保持高吞吐
• 支援連接埠跳躍（Port Hopping），對抗 UDP 限速和封鎖
• 設定簡單，伺服器端和客戶端都易於部署
• 對伺服器頻寬要求較高——它會真的試圖用滿你設定的頻寬上限

Clash 中 Hysteria2 節點設定範例：

- name: "HY2-Node"
  type: hysteria2
  server: example.com
  port: 443
  password: your-password
  sni: example.com
  skip-cert-verify: false
  up: 50        # 上行頻寬 Mbps
  down: 200     # 下行頻寬 Mbps

up 和 down 是 Hysteria2 的關鍵參數，告訴 Brutal 演算法你的頻寬上限。設太低浪費效能，設太高可能導致丟包加劇。建議從實際頻寬的 70%–80% 開始測試調整。

TUIC：均衡之選

TUIC（The Universal Implicit Congestion Control）同樣基於 QUIC，但走了一條不同的路。它由 sing-box 專案作者開發，設計目標是在低延遲和穩定性之間取得平衡，而非一味追求極限速度。

TUIC 的主要特點：

• 基於 QUIC，原生 TLS 1.3 加密
• 使用標準 QUIC 壅塞控制（BBR/Cubic），行為更「溫和」
• 支援 UDP over Stream 模式，相容性和穩定性更好
• 支援 0-RTT 交握，連線建立極快
• 對伺服器資源佔用相對較低

Clash 中 TUIC 節點設定範例：

- name: "TUIC-Node"
  type: tuic
  server: example.com
  port: 443
  uuid: your-uuid-here
  password: your-password
  sni: example.com
  alpn: [h3]
  skip-cert-verify: false
  congestion-controller: bbr
  udp-relay-mode: native

congestion-controller 可選 bbr 或 cubic。BBR 在高延遲線路上表現更好，Cubic 則更保守穩定。一般建議先用 BBR，如果出現不穩定再切換到 Cubic。

Hysteria2 vs TUIC：怎麼選

兩款協定沒有絕對的優劣，關鍵看你的網路環境和使用場景：

• 高丟包、高延遲國際線路 → Hysteria2。Brutal 演算法能強制利用頻寬，速度提升最明顯
• 網路品質中等、追求穩定 → TUIC。標準壅塞控制更可預測，長時間使用不易出現異常
• 看串流媒體、下載大檔案 → Hysteria2。極限吞吐量更高
• 日常瀏覽、社交、辦公 → TUIC。低延遲連線建立，體驗更流暢
• 伺服器頻寬有限 → TUIC。不會像 Hysteria2 那樣試圖佔滿頻寬
• 伺服器頻寬充足 → Hysteria2。能把大頻寬優勢轉化為實際速度

實際使用中，很多使用者會在訂閱中同時保留兩種協定的節點，根據目前網路狀況靈活切換。Clash 的 url-test 代理群組可以自動選擇延遲最低的節點，但無法自動判斷哪種協定在目前網路下速度更快——這需要你手動測試幾次來建立經驗。

在 Clash 中最佳化 QUIC 協定體驗

確保核心版本夠新

Hysteria2 和 TUIC 都需要 Mihomo 核心支援。在客戶端設定中檢查核心版本，建議使用 v1.18 以上版本，以獲得最佳相容性和效能。

UDP 連通性

QUIC 基於 UDP，如果網路環境封鎖或限速 UDP 流量，兩種協定都會失效。Hysteria2 的連接埠跳躍功能可以一定程度緩解封鎖——透過在多個連接埠間輪換，降低單一連接埠被封鎖的機率：

- name: "HY2-Hopping"
  type: hysteria2
  server: example.com
  port: 443
  ports: 443,8443,2053,2083,2087,2096
  password: your-password

與 TUN 模式配合

QUIC 協定在 TUN 模式下運作良好，但需確保 DNS 設定正確。建議使用 fake-ip 模式並開啟 udp 支援，否則部分 QUIC 連線可能因 DNS 解析問題而失敗。

不要過度疊加混淆

QUIC 本身已有 TLS 加密，無需再套一層 obfs 混淆。額外的封裝層只會增加開銷、降低效能。如果擔心流量特徵，Hysteria2 的 Salamander 混淆已經足夠。

常見問題排查

節點顯示逾時或無法連線

首先確認 UDP 是否通暢——在命令列執行 nc -u example.com 443 測試 UDP 連通性。如果 UDP 被封鎖，需要聯絡服務提供商確認是否支援 TCP 回退，或改用 TCP 系協定節點。

Hysteria2 速度達不到預期

檢查 up/down 參數是否設得太低。另外，Brutal 演算法在丟包率超過 20% 時也會顯著降速——這不是協定的問題，而是實體線路的極限。嘗試切換不同線路的節點對比。

TUIC 頻繁斷線

嘗試將 congestion-controller 從 BBR 改為 Cubic。如果使用了 udp-relay-mode: native，改為 quic 也可能改善穩定性。檢查伺服器端是否限制了單一 IP 連線數。

兩種協定都比 SS/VMess 慢

這說明你的網路環境對 UDP 不友善，或者節點伺服器距離太遠。QUIC 的優勢在中高丟包線路上才能體現——如果丟包率低於 1%、延遲低於 50ms，傳統 TCP 協定可能反而更穩定。用測速工具對比同一節點的不同協定，選擇實際最快的那個。

總結

Hysteria2 和 TUIC 代表了代理協定從 TCP 向 QUIC 演進的方向。Hysteria2 用 Brutal 壅塞控制追求極限速度，適合高丟包、大頻寬場景；TUIC 用標準 QUIC 壅塞控制追求均衡穩定，適合日常使用。兩者都需要 Mihomo 核心支援，在 Clash 中設定簡單，只需在訂閱或設定檔中加入對應節點即可。

建議你在訂閱中保留多種協定的節點，在實際網路環境中測試對比，找到最適合自己的協定組合。別忘了從本站下載最新版 Clash 客戶端，確保核心版本支援這些新協定。