Cloak Pluggable Transport on a VPS: Domain-Fronted Proxy Setup

Cloak (the ck-server / ck-client project by cbeuw) is not a proxy by itself. It is an obfuscation layer that sits in front of an existing proxy such as Shadowsocks, OpenVPN, or any TCP/UDP service, and makes the encrypted tunnel look like a legitimate TLS conversation with a real website. The threat model it solves is the one that gets plain Shadowsocks blocked: modern censorship systems no longer just match on ports or known signatures, they actively probe suspicious endpoints. A censor's automated prober opens a connection to your server, and if the server responds in a way that does not look like the website it claims to be, the IP is flagged and blocked.

Cloak defeats this with three mechanisms working together. First, every Cloak session begins with a forged TLS ClientHello/ServerHello exchange that mimics a real browser handshake, so passive deep packet inspection sees ordinary TLS 1.3. Second, the server is steganographically authenticated: legitimate clients embed a cryptographic token inside the ClientHello that only the server can recognize, using the operator's public key. A connection without a valid token is not a Cloak client. Third, and most importantly, when an unauthenticated connection arrives (a censor's prober, a curious scanner, or a random bot), Cloak transparently forwards it to a real decoy web server. The prober sees a genuine website and nothing more. This is what makes Cloak resistant to active probing in a way that obfs4 and plain Shadowsocks are not.

The practical result: your offshore VPS appears to host a normal HTTPS site. Real visitors and probers get the decoy page. Only clients holding your key get tunneled through to the hidden proxy behind Cloak. For users in heavily filtered networks, this is the difference between a tunnel that survives for months and one that is fingerprinted and blocked within days.

Cloak's disguise relies on the TLS Server Name Indication (SNI) field, the unencrypted hostname a client sends at the start of every HTTPS connection. Cloak lets you configure a ServerName that points at a plausible, high-reputation domain. A censor inspecting the SNI sees a connection to, for example, a popular CDN-hosted site rather than to a flagged proxy host. This is the "domain-fronted" character of the transport: the visible destination differs from the hidden one.

True classic domain fronting (where the SNI names one site on a shared CDN and the encrypted Host header names another) has been largely shut down by the major CDNs, so Cloak's modern and reliable mode is decoy routing on your own VPS. You set RedirAddr on the server to a real upstream website, and any connection that fails Cloak authentication is reverse-proxied there. The server genuinely speaks to that decoy and relays its TLS, so a prober's connection is real end to end. Choose a decoy that is mundane, frequently visited, served over HTTPS, and unlikely to itself be blocked in your target region. A generic documentation site or a software project's homepage works well; avoid anything political or already filtered.

Cloak also multiplexes. A single Cloak session carries multiple logical streams over one or a small pool of TCP connections, so your traffic pattern (connection count, timing, packet sizes) resembles a browser loading a page rather than a long-lived single tunnel. This blunts traffic-analysis classifiers that flag the steady, long-duration flows typical of an unobfuscated VPN. Combined with the TLS mimicry and the decoy fallback, the multiplexing makes a Cloak endpoint statistically hard to separate from ordinary web browsing.

Order any plan with full root access; a single vCPU and 1 GB RAM comfortably handles Cloak in front of Shadowsocks for personal and small-group use. Connect over SSH as root and update the system (apt update && apt upgrade -y on Debian/Ubuntu). You will run two things on the server: the proxy you are hiding (Shadowsocks here) and Cloak in server mode wrapping it.

First install Shadowsocks (the Rust implementation ssserver from shadowsocks-rust is recommended) and have it listen on a local loopback port, for example 127.0.0.1:1984, so it is never directly reachable from the internet. Then download the Cloak server binary from the project's GitHub releases:

wget https://github.com/cbeuw/Cloak/releases/latest/download/ck-server-linux-amd64 -O /usr/local/bin/ck-server
chmod +x /usr/local/bin/ck-server

Generate the key material with the bundled utility. Cloak uses a public/private key pair plus per-user UIDs:

ck-server -key       # prints a fresh public/private key pair
ck-server -uid       # prints a new user UID (one per client)

