# ginuerzh/gost: a maintenance-mode Go tunnel and proxy chain

> GOST v2 is a multi-protocol proxy and tunnel in a single Go binary, with HTTP2, QUIC, KCP, SSH, Shadowsocks and obfs4 transports. Its README now says new features go to go-gost/gost instead, so the decision is whether v2 still fits your deployment.

**ginuerzh/gost** — GO Simple Tunnel - a simple tunnel written in golang

- Repository: https://github.com/ginuerzh/gost
- Stars: 18,242 · Forks: 2,635
- Language: Go
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/ginuerzh-gost

## What ginuerzh/gost solves for people running proxies and tunnels

The README describes GOST as a secure tunnel implemented in Go, and the feature list is a catalogue of the jobs a network operator usually solves with several separate daemons. One binary listens on many ports at once, each port speaking a different protocol. The README gives a single example that starts an HTTP2 listener on 443, a SOCKS5 listener on 1080 and a Shadowsocks listener on 8338 from one command line. That is the core appeal: instead of running a SOCKS server, a Shadowsocks server and a TLS wrapper as separate services, you run one process and one configuration surface.

The second job is chaining. A gost client can be told to reach a destination through a sequence of forwarding proxies, and the README states each hop may be any HTTP, HTTPS, HTTP2, SOCKS4, SOCKS5 or Shadowsocks proxy. That matters when the path from your machine to the target crosses networks you do not control, and you want to compose existing proxies rather than deploy a new overlay. The same binary also does local and remote TCP and UDP port forwarding, which covers the simpler case where you only need one port moved.

The audience is therefore narrow and technical: engineers who already know which proxy protocol their environment tolerates and need a tool that speaks it. There is no GUI in this repository and no configuration wizard. Everything is flags on the command line or a service definition you write yourself.

## How the listener, chain and transport layers fit together

The repository layout mirrors the design. Top-level Go files such as chain.go, forward.go, relay.go, node.go and selector.go sit alongside protocol files named after their wire formats: http.go, http2.go, kcp.go, quic.go, obfs.go, redirect.go. The command line is parsed in cmd/gost, which is also the build target in the Dockerfile and the Makefile.

A run of gost is described by two kinds of flag. The -L flag defines a listener: an address, optionally a scheme, optionally authentication, and optionally a forwarding target. The -F flag defines a forwarding proxy that outbound traffic passes through. When several -F flags are given, the README states gost forwards the request through the proxy chain in the order the flags appear, ending at the address in the last -F. That ordering is the whole configuration model for chaining, and it means a chain is positional: reordering flags changes the path.

Transport selection is expressed in the scheme of the flag value. http2:// is a standard HTTP2 proxy that stays compatible with HTTPS proxies, while h2:// and h2c:// are channel modes that carry other protocols. quic:// uses quic-go, kcp:// uses kcp-go and kcptun. The README adds two constraints that are easy to miss: QUIC and KCP can only be the first node of a proxy chain. SSH has a similar split, forward+ssh:// for forwarding mode and ssh:// for channel mode.

Encryption is negotiated per protocol rather than globally. The README states that when both ends are gost, SOCKS5 traffic is encrypted because the two sides negotiate the tls or tls-auth methods; if the peer is a standard SOCKS5 implementation, it falls back to no-auth or user/pass. That is a useful property and also the reason a mixed-vendor chain behaves differently from an all-gost chain.

## Installing ginuerzh/gost and running a first proxy

The README lists five installation routes: prebuilt binaries from the releases page, a source build, Docker, Homebrew, and the Ubuntu snap store. The Docker image is published as ginuerzh/gost, and the README shows a version check as the first command, which is the fastest way to confirm the image runs on your host.

```bash
docker run --rm ginuerzh/gost -V
```

If you prefer to build from source, the README's steps clone the repository and build from the cmd/gost directory. The Dockerfile does the same thing with a cross-compilation toolchain and CGO disabled, so a plain local build should match.

```bash
git clone https://github.com/ginuerzh/gost.git
cd gost/cmd/gost
go build
```

The first real use is a proxy on a local port. With no -F flag, gost acts as a standard HTTP and SOCKS5 proxy, so a browser or a curl invocation pointed at that port goes out through it. The README shows the bare form and the authenticated form.

```bash
gost -L=:8080
```

```bash
gost -L=admin:123456@localhost:8080
```

To place a forwarding proxy in front, add -F with the upstream address. The README's example sends traffic from the local listener through 192.168.1.1:8081, and the authenticated variant prefixes the scheme and credentials.

```bash
gost -L=:8080 -F=192.168.1.1:8081
```

```bash
gost -L=:8080 -F=http://admin:123456@192.168.1.1:8081
```

