目录

Hysteria 2:QUIC协议加持的抗审查代理工具完全指南

Hysteria 2:QUIC 协议加持的抗审查代理工具完全指南

学习目标

读完本文后,你将能够:

  1. 说清 Hysteria 的核心原理与抗审查机制
  2. 独立完成 Hysteria 服务端与客户端的基础配置
  3. 根据使用场景选择合适的代理模式(SOCKS5/HTTP/TUN)
  4. 排查 Hysteria 部署中的常见连接与性能问题

文章目录

  1. 核心能力速览
  2. 工作原理
  3. 安装
  4. 配置
  5. 运行
  6. TUN 模式(推荐)
  7. 多用户与访问控制
  8. 性能对比
  9. 适用场景
  10. 常见问题解答
  11. 总结与进阶路径

核心能力速览

能力说明
协议自定义 QUIC,伪装为 HTTP/3
代理模式SOCKS5、HTTP Proxy、TCP/UDP 转发、TUN 模式
性能专为丢包网络设计,超越 TCP
跨平台macOS、Windows、Linux,ARM64 / x86_64
部署单一静态二进制,无外部依赖

工作原理

QUIC 协议基础

QUIC 是 Google 于 2012 年提出的传输层协议,2019 年成为 HTTP/3 的底层协议。与 TCP 相比,QUIC 的核心优势在于:

  • 零往返建立连接(0-RTT):首次连接无需握手延迟
  • 多路复用:一条连接上并行多个数据流,不存在 TCP 的队头阻塞
  • 丢包独立恢复:一个流丢包不影响其他流
  • 连接迁移(Connection Migration):网络切换(如 Wi-Fi 切蜂窝)时连接不中断

Hysteria 的协议伪装

Hysteria 在 QUIC 之上构建了自己的控制平面与数据平面,并将流量特征伪装成标准 HTTP/3。具体来说:

  • 客户端与服务器之间建立一条 QUIC 连接
  • QUIC 握手阶段会发送 TLS 1.3 证书,与真实 HTTPS 流量无法区分
  • DPI 设备看到的是一段带有标准 TLS 握手特征的 HTTP/3 流,而非代理协议握手

这使得 Hysteria 在中国大陆等部署了严格 DPI 的网络环境中,比普通代理协议更难被检测和封锁。

拥塞控制

Hysteria 内置了专为高丢包网络设计的拥塞控制算法(如 BBR 的变体),能够在卫星网络、跨国链路等高延迟高丢包环境下保持良好性能。

安装

官方脚本(一键)

# Linux/macOS
curl -fsSL https://get.hysteria.network | bash

# 或指定版本
curl -fsSL https://get.hysteria.network/@v2.5.0 | bash

二进制下载

GitHub Releases 下载对应平台压缩包,解压后得到 hysteria 可执行文件。

Docker

docker run --rm \
  -v /path/to/config.toml:/etc/hysteria/config.toml \
  -p 443:443 \
  -p 443:443/udp \
  goofball404/hysteria server

配置

Hysteria 使用 TOML 格式配置文件。以下是典型场景的配置:

服务端

# /etc/hysteria/config.toml
[server]
bind = ":443"
tls = { cert = "/path/to/cert.crt", key = "/path/to/private.key" }

# 认证
auth = { type = "password", password = "your-secret-password" }

# 速度限制(可选)
# speed_limits = "1Gbps"

客户端

# config.toml
server = "your-server-ip:443"

# 认证密码(与服务端一致)
auth = { type = "password", password = "your-secret-password" }

# TLS 配置
tls = { insecure = false }  # 生产环境设为 false

# 代理协议(以 SOCKS5 为例)
socks5 = { listen = "127.0.0.1:1080" }
http = { listen = "127.0.0.1:8080" }

生成 TLS 证书(Let’s Encrypt 示例)

certbot certonly --standalone -d your-domain.com --agree-tos -n -e tls-sni-01-challenge
# 证书路径:/etc/letsencrypt/live/your-domain.com/fullchain.pem
# 私钥路径:/etc/letsencrypt/live/your-domain.com/privkey.pem

运行

# 服务端
hysteria server -c /etc/hysteria/config.toml

# 客户端(后台运行)
hysteria client -c config.toml

TUN 模式(推荐)

TUN 模式将 Hysteria 虚拟为一张网络设备,所有流量自动经代理转发,适合全局代理场景:

