Shadowsocks and Xray: When VPN Gets Blocked

I work with VPNs a lot. Not as a theoretical topic, but in the everyday operational sense: connecting sites, bringing customers into company networks, keeping servers reachable, configuring firewalls cleanly, renewing certificates, stabilizing IPsec tunnels, debugging SSL VPN clients and eventually finding out why a location suddenly cannot get through anymore.

Normally, that is boring, solid network work. That is exactly how it should be.

But there are cases where a technically correct VPN is no longer enough. Especially with customers from countries with heavily regulated internet access, for example China or Russia, we repeatedly see situations where classic VPN protocols are blocked, disrupted or deliberately detected. Since I work in Dubai with a very international customer base, this is not an abstract issue. You work with people and companies from many regions, and the operational question is not which political weather system is behind it today. The question is: how can legitimate access to your own infrastructure remain possible when the connection is filtered on the way there?

This is where terms such as Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY or XHTTP start appearing. At first it looks like a confusing mix of projects, forks and abbreviations. And honestly: part of it is exactly that.

Why Shadowsocks existed in the first place

Shadowsocks did not come out of the classic enterprise VPN world. It was not created because someone wanted a nicer site-to-site solution or because IPsec was too complicated. The origin was much more direct: in 2012, a developer using the pseudonym clowwindy wanted a lightweight way to reach the open internet from inside a heavily filtered network.

That explains a lot about the design. Shadowsocks was meant to be light, fast and practical. Not a heavy VPN client, not a large gateway product, not a full remote-access suite with identity management and compliance reporting. Instead, it was a local SOCKS5 proxy that encrypts traffic and sends it to a server outside the blockade.

So the need was not “more enterprise security features”. The need was: “I need a working exit path from a network that filters certain protocols and destinations.” That is why Shadowsocks remains interesting and easy to misunderstand. It is very good as a slim transport component. It is not automatically a complete enterprise VPN.

In 2015 the story became more political: clowwindy wrote on GitHub that the police had visited him and that he had to stop working on the project. Development then continued through forks and other implementations. That fits the broader history of such tools: they often start from very concrete technical pain and then become part of a much larger arms race between users, developers and filtering infrastructure.

Why a VPN stands out at all

Many people think of encryption first when they hear VPN. That is correct, but it is only part of the story.

A censor, provider or large national firewall does not necessarily have to read the contents of an encrypted connection in order to disrupt it. Often it is enough to recognize the envelope. An IPsec tunnel, SSL VPN, WireGuard or OpenVPN all have typical characteristics: ports, packet sizes, handshake patterns, certificate behavior, timing, UDP behavior, retries, error messages or simply known server IP addresses.

Think not of the letter, but of the envelope. The letter is encrypted, but the envelope has a certain size, color and stamp, and it always comes from the same sender. Someone sorting only envelopes does not need to read the text. They can still say: I know this kind of envelope; send it to special inspection.

Network traffic is similar. Deep packet inspection and traffic classification do not only look at ports. They analyze patterns. In TLS connections, client hello fingerprints, SNI, certificate chains or ALPN information can stand out. In fully encrypted protocols, the apparently random nature of the first packets can itself become a signal. Research on the Great Firewall has shown that not only known protocol signatures matter, but also packet lengths, entropy and printable ASCII characters in early packets.

That is the uncomfortable point: “everything looks random” is not automatically inconspicuous. Sometimes exactly that is suspicious.

What research shows

In my experience, the decisive point is not that censorship systems can “detect VPNs”. We already knew that at a high level. The interesting part is how unspectacular many of these detections are technically.

A good entry point is measurement work by GFW Report, presented in 2020 at the ACM Internet Measurement Conference. GFW Report is not a product or vendor, but a research and measurement project around the Great Firewall. IMC simply refers to the conference where the work was published.

The important point from that work: this was not a magical decryption attack. The Great Firewall combined passive observation with active probing. First, connections became suspicious because of features such as the length and entropy of the first data packet. Then active probes followed: the censor connects to the suspected server, replays old or modified packets and watches whether the other side behaves like a Shadowsocks server.