What you should see is the listener accepting connections on 8080 and forwarding them to the upstream proxy. If the upstream requires credentials you did not supply, the connection fails at the handshake rather than at startup, because the README does not describe a preflight check of the forwarding proxy.

## Where ginuerzh/gost v2 stops being the right tool

The most important limitation is stated by the project itself. The README carries a notice that the project has entered a maintenance phase and will not gain new features, and that this repository has been superseded by go-gost/gost, where all new development happens. The same notice points readers to gost.run for v3 documentation and v2.gost.run for v2 documentation. Anyone starting a new deployment today should treat that as the deciding fact, not as a footnote. The last push to this repository was on 2026-08-30, and the most recent release listed is v2.12.0 from 2024-10-10, so the v2 line is not where new work lands.

There are also mechanical constraints inside v2. QUIC and KCP can only occupy the first position in a proxy chain, so a design that wants to switch transport mid-chain cannot be expressed. UDP forwarding through a chain requires the last -F to be a gost SOCKS5 proxy, because the README states gost uses UDP over TCP for that case; a chain ending in a non-gost SOCKS5 server will not carry UDP the way you might expect. Shadowsocks UDP relay is server-side only according to the README, so a client cannot use gost for that direction.

Forwarding tunnels have a timeout. The README states each UDP forwarding channel closes when no data crosses it within the timeout, and that the default is 60 seconds, adjustable with the ttl parameter. For a long-idle UDP flow that is a behaviour you must plan around. Finally, the built-in TLS certificate is convenient for testing and a poor choice for anything public; the README explains that gost loads cert.pem and key.pem from its working directory if present, or takes explicit paths through the cert and key parameters.

## How this differs from a single-protocol proxy such as Shadowsocks

The obvious alternative for tunnelling is a dedicated Shadowsocks implementation, and gost does support the Shadowsocks protocol through the shadowsocks-go library, with ss:// for TCP and ssu:// for server-side UDP relay. The difference is scope rather than speed. A Shadowsocks server does one thing: it speaks the Shadowsocks protocol to clients and forwards their traffic. It has no concept of a proxy chain, no HTTP2 or QUIC transport, and no per-listener protocol mixing.

In gost the Shadowsocks listener is one of several that can share a process. The README's multi-port example starts an HTTP2 listener, a SOCKS5 listener and a Shadowsocks listener together, and the same outbound chain can sit behind all of them. That composition is the reason to choose gost over a single-protocol server. The reason to choose the single-protocol server is the reverse: a smaller surface, fewer moving parts, and no ambiguity about which negotiation path a given connection took. If your environment only ever needs Shadowsocks, adding gost adds transports you will not use and a configuration model you must learn.

The same trade-off applies against the successor project. go-gost/gost is not a different kind of tool; it is where the same project continues. Choosing between them is a question of whether you want the frozen v2 behaviour or the actively developed line, and the README is explicit that new features go to the new repository.

## Conclusion

Adopt ginuerzh/gost v2 when you need a single binary that speaks HTTP, SOCKS5, HTTP2, QUIC, KCP, SSH, Shadowsocks and obfs4 on the same host, and you can pin the release you build against. Do not adopt it for new protocol work: the README states the repository has been superseded by go-gost/gost and that new features are developed there. Before committing, verify that the transports you need are still present in the v2 tree you build, check whether your deployment depends on the built-in TLS certificate or on cert.pem and key.pem in the working directory, and read the v2.gost.run pages for the flags you intend to use rather than relying on the quick-start examples alone.

## FAQ

### Is ginuerzh/gost still maintained?

The README states the project has entered a maintenance phase and will not add new features, and that the repository has been superseded by go-gost/gost where all new development happens. The last push to this repository was on 2026-08-30, and the latest release listed is v2.12.0 from 2024-10-10.

### How do I install ginuerzh/gost with Docker?

The README publishes the image as ginuerzh/gost and shows a version check with docker run --rm ginuerzh/gost -V. The repository Dockerfile builds the binary from cmd/gost and sets it as the entrypoint.

### What proxy protocols does ginuerzh/gost support?

The README lists HTTP, HTTPS, HTTP2, SOCKS4(A) and SOCKS5, Shadowsocks over TCP and UDP, SNI proxy, SSH, QUIC, KCP and obfs4, plus TCP and UDP port forwarding and transparent proxy. Each forwarding hop in a chain may be any HTTP, HTTPS, HTTP2, SOCKS4, SOCKS5 or Shadowsocks proxy.

## Sources

- [ginuerzh/gost on GitHub](https://github.com/ginuerzh/gost)
- [Issues](https://github.com/ginuerzh/gost/issues)
- [License: MIT](https://github.com/ginuerzh/gost/blob/master/LICENSE)
- [README](https://github.com/ginuerzh/gost/blob/master/README.md)
- [Releases](https://github.com/ginuerzh/gost/releases)

---

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