# 服务端 config.toml
[server]
tun = { name = "hysteria-tun", mtu = 1500 }
# 客户端 config.toml
tun = {
  name = "hysteria-tun",
  mtu = 1500,
  # 路由:默认所有流量走代理
  route = { default = true }
}

多用户与访问控制

[server]
# 基于 IP 的速率限制
rate_limit = "100Mbps"

# 允许特定 CIDR
allow_ip = ["10.0.0.0/8", "192.168.0.0/16"]

# 流量统计
traffic_stats = true

性能对比

数据来源为 Hysteria 官方测试,在 20% 丢包率的跨国链路上测试吞吐:

方案平均吞吐备注
直连 TCP~5 Mbps受丢包严重影响
WireGuard~35 MbpsUDP 表现优于 TCP
Hysteria~85 MbpsQUIC 多流+BBR 显著胜出

适用场景

  • 高审查环境:伪装为 HTTP/3,难以被 DPI 识别
  • 高丢包网络:跨国链路、卫星网络等 QUIC 优势明显
  • 单端口多服务:一条 443 端口承载 SOCKS5、HTTP、TUN 多种服务
  • 轻量部署:单一二进制,配合 cron 即可实现自动更新

总结与进阶路径

Hysteria 2 通过 QUIC 协议的自定义实现,在抗审查与高性能之间取得了难得的平衡。对于身处高审查网络环境、同时对带宽质量有要求的用户,它是一个值得优先考虑的代理方案。其单文件部署、自动更新、TOML 配置等工程细节也降低了运维复杂度。

进阶学习

  1. 配合 CLIProxyAPI 实现多代理负载均衡
  2. 结合 s-ui 实现可视化代理管理
  3. 高可用部署:多节点 Hysteria + DNS 轮询实现故障自动切换

常见问题解答

Q1:服务端启动失败,提示端口 443 被占用?

A:先检查是否有其他服务(如 Nginx、Caddy)占用了 443 端口,可暂时关闭或修改这些服务的端口。如果 443 端口无法使用,可将 Hysteria 绑定到其他端口(如 8443),但伪装效果会下降。

Q2:客户端连接后速度很慢?

A:排查步骤:

  1. 检查服务端与客户端的版本是否一致,跨大版本可能不兼容
  2. pingmtr 检查链路丢包率,高丢包环境下可尝试调整拥塞控制算法
  3. 确认是否启用了 TUN 模式,TUN 模式相比 SOCKS5 有更低的开销

Q3:TLS 证书验证失败?

A:生产环境务必使用 Let’s Encrypt 等受信任的证书,不要使用自签证书。如果测试环境需要使用自签证书,客户端配置需设置 tls = { insecure = true },但生产环境禁止此操作。

Q4:TUN 模式无法启动?

A:TUN 模式需要 root/管理员权限,启动时需加 sudo(Linux/macOS)或以管理员身份运行(Windows)。同时检查系统是否支持 TUN 虚拟设备,部分低成本 VPS 可能未开启此功能。


自测问题

题 1:Hysteria 的抗审查核心是什么?

参考答案Hysteria 将自定义 QUIC 协议流量伪装为标准 HTTP/3 流量,QUIC 握手阶段会发送 TLS 1.3 证书,与真实 HTTPS 流量无法区分,DPI 设备无法识别为代理协议。

题 2:高丢包环境下为什么 Hysteria 性能优于 TCP 代理?

参考答案QUIC 协议支持多路复用(不存在 TCP 队头阻塞)、丢包独立恢复(一个流丢包不影响其他流),且 Hysteria 内置专为高丢包网络设计的拥塞控制算法,因此性能显著优于传统 TCP 代理。

题 3:生产环境部署 Hysteria 有哪些注意事项?

参考答案1. 务必使用受信任的 TLS 证书(如 Let's Encrypt),不可使用自签证书 2. 服务端 443 端口需未被占用 3. 客户端与服务端版本需匹配,跨大版本可能不兼容 4. TUN 模式需要 root/管理员权限

注意事项

  • TLS 证书:生产环境务必使用真实受信任的证书,不可自签(否则流量会被识别为异常)
  • 端口 443 独占:服务端 443 端口需未被占用
  • 客户端与服务端版本需匹配:跨大版本可能不兼容
  • TUN 模式需 root/管理员权限