For administrators, this matters because it shows two different defense layers:

• The traffic must not look too conspicuous passively.
• The server must not answer active tests like a proxy.

In 2023 it became even less comfortable. Another GFW study showed that fully encrypted traffic can be blocked with simple heuristics. In simplified terms: if the first TCP payload looks neither like TLS, nor HTTP, nor printable text, but like a random block of data, that alone can be a signal. That is why “maximally random” is not always the best camouflage goal.

In 2024, research on encapsulated TLS handshakes added another point: even when the outer tunnel is encrypted and well disguised, an inner TLS handshake can appear as a pattern inside a nested protocol stack. That is especially relevant for setups where normal HTTPS traffic runs through another encrypted proxy tunnel. Random padding helps only to a limited degree there; stream multiplexing looks more promising in the research, but it does not automatically solve the problem if only one application stream is visible in the end.

Newer work on timing and cross-layer RTTs adds to this. The uncomfortable part is structural: a proxy shifts transport and application sessions against each other. These timing differences can be measurable regardless of whether the client is close to the proxy or far away. You cannot simply configure that away with another header.

The consequence is sober but healthy: the protocol label is not what decides. The whole behavior of the setup does.

Shadowsocks is not a classic VPN

Shadowsocks is often put into the same bucket as VPN. For everyday language that is understandable, but technically it is imprecise.

Shadowsocks is an encrypted proxy, loosely based on SOCKS5. A client runs locally and offers applications a proxy. This client encrypts the traffic and sends it to a remote Shadowsocks server. The server decrypts the request, connects to the actual destination and forwards the response back through the encrypted path.

That is slimmer than a full VPN. Shadowsocks does not automatically pull the entire operating system into a tunnel. It is more like a tool for sending selected traffic over another path. Depending on the client, operating system and additional components, you can build something that feels almost VPN-like, but the basic idea remains proxy instead of site-to-site VPN.

For administrators, that matters because it corrects expectations:

• Shadowsocks does not replace clean site-to-site IPsec.
• Shadowsocks is not magical protection against every form of detection.
• Shadowsocks is very useful when a simple, fast, encrypted proxy out of a restrictive network is needed.

Technically, Shadowsocks has evolved over the years. Old stream-cipher setups should no longer be the benchmark. Modern Shadowsocks deployments belong in the AEAD world, and Shadowsocks 2022 goes one step further: it uses a pre-shared symmetric key base, modern mechanisms such as BLAKE3-based derivation, replay protection and other corrections compared with older editions. But one limitation also matters: according to the specification, Shadowsocks 2022 does not provide forward secrecy. If a key is compromised, clean rotation is not optional.

With shadowsocks-rust, there is a modern implementation that can also run via Docker. On the server side, for example, ssserver runs; on the client side, sslocal. Between them you need more than just any password: properly generated secrets, a reachable port, current ciphers and a clear decision on whether TCP, UDP or both are required.

Why Xray-core is a different category

Xray-core is not simply “Shadowsocks, but newer”. It is more of a framework for proxy and tunnel scenarios.

Xray can combine different inbound and outbound protocols: VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS and HTTP. On top of that you place transports such as RAW, WebSocket, gRPC, XHTTP or Hysteria and combine them with TLS, REALITY or XTLS Vision. VMess still appears in many older setups, but for new deployments it is more legacy; in current Xray setups, VLESS is usually at the center.

Shadowsocks is the quick screwdriver. Xray is the toolbox. You can build simple setups with it, but also designs where a local SOCKS or TUN client accepts traffic, sends it via VLESS with REALITY to a server and the server forwards it to the internet through a normal freedom outbound.

VLESS must be understood correctly: VLESS is not the camouflage itself, but a lightweight proxy protocol with UUID-based authentication. Confidentiality and the actual camouflage effect come from the transport and security layer underneath, such as TLS, REALITY or XTLS Vision.

