Self-host Hysteria 2 on Netcup — a fast QUIC proxy on a 10 € VPS

Self-host Hysteria 2 on a Netcup VPS to run a fast, censorship-resistant QUIC proxy that masquerades as plain HTTP/3 web traffic. Hysteria is a single-binary Go application that speaks a customised QUIC variant over UDP, ships its own Brutal congestion controller for hostile networks, and is small enough to idle at under 50 MB of RAM. A 10 € Netcup VPS gives it the CPU and the symmetric European bandwidth it actually needs.

TL;DR: Running Hysteria 2 on Netcup in 5 minutes

Hysteria 2 is the current major version of the Hysteria proxy, released as app/v2.9.1 on 10 May 2026 under MIT. The server is a 20-something-megabyte Go binary that listens on UDP (default :443), terminates a QUIC connection from the client, and forwards traffic through SOCKS5, HTTP proxy, TCP/UDP forwarding, Linux TProxy, or TUN. The masquerade feature makes the server respond to non-Hysteria HTTPS requests as if it were a regular web server — which is how it survives deep packet inspection on hostile networks.

• What it is: a QUIC-based proxy and VPN designed for lossy, throttled, or DPI-filtered networks.
• What it competes with: WireGuard, OpenVPN, Xray/V2Ray, TUIC, sing-box, Shadowsocks.
• Hosting profile: 30–150 MB RAM idle, network-bound under load, CPU-bound at gigabit-plus throughput because QUIC runs in userspace.
• Default port: UDP 443, deliberately picked to look like a normal HTTP/3 web server.
• Persistence: a single YAML file at /etc/hysteria/config.yaml and the ACME certificate cache. No database.
• License: MIT, no telemetry, no managed-tier upsell.

