# snell, a one-command installer for Snell proxy servers with a Docker image

> jinqians/snell packages the Snell v4, v5 and v6 proxy servers into a shell installer that detects the distribution and a multi-architecture Docker image that prints the client configuration on first start. It also carries ShadowTLS v3 fronting, multi-user accounts and a management menu.

**jinqians/snell** — Snell V4/Snell V5/Snell V6 一键安装脚本，支持Debian/Ubuntu/Centos/Alpine

- Repository: https://github.com/jinqians/snell
- Website: https://vps.jinqians.com
- Stars: 739 · Forks: 101
- Language: Shell
- License: GPL-3.0
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/jinqians-snell

## What the project packages and where the pieces live

The project is a one-click installer and Docker image for the Snell proxy servers, covering Snell v4, v5 and v6, with support for ShadowTLS v3, multiple users and BBR congestion control. The description also notes that the multi-architecture Docker image prints the client configuration on startup, which is the detail that makes the container approach usable.

The repository layout shows two parallel implementations of the same thing. There are three shell scripts at the top level, snell.sh, snell-centos.sh and snell-alpine.sh, which is the native installation path with a variant per distribution family. Then there is a docker/ directory holding the container build, and the top level also has a src/ directory, a sources/ directory, a scripts/ directory, a tools/ directory and a surge.conf file.

The README is bilingual, with Chinese and English versions linked at the top, and the documentation is a wiki rather than files in the repository. The wiki pages are organised by topic: an introduction with a feature overview and the repository structure, a page on installation and management covering the multi-function menu, having v4, v5 and v6 on one machine at the same time and Alpine, a page on rules-based routing with sing-box, a Docker deployment page covering image tags, ShadowTLS, v6, switching versions, Compose and environment variables, a traffic management page and a PSM proxy management page, a protocol introduction comparing v4, v5 and v6 with the v6 parameter choice and ShadowTLS, and a page on Surge configuration files.

The licence is GPL-3.0, the project is GPL-3.0 as stated in the README, and the last push was on 2026-10-06. The releases are V2.6, V2.7 and V3.0, all in early 2025, and the default branch is main.

One detail in the README is worth noting for anyone assessing the project. The sponsorship section says reputable merchants are welcome to sponsor, and the running statistics section shows a chart of daily runs over the last thirty days, which suggests the installer is used in production by a fair number of operators.

## The installer and how it detects your system

The one-line install is a pipe from a URL into a shell, and there is a per-distribution alternative:

```bash
sh -c "$(curl -fsSL https://install.jinqians.com)"
```

The README says the script detects the system automatically, and the supported list is Debian, Ubuntu, CentOS, RHEL and Alpine. The table then gives the direct commands for each family, with separate URLs for the Alpine native install on 3.18 and below, the Alpine Docker route for 3.19 and later, and a multi-function menu covering Snell, SS-2022 and ShadowTLS.

After installation you run snell to enter the management menu, which the README lists as covering viewing the configuration, changing the port, PSK and DNS, managing multiple users, version management with v4, v5 and v6 coexisting on one machine, ShadowTLS, BBR, and rules-based routing.

The decision about which install to use is worth spelling out, because the Alpine split is not arbitrary. Alpine uses a different init system and a different package manager, so the native script for 3.18 and below is a different code path, while 3.19 and later are pointed at the Docker route instead. That is a sensible way to handle the fact that newer Alpine releases changed how the base image works.

The single command form deserves a mention because it is the kind of thing worth thinking about before running. Piping a remote script into a shell means the content that runs is whatever the server returns at that moment, and this is a Chinese-language hosting tool distributed with a set of per-distribution URLs. The scripts are in the repository, so the alternative is to read the relevant one first and run it from a local copy, which takes a minute and removes the question of what changed between your review and the fetch.

## The Docker image and the compose file

The image is published on Docker Hub as jinqians/snell-server and is multi-architecture, with amd64, arm64 and armv7, and the README notes that v6 has no armv7 build. The container runs as the nobody user, which is why the configuration directory has to be created and chowned first:

```bash
mkdir -p ./snell-config && chown -R 65534:65533 ./snell-config
docker run -d --name snell-server --restart unless-stopped \
  -p 6160:6160/tcp -p 6160:6160/udp \
  -e SNELL_VER=v5 -e SNELL_PORT=6160 \
  -v ./snell-config:/etc/snell \
  jinqians/snell-server:v5
```

The numeric user and group identifiers are the standard nobody pair, and matching them on the host directory is the detail that stops the container failing to write its configuration.