REALITY is the more interesting component because it does not simply do “TLS again”. To the outside, the server borrows the TLS handshake of a real third-party HTTPS site. To an observer, this does not look like a homemade proxy certificate, but like a real certificate from a real website. Only an authorized client, using the configured key material, recognizes that it is talking to its own Xray server.

That mainly addresses the server-side TLS fingerprint and active-probing layer. uTLS additionally helps on the client side by imitating browser client hellos. Still, Xray is not an invisibility cloak: timing, packet sizes, ALPN, server behavior and nested TLS patterns can continue to produce signals. XTLS Vision and XHTTP are therefore interesting building blocks, but not a finished guarantee. A little padding helps little if the basic pattern of nested traffic remains visible.

There is also a practical point: UDP-based approaches such as Hysteria or QUIC can be very performant, but restrictive networks often throttle, block or treat them worse than outgoing TCP/443. That is exactly why Xray requires more discipline in operation than Shadowsocks: pin versions, test changes, read release notes and do not blindly adopt every new recommendation from a forum.

The confusion around forks and names

Anyone who starts researching quickly lands in old blog posts, GitHub forks and half-maintained clients. That comes from the history of these tools.

Shadowsocks itself is a protocol and an ecosystem with several implementations. shadowsocks-rust is an obvious choice today if you want to operate a modern server. Older implementations such as shadowsocks-libev are still known, but depending on project status they are more legacy or bugfix-oriented.

ShadowsocksR was a fork with additional obfuscation and protocol ideas. SSR appears in many old guides. I would be careful with it today. Not because every old installation is automatically bad, but because with such projects you have to check very carefully whether client, server, crypto, updates and community are still trustworthy.

Xray-core, in turn, came out of the V2Ray environment but has developed independently. That is why it is dangerous to blindly apply old V2Ray tutorials to Xray. Some concepts are similar, but configurations, features and recommendations have changed.

V2Fly, today’s community project around V2Ray, is still relevant. It is more of the conservative toolkit. Xray-core is more aggressive with new features such as REALITY, XTLS Vision or XHTTP. Alongside it, sing-box exists as a modern universal platform that also brings many of these protocols together. This article keeps Xray in focus, but in a lab I would at least look at sing-box because many clients and mobile setups now land there.

My pragmatic advice would be:

• For simple new setups: evaluate Shadowsocks with a current implementation.
• For more difficult networks: evaluate Xray-core with a clean, current design.
• For old SSR or V2Ray guides: first check project status and security posture, then decide.
• For productive customer scenarios: do not copy a setup from a blog without understanding it yourself.

What you need on both sides

A minimal setup always consists of two sides.

On the remote side, you need a server outside the restrictive network. That can be a small VPS, your own server in a data center or controlled infrastructure in a region reachable from the customer site. This server must be hardened, patched, monitored and documented properly. If you just spin up a cheap instance and never look at it again, you are building long-term risk.

On the client side, you need a suitable program. With Shadowsocks, that is often a local SOCKS client or an app that can set system proxy rules. With Xray, it can be an Xray-based client, TUN mode, a router setup or an app that imports profiles.

Between the two you need:

• a clearly defined purpose
• clean authentication
• current software versions
• controlled DNS resolution
• logging without unnecessary customer data
• reachability monitoring
• a plan for rotating servers, ports and secrets
• a legal and contractual review of whether the operation is allowed

The last point is not decoration. In some countries, even the use of such tools can be legally problematic. In a company context, it also matters whether you are making your own systems reachable, operating customer networks or providing employees with general internet access. Those are different risks.

DNS is often the underestimated part. If the browser or operating system still resolves the destination domain through the local provider, the tunnel is only half as useful. The content may go through the proxy, but the DNS request still tells where the user wanted to go. With SOCKS, HTTP proxy and TUN setups, you therefore have to verify separately whether DNS really uses the intended path, whether IPv6 is handled cleanly and what happens when the tunnel breaks.

Logging is similarly sensitive. For troubleshooting, you want to see whether a tunnel is alive. For privacy and customer protection, you want to store as little as possible. A good setup therefore collects technical states, latency, error rates and volume indicators rather than complete connection lists with destination domains. Debug logs, TLS key logs or unmasked access logs do not belong permanently on production systems.

