# Suo5: an HTTP tunneling tool for forward proxying out of restricted networks

> Suo5 turns a web endpoint into a SOCKS5 proxy through HTTP chunked encoding, with four transport modes for different reverse proxy setups. It is a security testing tool, not a general purpose proxy.

**zema1/suo5** — 高性能 HTTP 正向代理工具 | A high-performance http tunneling tool

- Repository: https://github.com/zema1/suo5
- Stars: 2,813 · Forks: 255
- Language: Go
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/zema1-suo5

## The problem Suo5 solves: a forward proxy out of a network that will not let you out

The README states the goal plainly: stable forward proxying in scenarios where the host cannot reach the outside network. That is a narrow problem with a specific shape. You have code execution or file upload on a server behind a reverse proxy, that server can make outbound HTTP requests, and you want a SOCKS5 listener on your own machine whose traffic exits through the remote host. Suo5 is the client half of that arrangement plus the server-side scripts that make the remote half work.

The audience is stated in the warning at the top of the README: security researchers, network administrators and related technical staff doing authorized security testing, vulnerability assessment and security auditing. The project repeats that unauthorized use is illegal and that the user carries the legal responsibility. That is not boilerplate to skim past. A tool whose entire function is to move traffic through a host you do not own has no benign default use case, and the README does not pretend otherwise.

What distinguishes it from a plain web shell is transport. A web shell gives you command execution; Suo5 gives you a socket. The README positions the performance claim against FRP, saying full duplex mode approaches FRP in transfer performance. That is the project's own comparison, not an independent measurement.

## How the transport modes work and why there are four of them

Suo5 does not have one protocol. It has four modes, and the README's comparison table explains the trade-off in terms of latency and throughput.

Full duplex uses bidirectional Chunked-Encoding so a single connection carries traffic both ways. The README calls this the best performance option and recommends it for direct connections or simple reverse proxies. Half duplex pairs a downstream long connection with upstream short connections, which the README says holds up under Nginx reverse proxying and some WAF scenarios. Classic mode uses short connections in both directions with polling, described as the fallback for multi-layer reverse proxies and environments that strictly limit long-lived connections. Auto is the default and probes the target to pick among the other three.

The mechanism behind the mode selection shows up in the client output. On connecting, the log lines report a preferred connection mode, a handshake with a session id, and then a confirmation of the mode actually in use. In the README example the target settles on half mode, the tunnel starts on 127.0.0.1:1111, and the client opens a test connection to confirm the path works before declaring success.

Classic mode is the one with tunable knobs, because polling is a rate question. The CLI exposes --classic-poll-qps (alias --qps, default 6) and --classic-poll-interval (alias --qi, default 200 milliseconds). Those defaults mean classic mode is not trying to be fast; it is trying to survive. If you find yourself tuning these upward, you are probably in an environment where the long connection modes were blocked for a reason.

## Installing the Suo5 client and running a first tunnel

Suo5 ships as prebuilt binaries on the Releases page. The README lists two families: suo5-gui-* for the graphical version and suo5-cli-* for the command line version, across Windows, macOS (Intel and Apple Silicon) and Linux. The GUI is built on Wails and depends on the system Webview framework. The README warns that Windows 11 and macOS include it, while other systems will prompt to download and install it, and the GUI will not work if that install is refused.

There is no package manager install documented in the README. You download the binary for your platform and run it. The server side is separate: the README says to upload the corresponding server file from the assets directory to the target server and confirm it executes.

The default invocation is deliberately minimal. Auto mode is the default, so one flag is enough:

```bash
./suo5 -t http://target.com/suo5.jsp
```

The README's example output shows the client connecting, reporting a preferred mode of half, completing a handshake with a session id, starting the tunnel at 127.0.0.1:1111, and finishing with a test connection that prints congratulations when it works. Once that appears, the SOCKS5 listener is live. To send a request through it, the README gives this example:

```bash
curl -x socks5h://127.0.0.1:1111 http://internal.target.com
```

If you need the listener reachable from another machine or want authentication, both are flags on the same command. The README shows changing the listen address to 0.0.0.0:7788 and setting credentials with --auth user:pass123. The default listen address is 127.0.0.1:1111 with no authentication, which is a reasonable default and worth keeping unless you have a specific reason to widen it.

## Server-side compatibility is the real constraint on adoption

The client is one binary. The server side is a set of files in the assets directory, and the README's compatibility list is where the practical limits live. Java covers Tomcat, WebLogic, JBoss and Resin, with JDK6 through JDK 2x listed. .Net covers IIS with all .Net Framework versions from 2.0 upward. PHP covers Nginx and Apache environments across PHP 5.6 to PHP 8.x.

Read that list as a set of exclusions. If the target runs a Java middleware not named there, or a runtime outside the stated ranges, the README offers no path. The compatibility claim is broad in version range but narrow in product coverage, which is the opposite of what you might expect from a tool that advertises good server compatibility.

For Java targets the README points elsewhere for deployment, recommending the MemshellParty project to generate a memory shell and inject it. That is a handoff, not an integration: Suo5 does not generate the memory shell itself, and the README does not document that workflow beyond the pointer.

Network conditions get their own list. The README claims support for one, two and multi-layer reverse proxies, for load balancing via traffic forwarding and request retries, and for upstream proxies over HTTP or SOCKS5. The --redirect flag exists specifically for the load balancing case, described as redirecting to a URL when the host does not match. The --proxy flag takes an upstream proxy such as socks5://127.0.0.1:7890. Both are real mechanisms, but neither is documented with a worked example in the README.

## Where Suo5 is the wrong tool, and how it differs from Gost and Neo-reGeorg

The clearest limitation is stated by the project itself, in a note about Burp. The README says that only classic mode supports capturing traffic in Burp, and that other modes will cause connection anomalies. So the mode with the best performance is the mode you cannot inspect. If your workflow depends on seeing requests in an intercepting proxy, you are pushed to the slowest transport, with its polling defaults of 6 queries per second and a 200 millisecond interval. That is a real cost and the README does not soften it.

There are other flags that exist because things break. --no-gzip disables gzip compression and the README says it improves compatibility with some old servers. --no-browser-headers stops sending Accept and Accept-Encoding. --no-heartbeat disables the data the client sends to the remote server every 5 seconds. Each of these is a workaround for a specific failure, and the README does not enumerate which servers need which.

Compared with Gost, the approach is inverted. Gost is a general purpose tunneling and proxy toolkit that you configure to build a tunnel; Suo5 is a single purpose client whose server half is a file you plant on a web server, and whose value comes from surviving middleware that would break a normal tunnel. If you control both ends and can run a real service, Gost is the more direct answer. Suo5 exists for the case where you cannot.

Compared with Neo-reGeorg, the difference is transport engineering. ReGeorg-style tunnels historically rely on request and response cycles over a web endpoint. Suo5's full duplex mode uses bidirectional Chunked-Encoding to get both directions onto one connection, which is where the performance claim comes from. The README's comparison to FRP is the project's own framing of how far that gets.

## Licence, maintenance and what an upgrade costs you

Suo5 is MIT licensed, and the LICENSE file is at the repository root. MIT is permissive: it allows use, modification and redistribution with the copyright notice and permission notice retained, and it provides the software without warranty. Nothing in the README adds terms beyond that, and nothing in it restricts commercial use. If you redistribute the binaries or embed the code, keep the notice intact. That is a description of the licence text, not legal advice; if the deployment matters legally, read LICENSE yourself.

The repository is not archived, and the last push was on 2026-07-14, which is the same date as the v2.2.0 release. Before that, v2.1.0 landed on 2026-01-29 and v2.0.0 on 2025-12-08. Three releases across roughly seven months, with the most recent one recent enough that the project is not dormant.

Upgrade cost is mostly on the server side, and that is the part worth planning for. The client is a binary you replace. The server file is something you deployed onto a target, and the README does not document a version negotiation or a compatibility guarantee between client and server versions. It also does not document rollback. If you upgrade the client and the deployed server file is from an older release, the README gives no statement about whether that combination works. Treat the client and server files as a matched pair from the same release, and keep the previous pair until the new one is confirmed working.

The module targets Go 1.26.5 and replaces the upstream gorilla/websocket with a fork at github.com/zema1/websocket. Anyone building from source inherits that replacement, and it is worth knowing about before you vendor the dependency graph.

## Conclusion

Suo5 fits authorized security testing where a target host can reach the internet but you cannot reach the host directly, and where you control the deployed server file. It does not fit production traffic routing, and it does not fit anyone without written authorization for the target. Before adopting it, verify that the target middleware version is covered by the compatibility list in the README, and test classic mode first if you need to inspect traffic in Burp, because the README states that only the short connection mode survives that.

## FAQ

### What is Suo5 used for?

It is an HTTP tunneling tool that opens a local SOCKS5 proxy and forwards traffic through a remote web endpoint. The README states its purpose as stable forward proxying in scenarios where the host cannot reach the outside network, and limits its intended audience to authorized security testing, vulnerability assessment and security auditing.

### How do I install and run the Suo5 client?

Download the binary for your platform from the Releases page, choosing suo5-gui-* for the graphical version or suo5-cli-* for the command line version. The README does not document a package manager install. Then run the client against a deployed server URL with -t, and the tunnel comes up on 127.0.0.1:1111 by default.

### Which Suo5 transport mode should I use?

Auto mode is the default and probes the target to choose. Full duplex gives the best performance for direct connections or simple reverse proxies, half duplex suits Nginx reverse proxying and some WAF scenarios, and classic mode is the fallback for multi-layer reverse proxies and environments that restrict long connections. The README notes that only classic mode supports capturing traffic in Burp.

### Does Suo5 work with load balancers and upstream proxies?

The README claims support for load balancing through traffic forwarding and request retries, and the --redirect flag exists to redirect to a URL when the host does not match. Upstream proxies are supported through the --proxy flag over HTTP or SOCKS5, for example socks5://127.0.0.1:7890.

## Sources

- [Issues](https://github.com/zema1/suo5/issues)
- [License: MIT](https://github.com/zema1/suo5/blob/main/LICENSE)
- [README](https://github.com/zema1/suo5/blob/main/README.md)
- [Releases](https://github.com/zema1/suo5/releases)
- [zema1/suo5 on GitHub](https://github.com/zema1/suo5)

---

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