Create /etc/cloak/ckserver.json with your private key, the proxy book mapping a method name to the backend, the bind port (443), and the decoy redirect target:

{
  "ProxyBook": { "shadowsocks": ["tcp", "127.0.0.1:1984"] },
  "BindAddr": [":443"],
  "BypassUID": [],
  "RedirAddr": "a-plausible-decoy-site.example",
  "PrivateKey": "YOUR_SERVER_PRIVATE_KEY",
  "AdminUID": "YOUR_ADMIN_UID",
  "DatabasePath": "/etc/cloak/userinfo.db",
  "StreamTimeout": 300
}

Run it as a service so it survives reboots. Create a systemd unit at /etc/systemd/system/cloak.service that executes /usr/local/bin/ck-server -c /etc/cloak/ckserver.json, then systemctl enable --now cloak. Because Cloak binds 443 and forwards unauthenticated traffic to your decoy, make sure no other service is already holding that port. Your VPS now presents as an HTTPS host that quietly tunnels authenticated Cloak clients to local Shadowsocks.

On the client device, install the matching Shadowsocks client and point it at a local Cloak instance instead of directly at the server. The Cloak client takes a JSON config carrying the operator's public key, your assigned UID, the public server name to present in the SNI, and the same ProxyMethod name ("shadowsocks") you defined in ProxyBook. The Shadowsocks client connects to 127.0.0.1 where ck-client listens, ck-client wraps the stream as fake TLS to your VPS on port 443, and the server unwraps it back to Shadowsocks. On mobile, the Shadowsocks Android client supports Cloak as a plugin (ck-client) configured through the plugin options string, so no separate process management is needed.

To maximise resistance to active probing, get the details right. Use a unique UID per user and revoke compromised UIDs at the server rather than rotating the whole key. Pick a RedirAddr decoy that is reachable, fast, and innocuous in the target country, because a prober that gets a slow or broken response is itself a signal. Set BrowserSig on the client to a current browser fingerprint (Chrome or Firefox) so the forged ClientHello matches what real traffic in that region looks like; a stale or unusual TLS fingerprint can be flagged by sophisticated classifiers. Keep StreamTimeout reasonable so idle multiplexed streams close cleanly.

Lock down the rest of the VPS as you would any exposed host: key-only SSH on a non-standard port, a firewall that allows only 443 inbound (and your SSH port) and rejects the rest, and fail2ban on the SSH service. Do not run a second, unobfuscated proxy on a guessable port "just in case" because that becomes the weak link a scanner finds. The whole value of Cloak is that the server has exactly one externally interesting behaviour, looking like a web server, so keep your attack surface aligned with that story. Because you control the server end to end on offshore infrastructure, there is no third-party operator who can be compelled to hand over a connection log.

Where you host the Cloak endpoint matters for both reachability and legal exposure. For users in the RU/CIS region and other heavily filtered networks, latency and routing to the VPS dominate the experience: a tunnel that survives DPI but adds 300 ms of round-trip is unpleasant for interactive use. Our Romania VPS plans sit on well-peered European routes with low latency to both Western Europe and CIS networks, which makes them a strong default for a Cloak front. Romania also sits outside the 5/9/14-Eyes intelligence-sharing arrangements and has no VPS-applicable mandatory data-retention regime, so there is little a foreign request can compel even before considering that you keep no logs.

Iceland is the alternative location, with constitutional speech protections and a long track record of hosting privacy-sensitive projects; it tends to deliver better round-trip times for users in North America. For operators serving many simultaneous users, or anyone wanting a dedicated IP that is not shared with other tenants, the offshore dedicated server options give you a clean IP reputation, which matters because Cloak's disguise is undermined if the IP itself is already on a blocklist from a previous tenant's activity. A fresh static IPv4 on a quiet ASN is part of what keeps the decoy story believable.

You can start small and scale: a single offshore VPS is enough to validate the configuration and serve a handful of clients, and you can move to a larger plan or a dedicated box as usage grows without changing the Cloak setup. Whatever location you pick, the key privacy property is the same as for any self-hosted transport on our infrastructure: you are the only party holding the keys, the user database, and the configuration, so there is no intermediary to log or disclose your traffic.