Hysteria 2: Complete Protocol Overview, Differences from Hysteria 1, Server and Client Setup

Introduction

Over recent years, blocking systems and deep packet inspection (DPI) have become more precise, aggressive, and cunning. Traditional TCP-based VPNs increasingly suffer from reduced speed and unpredictability, especially on mobile and congested networks. Against this backdrop, Hysteria 2 has established itself as one of the most practical transports for stable tunneling over QUIC/UDP: quick startup, high loss tolerance, effective obfuscation, and thoughtful ease of administration. In this article, we'll explore the protocol's architecture, key differences from Hysteria 1, best server and client setup practices, plus handy checklists, tuning tips, and real-world cases.

What you’ll gain: a clear mental model of Hysteria 2, a collection of proven configs and steps, diagnostic tools, DPI bypass strategies, and answers to challenging questions. Our goal is for this article to become your go-to practical guide to Hysteria 2—by practitioners, for practitioners.

Basics

What is Hysteria 2 and why QUIC/UDP?

Hysteria 2 is a high-performance tunnel running on QUIC/UDP with authentication, TLS 1.3 encryption, and optional obfuscation. Unlike TCP-based VPNs, QUIC operates over UDP, implementing congestion control and reliable delivery at the user-space level. Practically, this means faster connection setup, fewer stalls when packets drop, better handling on unstable networks, and no slow recovery issues common in long TCP sessions.

Where Hysteria 2 shines the most

• Networks with high latency and packet loss (mobile, busy Wi-Fi environments).
• DPI bypass targeting TCP signatures, TLS fingerprints, and unusual traffic behavior patterns.
• High-load scenarios with numerous short requests: fast pipeline ramp-up and reduced overhead.

Differences between Hysteria 2 and Hysteria 1

• Transport model: Hysteria 1 supported extra masking modes (like faketcp), whereas Hysteria 2 focuses on clean, high-quality QUIC/UDP, minimizing recognizable artifacts.
• Protocol purity: improved alignment with standard QUIC and TLS 1.3 behavior, reducing chances of transport-specific detection.
• Obfuscation: Hysteria 2 employs lightweight obfuscation before the TLS handshake (e.g., 'salamander' mode) to hide DPI predicates before encryption starts.
• Authentication model: simplified, password/token-based with better ergonomics for multi-client use cases.
• Performance: updated congestion control and buffering parameters based on real-world experience; enhanced heuristics for initial bandwidth estimation.
• Masquerade: easier setup for "plausible" responses to random scanners and probes, reducing risk of selective port blocking.

Deep Dive

Hysteria 2 protocol stack

• UDP as the base transport: minimal head-of-line blocking headaches, independent from TCP state machines in network devices.
• QUIC: provides encryption at the transport level, independent congestion control, and stream multiplexing without global blocking.
• TLS 1.3 over QUIC: fast handshakes, session resumption, compact cipher suites, limited metadata leakage. Typically, only SNI is visible unless ECH is used (currently limited in practice).
• Pre-TLS obfuscation: a lightweight layer making early traffic less predictable for DPI, lowering detection chances before the secure channel is established.

Authentication and access model

The standard practice is a symmetric password/token, either single or multiple for different users. This reduces deployment complexity and simplifies client integration across platforms (desktop and mobile). Password rotation is low effort and convenient for regular updates.

Performance algorithms and parameters

• Initial bandwidth estimation (up/down): you specify expected client upload/download capacity; the transport uses this as a hint for window size and pacing to reduce pipeline ramp-up delays.
• MTU and fragmentation: QUIC requires a minimum initial MTU of 1200 bytes. On problematic routes, enabling fragmentation or limiting datagram sizes on the client side (e.g., 1200 bytes) helps avoid PMTU black holes.
• Keepalive: regular minimal packets maintain NAT state, preventing unexpected drops of long idle sessions.
• Multiplexing streams: dozens of simultaneous bidirectional streams without blocking speed up web loads and API workflows.

Masquerading as ordinary traffic