Monitoring also has to be thought of differently from a normal VPN gateway. It is not enough that the container is running. What matters is whether a real test path through the tunnel works, whether DNS is routed correctly, whether individual target regions suddenly become blocked and whether a node viewed from the affected country looks different than it does from my office.

How I would classify it operationally

For me, Shadowsocks or Xray is not a replacement for firewall architecture, Zero Trust, MFA or clean segmentation. It is a transport tool for special cases.

A sensible company approach could look like this:

1. First check whether normal SSL VPN, IPsec or WireGuard works reliably.
2. If it is blocked, measure cleanly: DNS? Port? Protocol? Server IP? TLS fingerprint? UDP throttling?
3. Then test an alternative transport, for example Shadowsocks or Xray-core.
4. Use the tunnel only for required destinations, not to open the entire customer network blindly.
5. Filter restrictively on the server side which internal services are reachable.
6. Build monitoring so you do not hear from the customer first when the path is blocked again.
7. Have a fallback plan: second exit, different provider, different region, different protocol.
8. Separate secrets and client profiles per site or user so one leak does not compromise everything.
9. Build logs and metrics so operations remain possible without creating unnecessary trails.

Especially with sites, it is tempting to treat “at least it works again” as success. I understand that. When a customer can no longer reach their systems, the first goal is to restore connectivity.

But afterwards you have to clean up. Otherwise a temporary workaround becomes an invisible production path that nobody documented.

Why blockades often catch up

With these tools, you should never forget: the other side continuously adapts its detection.

If many people use the same Docker Compose snippet, the same port, the same TLS fingerprint, the same domain strategy and the same VPS provider, the pattern eventually becomes visible. Then “Xray” or “Shadowsocks” is not necessarily blocked in an abstract sense. A concrete pattern is blocked: specific handshakes, packet sizes, known IP ranges, typical clients, badly configured fallbacks or suspicious error responses.

That is why camouflage is not only a feature inside the tool. Camouflage is operations: the same tools, different domains, different providers, different client profiles and different traffic patterns can look very different in practice.

That is also why I am careful with some project or community claims. If a tool claims it is not detectable, that is first a project claim. If a paper shows that a specific feature was detected in a real network, that has a different quality. In practice you need both: the innovation speed of the projects and the sobriety of research.

My assessment

When I sort the topic for myself, I arrive at a simple classification.

Shadowsocks makes sense when you need a slim, fast, relatively simple encrypted proxy. It is good for first tests, temporary access and environments where no extremely aggressive detection is active.

Xray-core makes sense when the network is harder, when multiple transport variants are needed or when you deliberately want to work with VLESS, REALITY, WebSocket, gRPC or XHTTP. But you have to understand more. Xray is less forgiving because its flexibility also allows more misconfiguration.

For customer environments, I would never sell either as a “VPN replacement”. I would describe it as an alternative transport path for legitimate access. That sounds less spectacular, but it is more honest.

The most important difference in the end is not Shadowsocks versus Xray. The most important difference is: do I understand which problem I am solving?

If the problem is a normal remote-access scenario, I use normal VPN technology. If the problem is state or provider-side protocol detection, I have to talk about recognizability, fingerprints and operational strategy. And if I cannot explain that cleanly, I should not operate it productively for customers.

Conclusion

Shadowsocks and Xray-core are tools from a world where network connections do not simply “work” or “not work”. Sometimes they are classified, throttled, actively tested or blocked. Anyone who supports international customers will eventually encounter those realities.

I find the topic interesting precisely because it makes networking very concrete. It is not only about encryption. It is about patterns, fingerprints, routing, DNS, operations, law, responsibility and the fact that a working tunnel is not automatically a good design.

For me, the next step is clear: I do not want to know Shadowsocks and Xray-core only superficially, but to reproduce them in a small lab. Not to blindly bypass censorship, but to better understand why classic VPNs sometimes stand out and which alternatives can be operated in a technically serious way.

Until next time,
Joe

FAQ