Both TCP and UDP are published, and that is not a mistake. Snell carries its traffic over UDP, and the TCP mapping covers the case where a client falls back or where the server expects a connection on the same port.

The compose file is the same configuration expressed as a service:

```yaml
services:
  snell:
    image: jinqians/snell-server:v5
    container_name: snell-server
    restart: unless-stopped
    ports:
      - "6160:6160/tcp"
      - "6160:6160/udp"
    environment:
      - SNELL_VER=v5
      - SNELL_PORT=6160
    volumes:
      - ./snell-config:/etc/snell
```

The version is selected twice, once in the image tag and once in the SNELL_VER environment variable, and the README explains that for v6 you use the v6 tag and SNELL_VER=v6, plus the SNELL_MODE variable to pick the encryption mode, with the note that the client must agree with the server on the mode. That last constraint is the one to keep in mind: a mismatch does not produce a helpful error, it produces a connection that never establishes, and the README says as much by telling you the client has to match.

ShadowTLS is optional in both paths. In the script install it is a menu entry, and in Docker it is enabled with environment variables such as SHADOWTLS_ENABLE=1. The effect is that the server exposes only the ShadowTLS port, so what is on the wire looks like ordinary TLS to a casual observer.

## Getting the client configuration and the protocol differences

This is the part of the design that makes the container approach work, and it is short.

With the script install, you run snell and pick the view configuration entry from the menu. With Docker, the configuration is printed in the container logs on first start and is also saved into the configuration directory as client-config.txt.

What you get is a Surge format line, and the README shows the shape of one:

```text
HK = snell, 1.2.3.4, 6160, psk = your_psk, version = 5, reuse = true, tfo = true
```

The first field is the label, then the protocol name, the address, the port, the pre-shared key, the version, and the connection options. The reuse and tfo flags correspond to connection reuse and TCP fast open.

The version field is where the protocol differences bite, and the wiki has a dedicated page on it comparing v4, v5 and v6, covering how to choose the v6 parameters. The short version from the README is that the client must match the server, so getting the version right in two places is the whole task.

The ShadowTLS layer changes the port the client connects to, and the wiki has a separate page for Snell with ShadowTLS v3 covering the server side and the client side.

The rules-based routing page is the one that describes a deployment rather than a feature. It explains using sing-box to route by ruleset while the server side remains the official snell-server, which is a useful pattern: the routing intelligence lives in a separate program that speaks the protocol, and the Snell server stays a plain server.

The traffic management page and the PSM proxy management page cover the operational side, and the PSM project is a separate repository in the same organisation named proxy-stack.

## Conclusion

Adopt this project if you operate Snell servers and want the install, the version switching and the ShadowTLS fronting handled by one script and one image rather than by hand. Skip it if you only need a single Snell server on one machine, since the upstream server binary is a small download. Verify first by running the image on a spare port and confirming that the printed client configuration matches the version and mode you selected, and by reading the wiki pages on the protocol versions before exposing anything.

## FAQ

### What does the jinqians/snell project provide?

A one-click installer and a multi-architecture Docker image for the Snell v4, v5 and v6 proxy servers, with ShadowTLS v3 fronting, multi-user accounts, BBR congestion control and a management menu. The image prints the client configuration on first start.

### Which distributions does the installer support?

It detects Debian, Ubuntu, CentOS, RHEL and Alpine automatically, with a separate native script for Alpine 3.18 and below and a Docker based route for Alpine 3.19 and later, because newer Alpine releases changed how the base image works.

### How do I run the Snell server in Docker?

Create a configuration directory and chown it to the nobody user and group, then run the image with both TCP and UDP published on the server port, the SNELL_VER and SNELL_PORT environment variables set, and the configuration directory mounted at /etc/snell. The image is jinqians/snell-server with amd64, arm64 and armv7 available, and v6 has no armv7 build.

### How do I get the client configuration?

With the script install you run snell and choose the view configuration menu entry. With Docker the configuration is printed in the container logs on first start and is also saved as client-config.txt in the configuration directory. The result is a Surge format line containing the protocol, address, port, PSK and version.

### What licence is the snell project released under?

GPL-3.0, with the terms in the LICENSE file. The project is by jinqians, with an English and a Chinese README, a wiki holding the documentation, and a releases list showing V2.6, V2.7 and V3.0 in early 2025.

## Sources

- [jinqians/snell on GitHub](https://github.com/jinqians/snell)
- [License: GPL-3.0](https://github.com/jinqians/snell/blob/main/LICENSE)
- [Project website](https://vps.jinqians.com)
- [README](https://github.com/jinqians/snell/blob/main/README.md)
- [Releases](https://github.com/jinqians/snell/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jinqians-snell