goproxy: one Go binary that speaks HTTP, SOCKS5, TCP, UDP and WebSocket

A protocol list that hides the real subject: routing

The pitch on the repository page is a protocol list. goproxy handles HTTP, HTTPS, SOCKS5, WebSocket, TCP and UDP, and the topics on GitHub match that inventory: http-proxy, socks5-proxy, websocket-proxy, tcp-proxy, udp-proxy, transparent-proxy, kcptun, ss-proxy. Read as a capability list it looks like a Swiss army proxy. Read as a design, it is one routing engine with several transports bolted onto it.

The routing rules show this more clearly than the feature list does. The tree contains `resolve.rules` and `rewriter.rules`, plus bare files named `hosts`, `blocked`, `ad.txt` and `dr.txt`. Those are decision inputs: names to resolve, rules to rewrite, hosts to route directly, and names to refuse. Everything else in the project, chain or single hop, is a way of arriving at the same routing decision.

There is also a `config.go` at the repository root, which tells you flags are parsed in Go rather than from a config file alone. The go.mod pins `gopkg.in/alecthomas/kingpin.v2`, a command line parser, which is consistent with that. The repository declares the Go language, GPL-3.0 as its licence, `master` as the default branch, and the homepage goproxy.win.

Chaining, NAT bridging and SSH relay in the same process

Three capabilities here are less common than the protocol list suggests, and they are the ones that make goproxy different from a plain SOCKS5 server.

The first is N-level chaining. The README describes the program acting as an upstream proxy for another copy of itself, so a chain of N instances can sit between a client and the internet. Encryption applies to the hop between two goproxy instances rather than only to the client connection. The second is SSH relay: the README states that HTTP, HTTPS and SOCKS5 traffic can be relayed over SSH so that a local machine comes online through a remote Linux server that runs no proxy daemon of its own. The third is NAT bridging, referred to in the README as `tbridge`, which sits alongside client IP black and white lists in the same feature group.

Protocol conversion is the fourth. An existing HTTP or SOCKS5 or SS upstream can be presented on a single port that answers all three, which is how you consolidate several existing proxies behind one endpoint instead of rewriting client configuration.

Port forwarding is separate from all of this. TCP and UDP port mapping appears as its own feature line, so the same binary can publish a local port as well as proxy traffic.

Getting it onto a machine: install scripts, releases and a docker directory

The repository ships four shell scripts at the top level: `install.sh`, `install_auto.sh`, `install_commercial.sh` and `install_auto_commercial.sh`, plus `uninstall.sh` for removal. There is also a `docker/` directory. The scripts come in matched pairs, one interactive and one automatic, which tells you the project expects some hosts to be provisioned by a human watching a terminal and some to be provisioned by a provisioning system.

The Go module identity and toolchain line are the two facts worth confirming before you build:

module github.com/snail007/goproxy

go 1.16

A module directive at `go 1.16` means the project still declares an old language version even though the current release line is v15.3. Newer Go toolchains build it, but the declared floor is a useful signal about what the code has been checked against.

For a host you are setting up by hand, the script is the documented path:

sh install.sh

The README also links binary downloads on the releases page and an official site at goproxy.win. Note the shape of the release history: v15.1 on 2025-06-11, v15.2 on 2025-09-02 and v15.3 on 2026-08-17, the same day as the last push recorded for the repository. A gap of roughly a year between v15.1 and v15.2 is worth knowing before you pin a version.

TLS, KCP and an AES layer you can add on top

Encryption is presented in layers rather than as one on or off switch, and the certificate flags are where the detail sits.

The README states that by default the `-C` and `-K` flags take file paths to a certificate and its key. If either value starts with `base64://`, the remainder is treated as base64 data and decoded after being read. That is a meaningful deployment detail: it lets a certificate be supplied as an environment variable or secret value in an orchestrator without writing it to disk.

Above TLS, the KCP protocol from kcptun is supported for HTTP, SOCKS5 and SPS proxies, described as reducing latency on lossy links. On top of TLS and KCP the project offers optional custom encryption with internal AES256, where you define a password, and optional compression applied after encryption. The order matters: compression runs on already-encrypted bytes, so it cannot reduce the size of the ciphertext.

Load balancing and speed limits are also in scope. The README lists upstream load balancing and high availability with repeated upstream parameters, plus speed limiting across HTTP, SOCKS5, SPS and TCP proxies, and per-user or per-IP limits configured through files.

Free build, commercial build and a family of sibling repositories

The README is candid that goproxy exists in two editions and links a page comparing free and commercial. That comparison matters for anyone evaluating the project, because the feature list on the repository page does not say which column a given capability falls into.

The ecosystem is spread across sibling repositories rather than kept in one tree. The README links a desktop edition at `snail007/proxy_admin_free`, an Android global edition at `snail007/goproxy-ss-plugin-android`, an Android server edition at `snail007/goproxy-android`, and an SDK at `snail007/goproxy-sdk`. Each of those is a separate repository with its own release cycle.

The web console is the ProxyAdmin project, presented as a powerful web console for goproxy. In this tree the `gui/` directory is where in-repository console work sits, and `main.go` is the entry point. If you are evaluating goproxy as an infrastructure component, the practical question is not only what the free build does but how much of the management surface you get without the commercial one, and the repository does not answer that in one place.

What the repository layout tells you, and what the README leaves out

The top-level entries describe the architecture better than the README does. `direct/` and `blocked/` are directories rather than single files, so routing decisions are structured. `services/` holds the proxy services themselves. `utils/` holds shared helpers. `doc/` and `docs/` are two separate documentation directories, with the README pointing at hosted manuals under `snail007.goproxyauth.com` and `snail007.github.io`. `rhttp.toml` is the sample configuration, and `VERSION` and `CHANGELOG` are tracked in the repository root, so version history is partly readable without leaving the tree.

Dependencies are unusually light for a project of this scope. go.mod requires kingpin.v2 for flag parsing, `golang.org/x/time` for rate limiting, and three indirect packages including `stretchr/testify` for tests. A proxy that handles SOCKS5, UDP and WebSocket normally pulls in protocol libraries, so their absence suggests the protocol handling is implemented inside `services/` rather than assembled from external modules.

One caveat on the README itself. The feature list on the repository page ends partway through its entry on port range listening, which is the last complete feature before the text runs out. The rule files, the configuration sample and the install scripts are therefore a more reliable guide to what this project does than the feature enumeration, and the hosted manuals are where the remaining detail lives.

Editorial conclusion

goproxy is worth a look when you need a forward proxy, a reverse proxy, an SSH relay or a NAT bridge in one process, because those four things are the project's real subject and the repository layout reflects that. The cost is that the README is a feature inventory rather than a manual, the free build and the commercial build are separate products, and GPL-3.0 is the licence the repository declares. Start by reading install.sh and the rhttp.toml sample in the tree, then decide whether the chain and rule files solve a problem you actually have.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. snail007/goproxy on GitHub