Shadowsocks

How the connection works

A local proxy forwards supported traffic to a remote proxy, which connects to the destination. The applications using it and any TUN integration determine coverage. The 2022 protocol edition and older AEAD editions must be identified separately.

Configuration checkpoints

• Match the protocol edition, encryption method and key format on both ends. A 2022 method is not interchangeable with a similarly named older AEAD method.
• Identify application proxy settings and whether the client adds a TUN interface. Record which apps and UDP flows are actually supported.
• Review where hostnames are resolved and which traffic bypasses the proxy. Never share a real ss:// link: it may contain the server address and secret.

Verify the traffic path

• Check IPv4 and IPv6 routes separately. A route for one address family does not demonstrate coverage of the other.
• Check the resolver used by the operating system and by applications that select their own DNS service. A public DNS lookup on this site does not test your device for DNS leaks.
• Observe a controlled disconnect on your own device. Protocol support does not establish a client kill switch or application-specific routing policy.

Diagnose a connection problem

Separate endpoint reachability, authentication, route selection and DNS resolution. Record the client version and the exact error; change one setting at a time. A handshake with no working traffic often needs route or resolver investigation, while an authentication error needs credentials or certificate checks.

Scope and limitations

A configured proxy does not automatically capture all device traffic. Check application proxy settings, UDP support, DNS behavior and the specific client implementation.

This page explains a mechanism and a verification approach. It contains no original speed, regional-access or leak measurements. Throughput depends on the implementation, device, path and server; a protocol name cannot identify a universal winner.