Sing-box VPS Setup: One Core for VLESS-Reality, Hysteria2 and TUIC

The censorship-circumvention stack used to mean running several programs at once: one for VMess/VLESS, another for Hysteria, a third for TUIC, each with its own config format, service file and update cycle. Sing-box collapses all of that into one statically linked binary with a single JSON config and a unified routing engine.

• One process, many protocols. A single inbounds array can expose VLESS-Reality on 443, Hysteria2 on a UDP port and TUIC on another, all routed through one set of rules.
• Reality built in. Sing-box ships native Reality support, so you do not need an Xray sidecar to defeat active probing - the TLS handshake of a real website is borrowed without owning that site's certificate.
• QUIC done right. Hysteria2 and TUIC ride on UDP/QUIC, which behaves like ordinary HTTP/3 traffic and recovers far better than TCP on lossy international links - the exact conditions a user behind a national firewall faces.
• Same binary on both ends. Server and client run identical code, so a config that works in your terminal works in the GUI clients (sing-box, NekoBox, Hiddify) without translation.

The result is one service to harden, one config to audit and one binary to update - a smaller attack surface and far less that can silently break. For the underlying server you want a host that will not fold to an upstream takedown the moment your endpoint is noticed; an offshore VPS with root access and crypto checkout is the natural base layer.

Start from a clean Debian 12 or Ubuntu 22.04+ VPS with root. The official installer detects your CPU architecture and drops a systemd unit in place:

bash <(curl -fsSL https://sing-box.app/install.sh)

Confirm the binary and check the version - you want the latest stable, since Reality and Hysteria2 are still evolving:

sing-box version

The package leaves an empty config at /etc/sing-box/config.json and a service named sing-box. Before writing the real config, generate the cryptographic material the protocols need. Reality requires an x25519 keypair, and every VLESS/TUIC client needs a UUID:

sing-box generate reality-keypair
sing-box generate uuid
sing-box generate rand --base64 8   # short_id for Reality

Keep the private key on the server only; the matching public key goes into each client. Open the ports you intend to use in the firewall (here 443/TCP for Reality and 8443/UDP for Hysteria2 and TUIC), then validate before you ever start the service:

sing-box check -c /etc/sing-box/config.json
systemctl enable --now sing-box
journalctl -u sing-box -f

Running check first means a typo fails loudly in the terminal instead of leaving you with a dead endpoint and no clue why. Tail the journal on first start to confirm each inbound binds without error.

Active probing is how a national firewall confirms a suspicious server: it connects to your port, speaks a little TLS, and watches how you answer. A naive proxy answers in a way no real web server would, and the IP gets blocked. Reality defeats this by relaying the initial TLS handshake to a genuine, popular HTTPS site - so a probe sees that site's real certificate and behaviour, while authorised clients with the correct key get tunnelled instead.

{
  "inbounds": [{
    "type": "vless",
    "listen": "::",
    "listen_port": 443,
    "users": [{ "uuid": "YOUR-UUID", "flow": "xtls-rprx-vision" }],
    "tls": {
      "enabled": true,
      "server_name": "www.cloudflare.com",
      "reality": {
        "enabled": true,
        "handshake": { "server": "www.cloudflare.com", "server_port": 443 },
        "private_key": "YOUR-REALITY-PRIVATE-KEY",
        "short_id": ["YOUR-SHORT-ID"]
      }
    }
  }]
}

The two rules that matter most for survival:

• Pick a real handshake target that is reachable from inside the censored network and not itself blocked. The server_name and handshake.server should match a large CDN-fronted domain whose TLS fingerprint is unremarkable. If the target is blocked locally, your camouflage points at a wall and stands out.
• Use flow: xtls-rprx-vision. Vision flow shapes packet timing and sizes so the encrypted stream does not betray the tell-tale fixed-length records that classifiers flag.

Because Reality borrows a real handshake, there is no Let's Encrypt certificate to renew and no domain to register against your endpoint - one less paper trail. Pair it with a clean IP: a fresh, dedicated address from an offshore dedicated server or a low-reputation-risk VPS avoids the collateral blocking that hits recycled, already-flagged ranges.

Reality on TCP/443 is a strong default, but UDP-based QUIC protocols often punch through when TCP is throttled or RST-injected. Sing-box lets you add them as extra inbounds in the same file - no second daemon.

Hysteria2 runs over QUIC with a built-in congestion controller (Brutal) that ignores the artificial packet loss censors use to slow tunnels. It needs a TLS certificate; a self-signed one plus insecure on the client works, or use a real cert if you have a domain:

{
  "type": "hysteria2",
  "listen": "::",
  "listen_port": 8443,
  "users": [{ "password": "YOUR-STRONG-PASSWORD" }],
  "tls": {
    "enabled": true,
    "alpn": ["h3"],
    "certificate_path": "/etc/sing-box/cert.pem",
    "key_path": "/etc/sing-box/key.pem"
  }
}

TUIC v5 is the lighter QUIC option - low handshake overhead and good multiplexing, useful on mobile networks that drop idle connections. ShadowTLS v3 is a different tactic: it wraps Shadowsocks traffic behind a real TLS handshake to a chosen domain, so on the wire it looks like an HTTPS visit to that site, while resisting the probing that plain Shadowsocks fails.

Running all four lets a client fail over: if 443 Reality is interfered with, the app silently switches to Hysteria2 or TUIC on UDP. Keep each protocol on its own port, give every user a distinct UUID or password so you can revoke one without churning the rest, and rate-limit nothing at the firewall that would make your QUIC ports behave unlike normal HTTP/3. A VPS with unmetered or high bandwidth matters here - Hysteria2's aggressive congestion control will happily saturate the link, and you do not want overage fees on a tunnel you use daily.

A circumvention endpoint that gets discovered is worse than useless - it can taint the whole IP range. A few operational habits keep yours quiet:

• Lock SSH down first. Key-only auth, a non-default port and a firewall that exposes only your proxy ports plus SSH. The proxy is the only thing the internet should be able to reach.
• Do not co-host a website on the same IP. If your Reality target is www.cloudflare.com but your IP also serves a half-built nginx page, the mismatch is a giveaway. Keep the box single-purpose.
• Run as a non-root service user and keep sing-box updated; Reality and Hysteria2 fingerprints shift as detection improves, and an old binary is an old, classifiable signature.
• Watch the journal, not a dashboard. Heavy logging is itself a liability if the box is ever seized; sing-box can run with minimal log level, and you should resist adding analytics that record who connected when.
• Rotate UUIDs and the Reality short_id if you ever suspect a config leaked through a shared client export.

The protocol layer is only as resilient as the host under it. The reason to run sing-box on an offshore VPS rather than a mainstream cloud provider is jurisdiction and payment: anonymous crypto checkout, no KYC, full root, and a host that will not pull your server on the first automated complaint. Start small - a single low-cost VPS comfortably runs all four protocols for personal use - and scale to a dedicated IP only when you need clean reputation for a wider group.