
Hysteria2 is based on the QUIC protocol (UDP), and is theoretically much faster than TCP-based protocols in high-latency, high-packet-loss networks. However, many people find speeds are mediocre after deployment—usually because bandwidth parameters aren’t configured correctly or the right congestion control algorithm isn’t selected.
This article focuses on tuning. It assumes you’ve already got the basic deployment working (see Hysteria2 Setup Guide) and now want to maximize your speeds.
Bandwidth Parameters: The Configuration That Impacts Speed Most
Hysteria2’s bandwidth parameters control its sending rate. Misconfiguration or omission is the most common reason for poor speeds.
Server-side bandwidth
In /etc/hysteria/config.yaml:
bandwidth:
up: 1 gbps # Server upstream (client download direction)
down: 1 gbps # Server downstream (client upload direction)
This is the actual bandwidth ceiling of the VPS, not your home internet speed.
Common VPS bandwidths:
- DMIT HK/US Premium: 1 Gbps port, but shared—actual peak 200-500 Mbps
- AWS t3 instances: 5-25 Gbps (burst)
- Budget VPS: typically 100-500 Mbps
How to test your VPS’s actual bandwidth:
# On the VPS, install speedtest
curl -s https://packagecloud.io/install/repositories/ookla/speedtest-cli/script.deb.sh | bash
apt install speedtest-cli -y
speedtest
Fill in the bandwidth value based on the speedtest results.
Client-side bandwidth
In your mihomo config:
proxies:
- name: "hy2-node"
type: hysteria2
server: Your_VPS_IP
port: 443
password: Your_Password
bandwidth:
up: "50 mbps" # Your home broadband upload
down: "200 mbps" # Your home broadband download
This is the actual bandwidth of your local device. Check speedtest.net or your ISP’s speed test, then use 80% of the measured result (leave some headroom).
Consequences of Bandwidth Mismatch
| Problem | Cause |
|---|---|
| Speeds capped at 10-20 Mbps | Client bandwidth not configured, using default (tiny value) |
| Speeds fluctuate wildly | Client bandwidth set higher than actual, congestion control triggering frequently |
| Fast downloads, slow uploads | up/down reversed |
Congestion Control Algorithm: BBR vs Brutal
Hysteria2 supports two congestion control modes:
BBR (default): Google’s TCP congestion control algorithm, ported to QUIC. It dynamically adjusts the sending rate based on network conditions—conservative but stable.
Brutal: Hysteria2’s own algorithm—ignores congestion signals and forcefully sends at the configured target bandwidth, like “reckless mode.” Works great on networks with severe packet loss, but consumes more bandwidth resources.
When to Use Brutal
- Network packet loss exceeds 5%
- Your VPS route goes through international backbone networks with high latency
- You want stable speed (e.g., steady 50 Mbps), and don’t mind occasional packet loss
Brutal Configuration
On the server side in config.yaml:
quic:
initStreamReceiveWindow: 26843545
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864
maxConnReceiveWindow: 67108864
maxIdleTimeout: 30s
keepAlivePeriod: 10s
disablePathMTUDiscovery: false
bandwidth:
up: 1 gbps
down: 1 gbps
On the client side (mihomo), enable Brutal mode:
proxies:
- name: "hy2-brutal"
type: hysteria2
server: Your_VPS_IP
port: 443
password: Your_Password
brutal-opts:
enabled: true
up: 50 # Mbps, target upload speed
down: 200 # Mbps, target download speed
Once Brutal is enabled, the client will forcefully send at the target speed regardless of network quality.
Real-World Comparison
I tested from home internet in Guangzhou with a DMIT Hong Kong VPS (latency ~25ms, light packet loss):
| Configuration | Download Speed | Upload Speed | Stability |
|---|---|---|---|
| BBR, no bandwidth config | ~15 Mbps | ~8 Mbps | Stable |
| BBR, correct bandwidth config | ~80 Mbps | ~40 Mbps | Stable |
| Brutal, target 100M | ~95 Mbps | ~45 Mbps | Some jitter |
Conclusion: BBR + correctly configured bandwidth is usually good enough. Brutal is for specific scenarios (high packet loss, or when you need stable speed guarantees).
QUIC Window Size Tuning
QUIC’s receive window size affects maximum concurrent throughput. Default values can be a bottleneck in high-bandwidth environments.
Recommended configuration (high-speed environments, 100 Mbps+):
quic:
initStreamReceiveWindow: 26843545 # 25.6 MB
maxStreamReceiveWindow: 26843545
initConnReceiveWindow: 67108864 # 64 MB
maxConnReceiveWindow: 67108864
These are empirical values suitable for 100-500 Mbps scenarios. If your bandwidth is higher, you can increase further (recommendation: don’t exceed 10% of total RAM).
MTU Tuning
UDP/QUIC packet size affects efficiency. Default MTU isn’t necessarily optimal for VPN scenarios.
Check your current network interface MTU:
ip link show eth0
# MTU is usually 1500
Hysteria2’s QUIC packets on a 1500 MTU network have actual payload of ~1200-1350 bytes (subtracting header overhead).
For most scenarios, no manual MTU adjustment is needed. Only try lowering MTU if you notice abnormally low speeds on certain enterprise networks or ISPs where you see heavy fragmentation:
# Client mihomo
proxies:
- name: "hy2-node"
type: hysteria2
# ... other config ...
# Some clients support MTU setting
mtu: 1200
Port Selection
Hysteria2 uses UDP, and port choice affects blocking risk:
| Port Type | Example | Blocking Risk |
|---|---|---|
| 443 | HTTPS (masquerade) | Low, but UDP 443 is uncommon |
| 80 | HTTP (masquerade) | Medium |
| Random high port (e.g., 44563) | No masquerade | High (easy to scan) |
Best practice: Use 443 or 853 (DNS over QUIC), masquerade as a legitimate protocol.
# Server side
listen: :443
# Masquerade as HTTPS
masquerade:
type: proxy
proxy:
url: https://www.bing.com
rewriteHost: true
With masquerade configured, regular HTTPS requests (non-Hysteria2 clients) to this port return normal content from bing.com.
Multi-Node Load Balancing
If you have multiple VPS instances, you can configure mihomo’s load-balance groups to use multiple Hysteria2 nodes simultaneously:
proxy-groups:
- name: "HY2 Balance"
type: load-balance
strategy: round-robin # Round-robin, evenly distribute traffic
proxies:
- hy2-us
- hy2-hk
- hy2-jp
url: "http://www.gstatic.com/generate_204"
interval: 300
Or use fallback mode (switch to backup if primary fails):
- name: "HY2 Fallback"
type: fallback
proxies:
- hy2-us # Primary
- hy2-hk # Backup
url: "http://www.gstatic.com/generate_204"
interval: 120
Comparison with REALITY
Whether to choose Hysteria2 or REALITY depends on your network environment:
| Scenario | Recommendation |
|---|---|
| Latency-sensitive (<30ms), stable connection | REALITY (low latency, no extra overhead) |
| High packet loss, unstable connection | Hysteria2 (QUIC retransmission is efficient) |
| Mobile networks (4G/5G) | Hysteria2 (QUIC is more mobile-friendly) |
| Need to bypass UDP blocking | REALITY (pure TCP) |
→ See Hysteria2 Setup Guide → See Xray REALITY Server Configuration → See VPS Selection Guide
📷 Cover Image · Generated with Flux Schnell AI · Panshi Brand Style