Shadowsocks-libev

Last reviewed Aug 26, 2026 · 778 words

Shadowsocks-libev encrypts traffic for applications that speak SOCKS5 and nothing else. It will not put your whole machine on a remote network, it does not carry DNS unless the client is told to, and one shared password is the entire user model. Inside those limits it is superb: a C daemon (GPL-3.0, 16,181 stars) that idles in 32 MB of RAM, runs on a 20-dollar router, and produces an encrypted stream that looks like nothing in particular to a middlebox. The other thing to know before you install it is that libev is now the maintenance branch. The same project points new deployments at shadowsocks-rust, which reads the same configuration file.

The whole server configuration is six keys

{
  "server": "0.0.0.0",
  "server_port": 8388,
  "password": "use-a-long-random-string",
  "method": "chacha20-ietf-poly1305",
  "timeout": 300,
  "fast_open": false
}

Save it as /etc/shadowsocks-libev/config.json, install the shadowsocks-libev package from Debian or Ubuntu, and systemctl enable --now shadowsocks-libev starts ss-server against it. The Docker route is the shadowsocks/shadowsocks-libev image with PASSWORD and METHOD environment variables and one published port. Move the port off 8388 to something random and high: it is not security, but it removes you from the scanners that check the default. Firewall everything else on the box. There is no user list, no rate limiting and no logging beyond stderr, so the daemon is only as safe as the host around it.

Pick an AEAD cipher and ignore the rest

The method field is the one place people get it wrong. Only the AEAD ciphers are acceptable: chacha20-ietf-poly1305 on ARM routers and anything without hardware AES, aes-256-gcm or aes-128-gcm on x86 with AES-NI where it is faster. The older stream ciphers still listed in some tutorials (aes-256-cfb, rc4-md5) are vulnerable to active probing and tampering and should be treated as plaintext. shadowsocks-rust adds the AEAD-2022 family, which fixes replay weaknesses in the original design and is one of the two reasons to prefer it for new installs; the other is that it is where development happens.

Clients, and the "not a VPN" problem in practice

On the client side ss-local opens a SOCKS5 listener on 127.0.0.1:1080, and you point applications at it. Firefox has a proxy setting with a "Proxy DNS when using SOCKS v5" checkbox that must be ticked, or name lookups go out unencrypted and give away every site you visit. Chrome takes the proxy from the OS, which is less controllable. Applications that ignore proxy settings, which is most of them, bypass Shadowsocks entirely. On OpenWrt, ss-redir with firewall rules gives transparent proxying for a whole LAN, which is the closest this gets to VPN behaviour and the reason the router use case is so popular. The Android client wraps a tun-to-SOCKS layer so a phone can route everything; on a desktop you want a similar wrapper or the discipline to check what is actually going through the tunnel. The threat model for normal people piece is a useful frame here: Shadowsocks protects a browser session on an untrusted network well and protects a whole device badly.

Where WireGuard wins, and where it does not

For reaching your own services, WireGuard through wg-easy or a Tailscale mesh is the better tool every time: whole-device routing, kernel speed, per-peer keys. WireGuard's weakness is that it is UDP with a recognisable handshake, and networks that block or throttle unknown UDP block it easily. Shadowsocks over TCP, especially with a SIP003 plugin such as v2ray-plugin dressing it as a WebSocket, keeps working where WireGuard does not. If your problem is a network that interferes with traffic rather than one you merely distrust, that is the case for Shadowsocks, and beyond it the proxy category lists the Xray-style tools that go further at the cost of complexity.

What I'd do

New installs get shadowsocks-rust on a small VPS with the configuration above, an AEAD-2022 or chacha20-ietf-poly1305 method, a random high port and nothing else exposed. Keep libev only where a router firmware or distro package already provides it, since it still works and the config carries over. Run ss-local on the laptop for a browser profile with SOCKS DNS enabled, and use WireGuard or Tailscale for everything that needs the whole machine. Do not call it a VPN in front of anyone who relies on it as one.