Last updated: March 15, 2026

Active probing detection represents one of the most sophisticated censorship techniques deployed by authoritarian networks. Unlike simple port blocking, active probing involves censors sending crafted packets to your server to identify the protocol being used. Shadowsocks alone provides encryption but lacks built-in protection against this attack vector. The Cloak plugin solves this problem by implementing protocol obfuscation and authentication that makes your Shadowsocks server appear as normal HTTPS traffic.

This guide walks through installing and configuring the Cloak plugin to transform your Shadowsocks setup into something that resists active probing detection.

Prerequisites

Before you begin, make sure you have the following ready:

Step 1 - Understand Active Probing

When a censor performs active probing, they send packets designed to trigger specific responses from known circumvention protocols. Shadowsocks servers respond in ways that reveal the protocol, enabling censors to identify and block the connection even when encryption prevents content inspection. Cloak addresses this by multiplexing Shadowsocks traffic over a TLS tunnel that looks indistinguishable from regular HTTPS traffic.

The plugin operates at the transport layer, meaning your Shadowsocks configuration remains unchanged. Cloak handles the obfuscation transparently, creating a dual-layer architecture where the outer TLS connection resists classification while the inner Shadowsocks connection provides the actual proxy functionality.

Step 2 - Install Cloak

Cloak is written in Go and compiles to a single binary. The installation process varies by operating system, but the general approach involves downloading the compiled binary or building from source.

On Linux servers, download the appropriate binary:

Download the latest release (check github.com/cbeuw/Cloak for current version)
VERSION="v2.2.1"
wget "https://github.com/cbeuw/Cloak/releases/download/${VERSION}/ck-server-linux-amd64"
chmod +x ck-server-linux-amd64
sudo mv ck-server-linux-amd64 /usr/local/bin/ck-server

On macOS, you can use Homebrew:

brew install cloak

Verify the installation:

ck-server -version

Step 3 - Server-Side Configuration

Cloak requires a configuration file in JSON format. Create /etc/cloak.json on your server with the following structure:

{
  "Listen": "0.0.0.0:443",
  "ProxyProtocol": "shadowsocks",
  "EncryptionMethod": "chacha20-poly1305",
  "UID": "YOUR_UID_HERE",
  "PublicKey": "YOUR_PUBLIC_KEY_HERE",
  "PrivateKey": "YOUR_PRIVATE_KEY_HERE",
  "AdminUID": "YOUR_ADMIN_UID_HERE",
  "DatabasePath": "/var/lib/cloak/users.json"
}

Generate the required cryptographic keys using the ck-server binary:

Generate keys (run locally or use a key generation tool)
ck-server -keygen

This outputs your UID, public key, and private key. The UID serves as a user identifier, while the public and private keys handle authentication.

The AdminUID is a special UID that grants administrative access, allowing you to manage connected users without authentication. In production deployments, you typically run a separate instance for administration or use the management API.

Create the database file:

sudo mkdir -p /var/lib/cloak
sudo touch /var/lib/cloak/users.json

The database stores user credentials and connection statistics. Each user entry includes their UID, data transfer limits, and connection parameters.

Step 4 - Configure Shadowsocks with Cloak

Your Shadowsocks configuration needs modification to work with Cloak. Edit your Shadowsocks server configuration (typically in /etc/shadowsocks-libev/config.json):

{
  "server": "127.0.0.1",
  "server_port": 8443,
  "password": "your_shadowsocks_password",
  "method": "chacha20-ietf-poly1305",
  "mode": "tcp_only"
}

The key change is setting the server to localhost on port 8443. Shadowsocks now listens internally, while Cloak handles external connections and forwards them to Shadowsocks.

Restart both services:

Restart Shadowsocks
sudo systemctl restart shadowsocks-libev

Start Cloak
sudo ck-server -c /etc/cloak.json

Configure Cloak to start automatically:

sudo systemctl enable cloak
sudo systemctl start cloak

Step 5 - Client-Side Configuration

On client machines, you need both a Shadowsocks client and the Cloak plugin. Install Cloak using the same method as the server, then configure your client.

Create a client configuration file /etc/cloak-client.json:

