Shadowsocks: why it's no longer an option

Short and honest: Shadowsocks today is a stopgap protocol. It's simple and fast, but it has no TLS masking, and under proper DPI it goes down. I'm keeping this article for reference so you understand why it's not in the main setup.

This material is about engineering your own infrastructure and is educational in nature. Complying with the laws of your own jurisdiction is your responsibility.

What it is and why it's no longer primary

Shadowsocks is a lightweight encrypting proxy. No domain, no certificate, no TLS handshake: there's a shared key and an encryption method, the traffic is encrypted as a stream and goes off to the server. Hence its upsides — simple and fast. And hence its 2026 death sentence: since there's no TLS, it has nothing to pretend to be an ordinary site with.

The Shadowsocks-2022 edition cleaned up the cryptography (AEAD, replay protection), but it didn't change the foundation. DPI sees a stream that resembles neither HTTPS nor anything legitimate — the statistics of lengths and timings give it away, and it has nothing to answer an active probe with. In that situation Reality hands the request off to someone else's big site and stays invisible, whereas SS just sticks out. So as a client entry point under the TSPU it doesn't survive.

The only niche — and even that with a caveat

Sometimes SS is proposed as an internal hop in a cascade (between your own nodes, where the traffic is already inside your perimeter and doesn't flash outward). Technically you can. But even here I don't recommend it: it's an unnecessary weak link, and from a security standpoint internal hops are better built on the same VLESS/Reality or on a secured transport, not on a protocol with no masking. If you really need something "quick" — see the config below, but keep in mind it's a compromise, not a best practice.

If you do end up needing it — a minimal config

For reference. The SS-2022 key is a fixed-length value in base64 (it's a crypto key, not a password):

# a 16-byte key for the 2022-blake3-aes-128-gcm method
openssl rand -base64 16

{
  "inbounds": [
    {
      "tag": "ss2022",
      "listen": "0.0.0.0",
      "port": 8388,
      "protocol": "shadowsocks",
      "settings": {
        "method": "2022-blake3-aes-128-gcm",
        "password": "BASE64_16BYTE_KEY",
        "network": "tcp,udp"
      }
    }
  ],
  "outbounds": [ { "protocol": "freedom" } ]
}

Keep the port different from 443, where your main Reality lives. Wrong key length → the inbound won't assemble.

What to use instead

As a client entry point — VLESS + Reality (masking under someone else's TLS), and under harsh TSPU add XHTTP on top. That's covered in the current guides in the "Protocols" section — look there, and keep Shadowsocks in reserve.