Setting Up Shadowsocks on a VPS: A Current Server and Client Guide

There is not much to a basic Shadowsocks setup. You need a VPS with its own public IP, server software that is still being maintained, a client that works with it, and an AEAD cipher available on both sides.

Getting those pieces to work together is where people tend to run into trouble. The server address, port, encryption method, and secret must be identical on the server and client. The relevant firewall rules also need to be in place. Even after all of that, each application must actually be told to use the Shadowsocks proxy.

This is the part people often overlook. A successful connection in the client only means that the client has reached the server. Your browser, terminal, or any other application may still be using the ordinary network connection.

By following these steps, you can effectively bypass censorship, protect your privacy, and access geo-restricted content.

Before your Shadowsocks Setup: choose a maintained implementation

Be careful with older Shadowsocks tutorials. Quite a few of them still rank well in search results, even though their installation instructions have not aged particularly well.

Some recommend clients that are no longer maintained. Others point to abandoned repositories or use older AES-CFB ciphers as if they were still the obvious choice for a new server. They are not.

Begin with an implementation that has recent releases and usable documentation. shadowsocks-rust is one widely used option. It includes server and client components and supports current cipher suites.

It is worth checking the project documentation before installing anything, even if you have configured Shadowsocks in the past. Package names disappear, repositories move, container images change owners, and release layouts get reorganized. Following the current official release instructions is usually safer than adding a third-party repository copied from a tutorial written several years ago.

Step 1: Prepare the VPS

Use a supported Linux distribution and install the available system updates before setting up Shadowsocks.

Create a non-root account with administrative privileges, tighten your SSH configuration, and make a note of the VPS public IP address. You will also need to select a port for the Shadowsocks service. Shadowsocks does not require one universal port, so the choice depends on what else is already running on the machine and how you intend to manage access.

Do not simply assume that your preferred port is available. If the server already runs a website, control panel, API, database, or another proxy service, inspect its current listeners first.

A port collision is not an interesting problem, but it can be a frustrating one. The configuration may look completely reasonable while ssserver quietly fails because another process has already claimed the address.

Step 2: Install the Shadowsocks server

Install your chosen implementation using the instructions maintained by its own project.

For shadowsocks-rust, the server executable is generally named ssserver. Once it is installed, check the installed version and keep that information handy. If the service behaves differently from an example you find later, the version number will help you work out whether the example still applies.

Cipher selection matters here. Older stream ciphers may remain available for compatibility, but that does not make them suitable defaults for a server being deployed today.

Choose a modern AEAD method that is supported by both the server implementation and every client you plan to use. Checking the clients now is easier than discovering an incompatibility after the server is already running.

Step 3 of the Shadowsocks Setup: write the server configuration

The core configuration is short. It needs four essential pieces of information:

• the interface or address that should accept connections
• the port assigned to Shadowsocks
• the cipher selected for this server
• the secret shared with its clients

One possible configuration would bind the service to 0.0.0.0 on port 8388 and use aes-256-gcm or chacha20-ietf-poly1305. That is only a workable example. Your own values should come from the software version, clients, and network environment you are actually using.

Spend a little more time on the secret. It should be long, random, and unique to this service. A memorable word with a few numbers attached is not a good substitute. Once the file has been created, restrict its permissions so that unrelated users on the server cannot read it.

Configuration formats are not identical across all Shadowsocks implementations. They can also change between releases. An example from another project—or even an old example from the same project—may contain unsupported fields or slightly different syntax.

Compare your configuration with the documentation for the exact version you installed. That small check can save a surprisingly long troubleshooting session.

Step 4: Configure the firewall

When seting Up shadowsocks, allow the traffic you need and leave unrelated ports closed.

For TCP relay, permit incoming TCP connections on the port selected in the server configuration. If your use case requires UDP relay, you may need a separate UDP rule for that same port. Opening the TCP port does not automatically permit UDP traffic.

There may also be more than one firewall between the client and the service.

Many VPS providers place a network firewall or security group in front of the virtual machine. Linux may then apply its own firewall rules inside the VPS. A port allowed in one layer can still be blocked by the other, so check both whenever the server appears to be running but remains unreachable.

Step 5: Run the server outside your SSH session

Run ssserver with the new configuration and check which address and port it has bound to. If those values differ from the ones you expected, sort that out before moving to the client.

