cbeuw/Cloak: A Pluggable Transport That Hides Proxies Behind Normal Web Traffic

The problem Cloak solves for proxy operators

OpenVPN, Shadowsocks and Tor all have recognisable traffic fingerprints. A censor that inspects packets can write a filtering rule for the handshake or the packet-size pattern and block the protocol without touching anything else. Cloak exists to remove that handle. The README describes it as a pluggable transport that enhances traditional proxy tools to evade deep packet inspection and data discrimination, and it is explicit that Cloak is not a standalone proxy program. It sits in front of an existing proxy and makes the connection look like a browser talking to a web server.

The target user is someone who already operates a proxy endpoint and controls the server. That is a narrower audience than the phrase VPN suggests. Cloak's own framing is defensive: the goal is that blocking it would cause collateral damage to services the censor relies on, because a host running Cloak server is meant to be indistinguishable from an innocent web server, both under passive observation and under active probing. If you are looking for a consumer VPN app, this is the wrong layer of the stack.

How Cloak disguises traffic and routes it to the real proxy

Two mechanisms do the work. The first is cryptographic steganography, documented in the project wiki under Steganography and encryption, which shapes the wire traffic so that a third party sees ordinary web browsing. The second is a reverse proxy: the server holds a ProxyBook object mapping a client-side ProxyMethod name to an upstream protocol and address, so multiple proxy servers can run on one host and Cloak bridges each client to the proxy it asked for. The README gives this example of the server-side mapping, where the key must match the client's ProxyMethod exactly because it is case-sensitive:

{
  "ProxyBook": {
    "shadowsocks": ["tcp", "localhost:51443"],
    "openvpn": ["tcp", "localhost:12345"]
  }
}

Clients reach that mapping through a UID and a set of keys. The server holds a base64 curve25519 PrivateKey; the client holds the matching PublicKey and its own base64 UID. Traffic is multiplexed over several underlying TCP connections, which the README says reduces head-of-line blocking, removes repeated TCP handshakes, and makes the traffic pattern resemble a real website. A Transport setting of direct or CDN decides whether the client connects straight to the server or tunnels through an intermediary CDN such as Amazon Cloudfront.

The design has a cost worth naming. Cloak's encryption is not transport security. The README states that the point of EncryptionMethod is to hide proxy fingerprints and make the payload statistically random-like, and that plain is acceptable only when the underlying proxy already provides both encryption and authentication through AEAD or similar. That is a sharp edge: a misconfigured client can end up with a tunnel that looks private and is not.

Building ck-client and ck-server from source

The README's build section is short and assumes a Go toolchain. The repository's go.mod pins go 1.24.0 with toolchain go1.24.2, so a recent Go release is expected. Clone, fetch dependencies and run make:

git clone https://github.com/cbeuw/Cloak
cd Cloak
go get ./...
make

The Makefile builds two binaries, ck-client from ./cmd/ck-client and ck-server from ./cmd/ck-server, and moves them into a build directory. A make install target moves build/ck-* into /usr/local/bin. The repository also ships a Dockerfile that clones the project inside a golang:latest image and runs make, which produces the binaries but does not configure or start anything. Example configuration files live under example_config, and the README points to a community script by @HirbodBehnam for a combined Shadowsocks and Cloak deployment on a server.

For a first real use, the sequence is: pick a RedirAddr that is a major site the censor allows, such as www.bing.com; set BindAddr to the addresses Cloak should listen on, for example [":443",":80"]; fill in ProxyBook with your upstream proxy; generate the curve25519 key pair; then start ck-server with the server config and ck-client with the client config, where UID, PublicKey, ProxyMethod and Transport must line up with the server side. The README does not document a first-run wizard, so expect to write both JSON files by hand from the examples.

Multi-user accounting and where it stops being enough