bash <(curl -fsSL https://get.hy2.sh/)
# edit /etc/hysteria/config.yaml
systemctl enable --now hysteria-server.service
journalctl --no-pager -e -u hysteria-server.service

Primary pick: VPS 1000 G12 — 4 vCPU, 8 GB RAM, 256 GB NVMe, around 10.37 €/month. The extra vCPUs matter: QUIC's userspace AEAD plus the Brutal controller is CPU-heavy at high throughput, and the smaller tier runs out of headroom before the network does.

• First month free: 5799nc17774618550
• Second code: 5799nc17800061380
• Third code: 5799nc17804382700

Introduction

Most teams pick WireGuard for a personal VPN because it's in-kernel, small, and well-understood. It also gets blocked, throttled, or fingerprinted the moment your network adversary cares enough to look — WireGuard handshakes have a recognisable pattern, the protocol does not pretend to be anything else, and UDP traffic on non-standard ports is the first thing a meddling middlebox flags. Self-hosted Hysteria sidesteps that fight entirely: the proxy speaks QUIC on UDP 443, the same port and same transport as every HTTP/3 site the user already visits, and serves a plausible HTTP page to anything that doesn't carry a valid auth token.

The trade-off is that Hysteria is not a router-level VPN replacement. It's a client-launched proxy — you run a Hysteria client app on each device, point your traffic at it, and it tunnels out through your VPS. For day-to-day usage that's fine; for whole-home routing you can pair Hysteria with a TUN-mode client on a Linux box and forward selectively. This article walks through the server side end-to-end.

Netcup fits this workload well for three concrete reasons. The data centres are in Nuremberg and Vienna on owned hardware, which keeps latency to most EU clients under 30 ms. The cheapest tier already ships NVMe storage and a real IPv4 — no surprise upsells for IO or addressing. And the included traffic allowance on every VPS G12 tier is generous enough that you will not see a network bill from a personal proxy unless something is very wrong.

What you'll get by the end: a Hysteria 2 server running behind a Let's Encrypt certificate on UDP 443, a config file that masquerades as a real HTTPS site, a systemd service that survives reboots, and a clear answer to which Netcup tier matches your bandwidth and user count.

What is Hysteria?

Hysteria is an open-source proxy written in Go on top of a customised QUIC stack. It runs as a single statically-linked binary in both server and client modes, uses the same wire protocol in both directions, and is distributed under the MIT licence. The current major version is Hysteria 2, with the previous Hysteria 1 series no longer recommended for new deployments — the protocol changed incompatibly between the two, and the v1 docs are kept around purely as reference.

The project sits in the same problem space as Xray/V2Ray, TUIC, sing-box, Shadowsocks, and WireGuard with a custom obfs layer. Compared to those, Hysteria's distinguishing decisions are: it commits hard to QUIC instead of trying to support every transport; it ships a custom Brutal congestion controller alongside BBR and Reno; it includes a built-in HTTP/3 masquerade so the server gracefully degrades into a fake web server for non-authenticated probes; and it exposes a port-hopping mode that automatically distributes traffic across a range of UDP ports to dodge stateful UDP throttling.

Architecture

A Hysteria deployment is a Go binary plus a YAML config. There is no database, no Redis dependency, no message queue. On Linux, the official installation script drops the binary at /usr/local/bin/hysteria, the config at /etc/hysteria/config.yaml, and a systemd unit called hysteria-server.service. The server runs as a dedicated hysteria system user by default — the script makes a policy choice you can override at install time with HYSTERIA_USER=root if you need raw-socket privileges for the TPROXY or TUN modes.

The wire protocol is QUIC over UDP. The server listens on a single UDP port (default :443), authenticates the client with a shared password (or one of several pluggable schemes: userpass, an HTTP callout, or a command), then forwards individual streams as TCP or UDP. There is no TLS handshake leaking distinguishing features — QUIC's TLS is encapsulated inside the QUIC handshake, and Hysteria's masquerade ensures that probes which don't authenticate get a normal-looking HTTPS response.

Modes

The server is the same binary regardless of where the traffic ends up. The client decides — socks5, http, tcpForwarding, udpForwarding, tun, and on Linux tproxy are all available. Most desktop users run the client in SOCKS5 mode and configure their browser or system proxy. Power users run it in TUN mode, which creates a virtual interface and routes packets transparently. There is no server-side toggle for this; the server forwards whatever the client asks it to.

Who maintains it

Hysteria is maintained by apernet (Aperture Internet Laboratory) on GitHub. The project moves fast — the v2 series saw nine point releases in the year leading up to v2.9.1 (10 May 2026), with the changelog dominated by congestion-controller tuning, masquerade improvements, and the recent Realms rendezvous feature that allows running a Hysteria server behind NAT without a public IP. The codebase is 92% Go, with the rest split between a handful of build scripts and the small extras package that holds the Brutal controller implementation.

How to use Hysteria

Core concepts

You only need to internalise four ideas to be productive with self-hosted Hysteria:

• listen — the address and UDP port the server binds. Default :443. Can be a single port (:443), a range for port hopping (:20000-50000), or a realm:// URI for NAT-traversal mode.
• tls vs acme — pick one. tls points at a cert and key on disk; acme lets the server fetch a Let's Encrypt certificate itself, given a public domain pointed at the box.
• masquerade — what the server returns to anyone who shows up without a valid Hysteria auth token. The two useful values in practice are proxy (reverse-proxy a real upstream) and string (serve a fixed HTML body). Either way the server stops looking like a proxy to a casual prober.
• auth — the password (or a more elaborate scheme). The simplest case is auth: { type: password, password: <random-string> }.

Optional but worth knowing: bandwidth (server-side caps that turn into client-side hints for the Brutal controller), acl (per-rule outbound routing — block ads, route some domains through a different exit), trafficStats (an HTTP API for per-user accounting), and obfs (Salamander, an additional obfuscation layer for adversaries that specifically target QUIC).

Day-to-day workflow

The server is fire-and-forget. You install it, write the config, enable the systemd service, and never touch it again until you change auth or the certificate path. Client setup happens in one of the many GUI applications that speak Hysteria 2 — sing-box, NekoBox, NekoRay, V2RayN, Hiddify, plus the official CLI client. Each takes either a hysteria2:// URI (which encodes server, password, and optional SNI) or an equivalent YAML file. There's nothing to keep in sync between server and client beyond the URI.

What you do periodically: check journalctl -u hysteria-server.service for ACME renewal events, watch the trafficStats API if you run multi-user, and bump the binary when a new release drops. The installer script handles upgrades — re-run bash <(curl -fsSL https://get.hy2.sh/) and it pulls the latest tag in place.

Integrations and extensibility

The server has two extension points worth mentioning. The first is the outbound system — you can declare named outbounds (direct, a SOCKS5 upstream, an HTTP proxy upstream) and route traffic to them via ACL rules. This lets you chain Hysteria behind another proxy for jurisdictional reasons, or send Netflix traffic through a residential exit while everything else goes direct. The second is authentication callouts — auth.type: http makes the server hit a URL you control for every connection attempt, which is how you'd integrate Hysteria with an existing user database or billing system.

Backup and operational reality

There are two files worth backing up: /etc/hysteria/config.yaml and the ACME certificate cache (default /var/lib/hysteria/.cache/). Lose either and you lose either your auth or your TLS state — both recoverable, both annoying. There is no SQLite, no state directory full of growing logs, no plugin store. Storage footprint of the server itself is a few tens of megabytes for the binary and the cert.

Quick Start Guide

This walkthrough assumes a fresh Debian 12 (or Ubuntu 24.04) VPS, a domain you control, and a client device. Replace proxy.example.com and your-strong-password with your real values.

1. Provision the box

Sign up for the VPS 1000 G12 at netcup.com and apply coupon 5799nc17800061382 for one free month. Drop your SSH public key in during creation. Once it's up, SSH in and lock down the daemon:

# /etc/ssh/sshd_config.d/00-hardening.conf
PasswordAuthentication no
PermitRootLogin prohibit-password

systemctl reload ssh

A Hysteria deployment puts a real UDP daemon on the public internet on port 443. The login surface is the only other thing exposed — keep it minimal.

2. Point a domain at the VPS

Add an A record (and an AAAA if you have IPv6) for proxy.example.com pointing at the VPS's address. Wait long enough for the record to propagate before continuing — dig +short proxy.example.com should return the VPS's IPv4 from a machine outside your network. ACME will fail loudly if the domain doesn't resolve to the box.

3. Install Hysteria

The project ships an installer that handles binary download, the dedicated hysteria system user, the systemd unit, and an example config:

bash <(curl -fsSL https://get.hy2.sh/)

Verify the install:

hysteria version
systemctl status hysteria-server.service

The service will be inactive (dead) until you write a real config — that's expected.

4. Write the server config

Replace the example with a minimal but production-shaped config. The masquerade block is what makes the server return a plain web page to anyone who isn't a real client.

# /etc/hysteria/config.yaml
listen: :443

acme:
  domains:
    - proxy.example.com
  email: [email protected]

auth:
  type: password
  password: your-strong-password

bandwidth:
  up: 200 mbps
  down: 1 gbps

masquerade:
  type: proxy
  proxy:
    url: https://news.ycombinator.com/
    rewriteHost: true

Generate a strong password with openssl rand -base64 32 and paste it in. The bandwidth values are hints for the client-side Brutal controller — set them at or slightly below your actual VPS link speed; setting them higher than reality causes the controller to push past what the network can absorb and degrades the connection.

5. Open the firewall and start the service

If you run ufw or nftables, allow inbound UDP 443. The Netcup VPS itself does not run a host firewall by default, but the box you provision may have one if you installed a panel image.

ufw allow 443/udp
systemctl restart hysteria-server.service
journalctl --no-pager -e -u hysteria-server.service

The log should show an ACME success ("certificate obtained") within a minute. If it doesn't, fix DNS first — every other failure mode is downstream of that one.

6. Configure a client

On the device side, install one of the Hysteria 2 clients and feed it a connection URI:

hysteria2://[email protected]:443/?sni=proxy.example.com

For SOCKS5 mode, the CLI client takes a YAML file:

# ~/.config/hysteria/client.yaml
server: proxy.example.com:443
auth: your-strong-password
bandwidth:
  up: 50 mbps
  down: 200 mbps
socks5:
  listen: 127.0.0.1:1080

hysteria client -c ~/.config/hysteria/client.yaml

Point your browser at socks5://127.0.0.1:1080 and visit a what-is-my-ip site. The IP should be the VPS.

7. Optional — enable port hopping

If you're proxying through a network that throttles or blocks persistent UDP on a single port, switch the server to a range and the client follows:

listen: :20000-50000

On Linux the server installs the redirection nftables rules automatically — no manual iptables work needed. The Hysteria binary needs CAP_NET_ADMIN for this, which the systemd unit already grants. In the client URI, encode the range:

hysteria2://[email protected]:20000-50000/?sni=proxy.example.com

The client rotates between random ports inside the range at a configurable interval, defaulting to 30 seconds.

Choosing the Right Netcup Server for cheap Hysteria hosting

Hysteria is unusually well-behaved on small hardware — at idle, the server uses under 50 MB of RAM and effectively no CPU. The constraint that actually matters is QUIC's userspace cipher path: every byte that flows through the proxy gets AEAD'd in Go, and at gigabit-plus throughput a shared vCPU can become the bottleneck before the network does. Pick the tier that matches the bandwidth you expect to sustain, not the user count.

VPS 500 G12 — thrifty pick for a personal proxy

Specs: 2 vCPU, 4 GB RAM, 128 GB NVMe, traffic included. Around 5.91 €/month (verify on netcup.com).

Plenty for one or two users running normal browsing through SOCKS5. The 4 GB of RAM is overkill — Hysteria will use a fraction of that — but the 2 vCPUs cap sustained throughput around 300–500 Mbps under the Brutal controller. If you only ever push a few hundred kilobits of mobile traffic, this tier is the right call.

There is no dedicated VPS 500 coupon category, so the available discount is the general €5-off-any-order coupon:

• 36nc17718015542
• 36nc17718015546
• 36nc17718015547

VPS 1000 G12 — recommended for most Hysteria deployments

Specs: 4 vCPU, 8 GB RAM, 256 GB NVMe, traffic included. Around 10.37 €/month (verify on netcup.com).

The sweet spot. Four vCPUs give the QUIC encryption path real room — sustained throughput sits around 800 Mbps to 1 Gbps for a single client with Brutal pushing hard, and the box has headroom for a half-dozen concurrent users without contention. 256 GB of NVMe is irrelevant for Hysteria itself but useful for the other things you'll inevitably put on the box (a reverse proxy, a small *arr stack, a mail relay).

Coupons (each pops a different code at build time):

• 5799nc17718015261
• 5799nc17800061381
• 5799nc17774618550

VPS 2000 G12 — multi-user or high-bandwidth

Specs: 8 vCPU, 16 GB RAM, 512 GB NVMe, traffic included. Around 19.25 €/month (verify on netcup.com).

Step up here if you're running Hysteria for a small team, a family, or a handful of devices that each do video calls and bulk transfers. The extra cores keep QUIC's AEAD path from queueing on a single vCPU when several users are concurrently downloading at full speed. Worth it for power users; overkill for one laptop and a phone.

• 5800nc17802654091
• 5800nc17718015232
• 5800nc17718015233

RS 1000 G12 — dedicated cores for predictable latency

Specs: 4 dedicated AMD EPYC 9645 (Zen 5) cores, 8 GB ECC DDR5 RAM, 256 GB NVMe. Around 12.79 €/month (verify on netcup.com).

A few euros above the VPS 1000 G12 but with guaranteed cores. For a Hysteria deployment, that mostly matters if you care about jitter — shared vCPUs can stall briefly when a neighbour spikes, which shows up as latency variance in real-time apps over the proxy. The RS line eliminates that class of stutter. Also the right pick if you intend to lean on the Brutal controller for sustained pushed-hard throughput, since brutal needs predictable CPU to behave well.

• 5159nc17718015444
• 5159nc17718015440
• 5997nc17800061380

Comparison at a glance

If you're trying Hysteria for the first time and you only need it on one or two devices, VPS 500 G12 is enough — you'll know within a week whether the box is throttling, and upgrading on Netcup is a one-click affair. If you're putting Hysteria in front of a household or a small team, the VPS 1000 G12 is the right starting point and you should not feel any need to go bigger until somebody complains. If you're running it for sustained video calls, gaming, or a few paying customers, jump to either VPS 2000 G12 (more aggregate cores) or RS 1000 G12 (more predictable cores) depending on whether you care more about throughput or jitter.

Conclusion

You now have Hysteria 2 running on Netcup: a single Go binary terminating QUIC on UDP 443, masquerading as an HTTPS site to anyone who shows up without a token, ACME-managed certificate, optional port hopping, and a client-side SOCKS5 endpoint your devices can point at. The total monthly cost on the recommended path is 10.37 € for the VPS 1000 G12 (less your first month with the coupon above, plus a euro or two off your next order with 36nc17718015541). For a censorship-resistant proxy under your own legal and operational control, that compares well against anything you'd rent.

Three things to keep an eye on over the next month. Watch journalctl -u hysteria-server.service once a week — ACME renewals run quietly and the only signal something has gone wrong is in the log. Watch your traffic graph in the Netcup customer panel — included traffic is generous, but a misbehaving client (or one of the more aggressive Brutal upload settings paired with a chatty backup tool) can chew through gigabytes faster than you'd think. And re-run the installer when v2.10.x lands — Hysteria's release cadence is brisk and the bugfix notes are usually worth applying.