Shadowsocks is an encrypted proxy protocol that carries application traffic from a local client to a remote server, which forwards it to the destination. Its protocol defines that protected proxy link, rather than automatically routing every packet from your device or supplying all the features of a managed VPN service.［1］

Key Takeaways:

The application entry, encrypted client-to-server link, and destination connection are distinct stages.

TCP and UDP are supported, but the application and integration must actually use the relevant path.

Classic AEAD and Shadowsocks 2022 have different key, framing, session, and replay rules.

A TUN interface can broaden traffic capture; it is an integration choice rather than a different definition of the protocol.

Encryption and probe resistance do not guarantee invisibility or availability on a particular network.

How does a Shadowsocks proxy carry an application's request?

In a common arrangement, an application sends a request to a local proxy interface supplied by a Shadowsocks client. The client encodes the destination information and protects the traffic for transmission to the remote Shadowsocks server. The server authenticates and decrypts the request, then makes the onward connection. Response traffic follows the corresponding return path.［1］

The figure separates local application entry from the encrypted remote link. It does not imply that the destination is protected by Shadowsocks encryption after the server forwards the traffic. HTTPS, where used, provides a separate browser-to-website protection layer.

The local proxy is not the remote protocol

A local SOCKS interface is one possible entry for applications. The Shadowsocks protocol between client and server is not simply an unencrypted SOCKS request sent over the Internet. It has its own protected message format, and the address information tells the remote server where to forward the traffic. Those two stages are easy to confuse because client applications often show both settings together.［1］

This also explains why merely starting a client does not prove an application is using it. The application may ignore a system proxy preference, use an unsupported traffic type, or send some connections directly. The VPN fundamentals guide places that scope question alongside the broader distinction between tunnels and proxies.

What does Shadowsocks encrypt, and who still needs trust?

Shadowsocks protects the client-to-server proxy link. An observer on that link should not be able to read its protected application payload merely by intercepting the packets. The server nevertheless has to recover destination information to forward the request, so the remote endpoint remains part of the trust model.［1］［2］

The onward connection has its own protection requirements. If an application uses HTTPS correctly, the server forwards encrypted website traffic without possessing the browser's website-session plaintext just because it terminates Shadowsocks. If the application sends unencrypted content, the proxy link does not magically extend its encryption all the way to the destination.

Confidentiality is not anonymity

The destination ordinarily sees the remote server's outgoing address. That address change does not remove a login identity, tracking identifiers, payment eligibility, or information submitted by the application. Similarly, a protected proxy link does not prevent an endpoint from retaining metadata or observing unencrypted content available to it.

The protocol, transport, and obfuscation guide distinguishes these properties. A protocol can encrypt application data without providing Tor's relay separation or a VPN provider's operational privacy policy. Evaluate each claim at the layer that can actually support it.

How do TCP and UDP differ in this model?

For TCP, the remote server can establish an onward stream and relay the application's bytes. Shadowsocks encrypts and frames the data on the client-to-server path; it does not turn the destination into a Shadowsocks participant. Classic AEAD specifies encrypted stream chunks, while the 2022 edition adds its own header structure and related validation.［1］［2］［3］

For UDP, the client and server exchange protected datagrams with destination information and edition-specific framing. Datagram loss, reordering, and network restrictions still matter. Support in the protocol does not prove that a particular client, local proxy interface, or application's integration carries UDP correctly.［1］

Application support and network support are separate

A program that sends TCP through a local proxy may still perform name lookups elsewhere. Another may need a datagram-capable local interface rather than only a TCP proxy setting. Those are integration questions, so “the protocol supports UDP” is not enough to conclude that games, calls, or every DNS query are covered.

Likewise, the remote link and destination link can fail independently. A reachable server does not prove that the requested destination responds, and a working TCP request does not certify the UDP path. Keep these observations separate rather than presenting one successful webpage as a whole-device traffic test.

How do Shadowsocks AEAD and Shadowsocks 2022 differ?

AEAD means authenticated encryption with associated data: encryption is paired with an integrity check. It describes a cryptographic construction, not one interchangeable Shadowsocks wire format. Classic AEAD and Shadowsocks 2022 define different ways to build messages and derive keys, so clients and servers need matching supported methods.［2］［3］

In classic AEAD, a pre-shared master key and a salt are used to derive a subkey. A TCP stream begins with a salt and continues with encrypted length and payload chunks; UDP packets use their own salt-based construction. Salt uniqueness is part of the security requirements. A salt is not a public-key handshake, and changing the salt does not establish forward secrecy.［2］

What the 2022 edition changes

Shadowsocks 2022 requires suitably sized random pre-shared keys for its methods rather than relying on the classic password-to-key convention. It changes key derivation and headers, introduces explicit time and replay requirements, and gives UDP sessions identifiers and packet-counter-based replay windows. Its specification explicitly states that it does not provide forward secrecy.［3］

The following table summarizes edition boundaries, not a recommendation to deploy a particular method. The exact method name and implementation support remain necessary when interpreting documentation or an existing configuration.

Property	Classic AEAD	Shadowsocks 2022
Key starting point	Pre-shared master key, potentially derived from a password	Random pre-shared key with method-specific length
TCP structure	Salt and encrypted length/payload chunks	Revised headers plus protected chunked payload
UDP organization	Salt-based protected datagrams	Explicit session IDs and packet IDs
Replay handling	Must be evaluated with the classic format and implementation	Explicit specification requirements, including UDP replay windows
Forward secrecy	Salt derivation is not a fresh asymmetric handshake	Specification explicitly says no forward secrecy

Do not describe the older format as having no replay defenses solely because the 2022 specification strengthens the rules. Conversely, do not copy 2022's session and replay semantics into an explanation of every classic client. An edition-qualified statement is more useful than a universal “Shadowsocks is secure” label.

Does TUN mode turn every application into a proxy client?

TUN integration captures IP packets through a virtual interface and can translate suitable traffic into proxy operations. It broadens the entry mechanism, but the Shadowsocks client-to-server protocol still forwards application traffic. Traffic capture, translation, route selection, and the encrypted remote link are separate responsibilities.

A broad route can be useful without proving complete coverage. IPv4, IPv6, DNS, excluded routes, unsupported traffic, and disconnect behavior still require verification in the specific software. A TUN option is therefore evidence of an interface mechanism, not a certificate that every packet and every failure state is handled.

Entry arrangement	What may enter the proxy path	What must be checked separately
Application proxy setting	Requests from applications honoring that setting	Other apps, local DNS, and supported UDP behavior
Operating-system proxy preference	Applications that follow the OS preference	Apps that ignore it and non-proxy traffic
TUN integration	IP traffic captured and translated by the client	Routes, address families, DNS, exclusions, and failure policy

Compare traffic scope before comparing product labels

When comparing a Shadowsocks setup with AethoVPN's documented global-mode behavior, begin with the actual traffic capture rules: an application proxy preference and a device-wide routing mode describe different coverage. The WireGuard and Shadowsocks scope comparison helps identify which arrangement fits a traffic requirement; it does not establish which protocol a managed service uses.

The WireGuard IP tunnel explanation shows the contrasting starting point. The VLESS/REALITY and Shadowsocks comparison provides a separate layer-by-layer comparison without substituting a proxy-core feature for a protocol property.

Can encrypted Shadowsocks traffic still be detected?

Encrypted bytes can still have observable packet sizes, timing, addresses, and implementation behaviors. Active probing adds another question: how does a suspected server react when a network observer sends crafted traffic to it? Neither ordinary encryption nor an address change proves immunity to either form of detection.

A 2020 measurement study of China's filtering system reported passive identification followed by active probes against the Shadowsocks deployments examined. That finding describes the study's dates, network, implementations, and tested formats. It predates Shadowsocks 2022 and is not evidence that every current 2022 deployment responds the same way or that all networks use the same detection rules.［4］

Avoid turning a design goal into an availability promise

The 2022 specification includes requirements aimed at resisting replay and active probing, including handling invalid requests. These are protocol and implementation requirements, not a guarantee of universal reachability. A server address can still be blocked, and a network can restrict traffic using information beyond decrypted payload content.［3］

Our VPN protocol overview is background for the naming and layers. This article does not present a regional access experiment, a deployment recipe, or a performance ranking. Use permitted software and networks in accordance with local law, organizational rules, and service terms.

Summary

Shadowsocks forwards application traffic over a protected client-to-server link.
Local entry, encrypted carriage, and destination protection have separate boundaries.
Classic AEAD and 2022 must be described with their own key and replay rules.
TUN integration and detection resistance need implementation-specific evidence.

FAQ

Is Shadowsocks a whole-device VPN by itself?

Shadowsocks defines an encrypted proxy protocol rather than automatic whole-device routing. A client may add TUN integration, but routes, DNS, address families, and failure behavior still determine the actual scope.

Is Shadowsocks just SOCKS5 with another name?

A local SOCKS interface can feed a Shadowsocks client, but the remote encrypted protocol has its own format. The local application entry and protected client-to-server link are distinct stages.［1］

Can Shadowsocks carry UDP traffic?

The protocol supports UDP forwarding as well as TCP. Actual UDP coverage also depends on the client, application entry mechanism, and network path, so a TCP webpage test does not certify it.［1］

Are classic AEAD and 2022 keys interchangeable?

The editions have different method requirements and wire formats. A client and server must agree on a supported method and its valid key format; a shared product name does not make configurations interchangeable.［2］［3］

Does Shadowsocks 2022 provide forward secrecy?

The 2022 specification explicitly says it does not provide forward secrecy. Random pre-shared keys and session-specific derivation do not replace a fresh asymmetric key agreement providing that property.［3］

Does a proxy server see HTTPS website content?

Correctly used HTTPS still protects browser-to-website content while the proxy forwards it. The server handles destination information and metadata, and unencrypted application content has different exposure.

Does active-probing resistance guarantee that a server stays reachable?

Probe resistance addresses particular identification techniques rather than every reason a connection can fail. Address blocking, passive observations, network restrictions, and implementation differences can still affect reachability.

Disclaimer: This conceptual explanation is not a regional access test or an instruction to override local law, network policy, or service terms.

Sources

Sources checked 5 October 2026.

What Is Shadowsocks? How the Proxy Protocol Works