Key plausibility factors: UDP port 443, ALPN 'h3' (where client supports it), valid and proper certificates, appropriate SNI. On random external requests (scanners or curious clients), the server can serve static content or proxy a legitimate website (masquerade) without revealing the tunnel service.

DPI and blocking: trends for 2026

• Hybrid DPI: combining signature and behavior-based criteria: packet size, frequency, timing, plus persistent TLS/QUIC fingerprints.
• UDP rate limiting: some providers restrict UDP, especially on common ports. Testing alternative ports and controlled fragmentation is essential.
• Individual IP reputation: shared VPN addresses get blacklisted faster. Dedicated IPs reduce mass correlation and neighbor noise.

Practice 1: Designing architecture and profiling risks

Step 1. Define goals

• DPI bypass for web browsing and API calls.
• Resilience to losses and high latency (mobile networks or long routes).
• Low detection profile: plausible port, valid TLS, minimal unusual behavior.

Step 2. Choose platform and hosting

• Server: lightweight VPS with guaranteed UDP support, 1–2 vCPUs, 1–2 GB RAM is enough to start. Storage: 10–20 GB.
• OS: modern Linux LTS with updated kernel (for better network stacks and timers).
• Network stack: prioritize nftables, systemd-networkd or NetworkManager, chrony/ntpd for accurate time.

Step 3. Domain, certificate, port

• Domain: a neutral name without “vpn” hints. Ideally, one that can host a legitimate site for masquerade.
• Certificate: publicly valid cert for the domain, RSA or ECDSA. Auto-renewal is critical.
• Port: UDP 443 as default for plausibility; backup port like 8443/UDP or another inconspicuous choice.

Step 4. Secret and rotation model

• Password/token in server and client configs—unique, strong, not shared with other services.
• Regular rotation: every 1–3 months or upon leaks.
• Separate secrets for user groups simplify access revocation.

Design checklist

• UDP open on firewall and provider panel.
• Server time synchronized (no big shifts).
• Certificate valid and auto-renewing.
• Ports 443/UDP and backup chosen.
• Passwords and rotation rules set.
• Masquerade content prepared (static page or reverse proxy).

Practice 2: Setting up Hysteria 2 server on Linux

Prerequisites

• 'hysteria' binary built or installed with Hysteria 2 support.
• Valid certificate and private key in PEM format obtained.
• Run permissions granted to dedicated user without shell access.

Basic server config (example)

Below is an illustrative YAML config. Field names may vary by version—check your build. Quoted values are examples; use your own secrets and paths.

• listen: ':443'
• tls:
•   cert: '/etc/hysteria/cert.pem'
•   key: '/etc/hysteria/key.pem'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• masquerade:
•   type: 'file'
•   dir: '/var/www/masq'
• quic:
•   alpn: ['h3']
•   max_idle_timeout: '30s'
•   disable_path_mtu_discovery: false
• bandwidth:
•   up: '50 Mbps'
•   down: '200 Mbps'

System and security

• Create user: `useradd --system --no-create-home --shell /usr/sbin/nologin hysteria`.
• Set key permissions: `chown -R root:hysteria /etc/hysteria` and `chmod 640` for key files.
• Open ports: nftables or iptables for UDP 443 and backup ports.
• SELinux/AppArmor: grant binary and config directory necessary permissions.

systemd service (minimal)

• [Unit] Description='Hysteria 2 Server' After=network.target
• [Service] User=hysteria Group=hysteria AmbientCapabilities=CAP_NET_BIND_SERVICE CapabilityBoundingSet=CAP_NET_BIND_SERVICE ExecStart='/usr/local/bin/hysteria' 'server' '-c' '/etc/hysteria/config.yaml' Restart=on-failure
• [Install] WantedBy=multi-user.target

Enable autostart: `systemctl enable --now hysteria.service`. Check logs: `journalctl -u hysteria -f`.

Kernel network tuning

