Abstract streaks of purple and green light

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

ProblemCause
Speeds capped at 10-20 MbpsClient bandwidth not configured, using default (tiny value)
Speeds fluctuate wildlyClient bandwidth set higher than actual, congestion control triggering frequently
Fast downloads, slow uploadsup/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):

ConfigurationDownload SpeedUpload SpeedStability
BBR, no bandwidth config~15 Mbps~8 MbpsStable
BBR, correct bandwidth config~80 Mbps~40 MbpsStable
Brutal, target 100M~95 Mbps~45 MbpsSome 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 TypeExampleBlocking Risk
443HTTPS (masquerade)Low, but UDP 443 is uncommon
80HTTP (masquerade)Medium
Random high port (e.g., 44563)No masqueradeHigh (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:

ScenarioRecommendation
Latency-sensitive (<30ms), stable connectionREALITY (low latency, no extra overhead)
High packet loss, unstable connectionHysteria2 (QUIC retransmission is efficient)
Mobile networks (4G/5G)Hysteria2 (QUIC is more mobile-friendly)
Need to bypass UDP blockingREALITY (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