ShadowTLS VPS Setup: Disguise Proxy Traffic as Genuine TLS

Most encrypted proxies leak a fingerprint. A raw Shadowsocks connection is high-entropy from the very first byte, with no TLS handshake in front of it, and modern DPI systems flag that statistical signature even though they cannot read the payload. ShadowTLS solves this by making your connection begin with a genuine TLS 1.3 handshake to a real, well-known website — the "donor" or "handshake server". To a censor on the wire, the connection looks exactly like a browser opening HTTPS to that popular domain, because for the first round-trips it literally is.

Here is the mechanism in plain terms. Your ShadowTLS client opens a TLS connection whose SNI points at the donor (say a large CDN-hosted site). The ShadowTLS server on your VPS proxies that handshake straight through to the real donor and relays the donor's authentic ServerHello, Certificate, and CertificateVerify back to you. The certificate is real and chains to a public CA, so it survives any certificate inspection. Authentication is carried invisibly: the client embeds an HMAC of the ClientHello, keyed by your shared password, inside the 32-byte TLS SessionID. Only your server can verify it.

Once the handshake completes and the client sends its Finished message, ShadowTLS stops relaying the donor and switches the same TCP stream over to your real Shadowsocks data. From that point both directions carry application data frames prefixed with a 4-byte HMAC derived from the server random, which prevents tampering, reordering, and replay. Version 3 (the current protocol) is the one to use: it added HMAC "tainting" of the relayed handshake frames and proper challenge binding, closing the replay and traffic-hijack weaknesses that researchers found in v1 and v2.

ShadowTLS only delivers its privacy and unblockability properties when you hold the server. A commercial "ShadowTLS VPN" reintroduces exactly the third party you were trying to remove: someone who can see your real destination after the proxy decrypts it, and who can be compelled to log or hand over data. Self-hosting on a VPS with full root access means the only entity that ever sees your decrypted traffic is you.

Two things make a VPS suitable for this. First, jurisdiction: an offshore location outside the 14-Eyes intelligence-sharing arrangements, with no VPS-level data-retention mandate, removes the easy legal lever a censor or investigator would otherwise pull. Romania and Iceland both qualify and have strong connectivity toward Western Europe and the CIS region, which keeps latency tolerable for users behind aggressive DPI. Second, a clean, dedicated static IPv4: shared or "residential-recycled" IPs are far more likely to be on a censor's blocklist before you even start. Our offshore VPS plans ship with full root, a clean static IPv4, and a 1 Gbps uplink, which is the right foundation for a camouflage proxy.

For higher concurrency — serving a family, a newsroom, or a small community rather than just yourself — the handshake relaying and per-frame HMAC do add CPU work under load. A 1 vCPU plan comfortably serves a handful of clients; for dozens of simultaneous heavy users, step up to a multi-core plan or a dedicated offshore server so the TLS relay never becomes the bottleneck.

The cleanest deployment runs ShadowTLS as the public-facing front end and Shadowsocks-2022 as the backend on localhost. ShadowTLS is the reference Rust implementation (ihciah/shadow-tls); the same protocol is also built into sing-box and Xray cores if you prefer a single binary. Start on any plan with at least 1 vCPU and 512 MB RAM, connect as root, and update the system.

1. Install a Shadowsocks-2022 server bound to localhost. Pick the AEAD-2022 cipher 2022-blake3-aes-128-gcm and generate a base64 key:

openssl rand -base64 16   # use this as the SS-2022 password
ss-server -s 127.0.0.1 -p 8388 \
  -m 2022-blake3-aes-128-gcm -k <BASE64_KEY>

2. Install ShadowTLS in front of it. Choose a donor that genuinely supports TLS 1.3, is not your own brand, and is unlikely to be blocked where your users are. The server listens on 443, authenticates with your shared password, forwards verified clients to the local Shadowsocks port, and forwards everyone else to the real donor:

shadow-tls --v3 server \
  --listen 0.0.0.0:443 \
  --server 127.0.0.1:8388 \
  --tls cdn.example.com:443 \
  --password <SHADOWTLS_PASSWORD>

3. On the client, the two layers mirror the server. Point ShadowTLS at your.vps.ip:443 with the same SNI and ShadowTLS password, then point your Shadowsocks-2022 client at ShadowTLS's local listen port using the SS-2022 cipher and key. In sing-box this is a single outbound with a shadowtls wrapper around a shadowsocks dialer — set version: 3, the handshake.server SNI, and matching passwords.

4. Run both as systemd services with Restart=always so they survive reboots, and keep the Shadowsocks port bound to 127.0.0.1 so it is never reachable from the internet directly — only ShadowTLS should be able to reach it.

The headline defense is automatic. When a censor's prober connects to your port 443, it cannot produce the correct HMAC in the SessionID because it does not know your ShadowTLS password. Your server therefore treats it as a probe and transparently TCP-forwards the whole connection to the real donor. The prober receives the donor's genuine certificate and content and concludes your VPS is just a mirror or front for that legitimate site — there is no separate response that distinguishes you from a normal host. That is what makes ShadowTLS v3 robust where older TLS-obfuscation tricks failed.

You still have to avoid operator mistakes that re-expose you:

• Choose the donor carefully. It must serve TLS 1.3, ideally be on a CDN so its IP set is huge and innocuous, and crucially must not be a site that obviously has nothing to do with your VPS's IP range or rDNS. A mismatch between your IP's apparent owner and the claimed SNI is the kind of anomaly a sophisticated censor correlates.
• Never reuse the donor's real domain on your own host. ShadowTLS relays the donor; it does not impersonate a certificate you control. Do not put a self-signed or mismatched cert in front.
• Use Shadowsocks-2022, not the legacy AEAD ciphers. SS-2022 adds replay protection and stronger key derivation; older chacha20-ietf-poly1305 Shadowsocks is more replay-prone behind a camouflage layer.
• Lock the firewall down. Allow inbound only on 443 (ShadowTLS) and your SSH port; reject everything else. Keep SSH key-only, on a non-standard port, with fail2ban watching auth failures.
• Rotate the password if a client device is lost. Both the ShadowTLS password and the SS-2022 key are shared secrets; treat them like VPN credentials.

Done correctly, an observer sees a normal TLS 1.3 session to a popular site, an active prober sees that same legitimate site, and only a client holding your password ever crosses over into the Shadowsocks tunnel.