A Decade of Open Source, Absorbed by Large Models, Is Finishing shadowsocks's Original Vision

The Claim

When shadowsocks was proposed in 2012, it argued for two things side by side:

• Decentralized deployment: every user runs their own server, rather than relying on a handful of public nodes
• A customizable protocol layer: a plugin mechanism lets users write their own transport-layer disguise, so no single fingerprint can be characterized

The first has been partly realized over the past decade. Cheaper VPSes and one-line install scripts made self-hosting easy for technical users, though it stayed out of reach for everyone else. The second was almost never delivered by ordinary users: worldwide there are probably fewer than a thousand developers who can write a production-ready obfuscation plugin on their own, and the result is that the vast majority of users share the protocol fingerprints of a few projects, v2ray, xray, hysteria and so on.

What changed in 2025 and 2026 is this: all the code the open source community has contributed to circumvention tools over the past decade or more, including shadowsocks, v2ray, xray, trojan, hysteria, naive and reality, along with protocol specs like SIP003, VLESS and Hysteria2, has been absorbed into the training data of large models. The direct consequence is that the cost of both deployment and protocol customization collapsed at the same time.

This post records two cases I actually ran.

What Models Absorbed

Looking at how mainstream 2026 code models handle circumvention-related tasks, here is what has been reliably absorbed:

To the model, "write a SIP003 plugin" is about as hard as "write an HTTP server". Both patterns show up often enough in the training data.

Case 1: A 10-Minute Deploy

The most direct use case: you have an empty VPS and need a working server plus client.

How it went in practice: run any code agent on the VPS (Claude Code / opencode / Cursor) and give it one prompt:

Deploy a shadowsocks-rust server on this VPS, using a SIP003 plugin for HTTP/2 obfuscation. Set up systemd so it starts automatically, open port 443, and generate a client config file for me.

The model handles system detection, package installation, generating a strong random password and port, writing the systemd unit, firewall rules and exporting the client config, with no cognitive load on the user at any point. A working link in under 10 minutes.

The last remaining barrier to shadowsocks's first goal, decentralized deployment, namely "can read the docs, isn't scared of a command line", is gone.

Case 2: An Obfuscation Plugin from a Non-SOTA Model

A more aggressive test: have a completely free, non-SOTA model write a SIP003 obfuscation plugin from scratch, to see what protocol customization actually costs.

The tools used:

• Code agent: opencode, open source, CLI first
• Model: deepseek-v4-flash-free, through OpenRouter's free tier
• Provider cost: $0
• Local cost: $0
• Development time: ~2.5 hours, including debugging and end-to-end verification
• Output: 410 lines of Go, one file, one non-standard dependency

DeepSeek v4 flash is not the strongest code model around. It is positioned as the low-latency, low-cost, high-volume tier and it lags clearly behind Claude Opus 4.7 and GPT-5.5 on benchmarks. For this task it was good enough.

The starting point is a prompt in Chinese:

The model decided on its own to pull in golang.org/x/net/http2, build HEADERS + DATA frames and handle HPACK encoding:

The end result, sip003-http2-obfuscator, is laid out like this, and passes an end-to-end integration test against shadowsocks-rust:

http2-obfuscator/
├── main.go              # ~410 lines
├── build.sh
├── test_integration.sh  # end-to-end integration test
├── go.mod / go.sum
└── README.md

The model stepped into two traps along the way, one about the direction semantics of the SIP003 environment variables, the other about interleaved concurrent writes of HTTP/2 frames, and it fixed both itself once fed the error logs. I did not hand-write a single line of Go during the whole session.

The marginal cost of switching to a different disguise is very low. Swap the HTTP/2 scaffolding for WebSocket, gRPC, DoH or QUIC, let the same free model run again, and it should take about the same time. Every user is in a position to maintain a private variant that belongs to them alone.

Closing

The "customizable protocol layer" in the original shadowsocks design held up technically and was almost impossible to execute in practice. The SIP003 interface has been ready to accept arbitrary third-party plugins since 2017, but the matching "arbitrary third party" never showed up.

What actually filled that gap is a decade of open source contributions settling into large models. The code, documentation, issue threads and hard-won notes from shadowsocks, v2ray, xray and the rest all became background knowledge for the models. "Implement a transport-layer obfuscator" went from expert work to a routine task you can hand to an agent. That a free, non-SOTA DeepSeek v4 flash can finish it in a few hours says the capability is now available to ordinary users.

Two structural consequences follow:

1. Decentralized deployment reaches non-technical users: a VPS and basic English are enough to complete a full deployment
2. Protocol diversity can finally be supplied at scale: a single fingerprint is easy to block in bulk, but when every user can generate a private variant for free, DPI feature engineering has to identify each disguise one at a time, and stops working at scale

A self-written protocol will never beat v2ray, xray or hysteria on how well it holds up, and those remain the better choice for performance, probe resistance and ecosystem maturity. But "everyone can write a usable obfuscator for free" and "only a few projects can write one" are two completely different situations. The former is what shadowsocks described back in 2012, and the 2026 toolchain is the first time that description can actually be built.