• net.core.rmem_max=67108864; net.core.wmem_max=67108864
• net.ipv4.udp_mem='262144 524288 1048576'
• net.ipv4.udp_rmem_min=4096; net.ipv4.udp_wmem_min=4096
• net.ipv4.ip_local_port_range='10000 65000'
• net.core.default_qdisc=fq (modern kernels)

Apply via sysctl.d and reload settings. Monitor system limits using `ss -u -a`, `ethtool -S`, `nstat`.

Masquerade: plausible response

• Type 'file': static files under '/var/www/masq' (simple site placeholder).
• Type 'proxy': reverse proxy to external site (don’t overload—it’s for realism, not traffic).

Verification

• UDP port: `nmap -sU -p 443 your_IP` should show open.
• QUIC packets: `tcpdump -ni any udp port 443` to confirm Initial and Handshake exchanges.
• Certificate: verify TLS 1.3 on QUIC port with tools or HTTP/3-enabled browser when masquerading.

Practice 3: Client setups (Desktop)

Option A: native 'hysteria' client

Basic client YAML example:

• server: 'your_domain:443'
• auth:
•   type: 'password'
•   password: 'S3cure-Long-Secret-Token'
• obfs:
•   type: 'salamander'
•   password: 'Another-Obfs-Secret'
• tls:
•   sni: 'your_domain'
•   insecure: false
• quic:
•   alpn: ['h3']
• bandwidth:
•   up: '20 Mbps'
•   down: '150 Mbps'
• socks5:
•   listen: '127.0.0.1:1080'
• http:
•   listen: '127.0.0.1:8080'

Run: `hysteria client -c client.yaml`. In browser, set local SOCKS5 proxy 127.0.0.1:1080 or HTTP proxy 127.0.0.1:8080.

Option B: sing-box (universal client)

Example JSON config with 'hysteria2' outbound and local SOCKS inbound. Single quotes shown for readability—replace with double quotes in real JSON:

• {
•  'inbounds': [ {'type':'socks','listen':'127.0.0.1','listen_port':1080} ],
•  'outbounds': [
•   { 'type':'hysteria2', 'server':'your_domain', 'server_port':443, 'password':'S3cure-Long-Secret-Token', 'obfs':'salamander', 'obfs-password':'Another-Obfs-Secret', 'tls':{'enabled':true,'server_name':'your_domain','alpn':['h3']}, 'udp_fragment':{'enabled':true,'length':1200,'interval':0}, 'multiplex':{'enabled':true,'max_streams':32} }
•  ]
• }

Run sing-box with this config and set local SOCKS proxy in apps. If MTU issues arise, reduce 'udp_fragment.length' to 1200 or even 1180.

Option C: v2rayN / Clash Meta / Nekoray

• Manually import Hysteria 2 profile: specify server, port, password, obfs 'salamander' and its password, SNI, enable ALPN 'h3' if supported by client.
• Set local SOCKS/HTTP proxy for apps or enable client TUN mode to capture all traffic.

Speed and stability tests

• Latency: `ping` to server (rough estimate), then real app latency.
• Packet loss: `mtr` to server without proxy and through tunnel (indirect check).
• Bandwidth: download large files, stream 1080p/4K video, parallel downloads; watch for stability not just peak speed.

Practice 4: Mobile clients and router

Android: v2rayNG and similar

• Create Hysteria 2 profile: server address, port 443, password, obfs 'salamander' with password, SNI as your domain, enable QUIC/HTTP3 options if available.
• Mode: choose TUN/VPN for system-wide interception or manual proxy setup per app.
• MTU: if pages stall, enable fragmentation or reduce datagram size to 1200.

iOS: Shadowrocket, FoXray, etc.

• Import Hysteria 2 config or fill fields manually. Ensure server cert validity; avoid insecure=true unless absolutely necessary.
• Bypass profiles: add exceptions for internal domains and local networks.

OpenWrt/router: transparent proxy

• Install sing-box on router, create hysteria2 outbound and TUN inbound.
• Route entire traffic through TUN, with exceptions for local subnets, NTP, firmware updates.
• Test on clients: stable YouTube 4K, messenger downloads, online games (check UDP modes).

Practice 5: Anti-DPI strategies and masking

Basic strategy

• UDP 443 port, valid public certificate, proper SNI.
• ALPN 'h3' if client supports it, masquerade as 'file' or 'proxy'.
• Obfs 'salamander' with password separate from main auth password.

Enhancements

• Rotate ports and passwords every 1–3 months.
• Duplicate entry points: main port 443 and backup (e.g., 8443/UDP) in client config.
• IPv6 + IPv4: an extra vector for selective blocking situations.
• Limit datagram size (1200) to reduce fragmentation patterns along the path.

Blockage response framework

1. Event: connection degradation or UDP 443 drops.
2. Diagnosis: UDP test on backup port; check server logs; capture pcap on entry.
3. Response: switch clients to backup port; change passwords; if needed, rotate SNI and domain.
4. Consolidation: update masquerade, strengthen MTU tuning, redistribute traffic between IPv4 and IPv6.

Practice 6: Performance and stability

Kernel and network tuning

• Increase rmem/wmem and UDP buffers according to load.
• Enable fq as default qdisc for smoother queue shaping.
• Check CPU governor—performance mode on busy instances reduces timer jitter.
• IRQ affinity and NUMA: assign network IRQs to dedicated cores under heavy load.

Client parameters

• Set realistic bandwidth up/down values; avoid overestimates.
• udp_fragment length: 1200 on difficult routes, 1250–1350 where safe (test accordingly).
• multiplex max_streams: 16–64 for web traffic, fewer for games/real-time use.

Observability

• Server logs: warning/info for production, debug temporarily for investigations.
• Selective pcap: filter UDP and port; watch packet sizes and intervals.
• System metrics: latency, loss, CPU, softirq, and NIC driver drops.

Practice 7: Operations, updates, and security

Operational checklist

• Auto-renewal of certs functioning; failure notifications enabled.
• Password rotation; revoke access promptly upon client compromise.
• Backup port and client profiles ready and tested.
• Logs exclude sensitive details; logs are rotated.

Updates

• Plan rolling restarts during low traffic periods.
• Keep backup binaries from previous versions.
• Compare config format changes with example on staging before production.

Security

• Minimal process permissions, separate user/group.
• Firewall default deny, whitelist only necessary ports.
• Monitor unusual UDP spikes or scanning activity.

Common mistakes and anti-patterns

• Invalid certificate or SNI: causes handshake failures and suspicious retries.
• Only TCP 443 open: forgetting UDP prevents client connection.
• Overestimated bandwidth: causes unstable speeds and drops under load.
• No masquerade: port gives “empty” responses attracting scanners.
• Same password for many clients: complicates access revocation and incident tracking.
• Too large MTU: stalls due to PMTU black holes, especially in mobile networks.
• Invalid server time: TLS errors and odd failures without clear cause.

Tools and resources

Administration and diagnostics

• tcpdump, Wireshark: targeted captures for checking QUIC Initial/Handshake and datagram sizes.
• nftables, iptables: rules for UDP ports and basic rate limiting.
• journalctl, systemd: service log management and viewing.
• iperf3 (UDP): rough throughput and loss estimation.
• mtr: combined traceroute plus loss analysis to server.

Client apps

• hysteria (client and server), sing-box (universal client with TUN), v2rayN, Nekoray, Clash Meta, mobile clients on Android and iOS.
• OpenWrt: sing-box as system service with TUN for entire network.

Practical alternative to self-hosting

If you want a quick and practical alternative to self-hosting, consider the vpn.how service as a solid option: personal VPN server with dedicated IP (not shared), significantly reducing mass blacklist risk; supports WireGuard, OpenVPN, IKEv2, L2TP, SSTP protocols—you can choose depending on your needs and network environment; locations in Moscow, Saint Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapore, Sydney, Madrid, Helsinki, Stockholm, Warsaw, Copenhagen, Stavanger; accepts Russian bank cards (including major banks), SBP, USDT/BTC; plans from ₽490 per day and ₽2490 monthly with discounts for long-term; server activates automatically within minutes after payment, no logs. DPI bypass benefits from stable protocols like WireGuard on non-standard ports or IKEv2 on 4500/UDP.

