shadowsocks_install: eight scripts, four implementations, three distros

One script per implementation and distro pair, not one installer

The first thing to understand is that there is no install command to run and no single entry point. The repository is a shelf of shell scripts, each covering one combination of server implementation and distro family, and the file you pick decides what you get. Across the top level there are scripts for the Python, libev, Go and ShadowsocksR implementations, a separate libev script for Debian and Ubuntu against the CentOS one, a watchdog, and an haproxy helper. Nothing in the repository marks one implementation as preferred over another, so the choice is delegated to you and to the page each script links to. Next to the scripts the tree also carries extensionless files named after the same variants, such as shadowsocks-libev-debian and shadowsocksR, plus a shadowsocks-manager file and the docker/ and sample_config/ directories, and none of those are described in the Readme.

shadowsocks.sh
shadowsocks-libev.sh
shadowsocks-libev-debian.sh
shadowsocks-go.sh
shadowsocks-crond.sh
shadowsocksR.sh
shadowsocks-all.sh
haproxy.sh

CentOS and Debian get different libev files for the same server

The clearest illustration of the split is the libev implementation, which has two scripts rather than one. shadowsocks-libev.sh installs the libev server for CentOS, and shadowsocks-libev-debian.sh installs the same server for Debian and Ubuntu, each with its own documentation page on teddysun.com. That duplication is the whole design: package names, service names and paths differ between the two families, so a script written for one is not quietly reusable on the other. The consequence for a reader is that reading the wrong file's page gives you instructions for a distribution you are not running. It also means upgrades are per file. There is no shared installer to update, so when a base package moves or a service definition changes, each script has to be revisited on its own.

shadowsocks-crond.sh is a watchdog, not an installer

One script in the set has a different job from all the others. shadowsocks-crond.sh checks whether a Shadowsocks server of any version is running and starts it if it is not. That makes it the piece that keeps a stopped node alive, and its stated scope is deliberately wide: any version, not the one a particular installer script put in place. What the Readme does not give you is the half that makes a watchdog work. There is no crontab line, no systemd timer unit and no install target shown, so how often it should run, under which account and with what working directory are decisions you have to make and document yourself. The script name hints at cron, but the scheduling is left as an exercise.

shadowsocks-all.sh installs every implementation on one host

There is also a script that covers every implementation. The Readme describes shadowsocks-all.sh as auto installing the Shadowsocks server (all version) for CentOS, Debian and Ubuntu, documented on its own teddysun.com page. The Readme does not say whether that means installing every implementation side by side or choosing one of them at run time, so read its page before running it on a machine that already has a server.

haproxy.sh puts a second daemon on the same host

Two of the eight scripts are documented somewhere other than teddysun.com. shadowsocksR.sh points at shadowsocks.be/9.html, and haproxy.sh points at shadowsocks.be/10.html, while the other six link to numbered pages on teddysun.com. The haproxy script exists to install haproxy for a Shadowsocks server, which means a second network daemon on a machine that already runs one, with its own configuration and its own failure modes to reason about when traffic stops flowing. The Readme does not show the resulting haproxy configuration or explain how the two are wired together, so the haproxy layer is something you assemble from an external page and then own. Two services also means two things to restart after a reboot.

Each script links to its own page, and the Readme is only the index

The whole of the Readme is a list of script names, one-line descriptions and links, which makes it an index rather than a manual. Each entry points somewhere different: teddysun.com/342.html for the Python server, 357.html for libev on CentOS, 358.html for libev on Debian and Ubuntu, 392.html for the Go server, 525.html for the watchdog, 486.html for the all-versions installer, and the two shadowsocks.be pages for ShadowsocksR and haproxy. That means eight separate pages to reconcile before you understand what any of the scripts do, and no single place where the options, defaults and failure cases are listed side by side. The copyright line reads 2014-2019, which tells you how long the index has been assembled and by whom, but nothing about which pages are still current.

No releases, no stated license, and you run master

The repository has no GitHub releases. Pin a specific Git commit and review its scripts before running them; the recorded last push was on 2026-03-07. For shell scripts that install services, that distinction is the difference between a script you can name in a runbook and one that changes under you, and there is no changelog to tell you what changed. The license is not stated either: the Readme carries a copyright line for 2014-2019 and nothing about terms, which is worth settling before you redistribute or build on any of these files. Treat the linked pages, not the repository, as the thing you should keep a copy of.

Editorial conclusion

It fits someone administering their own CentOS, Debian or Ubuntu machine who wants the server installed by script and is willing to read the linked page for the options that matter. It does not fit anyone looking for a Windows client, a documented container build, or a pinned release to deploy, since the repository publishes none. Before running anything, check four things: which implementation the page for your script recommends, because no file is marked as preferred; how the script names and registers the service on your distro; how shadowsocks-crond.sh is meant to be scheduled, since no cron line is given; and the absence of stated license terms, which matters if you intend to redistribute or audit what you run.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. teddysun/shadowsocks_install on GitHub