Cloak adds user management that the underlying proxy may not have. BypassUID lists UIDs authorised with no bandwidth or credit limit. AdminUID enables the admin user, and DatabasePath points at userinfo.db, a bbolt database that stores usage information and restrictions; Cloak creates the file if it is missing. The README notes that DatabasePath has no effect if AdminUID is empty or invalid, and that both AdminUID and DatabasePath can be left empty if every user is in BypassUID. Traffic management covers usage credit and bandwidth control, and the default listening port is 443.

That accounting layer is also where the sharp edges are. If you only use BypassUID, there is no per-user enforcement at all. If AdminUID is set but DatabasePath is wrong, the accounting silently does nothing useful. The database is a local file, so a server rebuild without that file loses the usage history. And the README does not document rollback or migration for userinfo.db, so an upgrade path that changes the schema is not described in the project's own documentation.

There is also a category of problem Cloak is not built for. It does not create anonymity, it does not replace Tor's onion routing, and it does not protect against a censor who has already blocked the specific CDN or the RedirAddr site you chose. If the censor blocks your cover site outright, the disguise loses its value.

Cloak against a plain TLS tunnel or a bare Shadowsocks setup

The obvious alternative is running Shadowsocks or OpenVPN on its own, without a transport in front of it. The difference is in what the censor sees. A bare Shadowsocks stream has a protocol-specific shape that can be matched by a filtering rule; Cloak wraps the same stream so that, per the README, a host running Cloak server is indistinguishable from an innocent web server under both passive observation and active probing. The trade is operational: bare Shadowsocks is one process and one config, while Cloak is a second process, a key exchange, a ProxyBook mapping and a JSON config on each side.

A second comparison is a generic TLS tunnel, which also hides the payload inside TLS but does not attempt to imitate a real website's behaviour or to survive active probing in the way Cloak claims. Cloak's CDN transport mode is a further distinction, since it lets the client tunnel through an intermediary CDN such as Amazon Cloudfront, a path a plain tunnel does not offer. The honest summary is that Cloak buys a specific threat-model property at the cost of additional moving parts, and it only pays off when the adversary is doing deep packet inspection rather than simple IP blocking.

Maintenance, licence and what to check before upgrading

The repository is not archived, and the last push was on 2026-05-29. Releases are tagged, with v2.12.0 on 2025-07-23, v2.11.0 on 2025-06-30 and v2.10.0 on 2024-10-11, so the release cadence is irregular rather than monthly. The version string baked into the binaries comes from the Makefile, which reads the current git tag and falls back to master plus a short commit hash, so a binary built from a dirty checkout will not report a clean release number. That matters when you are trying to match a client and a server across an upgrade.

The project is licensed GPL-3.0. If you redistribute modified binaries, the licence's source-availability terms apply; if you only run it on your own server, the practical effect is limited. This is not legal advice, and anyone embedding Cloak in a product should read the licence text in the repository's LICENSE file.

Upgrade cost is mostly configuration drift. The README documents keys such as RedirAddr, BindAddr, ProxyBook, PrivateKey, BypassUID, AdminUID, DatabasePath, KeepAlive, UID, Transport, PublicKey, ProxyMethod, EncryptionMethod, ServerName and AlternativeNames, and a client and server built from different releases may disagree about which of those are required. KeepAlive defaults to 0, meaning disabled, and a zero or negative value turns it off, so a long-idle tunnel depends on the underlying proxy's own keepalive behaviour.

Editorial conclusion

Adopt Cloak if you already run OpenVPN, Shadowsocks or Tor and need the connection to look like ordinary HTTPS to a censor that inspects packets and probes servers. Do not adopt it if you want a standalone VPN client, if you cannot run a server on port 443, or if you need a hosted service with a support contract. Before deploying, verify that your underlying proxy provides both encryption and authentication if you plan to set EncryptionMethod to plain, confirm that RedirAddr points at a site the censor permits, and check that your client and server builds come from the same release tag.

Frequently asked questions

Official sources

1. cbeuw/Cloak on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases