Skip to main content

Protocol guide

What is Shadowsocks? ss:// links, encryption and safety

Shadowsocks is an encrypted proxy protocol derived from the SOCKS5 model. A usable profile needs a supported encryption method, password, host and port; a reachable socket alone is not a working proxy.

Checked Shadowsocks servers Compare all protocols Verification method
Network cables connected to routing equipment for a Shadowsocks protocol guide

Quick facts

Encrypted TCP and UDP proxyTransport
Cipher and passwordAuthentication
ss:// linkConfiguration

Shadowsocks in plain English

The local Shadowsocks client accepts proxy traffic from applications, encrypts it and sends it to the remote server. The server decrypts each request and connects to the destination. TCP and UDP support depends on both the client and server configuration.

Important: encryption protects traffic between the client and endpoint, but it does not make an unknown public operator trustworthy.

How Shadowsocks works

  1. An application sends traffic to the local Shadowsocks SOCKS or TUN interface.
  2. The client encrypts it using the configured method and password.
  3. The remote server decrypts the request and relays it to the destination.
  4. Responses return through the same encrypted proxy path.

Configuration fields that must be complete

FieldWhy it matters
Host and portRemote Shadowsocks endpoint.
Encryption methodMust be supported and match exactly.
Password or key materialCredential used by the selected method.
Plugin optionsOptional transport plugins must match on both sides.

PublicVPNList publishes a download only when the exact configuration is still present in an allowed, publication-compatible source and its fresh full-tunnel check succeeds.

Strengths

  • Small profiles and broad client support.
  • Can relay both TCP and UDP when configured on both ends.
  • Outline access keys use the Shadowsocks protocol family.

Limits and risks

  • It is primarily a proxy; full-device routing requires client TUN/VPN mode.
  • Old or unsupported cipher choices may fail or weaken compatibility.
  • Encryption does not prove that a public operator is trustworthy.

Safe setup and verification

  1. Use a maintained client that explicitly supports Shadowsocks.
  2. Inspect the server, transport, identity and authentication fields before importing.
  3. Keep certificate and server-identity validation enabled where the protocol supports it.
  4. Connect without opening sensitive accounts, then verify the visible IP and DNS path.
  5. Disconnect and remove stale public profiles after low-risk testing.
Check public IPRead public VPN risks

Common connection problems

  • Confirm that the cipher name and password match exactly.
  • Remove unsupported plugins or copy every plugin option.
  • Check whether the client has UDP relay enabled when needed.
  • Verify changed public IP and DNS after enabling full-device mode.

A client “connected” indicator is not enough. A valid test must send real HTTPS traffic through the protocol and confirm that the public exit IP changed.

Official technical reference

For field semantics and protocol behavior, consult the Shadowsocks documentation. PublicVPNList adds operational testing and publication policy; it does not replace the specification.

Related protocol guides

Frequently asked questions

Is Shadowsocks a VPN?
Shadowsocks is primarily a proxy protocol. It becomes a full-device path only when a compatible client routes all traffic through a TUN or VPN interface.
What does a usable Shadowsocks profile need?
It needs all endpoint, authentication, transport and security fields required by the server. A hostname and open port alone are not a downloadable working configuration.
How does PublicVPNList verify Shadowsocks endpoints?
The checker starts the real protocol client in an isolated VM, sends HTTPS through the tunnel and requires the observed public exit IP to differ from the direct checker IP.
Is a checked public endpoint safe for sensitive accounts?
No technical connectivity test can verify the operator, logging policy or jurisdiction. Avoid banking, private work and identity-sensitive sessions on unknown public infrastructure.

Page history

  • 2026-08-31 — Published the protocol overview, configuration requirements, troubleshooting guidance, safety notes and PublicVPNList verification policy.