For the first run, starting it in an SSH terminal is perfectly reasonable. You can see errors as they happen. Just do not leave it that way once the test is over: closing the terminal may kill the process, and a server reboot will not bring it back automatically.

For regular use, run Shadowsocks through a service manager such as systemd, where available. Configure the service to restart appropriately and start with the operating system.

Before connecting several devices, look at the startup logs. This is where you are likely to spot an invalid cipher name, a malformed configuration, an incorrect file path, insufficient permissions, or a port already occupied by another process.

Fixing those problems now is much easier than investigating them later through a client that only reports a generic connection failure.

Step 6: Configure the client

Install a currently maintained Shadowsocks-compatible client on each device that will use the proxy.

The client needs the same connection details as the server:

• server IP address or hostname
• server port
• cipher
• secret

One incorrect character is enough to break the connection. Pay particular attention when copying a long generated secret or choosing a cipher from a dropdown containing several similar names.

After connecting, most clients create a local proxy endpoint on the device. This is often a SOCKS5 listener bound to 127.0.0.1 on a local port. Applications that support SOCKS proxies can be pointed directly to that address.

This does not necessarily change the route for the entire device. System-wide proxying is a separate job. If that is what you need, select a client with a supported TUN or transparent-routing mode and read how it handles exclusions, local traffic, and DNS. Those details vary considerably between platforms and clients.

Step 7: Check where the traffic is really going

A green status light tells you that something connected. It does not tell you which applications are using the proxy.

Start with one application and set its proxy manually. Once the client has reached the server, open an IP-checking page through that application. If the route is working as intended, the address shown there will usually belong to the VPS rather than your home or mobile connection.

Then repeat the test with an application that has not been configured to use the proxy.

The difference between those two results tells you something important. It shows whether application traffic is actually passing through Shadowsocks, rather than merely confirming that the client can communicate with the server.

Run a separate DNS check if leaks or split routing would be a problem in your case. The IP shown by one browser only describes that browser’s web traffic. DNS queries—and traffic from everything else on the device—may be following another route.

Where to look when the setup does not work

A timeout is usually a reason to check the route before touching the cipher settings. Make sure you have the right VPS address and port, then confirm that ssserver is running and has bound to an interface the client can reach. Check the firewall inside Linux as well as the firewall in the provider’s dashboard.

If all of that looks right, try the connection from another network. The block may be somewhere between the client and the VPS rather than on the server itself.

Cipher and authentication messages usually mean the two configurations do not match. Open the client and server settings together and compare the method and secret character by character. This is worth doing even if you are certain you copied them correctly.

UDP problems can be less obvious. You may find that browsing and other ordinary TCP traffic work while an application that relies on UDP does not. In that case, confirm that UDP relay is supported and enabled where needed. The selected port must also be permitted over UDP at every firewall layer.

Slow performance deserves measurement before configuration changes.

Check the latency between the client and VPS, look for packet loss, and see whether the server is reaching its CPU or network limits. The route between the VPS and the destination can also be poor even when the route from your device to the VPS looks fine.

Changing the cipher may affect performance in some environments, but it is only one part of the journey. Moving the VPS closer to the client or choosing a provider with better routing can make a much larger difference.

Making a VPS-based Shadowsocks server less exposed

Apply updates to the VPS and Shadowsocks instead of leaving a working installation untouched for years. Give the service its own random secret, limit who can log in over SSH, and shut down anything running on the server without a purpose.

Monitor resource use as well. This is particularly useful on smaller plans, where a traffic spike or busy process can exhaust the available CPU, memory, or bandwidth sooner than expected.

It is also important to be clear about what Shadowsocks protects.

The encrypted Shadowsocks link ends at the VPS. From there, the destination still needs to protect the connection itself. That is why HTTPS remains necessary: Shadowsocks and HTTPS cover different parts of the route.

Keep a backup of the server configuration if rebuilding the service quickly matters to you. The backup must be protected, however, because it contains the shared secret.

Avoid exposing that secret in screenshots, public repositories, support messages, or commands that will remain in shell history. If you suspect it has been disclosed, replace it rather than hoping nobody noticed.

Where to go from here

A Hostomize VPS gives you somewhere to run the Shadowsocks server without locking you into a preconfigured proxy product.

The choices above remain yours: the software release, cipher, firewall policy, routing rules, and client settings. That does mean a little more work at the beginning, but it also leaves you free to change or rebuild any part of the setup later.