{
  "RemoteHost": "your-server-ip",
  "RemotePort": 443,
  "LocalHost": "127.0.0.1",
  "LocalPort": 1080,
  "UID": "YOUR_UID_FROM_SERVER",
  "PublicKey": "YOUR_PUBLIC_KEY_FROM_SERVER",
  "PrivateKey": "YOUR_PRIVATE_KEY_FROM_SERVER",
  "ServerName": "your-domain.com",
  "NumConn": 4,
  "KeepAlive": 30
}

The ServerName field should match a valid TLS certificate on your server, this helps the connection pass through TLS inspection systems.

Configure your Shadowsocks client to use the Cloak plugin. In many clients, this means adding the plugin path and enabling it:

When the client connects, it performs a TLS handshake using the server’s domain name. The connection appears identical to legitimate HTTPS traffic to external observers. The inner Shadowsocks protocol only activates after the TLS tunnel is established.

Step 6 - Manage Users

Cloak includes a command-line tool for user management. Add a new user:

ck-server -uidgen | tee new_user.json

This generates a new UID and keys. Add the user to the database:

ck-server -adduser -c /etc/cloak.json -u NEW_UID -t 10000000 -d 500000000

This creates a user with a time limit of 10,000,000 seconds and a data limit of 500,000,000 bytes. Set limits to zero for unlimited access.

View connected users:

ck-server -status -c /etc/cloak.json

Remove a user:

ck-server -deluser -c /etc/cloak.json -u USER_UID

Production Considerations

For production deployments, consider these additional measures:

TLS Certificate - Use a valid TLS certificate from Let’s Encrypt. Cloak’s TLS tunneling relies on proper certificate validation to establish trust.

sudo certbot certonly -d your-domain.com
sudo cp /etc/letsencrypt/live/your-domain.com/fullchain.pem /etc/cloak/tls.crt
sudo cp /etc/letsencrypt/live/your-domain.com/privkey.pem /etc/cloak/tls.key

Obfuscated Servers - Cloak works best when hosted on IP addresses that aren’t already flagged. Consider using dedicated IPs for your Shadowsocks-Cloak setup rather than shared hosting.

Firewall Configuration - Ensure only port 443 is exposed externally. Shadowsocks on port 8443 should bind only to localhost.

Troubleshooting

If connections fail, verify these common issues:

  1. Certificate validation: Ensure the client has the correct time and can validate the server’s TLS certificate
  2. Firewall rules: Confirm port 443 accepts incoming connections
  3. Keys match: Verify UID, public key, and private key are consistent between server and client
  4. Service status: Check that both Cloak and Shadowsocks are running:
systemctl status cloak
systemctl status shadowsocks-libev

The logs often reveal specific failure points:

journalctl -u cloak -f

Cloak provides protection against active probing by transforming your Shadowsocks traffic into TLS-encrypted connections that blend with legitimate web traffic. This configuration requires more setup than basic Shadowsocks but offers significantly better resistance to sophisticated censorship infrastructure.

Frequently Asked Questions

How long does it take to configure cloak plugin for shadowsocks to evade?

For a straightforward setup, expect 30 minutes to 2 hours depending on your familiarity with the tools involved. Complex configurations with custom requirements may take longer. Having your credentials and environment ready before starting saves significant time.

What are the most common mistakes to avoid?

The most frequent issues are skipping prerequisite steps, using outdated package versions, and not reading error messages carefully. Follow the steps in order, verify each one works before moving on, and check the official documentation if something behaves unexpectedly.

Do I need prior experience to follow this guide?

Basic familiarity with the relevant tools and command line is helpful but not strictly required. Each step is explained with context. If you get stuck, the official documentation for each tool covers fundamentals that may fill in knowledge gaps.

Can I adapt this for a different tech stack?

Yes, the underlying concepts transfer to other stacks, though the specific implementation details will differ. Look for equivalent libraries and patterns in your target stack. The architecture and workflow design remain similar even when the syntax changes.

Where can I get help if I run into issues?

Start with the official documentation for each tool mentioned. Stack Overflow and GitHub Issues are good next steps for specific error messages. Community forums and Discord servers for the relevant tools often have active members who can help with setup problems.

Related Articles

Built by theluckystrike. More at zovo.one