Use cases and results

Case 1: Mobile network with 2–5% packet loss

• Conditions: RTT 120–180 ms, 2–5% loss, basic TCP VPN delivers bursty 2–6 Mbps speeds.
• Hysteria 2: alpn 'h3', udp_fragment 1200, bandwidth up/down 10/80 Mbps.
• Result: steady 12–18 Mbps on three parallel downloads, smooth 1080p video, rare micro-stutters vanished.

Case 2: Corporate Wi-Fi with aggressive DPI

• Conditions: filtering of unusual TLS fingerprints, UDP blocked on most ports except UDP/443 open.
• Hysteria 2: valid certificate, masquerade 'file' with simple website, obfs 'salamander'.
• Result: stable tunnel, scanners see a "normal" UDP 443 with placeholder site; average 30–40 Mbps during work hours.

Case 3: Home router with OpenWrt

• Conditions: provider intermittently limits UDP peaks, IPv6 available.
• Solution: sing-box on router, hysteria2 outbound, TUN inbound for whole network, backup port 8443.
• Result: stable 4K video, UDP-based games more predictable, lower latency and jitter versus TCP VPN.

FAQ

1) Is Hysteria 2 HTTP/3 or a “custom” QUIC?

Hysteria 2 uses QUIC and TLS 1.3; some clients allow ALPN 'h3' for disguising as HTTP/3. The tunnel’s logic is proprietary, not a full HTTP/3 proxy implementation.

2) Is UDP port 443 mandatory?

No, but UDP 443 improves plausibility. Keep backup ports for selective UDP 443 blocks. Test specifically in your network environment.

3) Can I use a self-signed certificate?

Technically yes, with clients set to insecure mode. Practically, it lowers masking quality and raises detection risk. A valid public certificate is recommended.

4) What about ECH and hiding SNI?

ECH is still limited and complex to integrate with arbitrary tunnels. Consider SNI visible; use neutral domains and proper masquerade content.

5) Is Hysteria 2 suitable for gaming?

Depends on the game. For TCP-based traffic, Hysteria 2 helps with loss and jitter. For raw UDP peer-to-peer games, using UDP proxy modes on clients/apps helps, but not all clients support it directly.

6) Is there TCP fallback?

Hysteria 2 lacks native TCP mode. Implement fallback at client level: alternate profile (WireGuard/IKEv2/OpenVPN) or separate transport. Always have a “plan B”.

7) Can server be behind a reverse proxy?

UDP proxying is more complex than TCP. Some QUIC proxy solutions exist, but it’s simpler and more reliable to listen directly on the UDP port. Use built-in masquerade features for appearance.

8) Why is speed below expectations?

Common causes: overestimated bandwidth hints, small system buffers, PMTU issues, UDP restrictions from provider. Lower MTU to 1200, increase buffers, check backup ports.

9) Is multi-user access supported?

Yes, via shared or separate passwords. For management, it’s better to assign distinct passwords per group/user and track usage.

10) Is IPv6 necessary?

Recommended. Dual stack improves resilience: if one stack degrades or is filtered, the other may stay functional.

Conclusion

Hysteria 2 is a mature, practical QUIC transport built for the era of aggressive blocking and unstable networks. It launches quickly, handles losses well, naturally disguises as familiar traffic with correct TLS and ALPN setup, and offers admins clear levers of control: pre-handshake obfs, masquerade, bandwidth hints, MTU control, and multiplexing. We’ve covered architecture, differences from Hysteria 1, server and client configurations, tuning, anti-DPI strategies, common pitfalls, and real results. Now it’s your turn. Build a minimal test setup, follow the design and operational checklists, capture a few pcaps, open backup ports, rotate secrets, and test for several days under real load. Robust connectivity isn’t a point—it’s a process. With Hysteria 2, that process becomes more transparent and manageable.