Fuso forwards ports through a server you control, in two Rust binaries

Two binaries and a quick five step path

Fuso ships as two programs produced from one Cargo package: fus runs on a server you control, fuc runs on the machine behind the NAT. The quick start is download the release, extract both binaries, put fus on the server and fuc on the client machine.

The defaults are minimal. The server listens on port 6722. The client forwards to 127.0.0.1:80 and is assigned a random access port, so after starting both sides you visit the random port on the server and traffic lands on port 80 of the client machine, which has to have something listening there.

That random assignment is the first decision to make. You can pin the external port with -b, for example --forward-port 80 -b 8888 to expose an external 8888 that reaches an internal 80. Pinning it is what you need for anything you intend to link to, since a random port changes every run.

The general forwarding flags are --forward-host and --forward-port, so forwarding to an RDP host on an internal network is fuc --forward-host 10.10.10.4 --forward-port 3389. The port the client and server use to talk to each other is separately configurable with --channel-port, which defaults to random.

SOCKS5 and UDP, with anonymous defaults you probably want to change

Beyond one-to-one forwarding, fuc can run as a SOCKS5 proxy. The flags are --socks to enable it, --su to enable UDP forwarding, --s5p for a password and --s5u for a username. UDP is only forwarded when --su is given, which the README states explicitly.

The defaults are the thing to look at. Without --s5p there is no password authentication, and without --s5u the account name is anonymous. On a public server that means an open proxy for anyone who discovers the port, so set both:

fuc --socks --su --s5p 123 --s5u socks

Note that this example also enables UDP forwarding, which widens the exposure beyond HTTP and TCP. Whether that is acceptable is a network decision rather than a tooling one.

The feature table marks basic forwarding, transport encryption, SOCKS5, SOCKS5 UDP forwarding, KCP support, multiple mappings, cascading proxy, data compression, RSA encryption and AES encryption as achieved, and websocket as not implemented.

Cascading and bridge mode, and the UDP limitation in between

Bridge mode is how you chain fuso instances across more than one hop. One side listens with --bridge-listen and --bridge-port, and the other connects by giving the address and port positionally, so fuc --bridge-listen 0.0.0.0 --bridge-port 9999 on the machine at 10.10.10.2 is joined by fuc 10.10.10.2 9999 elsewhere.

The cascade example in the README chains three: the first level listens on 9999 at 10.10.10.2, the second listens on 9991 at 10.10.10.3 and connects back to 10.10.10.2 9999, and the third connects to 10.10.10.3 9991.

The limitation is stated in the heading of that section: bridge mode cannot forward UDP at present. That is a real asymmetry, since the SOCKS5 mode does support UDP. A chain that needs game traffic or a QUIC connection will not work through the bridge path.

The listen address defaults to 127.0.0.1, and the bridge port defaults to disabled, so bridge mode is entirely opt-in.

Rust with tokio, smol and axum, mostly as optional features

The Cargo manifest is where the engineering is legible. The package is fuso at version 1.0.5-beta on edition 2021, with a build.rs and a cc build dependency, which is how the kcp C library gets compiled in.

Almost every dependency is optional. tokio at 1.17 with the full feature set, smol as an alternative async runtime, futures, serde with derive, bincode for serialisation, axum 0.5.1 for the HTTP surface, toml 0.5.9 for configuration, and clap 3.1.8 for the command line. That pattern says one binary can be built with only the pieces a given mode needs, and the topic tags list both tokio and smol, so more than one runtime is genuinely supported.

The cryptographic dependencies are rsa 0.6.1, aes 0.8.1 and cbc 0.1.2, which matches the RSA and AES entries in the feature table. lz4 handles the compression claim and kcp comes from an external project listed under External, alongside the SOCKS specification documents rfc1928 and rfc1929 checked into the repository.

One dependency worth flagging in the base set is async-mutex 1.4.0, which is not optional.

A server-side observer hook, and the CLI shape

fus takes an --observer option that takes a program and its arguments, and runs it when a connection is established or dropped. The README's example passes a bash script that notifies a Telegram channel, so fuc starting successfully can be announced to you rather than discovered by trial and error.

That hook is the operational substitute for a web panel. The README lists what is still to be improved, and two entries there are the web management panel and webhooks, alongside forward proxying, stream forwarding and documentation corrections. In other words, there is a command line hook for connection events but no HTTP interface for managing tunnels.

The forward proxy row is worth noting too. A reverse tunnel that you initiate from inside your network is a different shape from a forward proxy where the server initiates outbound connections, and Fuso does not claim the latter.

The command line interface is generated with clap's derive feature, and the flag naming is consistent: long flags with the double dash, several with short forms such as -b, --bl and --bp as aliases.

Release state, licence tension and the author's usage note

The repository is not archived and the last push was on 2026-04-22, but the default branch is refactor/dev, which tells you the released binaries and the current source may differ. Tagged releases are far older: v1.0.5-beta.7 from 2022-08-30, v1.0.5-beta.6 from 2022-08-14 and v1.0.4-beta.5 from 2021-12-18. The first of those carries the tag name v1.0.5-beta.7 while its release title reads v1.0.4-beta.7, which is the kind of inconsistency worth checking against the tag before you download.

The license is GPL-3.0, which permits commercial use. That sits awkwardly with the note at the end of the README, which states the technologies are for learning and exchange and asks that they not be used directly in commercial settings or for illegal purposes. GPL-3.0 is what governs the code; the note is the author's request, and if your use is commercial you have two conflicting signals and should resolve that before deploying it rather than after.

There is also no homepage listed. Documentation lives in doc/ inside the repository.

Editorial conclusion

Fuso fits a developer who already owns a public server and wants to expose one or two local services without installing anything on a router, and who is comfortable with a beta tool. Do not put it on a production path: the newest tagged release is v1.0.5-beta.7 from 2022-08-30, the default branch is refactor/dev, and the README lists a web panel and forward proxy as still to be done. Before using it, note that the README asks you not to use it in commercial settings even though the GPL-3.0 license permits it, and set an explicit --s5u and --s5p because SOCKS5 defaults to the anonymous account with no password.

Frequently asked questions

Official sources

1. editso/fuso on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases