Skip to main content

Protocol guide

What is Hysteria2? QUIC setup, configuration and safety

Hysteria2 is a TCP and UDP proxy built on QUIC. It needs working UDP, valid TLS parameters and authentication, so a normal TCP port scan cannot determine whether a server is usable.

Illuminated fiber optic strands representing fast Hysteria2 network transport

Quick facts

UDP with QUIC and TLSTransport
Password or server-defined authenticationAuthentication
hy2:// or hysteria2:// linkConfiguration

Hysteria2 in plain English

A Hysteria2 client establishes a QUIC connection protected by TLS and carries proxied TCP or UDP traffic inside it. QUIC runs over UDP and handles streams, loss and congestion differently from a TCP-based proxy. Optional obfuscation and bandwidth settings are deployment-specific.

Important: encryption protects traffic between the client and endpoint, but it does not make an unknown public operator trustworthy.

How Hysteria2 works

  1. The client reaches the server over UDP.
  2. QUIC and TLS establish an encrypted authenticated connection.
  3. Hysteria2 authentication is checked by the server.
  4. TCP or UDP proxy requests travel through QUIC streams or datagrams.

Configuration fields that must be complete

FieldWhy it matters
Server and UDP portDestination for the QUIC connection.
AuthenticationPassword or other server-selected credential.
SNI and certificate policyTLS identity and validation settings.
Obfuscation and bandwidthOptional parameters that must match the deployment.

PublicVPNList publishes a download only when the exact configuration is still present in an allowed, publication-compatible source and its fresh full-tunnel check succeeds.

Strengths

  • Carries TCP and UDP over a modern QUIC transport.
  • Designed to remain responsive on lossy or variable networks.
  • Supports standard TLS certificate validation.

Limits and risks

  • Networks that block or heavily throttle UDP can prevent connection.
  • Disabling certificate validation removes an important identity check.
  • Performance claims depend on the network and cannot be inferred from the protocol name.

Safe setup and verification

  1. Use a maintained client that explicitly supports Hysteria2.
  2. Inspect the server, transport, identity and authentication fields before importing.
  3. Keep certificate and server-identity validation enabled where the protocol supports it.
  4. Connect without opening sensitive accounts, then verify the visible IP and DNS path.
  5. Disconnect and remove stale public profiles after low-risk testing.

Common connection problems

  • Test UDP access to the exact port from the current network.
  • Check SNI, certificate validity and device time.
  • Copy authentication and obfuscation settings exactly.
  • Use a full HTTPS and exit-IP test after the tunnel starts.

A client “connected” indicator is not enough. A valid test must send real HTTPS traffic through the protocol and confirm that the public exit IP changed.

Official technical reference

For field semantics and protocol behavior, consult the Hysteria 2 protocol documentation. PublicVPNList adds operational testing and publication policy; it does not replace the specification.

Related protocol guides

Frequently asked questions

Is Hysteria2 a VPN?
Hysteria2 is primarily a proxy protocol. It becomes a full-device path only when a compatible client routes all traffic through a TUN or VPN interface.
What does a usable Hysteria2 profile need?
It needs all endpoint, authentication, transport and security fields required by the server. A hostname and open port alone are not a downloadable working configuration.
How does PublicVPNList verify Hysteria2 endpoints?
The checker starts the real protocol client in an isolated VM, sends HTTPS through the tunnel and requires the observed public exit IP to differ from the direct checker IP.
Is a checked public endpoint safe for sensitive accounts?
No technical connectivity test can verify the operator, logging policy or jurisdiction. Avoid banking, private work and identity-sensitive sessions on unknown public infrastructure.

Page history

  • 2026-08-31 — Published the protocol overview, configuration requirements, troubleshooting guidance, safety notes and PublicVPNList verification policy.